MariaDB GTIDレプリケーション本番導入｜非停止切り替えとフェイルオーバー検証フロー

GTIDレプリケーションを本番に持ち込む前に整理しておくこと

MariaDB の GTID（Global Transaction ID）レプリケーションは、従来のバイナリログポジション指定方式に比べてフェイルオーバー時の再同期が大幅に簡素化されます。具体的には、どのトランザクションまで適用済みかを各サーバーが自律的に把握しているため、昇格後のレプリカが「どのログのどこから再開するか」を手動計算する必要がなくなります。

ただし、本番導入で失敗が起きやすいのは「設定そのものの理解不足」よりも、「既存の非GTIDレプリケーション環境からの移行タイミングの読み誤り」や「検証フローの省略」が原因であるケースが一般的です。本記事では、新規構築ではなく稼働中の環境を対象に、ダウンタイムを最小化しながら GTID へ切り替える手順と、切り替え後のフェイルオーバー検証フローを順に説明します。

対象バージョンは MariaDB 10.6 以降を前提とします。10.6 は LTS リリースであり、2026年時点でも多くのディストリビューションのデフォルトパッケージに採用されています。Ubuntu 22.04/24.04、RHEL 9 系でも同様の手順が通用しますが、パッケージ名やサービス名（mariadb vs mysqld）の差異には注意してください。

GTID の仕組みと従来方式との本質的な違い

MariaDB の GTID は domain_id-server_id-sequence_number の3要素で構成されます。gtid_domain_id はマルチソースレプリケーションや地理的に分かれたクラスターで衝突を防ぐために使います。単一マスター構成であれば gtid_domain_id=1 のままで問題ありません。

従来のポジション方式では、フェイルオーバー後に新マスターへ接続し直す際に SHOW MASTER STATUS の出力を手動で確認し、CHANGE MASTER TO MASTER_LOG_FILE=..., MASTER_LOG_POS=... を発行する必要がありました。マルチレプリカ構成では、それぞれが異なるポジションまで適用済みである可能性があり、計算ミスが即データ不整合につながります。GTID では CHANGE MASTER TO master_use_gtid=slave_pos の一行で済み、レプリカは自身の gtid_slave_pos を基準に自動的に差分を取得します。

また、MariaDB の GTID は MySQL 5.7 以降の GTID とは互換性がありません。MySQL から MariaDB へ移行する場合、または混在環境を構築しようとしている場合は、この非互換性を事前に確認しておく必要があります。

稼働中環境を非停止でGTIDへ切り替える手順

既存の非GTIDレプリケーション（ポジション方式）が動いている前提での切り替えフローを説明します。マスター1台・レプリカ1台の構成を想定した想定例として読んでください。

ステップ1：my.cnf の変更とローリング再起動

まずレプリカ側の /etc/mysql/mariadb.conf.d/50-server.cnf（または /etc/my.cnf.d/server.cnf）を編集します。

[mariadb]
gtid_strict_mode = ON
log_bin = /var/log/mysql/mariadb-bin
log_slave_updates = ON
server_id = 2
gtid_domain_id = 1

gtid_strict_mode = ON は本番では必ず有効にします。これがオフの状態だと、GTIDのシーケンスにギャップが生じても検出されず、後のフェイルオーバー時に予期しない重複適用が発生することがあります。

レプリカを systemctl restart mariadb で再起動した後、レプリケーションを再開します。この時点ではまだポジション方式のままで動作します。

ステップ2：マスター側の設定変更と再起動

マスター側にも同様の設定を追記します（server_id = 1）。マスターの再起動前に、アプリケーション側の書き込みが激しい時間帯を避けることが望ましいですが、マスター再起動中も読み取りはレプリカへの参照切り替えで継続できる構成になっている場合は影響を局所化できます。

マスター再起動後、SHOW GLOBAL VARIABLES LIKE 'gtid%'; で gtid_binlog_state が表示されることを確認します。値が空でなければ GTID の記録が始まっています。

ステップ3：CHANGE MASTER TO で GTID モードへ切り替え

レプリカ側で以下を実行します。

STOP SLAVE;
CHANGE MASTER TO master_use_gtid = slave_pos;
START SLAVE;

SHOW SLAVE STATUS\G で Using_Gtid: Slave_Pos が表示されれば切り替え成功です。Seconds_Behind_Master が 0 に収束するまで待機します。この切り替えはレプリケーション停止中の短時間で完了するため、書き込みトランザクション自体はマスターで継続できます。

フェイルオーバー検証フローと昇格手順

