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和运行状况检查可以很好地设置故障转移，以便为客户自动和透明地处理故障转移。

MTS复制的死锁

1 个答案: