マスター/スレーブレプリケーションクラスターのセットアップは、ほとんどの組織で一般的な使用例です。 MySQLレプリケーションを使用すると、データをさまざまな環境にレプリケートでき、情報が確実にコピーされます。非同期でシングルスレッド（デフォルト）ですが、レプリケーションでは同期（または実際には「準同期」）に構成することもでき、スレーブスレッドを複数のスレッドまたはパラレルで実行できます。
このアイデアは非常に一般的であり、通常は簡単なセットアップで実現し、スレーブをリカバリまたはバックアップソリューションとして機能させます。ただし、特に悪いクエリ（プライマリキーや一意のキーの欠如など）が複製されたり、ハードウェアに問題が発生したりする場合（ネットワークやディスクのIOの問題など）、これは常に代償になります。これらの問題が発生した場合、直面する最も一般的な問題はレプリケーションの遅延です。
レプリケーションラグは、プライマリ/マスターとスタンバイ/スレーブノード間の実行の時間差によって計算されるトランザクションまたは操作の遅延のコストです。 MySQLの最も確実なケースは、主キーやインデックスの欠如、ネットワークハードウェアの不良やネットワークカードの誤動作、異なるリージョンやゾーン間の離れた場所、または実行中の物理バックアップなどの一部のプロセスなど、複製される不良クエリに依存しています。 MySQLデータベースを使用して、現在複製されているトランザクションの適用を遅らせます。これは、これらの問題を診断するときに非常に一般的なケースです。このブログでは、これらのケースに対処する方法と、MySQLレプリケーションの遅延が発生している場合の対処方法を確認します。
「SHOWSLAVESTATUS」：MySQLDBAのマントラ
場合によっては、これはレプリケーションラグを処理する際の特効薬であり、MySQLデータベースの問題の原因のほとんどすべてを明らかにします。レプリケーションラグが発生している疑いのあるスレーブノードでこのSQLステートメントを実行するだけです。
- Slave_IO_State -スレッドが何をしているのかを教えてくれます。このフィールドは、レプリケーションヘルスが正常に実行されているか、マスターへの再接続などのネットワークの問題に直面している場合、またはデータをディスクに同期するときにディスクの問題を示す可能性のあるデータのコミットに時間がかかりすぎる場合に、優れた洞察を提供します。 SHOWPROCESSLISTを実行するときにこの状態値を決定することもできます。
- Master_Log_File -I/Oスレッドが現在フェッチされているマスターのbinlogファイル名。
- Read_Master_Log_Pos -レプリケーションI/Oスレッドがすでに読み取ったマスターからのbinlogファイルの位置。
- Relay_Log_File -SQLスレッドが現在イベントを実行しているリレーログファイル名
- Relay_Log_Pos -SQLスレッドがすでに実行されているRelay_Log_Fileで指定されたファイルのbinlog位置。
- Relay_Master_Log_File -SQLスレッドがすでに実行していて、Read_Master_Log_Pos値と一致するマスターのbinlogファイル。
- Secondarys_Behind_Master -このフィールドには、スレーブで現在処理されているイベントの、スレーブの現在のタイムスタンプとマスターのタイムスタンプの差の概算が表示されます。ただし、スレーブSQLスレッドとスレーブI / Oスレッドの間で秒単位の差が取られるため、ネットワークが遅い場合、このフィールドでは正確な遅延を認識できない場合があります。そのため、読み取りの遅いスレーブI / Oスレッドに追いつく可能性がありますが、マスターするのはすでに異なります。
- Slave_SQL_Running_State -SQLスレッドの状態と値は、SHOWPROCESSLISTに表示される状態値と同じです。
- 取得済み_Gtid_Set -GTIDレプリケーションを使用する場合に使用できます。これは、このスレーブが受信したすべてのトランザクションに対応するGTIDのセットです。
- Executed_Gtid_Set -GTIDレプリケーションを使用する場合に使用できます。これは、バイナリログに書き込まれるGTIDのセットです。
たとえば、GTIDレプリケーションを使用し、レプリケーションラグが発生している以下の例を見てみましょう。
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.70
Master_User: cmon_replication
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000038
Read_Master_Log_Pos: 826608419
Relay_Log_File: relay-bin.000004
Relay_Log_Pos: 468413927
Relay_Master_Log_File: binlog.000038
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: 826608206
Relay_Log_Space: 826607743
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: 251
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: 45003
Master_UUID: 36272880-a7b0-11e9-9ca6-525400cae48b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: copy to tmp table
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:7631-9192
Executed_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:1-9191,
864dd532-a7af-11e9-85f2-525400cae48b:1-173,
df68c807-a7af-11e9-9b56-525400cae48b:1-4
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)このような問題を診断する場合、mysqlbinlogは、特定のbinlogのxおよびy位置で実行されているクエリを識別するためのツールにもなります。これを判断するために、Retrieved_Gtid_Set、Relay_Log_Pos、およびRelay_Log_Fileを取得してみましょう。以下のコマンドを参照してください：
[[email protected] mysql]# mysqlbinlog --base64-output=DECODE-ROWS --include-gtids="36272880-a7b0-11e9-9ca6-525400cae48b:9192" --start-position=468413927 -vvv relay-bin.000004
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 468413927
#200206 4:36:14 server id 45003 end_log_pos 826608271 CRC32 0xc702eb4c GTID last_committed=1562 sequence_number=1563 rbr_only=no
SET @@SESSION.GTID_NEXT= '36272880-a7b0-11e9-9ca6-525400cae48b:9192'/*!*/;
# at 468413992
#200206 4:36:14 server id 45003 end_log_pos 826608419 CRC32 0xe041ec2c Query thread_id=24 exec_time=31 error_code=0
use `jbmrcd_date`/*!*/;
SET TIMESTAMP=1580963774/*!*/;
SET @@session.pseudo_thread_id=24/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
ALTER TABLE NewAddressCode ADD INDEX PostalCode(PostalCode)
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET [email protected]_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;これは、ラグの原因となるDMLステートメントを複製して実行しようとしたことを示しています。このテーブルは、13Mの行を含む巨大なテーブルです。
SHOW PROCESSLIST、SHOW ENGINE INNODB STATUS、ps、top、iostatコマンドの組み合わせを確認してください
場合によっては、SHOWSLAVESTATUSでは原因を特定するのに十分ではありません。複製されたステートメントは、MySQLデータベーススレーブで実行されている内部プロセスの影響を受ける可能性があります。ステートメントSHOW[FULL]PROCESSLISTおよびSHOWENGINEINNODB STATUSを実行すると、問題の原因に関する洞察を提供する有益なデータも提供されます。
たとえば、ベンチマークツールが実行されていて、ディスクIOとCPUが飽和状態になっているとします。両方のSQLステートメントを実行して確認できます。 psおよびtopコマンドと組み合わせます。
診断しようとしている現在のボリュームの統計を提供するiostatを実行して、ディスクストレージのボトルネックを特定することもできます。 iostatを実行すると、サーバーのビジー状態または負荷状態を確認できます。たとえば、遅れているが同時に高いIO使用率を経験しているスレーブによって取得されます。
[[email protected] ~]# iostat -d -x 10 10
Linux 3.10.0-693.5.2.el7.x86_64 (testnode5) 02/06/2020 _x86_64_ (2 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.42 3.71 60.65 218.92 568.39 24.47 0.15 2.31 13.79 1.61 0.12 0.76
dm-0 0.00 0.00 3.70 60.48 218.73 568.33 24.53 0.15 2.36 13.85 1.66 0.12 0.76
dm-1 0.00 0.00 0.00 0.00 0.04 0.01 21.92 0.00 63.29 2.37 96.59 22.64 0.01
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.20 392.30 7983.60 2135.60 49801.55 12.40 36.70 3.84 13.01 3.39 0.08 69.02
dm-0 0.00 0.00 392.30 7950.20 2135.60 50655.15 12.66 36.93 3.87 13.05 3.42 0.08 69.34
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.06 183.67 0.00 183.67 61.67 1.85
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.40 370.93 6775.42 2557.04 46184.22 13.64 43.43 6.12 11.60 5.82 0.10 73.25
dm-0 0.00 0.00 370.93 6738.76 2557.04 47029.62 13.95 43.77 6.20 11.64 5.90 0.10 73.41
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.03 107.00 0.00 107.00 35.67 1.07
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 299.80 7253.35 1916.88 52766.38 14.48 30.44 4.59 15.62 4.14 0.10 72.09
dm-0 0.00 0.00 299.80 7198.60 1916.88 51064.24 14.13 30.68 4.66 15.70 4.20 0.10 72.57
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.10 215.50 8939.60 1027.60 67497.10 14.97 59.65 6.52 27.98 6.00 0.08 72.50
dm-0 0.00 0.00 215.50 8889.20 1027.60 67495.90 15.05 60.07 6.60 28.09 6.08 0.08 72.75
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 32.33 0.00 32.33 30.33 0.91
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.90 140.40 8922.10 625.20 54709.80 12.21 11.29 1.25 9.88 1.11 0.08 68.60
dm-0 0.00 0.00 140.40 8871.50 625.20 54708.60 12.28 11.39 1.26 9.92 1.13 0.08 68.83
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 27.33 0.00 27.33 9.33 0.28
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.70 284.50 8621.30 24228.40 51535.75 17.01 34.14 3.27 8.19 3.11 0.08 72.78
dm-0 0.00 0.00 290.90 8587.10 25047.60 53434.95 17.68 34.28 3.29 8.02 3.13 0.08 73.47
dm-1 0.00 0.00 0.00 2.00 0.00 8.00 8.00 0.83 416.45 0.00 416.45 63.60 12.72
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.30 851.60 11018.80 17723.60 85165.90 17.34 142.59 12.44 7.61 12.81 0.08 99.75
dm-0 0.00 0.00 845.20 10938.90 16904.40 83258.70 17.00 143.44 12.61 7.67 12.99 0.08 99.75
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.10 24.60 12965.40 420.80 51114.45 7.93 39.44 3.04 0.33 3.04 0.07 93.39
dm-0 0.00 0.00 24.60 12890.20 420.80 51114.45 7.98 40.23 3.12 0.33 3.12 0.07 93.35
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 3.60 13420.70 57.60 51942.00 7.75 0.95 0.07 0.33 0.07 0.07 92.11
dm-0 0.00 0.00 3.60 13341.10 57.60 51942.00 7.79 0.95 0.07 0.33 0.07 0.07 92.08
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00上記の結果は、高いIO使用率と高い書き込みを示しています。また、平均キューサイズと平均リクエストサイズが移動していることもわかります。これは、ワークロードが高いことを示しています。このような場合、MySQLがレプリケーションスレッドをチョークする原因となる外部プロセスがあるかどうかを判断する必要があります。
ClusterControlはどのように役立ちますか？
ClusterControlを使用すると、スレーブラグの処理と原因の特定が非常に簡単で効率的になります。 WebUIで直接通知します。以下を参照してください。
これにより、スレーブノードで発生している現在のスレーブラグが明らかになります。それだけでなく、SCUMMダッシュボードを有効にすると、スレーブノードの状態またはクラスター全体が何をしているかについての洞察が得られます。
これらはClusterControlで利用できるだけでなく、以下に示すように、これらの機能で不正なクエリが発生するのを回避する機能
冗長インデックスを使用すると、これらのインデックスがパフォーマンスの問題を引き起こす可能性があるかどうかを判断できます。重複するインデックスを参照する着信クエリ。また、主キーを持たないテーブルについても説明します。これは、特定のSQLクエリや、スレーブに複製されるときに主キーまたは一意キーのない大きなテーブルを参照するトランザクションの場合に、通常はスレーブラグの一般的な問題です。
MySQLレプリケーションの遅延への対処は、マスタースレーブレプリケーションのセットアップでよくある問題です。診断は簡単ですが、解決するのは困難です。主キーまたは一意キーが存在するテーブルがあることを確認し、スレーブラグの原因をトラブルシューティングおよび診断する方法に関する手順とツールを決定します。ただし、問題を解決する際には常に効率が重要です。