MTS 复制死锁

Deadlock on MTS replication

情况:

我们在 Percona MySQL 5.6.32-78.1 上使用 GTID 进行了主对主复制。在服务器上,大约有 10 个数据库,我们设置了 slave_parallel_workers=5。一台服务器用于前端处理,另一台用于后端。每周两三次,后端服务器上的复制因错误而死亡

2016-10-25 10:00:01 165238 [Warning] Slave SQL: Worker 4 failed executing transaction '0e7b97a8-a689-11e5-8b79-901b0e8b0f53:22506262' at master log mysql-bin.011888, end_log_pos 9306420; Could not execute Update_rows event on table shop.sessions; Deadlock found when trying to get lock; try restarting transaction, Error_code: 1213; handler error HA_ERR_LOCK_DEADLOCK; the event's master log mysql-bin.011888, end_log_pos 9306420, Error_code: 1213 2016-10-25 10:00:01 165238 [ERROR] Slave SQL: ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756 2016-10-25 10:00:01 165238 [Note] Error reading relay log event: slave SQL thread was killed

可能是什么原因?没有跨数据库 DML 语句,我想通过使用 MTS,每个数据库只使用一个线程(MTS 的好处是使用跨多个数据库的并行复制)?为什么复制会因死锁而中断?

编辑 2016-10-28:

table 的架构看起来像

CREATE TABLE `sessions` (
  `id` int(11) NOT NULL,
  `session_id` char(40) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `crypt_iv` blob NOT NULL,
  `data` mediumblob NOT NULL,
  `user_id` int(11) NOT NULL,
  `last_refresh` datetime NOT NULL,
  `timeout` datetime NOT NULL,
  `closed` tinyint(4) NOT NULL,
  `inserted` datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `sessions`
  ADD PRIMARY KEY (`id`),
  ADD UNIQUE KEY `session_id` (`session_id`),
  ADD KEY `user_id` (`user_id`),
  ADD KEY `timeout` (`timeout`);
ALTER TABLE `sessions` MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;

当时这个错误只发生在后端,从来没有发生在前端服务器上。目前我无法粘贴确切的语句,因为二进制日志已被清除。但是此 GTID 事务中的唯一语句是 table.

上的基于行的更新

我想所有会话都是在前端服务器上创建的。后端服务器上是否有会话清理作业?所以你在两台机器上都写了 table 。如果你有一个写重 table 的会话,你应该只在一台机器上写它以避免这种死锁。

实际上,您应该始终只在一台机器上执行所有写入操作,故障转移情况除外,当一个主机出现故障时。

haproxy 和运行状况检查有很好的设置,可以自动处理故障转移并且对您的客户透明。