mysql5.6gtidレプリケーションスレーブスタック(システムロック)?
https://dba.stackexchange.com/questions/117068
-
29-09-2020 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私は5.6gtidベースのレプリケーションを設定しました（5.6.26で）それは私がそれをしたときに動作するように見えました、それは私が通常のデータの横にしかし、私が見るのはこれだけなので、ある時点で何かが起こったに違いありません:
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: System lock
Master_Host: xxxxxxxxxxxxxxxxxx
Master_User: xxxxxxxxxxxxxxxx
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysqld-bin.000141
Read_Master_Log_Pos: 169293671
Relay_Log_File: mysqld-relay-bin.000003
Relay_Log_Pos: 16861206
Relay_Master_Log_File: mysqld-bin.000141
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 16860994
Relay_Log_Space: 169298584
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 55203
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 7846a847-62c7-11e5-91a6-e06995de432e
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: System lock
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274
Auto_Position: 1
もともと「Slave_Sql_Running_State」は「リレーログからイベントを読み取る」などと言っていましたが、システムロックにも変更されました（IO状態は常にそう言いました）。
それはそうです Seconds_Behind_Master ファイルシステム上ではリレーログのサイズが急速に大きくなりますが、リレーログは着実に増加しています。 Executed_gtid_set 変化しているように見えますが、それはあまりにも遅れているので、まだ何かが間違っているようです。...
ここにプロセスリストがあります:
mysql> show processlist; +------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+ | 1877 | root | localhost | NULL | Sleep | 6076 | | NULL | | 1878 | root | localhost | NULL | Query | 0 | init | show processlist | | 1886 | system user | | NULL | Connect | 783 | System lock | NULL | | 1887 | system user | | NULL | Connect | 0 | System lock | NULL | | 1888 | system user | | NULL | Connect | 783 | Waiting for an event from Coordinator | NULL | | 1889 | system user | | NULL | Connect | 55455 | System lock | NULL | +------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
私はスレーブを停止して再び起動しようとしましたが、それは助けにはなりませんでした。
誰かが私がこの作品を再び作ることを試みることができる何かアイデアを持っていますか？非常に高く評価されるだろう。
ありがとう！
解決
私は2よりも多くを参照してくださいので system user processlistのエントリでは、マルチスレッドレプリケーションを使用していると仮定します（slave_parallel_workers > 1).
それはバグのように見えます
Oct29、2014では、これは次のように表現されました David Moss
あなたのフィードバックをありがとう。この問題はバグ17326020でカバーされており、MySQL5.6.21および5.7.5の変更ログに次のものが追加されました:
I/OスレッドがGtidを使用してマスターに再接続されたとき トランザクションの途中でマルチスレッドスレーブが失敗しました トランザクションを中止し、リレーに部分的なトランザクションを残すには ログに記録し、同じトランザクションを再度取得します。これが発生しました リレーログのローテーションを行う場合。今、再接続するとき, このような場合、サーバーはログをローテーションする前にチェックし、待機します 最初に進行中のトランザクションが完了するために。
したがって、このバグをカバーするために新しいものは何も追加されず、修正されたように閉じています。
Dec10,2014では、これは次のように表現されました Laurynas Biveinis
問題:
MTS、Gtidおよび自動位置決めが有効になっている場合、作業者がaを適用すると IOスレッドの再接続によってrelaylogに残された部分的なトランザクション xidログイベントがトランザクションをコミットするのを待ちます。
残念ながら、SQLスレッドコーディネーターはマスターのスレッドコーディネーターに到達します。 次のrelaylogファイルでROTATEイベントを実行し、すべてのワーカーを待機します 回転を適用する前に、自分のタスクを終了します。
分析:
トランザクション全体がIOスレッドによって再び取得されるので、 再接続すると、スレーブは部分トランザクションを一度ロールバックする必要があります これに気づいてマスターから回転します。
このバグは、BUG#17326020によって既に修正されているのと同じ問題を報告します。 報告された問題はもう再現できません。だから、このパッチはちょうど 新しいテストケースを追加します。
提案
走れ。 FLUSH BINARY LOGS; マスターに
移動がSQLスレッドからの応答をトリガーするかどうかを確認します。
そうでない場合は、先に進んで削除してください slave_parallel_workers から my.cnf mysqlを再起動します。
あなたはMySQLを起動し、マスターとスレーブを起動してから error 1236, 、それはあなたが不可能な位置から複製を確立しようとしていることを意味します。GTIDとエラーメッセージのコンテキストでは、GTIDセット内のクエリのセットを完全に識別するために必要なバイナリログは存在しなくなりました,
あなたのを振り返ってみてください SHOW SLAVE STATUS\G
Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274
このことから、最後に実行されたGTIDは次のとおりです 7846a847-62c7-11e5-91a6-e06995de432e:4783274
これは、バイナリログが持っているか持っていたことを意味します 7846a847-62c7-11e5-91a6-e06995de432e:4783275 もはや存在しません。
スレーブでレプリケーションを停止し、マスターがバイナリログを（expire_logs_daysを介して）回転させるのに十分な長さのレプリケーションをオフにした後、スレーブがまだ見る必要があり、レプリケーションをオンにした場合、これが発生するのを見ることができます。
あなたの特定のケースでは、バイナリログのmysqlbinlogダンプを実行してみてください mysqld-bin.000141.何も出てこない場合は、スレーブをリロードしてレプリケーションをゼロから設定する必要があります。
