Shulou(Shulou.com)06/01 Report--

GTID-based replication, in the initialization phase, the Slave node will send the received and submitted GTID collection information to the Master node. This GTID set is equivalent to the union of the next two GTID sets, @ @ GLOBAL.gtid_executed + performance_schema.replication_connection_status.RECEIVED_TRANSACTION_SET.

The Master node compares the GTID collection information sent by the Slave node, and then sends all the GTID collections recorded in the existing binary log files that have not been executed on the Slave node to the Slave node.

So how does the Master node compare the GTID collection information sent by the Slave node?

Master nodes will classify GTID sets according to their own UUID, and calculate the difference sets of similar GTID sets respectively. In this session, if the Master node finds that there are more types of UUID in the GTID collection sent by the Slave node than the UUID on itself, the Master node will ignore the situation and the replication logic will continue.

The actual example is as follows, and replication in this case is normal.

GTID collection information on the Master node:

[root@mysql.sock] [db1] > show master status\ G

* * 1. Row *

File: bin.000002

Position: 796

Binlog_Do_DB:

Binlog_Ignore_DB:

Executed_Gtid_Set: 0c34233d-b2e1-11e9-85cf-080027f22add:1-2

4fdc13e1-b59e-11e9-b5e0-080027f22add:1-2

1 row in set (0.01 sec)

GTID collection information on the Slave node:

[root@mysql.sock] [lg] > show master status\ G

* * 1. Row *

File: bin.000004

Position: 832

Binlog_Do_DB:

Binlog_Ignore_DB:

Executed_Gtid_Set: 32a0c858-b59f-11e9-b069-0800270c3d91:1-2

447e96e1-b59f-11e9-95fe-0800270c3d91:1-2

B8282f18-b59e-11e9-83b0-0800270c3d91:1-5

1 row in set (0.00 sec)

After the replication relationship is established, the collection information on the Slave node:

[root@mysql.sock] [lg] > show master status\ G

* * 1. Row *

File: bin.000004

Position: 1763

Binlog_Do_DB:

Binlog_Ignore_DB:

Executed_Gtid_Set: 0c34233d-b2e1-11e9-85cf-080027f22add:1-2

32a0c858-b59f-11e9-b069-0800270c3d91:1-2

447e96e1-b59f-11e9-95fe-0800270c3d91:1-2

4fdc13e1-b59e-11e9-b5e0-080027f22add:1-2

B8282f18-b59e-11e9-83b0-0800270c3d91:1-5

1 row in set (0.00 sec)

If the Master node finds that the GTID corresponding to the same UUID on the Slave node is more than the GTID on itself, then the Master node will send an error ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER to the Slave node.

The actual example reports an error as follows:

Last_IO_Errno: 1236 (MySQL error code 1236 (ER_MASTER_FATAL_ERROR_READING_BINLOG): Got fatal error% d from master when reading data from binary log:'%-.320s')

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g.after a power or disk failure when sync_binlog! = 1. The master may or may not have rolled back transactions that were already replica'

Last_SQL_Errno: 0

Or the Master node finds that the GTID has been deleted in the difference set of the GTID set with the same UUID, and then the Master node will send an ER_MASTER_HAS_PURGED_REQUIRED_GTIDS error to the Slave node.

The actual example reports an error as follows:

Last_IO_Errno: 1236

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

Last_SQL_Errno: 0

After the above logic, the Master node is finally able to send the GTID set (difference) needed by the Slave node, and replication begins.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.