GTID レプリケーションへの切り替えが完了した後、必ずフェイルオーバーのリハーサルを本番相当の環境で実施します。以下は検証環境での想定例です。

マスター障害のシミュレーションと昇格

マスターを意図的に停止（systemctl stop mariadb）し、レプリカで遅延がゼロになっていることを事前に確認してから昇格を行います。

-- レプリカ側で実行
STOP SLAVE;
RESET SLAVE ALL;
SET GLOBAL read_only = OFF;

RESET SLAVE ALL は接続情報をすべてクリアします。昇格後のサーバーをマスターとして扱う際に必要です。アプリケーションの接続先をこのサーバーへ切り替えた後、書き込み動作を確認します。

旧マスターの復旧とレプリカとしての再参加

旧マスターを復旧させる際は、新マスターの gtid_binlog_state を確認し、旧マスターに差分がないかを SHOW GLOBAL VARIABLES LIKE 'gtid_binlog_state' で比較します。差分がある場合は旧マスター上で SET GLOBAL gtid_slave_pos = '...' を使って手動補正するか、mariabackup で新マスターからフルバックアップを取り直してリストアする方が安全です。

復旧後、旧マスターを新レプリカとして参加させます。

CHANGE MASTER TO
  MASTER_HOST = '新マスターのIP',
  MASTER_USER = 'repl_user',
  MASTER_PASSWORD = 'xxxxxx',
  master_use_gtid = slave_pos;
START SLAVE;

GTID を使っているため、ログファイル名もポジションも指定不要です。この手順のシンプルさが GTID 最大のメリットと言えます。

切り戻しと注意点：よくあるつまずきポイント

GTID レプリケーションへの切り替えにはいくつかの落とし穴があります。一般的なつまずきとして以下が挙げられます。

• gtid_strict_mode のギャップエラー：手動で SQL を実行したサーバーで GTID のシーケンスが飛んだ状態になっていると、gtid_strict_mode = ON の下でレプリケーションが即座にエラー停止します。原因特定には SHOW SLAVE STATUS\G の Last_SQL_Error を確認し、問題のトランザクションを特定の上で SET gtid_slave_pos で補正します。
• binlog_format の不一致：ROW ベースでないと特定の DML で不整合が起きやすいです。binlog_format = ROW を明示的に設定することを推奨します。
• read_only の設定漏れ：レプリカに read_only = ON が設定されていない場合、誤って書き込みが行われ GTID の乖離が生じます。MariaDB 10.5 以降では super_read_only も合わせて設定することで、SUPER 権限を持つユーザーによる誤操作も防げます。
• GTID から非 GTID への切り戻し：一度 GTID モードで書き込みが行われたバイナリログが残っている状態では、非 GTID レプリケーションへの単純な切り戻しは困難です。切り戻しを想定する場合は、切り替え直前のバイナリログポジションを記録しておくか、バックアップからの再構築を計画しておく必要があります。

2026年現行環境との差分と運用上の留意点

2026年時点での MariaDB の最新安定版は 10.11 LTS および 11.4 LTS です。10.6 LTS はまだサポート期間内ですが、新規構築であれば 10.11 または 11.4 の採用を検討する価値があります。11.x 系では GTID 周りの挙動に変更はありませんが、mariadb コマンド（従来の mysql クライアントの置き換え）が標準化されており、スクリプト内のコマンド名に注意が必要です。

Galera Cluster（MariaDB の同期マルチマスター実装）を使っている場合、GTID の扱いが若干異なります。Galera は独自の wsrep GTID を持ち、通常の非同期レプリケーションの GTID とは別管理になるため、Galera クラスターへの非同期スレーブを構成する際には wsrep_gtid_mode = ON の設定が必要です。

また、MaxScale（MariaDB 公式のプロキシ）を使ってフェイルオーバーを自動化している環境では、MaxScale 側の monitor モジュールが GTID を認識して昇格候補を自動選定します。手動フェイルオーバーを自動化する第一歩として、MaxScale の mariadbmon モジュールの評価も有用です。手動フェイルオーバーの手順を整備した上で、段階的に自動化へ移行するアプローチが安全です。

クラウド環境（AWS RDS for MariaDB、Azure Database for MariaDB）では GTID が内部的に使われていますが、gtid_slave_pos の直接操作や RESET SLAVE ALL には制限がある場合があります。マネージドサービスでは各プロバイダーのフェイルオーバー機構（RDS の Multi-AZ 等）に委ねる構成が基本となり、今回説明した手動手順は自己管理サーバーへの適用を前提としています。