https://www.percona.com/blog/2015/12/02/gtid-failover-with-mysqlslavetrx-fix-errant-transactions/

使用GTID复制时,Errant transactions是一个主要问题。 虽然这不是什么新鲜事,但GTID的缺点比常规复制更为臭名昭着。
错误的事务让您感到困难的是一个常见的DBA任务:故障转移。 现在像MHA这样的工具已经支持GTID复制(从0.56版本开始),这个协议变得越来越流行了,错误事务也是如此。 幸运的是,修复就像向空缺事务的数据库注入一个空的事务一样简单。 您可以轻松地通过master做到这一点,它会传播给所有的slaves。
我们来考虑以下情况:

     当master吹到空中并且不在画面中时会发生什么?
     当不只有一个而是几十个错误的事务时会发生什么?
     当你有大量的slaves时会发生什么?

事情开始变得更复杂一点。

第一种情况的附注:当你的master不在时,你怎么找到错误的事务? 那么,你不能。 在这种情况下,你应该检查你的slave和你以前的slave/即将成为master之间的错误事务。

让我们考虑替代品。 什么是每个单一的slave注入每个错误的事务空交易的解决方法是什么? MySQL实用程序mysqlslavetrx。 基本上,这个工具允许我们在一个步骤中跳过多个slave上的多个事务。

安装MySQL实用程序的一种方法是执行以下步骤:

  • wget http://dev.mysql.com/get/Downloads/MySQLGUITools/mysql-utilities-1.6.2.tar.gz
  • tar -xvzf mysql-utilities-1.6.2.tar.gz
  • cd mysql-utilities-1.6.2
  • python ./setup.py build
  • sudo python ./setup.py install

你准备好了

那么一些例子呢? 假设我们有一个GTID复制的主/从服务器,当前状态如下:

mysql> show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000002 | 530      |              |                  | 66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
mysql> show slave statusG
...
Executed_Gtid_Set: 66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2
Auto_Position: 1
1 row in set (0.00 sec)

向新的模式添加混乱的slave:

mysql> create database percona;
Query OK, 1 row affected (0.00 sec)
 
Now we have an errant transaction!!!!!
 
The slave status looks different:
 
mysql> show slave statusG
...
Executed_Gtid_Set: 66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2,
674a625e-976e-11e5-a8fb-125cab082fc3:1
Auto_Position: 1
1 row in set (0.00 sec)
 
通过使用GTID_SUBSET函数,我们可以确认事情从“好”到“不好”:
 
 
Before:
mysql> select gtid_subset('66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2','66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2') as is_subset;
+-----------+
| is_subset |
+-----------+
| 1         |
+-----------+
1 row in set (0.00 sec)
 
After:
mysql> select gtid_subset('66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2,674a625e-976e-11e5-a8fb-125cab082fc3:1','66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2') as is_subset;
+-----------+
| is_subset |
+-----------+
| 0         |
+-----------+
1 row in set (0.00 sec)
 
好吧,这是一团糟,明白了。 什么是错误的事务? GTID_SUBTRACT函数会告诉我们:
mysql> select gtid_subtract('66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2,674a625e-976e-11e5-a8fb-125cab082fc3:1','66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2') as errand;
+----------------------------------------+
| errand                                 |
+----------------------------------------+
| 674a625e-976e-11e5-a8fb-125cab082fc3:1 |
+----------------------------------------+
1 row in set (0.00 sec)
 
这个函数有两个参数,第一个写 show slave status 查出的所有Executed_Gtid_Set, 第二个参数写Executed_Gtid_Set 中正常的事务,可参考Retrieved_Gtid_Set
 
解决这个问题的经典方法是注入一个空的事务:
mysql> SET GTID_NEXT='674a625e-976e-11e5-a8fb-125cab082fc3:1';
Query OK, 0 rows affected (0.00 sec)
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> SET GTID_NEXT='AUTOMATIC';
Query OK, 0 rows affected (0.00 sec)
 
在此之后,错误的事务将不再是错误的。
 
mysql> show master status;
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                                                |
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
| mysql-bin.000002 | 715      |              |                  | 66fbd3be-976e-11e5-a8fb-1256731a26b7:1-2,
674a625e-976e-11e5-a8fb-125cab082fc3:1                                                                                                             |
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
1 row in set (0.00 sec)
 
好吧,让我们再添加一个slave。 现在是mysqlslavetrx工具变得非常方便的时刻。
 

What you need to know is:

  • The slave’s IP address
  • The GTID set

It will be simple to execute:

 

mysqlslavetrx --­­gtid­-set=6aa9a742­8284­11e5­a09b­12aac3869fc9:1­­ --verbose ­­--slaves=user:password@172.16.1.143:3306,user:password@172.16.1.144

 

gtid-set 写 所有slave上select gtid_subtract 查出来的事务

详细的输出将看起来像这样:

# GTID set to be skipped for each server:
# ­- 172.16.1.143@3306: 6aa9a742­8284­11e5­a09b­12aac3869fc9:1
# ­- 172.16.1.144@3306: 6aa9a742­8284­11e5­a09b­12aac3869fc9:1 #
# Injecting empty transactions for '172.16.1.143:3306'...
# ­- 6aa9a742­8284­11e5­a09b­12aac3869fc9:1
# Injecting empty transactions for '172.16.1.144:3306'...
# ­- 6aa9a742­8284­11e5­a09b­12aac3869fc9:1 #
#...done.
#

 

你可以从任何地方(master或slave)运行mysqlslavetrx。 您只需确保用户名和密码是有效的,并具有设置gtid_next变量所需的SUPER权限。

总结:利用MySQL实用程序。 在这种特殊情况下,使用GTID复制时,mysqlslavetrx非常有用,并且您希望执行干净的故障转移。 它可以作为MHA故障切换的前置脚本(自0.56版本以来支持GTID)添加,也可以简单地用于维护主站和从站之间的一致性。