5-Slave registration
The slave server, when properly configured with CHANGE MASTER TO ...
can start the MariaDB replication with the command START SLAVE
After authentication, some COM_QUERY packets are exchanged before sending
COM_REGISTER_SLAVE and COM_BINLOG_DUMP
The following COM_QUERY packets com from MariaDB 10.X slave using GTID
- SELECT UNIX_TIMESTAMP()
- SHOW VARIAB LES LIKE 'SERVER_ID'
- SET @master_heartbeat_period= 30000001024
- SET @master_binlog_checksum= @@global.binlog_checksum
- SELECT @master_binlog_checksum
- SET @mariadb_slave_capability=4
- SELECT @@GLOBAL.gtid_domain_id Part of GTID registration
- SET @slave_connect_state='0-10201-9868' The requested GTID from the slave
- SET @slave_gtid_strict_mode=0 Part of GTID registration
- SET @slave_gtid_ignore_duplicates=0 Part of GTID registration
Then COM_REGISTER_SLAVE completes the registration.
The COM_BINLOG_DUMP marks the request of binlog events stream
Note
If semi-sync is in use, the request for the network protocol change
is sent between COM_REGISTER_SLAVE and COM_BINLOG_DUMP
Example using 'ngrep' utility:
COM_REGISTER_SLAVE, semi-Sync and COM_BINLOG_DUMP
T 127.0.0.1:42158 -> 127.0.0.1:23240 [AP] 1a 00 00 00 15 75 27 00 00 08 53 42 73 6c 61 76 .....u'...SBslav 65 31 00 00 c9 5a 00 00 00 00 00 00 00 00 e1...Z........ T 127.0.0.1:23240 -> 127.0.0.1:42158 [AP] 07 00 00 01 00 00 00 02 00 00 00 ........... T 127.0.0.1:42158 -> 127.0.0.1:23240 [AP] 33 00 00 00 03 53 48 4f 57 20 56 41 52 49 41 42 3....SHOW VARIAB 4c 45 53 20 4c 49 4b 45 20 27 72 70 6c 5f 73 65 LES LIKE 'rpl_se 6d 69 5f 73 79 6e 63 5f 6d 61 73 74 65 72 5f 65 mi_sync_master_e 6e 61 62 6c 65 64 27 nabled' T 127.0.0.1:23240 -> 127.0.0.1:42158 [AP] 01 00 00 01 02 64 00 00 02 03 64 65 66 12 69 6e .....d....def.in 66 6f 72 6d 61 74 69 6f 6e 5f 73 63 68 65 6d 61 formation_schema 11 53 45 53 53 49 4f 4e 5f 56 41 52 49 41 42 4c .SESSION_VARIABL 45 53 11 53 45 53 53 49 4f 4e 5f 56 41 52 49 41 ES.SESSION_VARIA 42 4c 45 53 0d 56 61 72 69 61 62 6c 65 5f 6e 61 BLES.Variable_na 6d 65 0d 56 41 52 49 41 42 4c 45 5f 4e 41 4d 45 me.VARIABLE_NAME 0c 08 00 40 00 00 00 fd 01 00 00 00 00 5d 00 00 ...@.........].. 03 03 64 65 66 12 69 6e 66 6f 72 6d 61 74 69 6f ..def.informatio 6e 5f 73 63 68 65 6d 61 11 53 45 53 53 49 4f 4e n_schema.SESSION 5f 56 41 52 49 41 42 4c 45 53 11 53 45 53 53 49 _VARIABLES.SESSI 4f 4e 5f 56 41 52 49 41 42 4c 45 53 05 56 61 6c ON_VARIABLES.Val 75 65 0e 56 41 52 49 41 42 4c 45 5f 56 41 4c 55 ue.VARIABLE_VALU 45 0c 08 00 00 08 00 00 fd 01 00 00 00 00 05 00 E............... 00 04 fe 00 00 22 00 20 00 00 05 1c 72 70 6c 5f .....". ....rpl_ 73 65 6d 69 5f 73 79 6e 63 5f 6d 61 73 74 65 72 semi_sync_master 5f 65 6e 61 62 6c 65 64 02 4f 4e 05 00 00 06 fe _enabled.ON..... 00 00 22 00 ..". T 127.0.0.1:42158 -> 127.0.0.1:23240 [AP] 1c 00 00 00 03 53 45 54 20 40 72 70 6c 5f 73 65 .....SET @rpl_se 6d 69 5f 73 79 6e 63 5f 73 6c 61 76 65 3d 20 31 mi_sync_slave= 1 T 127.0.0.1:23240 -> 127.0.0.1:42158 [AP] 07 00 00 01 00 00 00 02 00 00 00 ........... T 127.0.0.1:42158 -> 127.0.0.1:23240 [AP] 1b 00 00 00 12 34 06 00 00 02 00 75 27 00 00 6d .....4.....u'..m 79 73 71 6c 2d 62 69 6e 2e 30 30 30 30 33 34 ysql-bin.000034
In the example we clearly see these two COM_QUERY commands:
- SHOW VARIABLES LIKE 'rpl_semi_sync_master_enabled'
- SET @rpl_semi_sync_slave= 1
are sent just after COM_REGISTER_SLAVE and before COM_BINLOG_DUMP
The MariaDB 10.x Master always sends, after the COM_BINLOG_DUMP:
- FAKE_ROTATE_EVENT (with current filename and pos)
- FORMAT_DESCRIPTION_EVENT:
Next Pos in the header is set to 0 if not requesting binlog file form the beginning
otherwise Next Pos is related to next event after FDE - FAKE_GTID_LIST_EVENT with latest GTID information.
After those first events, the master sends to connected slave binlog events related to changes in database.
The slave is just waiting for new events from master.
