レプリケーションソースサーバーをシャットダウンして、あとで再起動しても安全です。 レプリカがソースへの接続を失うと、レプリカはただちに再接続を試み、失敗した場合は定期的に再試行します。 デフォルトでは 60 秒ごとに再試行します。 これは、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 の場合) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 の場合) を使用して変更できます。 レプリカは、ネットワーク接続の停止にも対処できます。 ただし、レプリカは、ソースから slave_net_timeout 秒間データを受信しなかった後にのみネットワークの停止に気付きます。 停止時間が短い場合は、slave_net_timeout を減らすことをお勧めします。 セクション17.4.2「レプリカの予期しない停止の処理」を参照してください。
ソースバイナリログファイルがフラッシュされていないため、ソース側でクリーンでないシャットダウン (クラッシュなど) を実行すると、ソースバイナリログの最終的な位置がレプリカによって読み取られた最新の位置より小さくなる可能性があります。 これにより、ソースの起動時にレプリカをレプリケートできなくなる可能性があります。 ソースサーバーの my.cnf ファイルで sync_binlog=1 を設定すると、ソースがより頻繁にバイナリログをフラッシュするため、この問題を最小限に抑えることができます。 InnoDB とトランザクションを使用したレプリケーション設定で永続性と一貫性を最大限に高めるには、innodb_flush_log_at_trx_commit=1 も設定する必要があります。 この設定では、各トランザクションのコミット時に InnoDB redo ログバッファの内容がログファイルに書き込まれ、ログファイルがディスクにフラッシュされます。 オペレーティングシステムまたはディスクハードウェアは、ディスクへのフラッシュ操作が行われたことを mysqld に通知する場合があるため、トランザクションの永続性はまだこの設定で保証されていないことに注意してください。
レプリカの完全なシャットダウンは、レプリカが停止した場所を追跡するため安全です。 ただし、レプリカに一時テーブルが開かれていないことに注意してください。セクション17.5.1.31「レプリケーションと一時テーブル」 を参照してください。 予期しないシャットダウンにより問題が発生する場合があります (特に、ディスクキャッシュがディスクにフラッシュされない状態で問題が発生した場合)。
トランザクションの場合、レプリカは
relay-log.infoをコミットしてから更新します。 これらの 2 つの操作の間に予期しない終了が発生した場合、リレーログの処理は情報ファイルに示されているよりも先に進み、レプリカは再起動後にリレーログ内の最後のトランザクションからイベントを再実行します。同様の問題は、レプリカが
relay-log.infoを更新しても、書込みがディスクにフラッシュされる前にサーバーホストがクラッシュした場合に発生することがあります。 これが発生する可能性を最小限に抑えるには、レプリカmy.cnfファイルにsync_relay_log_info=1を設定します。sync_relay_log_infoを 0 に設定すると、ディスクへの書込みは強制されず、サーバーはオペレーティングシステムに依存してファイルを随時フラッシュします。
システムのこのような問題に対する耐障害性は、優れた無停電電源があると大幅に向上します。