MySQLレプリケーション標準ルール

バイナリ・ログのチェックサムが無効化されている

説明: MySQLサーバーによって読み書きされるバイナリ・ログは、クラッシュ時も安全に保たれるようになりました(完了イベント(またはトランザクション)のみログ記録されるか読み返されるため)。デフォルトでは、このサーバーにより、そのイベントの長さとそのイベント自体がログ記録され、この情報を使用して、そのイベントが正しく書き込まれたことが検証されます。また、binlog_checksumシステム変数を設定することで、このサーバーによってCRC32チェックサムを使用してそれらのイベントのチェックサムが書き込まれるようにして、ログとレプリケーション・プロセスの安全性のレベルを高めることができます。このサーバーでバイナリ・ログからチェックサムを読み取るようにするには、source_verify_checksumシステム変数を使用します。replica_sql_verify_checksumシステム変数を使用すると、レプリカSQLスレッドでリレー・ログからチェックサムが読み取られるようになります。

重大度: マイナー警告

アドバイス: binlog_checksumが%binlog_checksum%に設定されている理由を調査します。SET GLOBAL binlog_checksum = CRC32文を発行することでチェックサムを有効にします。binlog_checksum = CRC32をMySQL構成ファイル(my.cnf)に追加して、次回のサーバー起動時に必ずチェックサムが有効になるようにします。

バイナリ・ログの行ベース・イメージが過剰である

説明: 行ベースのレプリケーションでは、行イメージ制御がサポートされています。行変更ごとに、各行に対する変更を一意に識別し実行するために必要な列のみログ記録することで(すべての列ではない)、ディスク容量、ネットワーク・リソースおよびメモリー使用量を節約できます。binlog_row_imageサーバー・システム変数の値をminimal (必要な列のみログ記録する)、full (すべての列をログ記録する)またはnoblob (不要なBLOB列やTEXT列を除くすべての列をログ記録する)のどれかに設定することで、すべての行をログ記録するか最小限の行をログ記録するかを決定できます。

重大度: マイナー警告

アドバイス: binlog_row_imageが%binlog_row_image%に設定されている理由を調査します。SET GLOBAL binlog_row_image = minimalを発行することで、各行に対する変更を一意に識別し実行するために必要な列のみログ記録します。binlog_row_image = minimalをMySQL構成ファイル(my.cnf)に追加して、このサーバーの次回起動時に必ずその新しい設定が有効になるようにします。

ソースでバイナリ・ログからの読取り時にチェックサムが検証されない

説明: MySQLサーバーによって読み書きされるバイナリ・ログは、クラッシュ時も安全に保たれるようになりました(完了イベント(またはトランザクション)のみログ記録されるか読み返されるため)。デフォルトでは、このサーバーにより、そのイベントの長さとそのイベント自体がログ記録され、この情報を使用して、そのイベントが正しく書き込まれたことが検証されます。また、binlog_checksumシステム変数を設定することで、このサーバーによってCRC32チェックサムを使用してそれらのイベントのチェックサムが書き込まれるようにして、ログとレプリケーション・プロセスの安全性のレベルを高めることができます。このサーバーでバイナリ・ログからチェックサムを読み取るようにするには、source_verify_checksumシステム変数を使用します。replica_sql_verify_checksumシステム変数を使用すると、レプリカSQLスレッドでリレー・ログからチェックサムが読み取られるようになります。

重大度: マイナー警告

アドバイス: source_verify_checksumが%verify_checksum%に設定されている理由を調査します。SET GLOBAL source_verify_checksum = ON文を発行することで、チェックサムのサーバー検証を有効にします。source_verify_checksum = ONをMySQL構成ファイルに追加して、このサーバーの次回起動時に必ずサーバー・チェックサム検証が有効になるようにします。ただし、これによってソースでのオーバーヘッドが増えることに留意してください(ソースによって、バイナリ・ログ・イベントを読み取り、ディスク上のイベントのチェックサムがメモリー内のものと一致することを検証する必要があるため)。テスト・システムで、この変更を加える前と後にデータベース・パフォーマンスを測定して、そのオーバーヘッドを許容できることを確認してから、本番環境でこの変更をデプロイする必要があります。

レプリカでのネットワーク停止検出用の値が大きすぎる

説明: レプリカでは、ネットワーク接続の停止(これはレプリカでソース・サーバーから最新データを取得できるかどうかに影響し、それにより、レプリケーションが遅れます)に対処する必要があります。しかしながら、replica_net_timeoutの秒数の間ソース・サーバーからのデータの受信がなかったときのみ、レプリカによってネットワーク停止が通知されます。より速く停止(および関連する接続再試行)を検出し解決するように、replica_net_timeoutの値を減らすことができます。このパラメータのデフォルトは3600秒(1時間)であり、この値は、多くの環境にとっては大きすぎます。

