web-dev-qa-db-ja.com

mysql 5.6 gtidレプリケーションスレーブがスタックしました（システムロック）？

5.6のgtidベースのレプリケーションを設定しました（5.6.26で）、それを実行したときに機能しているようで、通常のデータの横に作成したランダムテストデータベースをレプリケートしました。しかし、ある時点で何かが起こったに違いありません。

 mysql>スレーブステータスの表示\ G 
 *************************** 1.行*** ************************ 
 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_ .____。] Replicate_Do_Table：
 Replicate_Ignore_Table：
 Replicate_Wild_Do_Table：
 Replicate_Wild_Ignore_Table：
 Last_Errno：0 
 La st_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 
 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_Crl ____。] Master_SSL_Crlpath：
 Retrieved_Gtid_Set：7846a847-62c7-11e5-91a6-e06995de432e：4757140-5030085 [.____。自動位置：1

現在、元々「Slave_SQL_Running_State」は「リレーログからのイベントの読み取り」などと言っていましたが、システムロックにも変更されました（IO状態は常にそうだと言っていました）。

Seconds_Behind_Masterは着実に増加しており、リレーログのサイズはファイルシステム上で急速に増大しますが、Executed_gtid_setは変化しているように見えますが、それでもかなり遅れているため、まだ問題が発生しているようです。

これがプロセスリストです：

 mysql> show processlist; 
 + ------ + ------------- + ----------- +- ----- + --------- + ------- + -------------------------- ------------- + ------------------ + 
 | Id |ユーザー|ホスト| db |コマンド|時間|州|情報| 
 + ------ + ------------- + ----------- + ------ +- ------- + ------- + ---------------------------------- ----- + ------------------ + 
 | 1877 |ルート| localhost | NULL |睡眠| 6076 | | NULL | 
 | 1878年ルート| localhost | NULL |クエリ| 0 | init |プロセスリストを表示| 
 | 1886年システムユーザー| | NULL |接続| 783 |システムロック| NULL | 
 | 1887年システムユーザー| | NULL |接続| 0 |システムロック| NULL | 
 | 1888年システムユーザー| | NULL |接続| 783 |コーディネーターからのイベントを待機しています| NULL | 
 | 1889 |システムユーザー| | NULL |接続| 55455 |システムロック| NULL | 
 + ------ + ------------- + ----------- + ------ +- ------- + ------- + ---------------------------------- ----- + ------------------ +

スレーブを停止して再起動しようとしましたが、役に立ちませんでした。

誰かが私がこれを再び機能させるために試すことができるアイデアを持っていますか？いただければ幸いです。

ありがとう

mysqlreplicationgtid
1
user77522

プロセスリストに2を超えるsystem userエントリが表示されるため、マルチスレッドレプリケーションを使用していると想定します（ slave_parallel_workers > 1）。

それはバグのようです

2014年10月29日、これはDavid Mossで表現されました

ご意見ありがとうございます。この問題はバグ17326020でカバーされ、以下がMySQL 5.6.21および5.7.5の変更ログに追加されました。

トランザクションの途中でI/OスレッドがGTIDとマルチスレッドスレーブを使用してマスターに再接続すると、トランザクションの中止に失敗し、部分的なトランザクションがリレーログに残ってから、同じトランザクションを再度取得していました。これは、リレーログのローテーションを実行したときに発生しました。この場合、サーバーは再接続時にログをローテーションする前にチェックし、進行中のトランザクションが完了するまでまず待機します。

したがって、このバグをカバーする新しいものは何も追加されず、修正済みとしてクローズします。

2014年12月10日、これはLaurynas Biveinisで表現されました

問題：

MTS、GTID、自動ポジショニングを有効にすると、ワーカーがIOスレッドの再接続によってrelaylogに残された部分的なトランザクションを適用すると、XIDログイベントがトランザクションをコミットするのを待ちます。

残念ながら、SQLスレッドコーディネーターは、次のリレーログファイルでマスターのROTATEイベントに到達し、すべてのワーカーがタスクを完了するのを待ってからROTATEを適用します。

分析：

トランザクション全体が再接続後にIOスレッドによって再度取得されるため、スレーブは、マスターからこのROTATEに気付いたら、部分的なトランザクションをロールバックする必要があります。

このバグは、BUG＃17326020で修正済みの同じ問題を報告しており、報告された問題は再現できなくなりました。したがって、このパッチは新しいテストケースを追加するだけです。

提案

マスターでFLUSH BINARY LOGS;を実行します

移動がSQLスレッドからの応答をトリガーするかどうかを確認します。

そうでない場合は、先に進んでmy.cnfから slave_parallel_workers を削除し、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を介して）バイナリログをローテーションするのに十分な時間レプリケーションをオフにしたままにすると、スレーブがまだ確認する必要があり、その後レプリケーションをオンにした場合に、この状況が発生します。

特定のケースでは、バイナリログmysqld-bin.000141のmysqlbinlogダンプを実行してみてください。それから何も出てこない場合は、スレーブをリロードし、レプリケーションを最初からセットアップする必要があります。

0
RolandoMySQLDBA