errant-transactions

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）添加，也可以简单地用于维护主站和从站之间的一致性。