Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
-
MXS-SPRINT-187
Description
MaxScale's binlogrouter:
MariaDB [(none)]> show slave status \G
|
Slave_IO_State: Reconnecting after a failed primary event read
|
Master_Host: x.y.z.w
|
Master_User: maxscaleuser
|
Master_Port: 3306
|
Connect_Retry: 1
|
Master_Log_File: mariadb_bin_log.000123
|
Read_Master_Log_Pos: 123456789
|
Master_Log_File & Read_Master_Log_Pos refer to the local maxscale's coordinates while the standard MariadB behaviour would report the Master's binary log coordinates.
Apart from consistency, without such info is difficult to read the Master binlog events since neither SHOW BINLOG EVENTS nor mysqlbinlog support GTID.
Some considerations on where to report MaxScale's local coordinates:
|
Master_Log_File: READ FILE Primary
|
Read_Master_Log_Pos: READ POS Primary
|
|
Relay_Log_File: EXEC FILE Local/Replica
|
Relay_Log_Pos: EXEC POS Local/Replica
|
|
Relay_Master_Log_File: EXEC FILE Primary Note: Slave might be lagging
|
Exec_Master_Log_Pos: EXEC FILE Primary Note: Slave might be lagging
|
|
n/a: WRIT'N FILE Local/Replica *** MISSING ***
|
n/a: WRIT'N POS Local/Replica *** MISSING ***
|
What's historically missing in the output is what is the position written in Local Relay log Coordinates
On a Slave where the Slave thread is stopped you will see a static (Relay_Log_File,Relay_Log_Pos) but the slave is most probably keep writing the relay log.
MaxScale does not execute but just read and write the Master events, so it's compatible with having only one set of "Relay" Coordinates.
In theory the right place to report maxscale write log coordinates would be in the missing fields.
If we have to keep the standard output then the second choice would be Relay_Log_File/Relay_Log_Pos (even if that's not really the exec position but rather the written position)