MTS 复制死锁

Question

情况：

我们在 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：

表的架构看起来像

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 事务中唯一的语句是对表的基于行的 UPDATE。

Answer 1

我猜所有的会话都是在前端服务器上创建的。后端服务器上是否有会话清理工作？所以你在两台机器上都有写。如果您有一个写入繁重的表作为会话，您应该只在一台机器上编写它以避免这种死锁。

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

有一些不错的设置，带有 haproxy 和运行状况检查，可以自动处理故障转移，并且对您的客户透明。