レプリケーション管理
対象範囲
このページは MygramDB 自身のレプリケーションライフサイクルを説明します。MySQL の昇格やレプリカ構成を管理する機能ではありません。MygramDB は起動時設定のエンドポイントから読み取ります。エンドポイントを変更するときは設定を変えて再起動してください。
メンテナンス操作との調整
DUMP SAVE、DUMP LOAD、定期スナップショット、SYNC は、単一の binlog リーダーと協調します。一貫した位置が必要な操作ではレプリケーションを停止してドレインし、成功時も失敗時も終了後に復帰させます。長いダンプ中は MySQL への追従が遅れることがあります。
| 操作 | レプリケーションの動作 | リーダーへの影響 |
|---|---|---|
DUMP SAVE | 一貫した GTID を保存するために停止し、終了後に再開します。 | 検索は継続します。保存中は遅延が増えることがあります。 |
DUMP LOAD | 状態の置換前に停止し、成功時はダンプの GTID を使ってレプリケーションを復帰させます。 | 復元データは原子的に切り替わります。readiness にはレプリケーションの利用可能性も必要です。 |
SYNC | 共有リーダーをドレインし、1 テーブルを別領域で構築してから再開します。 | すべての設定済みテーブルが単一リーダーを共有するため、通常はドレイン済み位置から再開します。 |
OPTIMIZE | 共有メンテナンス枠を取得します。 | ダンプや SYNC とは別に実行します。 |
長時間操作は一つの枠を共有します。別の操作が実行中に新しい要求を送ると busy で失敗します。実行中の操作が終了状態になるまで待ってください。
ソースエンドポイントを変更する
mysql.host と mysql.port は変更できないランタイム変数です。SET は immutable-variable エラーを返します。ソースを変えるときは設定を編集し、mygramdb -t <config> で検証してから再起動してください。
自動再接続は設定済みエンドポイントに限られます。そのエンドポイントが異なるソース UUID の MySQL を返すと、MygramDB は追従せずに拒否します。昇格やエンドポイント変更を調べ、適切であれば設定を更新して意図したソースに対して再起動してください。
レプリケーション停止中の readiness
協調したメンテナンス中の一時停止は、リーダー障害とは別に扱われます。/health/ready と INFO は実行中の操作を考慮します。実行中の SYNC またはダンプロード、未初期化データ、協調停止が終わった後にも開始・実行していないリーダーでは readiness が false になります。
DUMP LOAD が成功すると、レプリケーションを再開できなくても復元テーブルは初期化済みになります。データは入っていますが、readiness は false のままです。ヘルスの理由とレプリケーションエラーを使い、MySQL 接続、認証情報、GTID 履歴、スキーマのどれを修復するか判断してください。
運用チェックリスト
- メンテナンス前に
/health/ready、INFO、実行中の SYNC またはダンプの状態を確認します。 - 長時間操作は一つずつ実行します。
- 終了後にレプリケーションが動作し、readiness が
readyであることを確認します。 - ソースを移す場合は設定を変更して再起動します。ランタイムの endpoint
SETは使いません。 - エラー
2017でレプリケーションが停止した場合は、レプリケーション の特別な復旧手順に従います。