MTSレプリケーションのデッドロック

Question

状況：

Percona MySQL 5.6.32-78.1でGTIDを使用したマスター - マスターレプリケーションがあります。サーバー上には約10のデータベースがあり、slave_parallel_workers=5と設定しています。 1つのサーバーがフロントエンド処理に使用され、1つがバックエンドに使用されます。 2〜3回、週、バックエンドサーバー上のレプリケーションは、エラーの理由かもしれない何

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を使用すると、データベースごとに1つのスレッドしか使用されませんでした（MTSの利点はいくつかのデータベースで並列レプリケーションを使用しているためです）。なぜレプリケーションはデッドロックで壊れますか？

EDIT 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

すべてのセッションはフロントエンドサーバーで作成されていると思います。バックエンドサーバー上にセッションクリーンアップジョブがありますか？つまり、両方のマシンからテーブルに書き込みがあります。セッションとして書き込み重いテーブルを持っている場合は、このようなデッドロックを避けるために、1つのマシンに書き込む必要があります。

実際には、フェイルオーバーの場合を除いて、1つのマスターですべての書き込みを行う必要があります。

ハプロキシとヘルスチェックを使用すると、フェールオーバーが自動的に処理され、クライアントにとってトランスペアレントになるという素晴らしい設定があります。