重大度: マイナー警告

アドバイス: MySQL構成ファイル(my.cnf)の[mysqld]セクションで、replica_net_timeout=60 (または、使用している環境でのネットワーク接続停止の検出のための妥当な値)を設定します。replica_net_timeoutの現在の値は%net_timeout%です。

レプリカが読取り専用として構成されていない

説明: レプリカに対する独断的な更新や意図しない更新によって、レプリケーションが中断されることや、レプリカがそのソース・サーバーに対して矛盾するようになる場合があります。レプリカをread_onlyにすると、レプリカでそのソース・サーバーからの更新のみを受け入れクライアントからは受け入れなくするために役立ちます。これにより、意図しない更新の可能性が最小限になります。

重大度: マイナー警告

アドバイス: MySQL構成ファイル(my.cnf)内でread_only=1を設定してレプリカでソース・サーバーからの更新のみを受け入れクライアントからは受け入れないようにし、MySQLサーバーを再起動します。

レプリカでリレー・ログからの読取り時にチェックサムが検証されない

説明: MySQLサーバーによって読み書きされるバイナリ・ログは、クラッシュ時も安全に保たれるようになりました(完了イベント(またはトランザクション)のみログ記録されるか読み返されるため)。デフォルトでは、このサーバーにより、そのイベントの長さとそのイベント自体がログ記録され、この情報を使用して、そのイベントが正しく書き込まれたことが検証されます。また、binlog_checksumシステム変数を設定することで、このサーバーによってCRC32チェックサムを使用してそれらのイベントのチェックサムが書き込まれるようにして、ログとレプリケーション・プロセスの安全性のレベルを高めることができます。このサーバーでバイナリ・ログからチェックサムを読み取るようにするには、source_verify_checksumシステム変数を使用します。replica_sql_verify_checksumシステム変数を使用すると、レプリカSQLスレッドでリレー・ログからチェックサムが読み取られるようになります。

重大度: マイナー警告

アドバイス: replica_sql_verify_checksumが%sql_verify_checksum%に設定されている理由を調査します。SET GLOBAL replica_sql_verify_checksum = ON文を発行することで、レプリカでのチェックサムの検証を有効にします。replica_sql_verify_checksum = ONをMySQL構成ファイル(my.cnf)に追加して、このサーバーの次回起動時に必ずレプリカ・チェックサム検証が有効になるようにします。

レプリカでのSQL処理がマルチスレッドでない

説明: レプリケーションでは、レプリカでの、マルチスレッドによるトランザクションのパラレル実行がサポートされています。パラレル実行が有効になっている場合、レプリカSQLスレッドは、replica_parallel_workersサーバー・システム変数の値によって決まる多数のレプリカ・ワーカー・スレッドの、コーディネータの役割を果たします。なお、レプリカでの現在のマルチスレッド実装では、データと更新がデータベースごとにパーティション化されていることと、所定のデータベース内の更新が、ソース・サーバーで実行されたのと同じ相対的順序で発生することが前提となっています。ただし、様々なデータベース間でトランザクションを調整する必要はありません。そのうえ、トランザクションをデータベースごとに分散することもできます。つまり、レプリカ上のワーカー・スレッドで、他のデータベースに対する更新が完了するのを待つことなく、所定のデータベースでの以降のトランザクションを処理できます。また、様々なデータベースでのトランザクションがソース・サーバー上とは異なる順序でレプリカ上で発生する可能性があるため、最近実行されたトランザクションをチェックするだけでは、ソース・サーバー上の以前のトランザクションすべてがレプリカ上で実行されていることを確かめられません。このことは、マルチスレッド対応のレプリカを使用している場合のロギングとリカバリに影響があります。ただし、MySQL Server 5.7.5以降では、replica_preserve_commit_orderオプション変数を使用して、ソース・サーバー上のバイナリ・ログにトランザクションがコミットされた順序がレプリカ上で維持されていることを確認できます(MySQLマニュアル: レプリケーション・レプリカのオプションおよび変数)。また、MySQL Server 5.7.2以降では、スキーマ内パラレル化(LOGICAL_CLOCK)もサポートされています(MySQLマニュアル: レプリケーション・レプリカのオプションおよび変数)。

重大度: マイナー警告

アドバイス: replica_parallel_workersが%parallel_workers%に設定されている理由を調査します。SET GLOBAL replica_parallel_workers = n文を発行することで、レプリカでのトランザクションのパラレル実行を有効にします。ここでのnは、特定の環境に応じて異なります。replica_parallel_workers = nをMySQL構成ファイル(my.cnf)に追加して、このサーバーの次回起動時にトランザクションのパラレル実行が必ず有効になるようにします。