運用ガイド
運用の考え方
MygramDB の設定には二種類あります。小さな許可リストにある項目は、稼働中に SET で変更できます。接続、テーブル、レプリケーション、リスナーの設定は起動時専用です。設定ファイルを編集して検証し、プロセスを再起動してください。
ランタイム設定と設定ファイル
SET が変えるのは稼働中のプロセスだけです。設定ファイルは書き換えないため、恒久的な変更は設定ファイルにも反映してください。
ランタイム変数
有効な値は SHOW VARIABLES で確認し、許可された変数は SET で変更します。
SHOW VARIABLES LIKE 'cache%'
SET logging.level = 'debug'
SET cache.enabled = false
SET api.default_limit = 200, api.rate_limiting.capacity = 200| 変更できる変数 | 用途 |
|---|---|
logging.level、logging.format | 診断時の詳細度やログの形式を変更します。 |
api.default_limit、api.max_query_length | リクエストの既定値と上限を調整します。 |
api.rate_limiting.enable、api.rate_limiting.capacity、api.rate_limiting.refill_rate | TCP のレートリミッターを調整します。 |
cache.enabled、cache.min_query_cost_ms、cache.ttl_seconds | クエリキャッシュを有効化または調整します。 |
既知の変数でも、これ以外は変更できません。特に mysql.host と mysql.port は起動時専用です。
SET mysql.host = 'mysql-primary-2.example.com'
-- ERROR: Variable 'mysql.host' is immutable (requires restart)MySQL ソースを変更する
通信断の後、MygramDB は設定済みエンドポイントへ自動再接続します。この再接続ではソースを検証します。MySQL サーバー UUID が変わっていれば、昇格後のサーバーや無関係なサーバーを暗黙に追従せず、接続を拒否します。
計画メンテナンスやプライマリ昇格では、次の順で進めてください。
- 昇格後の MySQL サーバーで必要な GTID 履歴、ROW binlog 形式、設定済みテーブルを利用可能にします。
- MygramDB の設定で
mysql.hostと必要ならmysql.portを変更します。 mygramdb -t <config>で設定を検証します。- MygramDB を再起動し、readiness プローブが通ってからトラフィックを流します。
SET mysql.host や SET mysql.port は使わないでください。自動再接続が別のソース UUID を追従することもありません。
Readiness、liveness、トラフィック制御
GET /health/live はプロセスが生きているかを返します。トラフィックの判定には GET /health/ready を使います。初期データが読み込まれ、ダンプロードや SYNC が動いておらず、レプリケーションが利用可能なときだけ 200 を返します。それ以外は理由とレプリケーション診断を含めて 503 を返します。
curl -fsS http://127.0.0.1:8080/health/live
curl -fsS http://127.0.0.1:8080/health/readyTCP だけを使う構成では INFO を利用できます。data_initialized と readiness は /health/ready と同じ条件で判定されます。
# Server
data_initialized: true
readiness: ready設定したテーブルのどれかが初期化されていなければ、readiness は false のままです。起動時のダンプ復元または DUMP LOAD が成功すると復元したテーブルは初期化済みになりますが、レプリケーションの再開に失敗すれば readiness は false のままです。
レプリケーション診断
レプリケーションの状態は INFO、/health/ready、/health/detail、/metrics で確認します。ヘルスレスポンスには、レプリケーションの実行・開始状態、最後のエラーと数値コード、スキーマ非互換状態、最後に適用した時刻、その後の経過秒数が含まれます。
遅延の時刻は、MygramDB が適用済み GTID を進めたときに更新されます。replication_seconds_since_last_applied は経過時間の指標であり、MySQL に新しいコミットがない証明ではありません。ソースがアイドル中でも最近の適用イベントはありません。MySQL の書き込み状況、レプリケーション状態、エラー項目と合わせて監視してください。
readiness が 503 のときは、まず reason を読みます。初期ロード未実施、実行中の SYNC、実行中のダンプロード、停止したレプリケーションリーダー、非互換スキーマが代表的な状態です。復旧は レプリケーション、ダンプの手順は スナップショットとダンプ復旧 を参照してください。
安全な運用変更
長時間操作は一つのメンテナンス枠を共有します。SYNC、DUMP SAVE、DUMP LOAD、OPTIMIZE、定期スナップショットは重ねて実行できません。計画的に実行し、状態を監視し、同期中のテーブルへはトラフィックを流さないでください。
再起動が必要な設定変更では、構成が許すなら健全なインスタンスを残すロールアウトを行います。健全なプロセスを止める前に設定を確認し、起動後に INFO または /health/ready を確認してください。
ログローテーション
外部のローテーションツールがログファイルを移動した後、SIGUSR1 を送ると MygramDB はログファイルを開き直します。
kill -USR1 "$(pgrep -x mygramdb)"ローテーション後はプロセスマネージャーと新しいログファイルを確認してください。起動時専用の設定を変更するときは、シグナルではなく監視下で再起動します。