Global Transaction ID
GTID = source_id:transaction_id
source_id＝＝＞the originating server. Normally, the server's server_uuid is used for this purpose
transaction_id＝＝＞a sequence number determined by the order in which the transaction was committed on this server
■A global transaction identifier (GTID) is a unique identifier created and associated with each transaction when it is committed on the server of origin (master). This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication setup. There is a 1-to-1 mapping between all transactions and all GTIDs.
＝＝＞ all servers in a given replication setup？
これがあれば、いろいろ細かくコントロールできるよね。。
でも、それなりのハードルよりも、リスクだね。。
＝＞In MySQL 5.6.6 and later, this format is also used to supply the argument required by the START SLAVE options SQL_BEFORE_GTIDS and SQL_AFTER_GTIDS.
■GTIDs are always preserved between master and slave. This means that you can always determine the source for any transaction applied on any slave by examining its binary log. In addition, 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.
＝＝＞まぁ。。それはそうだね。。当たり前
■From the perspective of the database administrator or developer, GTIDs entirely take the place of the file-offset pairs previously required to determine points for starting, stopping, or resuming the flow of data between master and slave. This means that, when you are using GTIDs for replication, you do not need (or want) to include MASTER_LOG_FILE or MASTER_LOG_POS options in the CHANGE MASTER TO statement used to direct a slave to replicate from a given master; in place of these options, it is necessary only to enable the MASTER_AUTO_POSITION option introduced in MySQL 5.6.5.
＝＝＞これだよ！
■流れ
１A transaction is executed and committed on the master.
＝＞This 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
２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_next system variable as this GTID. This tells the slave that the next transaction must be logged using this GTID.
It is important to note that the slave sets gtid_next in a session context.
３The slave checks to make sure that this GTID has not already been used to log a transaction in its own binary log. If and only if this GTID has not been used, the slave then writes the GTID and applies the transaction (and writes the transaction to its binary log). By reading and checking the transaction's GTID first, before processing the transaction itself, the slave guarantees not only that no previous transaction having this GTID has been applied on the slave, but also that no other session has already read this GTID but has not yet committed the associated transaction. In other words, multiple clients are not permitted to apply the same transaction concurrently.
==>いちいちチェックする？
４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?that is, the GTID obtained from the master?immediately preceding the transaction in its binary log
■そのおかげさまで、メリットいろいろ。。悩みは？リスクは？
・Binary Log Group Commit
A significant improvement to replication performance has been enabled by the introduction of Binary Log Group Commit which groups writes to the Binlog,
rather than applying them one at a time.This enhancement significantly improves the performance of the replication master.
・Multi-Threaded Slaves
Slaves are better able to keep up with the master
・Optimized Row Based Replication
・The power of GTIDs are fully realized when used with the new MySQL replication utilities
mysqlfailover
mysqlrpladmin
・crash safe
The binlog and table data are transactionally consistent when using a transactional storage engine, and so the slave can automatically roll back replication to the last committed event before a crash, and resume replication without administrator intervention. Not only does this reduce operational overhead, it also eliminates the risk of data loss or corruption caused by the failure of a slave.
If a crash to the master causes corruption of the binary log, the server will automatically recover it to a position where it can be read correctly.
・チェックのメカニズムもあり、いろいろsmartでになるね