1. GTID = source_id:transaction_id

The source_id identifies the originating server
The transaction_id is a sequence number determined by the order in which the transaction was committed on this server

source_id 用来识别 transaction的<orginating server>
transaction_id 是一个 sequence number

3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
a sequence of GTIDs originating from the same server may be collapsed into a single expression

gtid_set
uuid_set [, uuid_set] ...

uuid_set:
uuid:interval[:interval]...

uuid:
hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh

h:
[0-9|A-F]

interval:
n[-n]
(n>=1)

once a transaction with a given GTID is committed on a given server, any subsequent transaction having the same GTID is ignored by that server. Thus, a transaction committed on the master can be applied no more than once on the slave, which helps to guarantee consistency.

The generation and lifecycle of a GTID consists of the following steps:

1. a transaction is executed and committed on the master
   his transaction is assigned a GTID using the master's UUID and the smallest nonzero transaction sequence number not yet used on this server; the GTID is written to the master's binary log (immediately preceding the transaction itself in the log).

2. After the binary log data is transmitted to the slave and stored in the slave's relay log. the slave reads the GTID and sets the value of its gtid_nextsystem variable as this GTID. This tells the slave that the next transaction must be logged using this GTID.
   The slave sets gtid_next in a session context.

3. The slave checks to make sure that this GTID has not already been used to log a transaction in its own binary log,Because gtid_next is not empty, the slave does not attempt to generate a GTID for this transaction but instead writes the GTID stored in this variable