Analysis of Gtid in MySQL master-slave replication

Gtid (global Transaction ID) is the number of a committed transaction and is a globally unique number. Its official definition is as follows:
Gtid= source_id:transaction_id

Each of the Gtid represents a database transaction. In the above definition, source_id represents the main library uuid (SERVER_UUID) that executes the transaction, and TRANSACTION_ID is a 1-based self-increment count that represents the nth transaction executed on the main library. MySQL guarantees the global uniqueness of gtid by ensuring that each database is server_uuid globally unique, and that each database generates a unique transaction_id itself.
In the context of Gtid's master-slave replication, performing show slave status\g on Slave can see the following information:

mysql> show slave status\G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event...             Slave_IO_Running: Yes            Slave_SQL_Running: Yes...           Retrieved_Gtid_Set: b5e3d908-fa6d-11e7-b931-06f990000100:1-3            Executed_Gtid_Set: b5e3d908-fa6d-11e7-b931-06f990000100:1-3                Auto_Position: 11 row in set (0.00 sec)

Retrieved_gtid_set represents the Gtid Set slave received from master, which can be emptied using the reset slave command;
Executed_gtid_set represents the Gtid Set that slave has executed and can be emptied with the Reset Master command.
Retrieved_gtid_set and Executed_gtid_set must be a subset of the Gtid Set on master, otherwise the following error will be reported:

mysql> show slave status\G*************************** 1. row ***************************...                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‘...1 row in set (0.00 sec)

When the slave is stopped and then started again, the following actions are performed:
1. Read the Gtid set on master (assuming set a)
2. Compare set A with its own retrieved_gtid_set (assumed set B) and execute a A-C transaction to maintain synchronization with master .

This is to be affixed to the verification of the operation, but the 51cto blog table display is very unfriendly, so the work of validation to everyone ~ ^o^

Analysis of Gtid in MySQL master-slave replication