MySQL GTID replication 理解深め

★gtid_mode must be ON on all servers or OFF on all servers
★GSo once GTIDs are enabled on all servers, you can have some slaves using file-based positioning and some other slaves using GTID-based positioning.


★GTID関係するパラメータ
mysql> show variables like '%gtid%';
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| enforce_gtid_consistency | ON        |
| gtid_executed            |           |
| gtid_mode                | ON        |
| gtid_next                | AUTOMATIC |
| gtid_owned               |           |
| gtid_purged              |           |
+--------------------------+-----------+


★START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56
START SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56


★START SLAVE UNTIL SQL_AFTER_MTS_GAPS
==>his statement causes a multi-threaded slave's SQL threads to run until no more gaps are found in the relay log, and then to stop
START SLAVE UNTIL SQL_AFTER_MTS_GAPS should be used before switching the slave from multi-threaded mode to single-threaded mode (that is, when resetting slave_parallel_workers back to 0 from a positive, nonzero value) after slave has failed with errors in multi-threaded mode.

ーーーーーーーーーーー
START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.slave_parallel_workers = 0;
START SLAVE SQL_THREAD;
ーーーーーーーーーーー


★MySQL Utilities Launchpad page. ＝＝＞python?


★enable GTID replication for an easier rollback in the event of a problem?
どうやる？？？

★show global variables like 'gtid_executed';
+---------------+--------------------------------------------+
| Variable_name | Value                                      |
+---------------+--------------------------------------------+
| gtid_executed | d3acef65-d68e-11e3-b9f4-08002760d1b6:1-981 |




+---------------+--------------------------------------------+

★オペレーション

・当一个slave连接到master, 这个新的协议将确保GTIDs的范围是slave已经执行的和已提交但请求丢失的事务. 这个master然后发送除此以外的其它事务, 也就是那些slave还没有执行的.＝＝＞依慢的状况为准 ！自动比较！

有了一个可靠的slave升级基础, 确保任何的事务在slave上都会被执行并且不会因为master的事件丢失而丢失

★The only part were we should pay attention is the server we choose for promotion: if it is not up-to-date, data may be lost or replication may be broken.

★SLAVE出错了，不知道什么原因。。GRID模式下，大部分都是自动的，变量也是只读的。。。

由于运行在GTID模式，所以不支持sql_slave_skip_counter语法

set global gtid_executed=''; set global gtid_purged=''

ERROR 1238 (HY000): Variable 'gtid_executed' is a read only variable

在SLAVE上！

Reset master

Stop slave

Reset slave

还记得刚才的gtid_purged那个点吗，只需重新设置下一个点即可

è????!!

set global gtid_purged='cf716fda-74e2-11e2-b7b7-000c290a6b8f:1-141';

★auto_position=0 时，很简单根据指定的 binlog 文件和偏移量， Master 将 binlog 中的各个数据变更事务发送给备库就好了。备库接收到对应的事务，判断是否本机发起的 ( 通过数据变更事务记录的 server_id 来判断 ) ，如果不是本机发起的，就直接执行。
在 auto_position=1 时，备库将自己的 gtid_executed 的事务集合传给 Master ， Master 找到第一个包含有非备库 gtid_executed 事务集中数据变更的 binlog ，将 binlog 中的各个 event 发送给备库。这样备库首先判断是否本机发起的，然后判断发送过来的各个数据变更事务是否在本机执行过。没有执行过的事务都需要在本地执行一遍。

★Retrieved_Gtid_Set 记录的是 IO thread 从主库拿到的事务集合

★回想一下，我们之前做的操作：手工删除了 binlog 日志和 binlog index 文件，然后启动了 MySQL 。这个操作在没有启动 GTID 的 MySQL 上，我们也做过类似的事情，备库并没有复制丢失的问题。我们手工删除了 binlog 以后，数据库会自动生成 binlog 。但是在 Master 中，它重新从 9300dd57-51da-11e3-989d-3cd92bee36a8:1 第一个事务开始计数。从另外一个侧面来说，已经执行完的 GTID 集合， MySQL 并没有单独保存，而是通过 Binlog 来获得的。
备库已经执行完了 9300dd57-51da-11e3-989d-3cd92bee36a8 :1 - 28123 这些事务。所以当 SQL thread 拿到从主库复制过来的变更事务时，发现这些事务都是它已经执行过的事务，那么它就不会再重复执行，从而导致对应的这些事务都会被丢失掉。如果在某种情况下，我们确实需要在手工删除，并启动数据库，建议同时将 auto.cnf 清理掉。这样主库会生成新的 UUID ，备库发现是新的事务就会执行这个变更了。

★LOAD DATA FROM MASTER;
LOAD TABLE TBLNAME FROM MASTER;