mariadb-replication-and-ha

MariaDB レプリケーションと高可用性

最終更新日：2026-06-24

MariaDB では、一貫性と可用性の要件に応じて、3 種類のレプリケーションを利用できます。

アプローチ	一貫性	フェイルオーバー	最適な用途
標準の非同期レプリケーション	結果整合性	手動またはツールによる支援	読み取りのスケーリング、バックアップ、低レイテンシの書き込み
準同期レプリケーション	結果整合性（非同期と同じ）	手動またはツールによる支援	クライアントに確認応答を返す前に、各コミットをレプリカが受信したことを保証します。これによりフェイルオーバー時の損失を制限します（AFTER_SYNCの場合のみ損失を防止できます）
Galera Cluster	同期（マルチプライマリ）	自動	データ損失ゼロの HA、マルチデータセンターでの書き込み

要件： GTID レプリケーション、準同期レプリケーション、並列レプリケーション（optimistic モードを含む）はすべて組み込み機能であり、現在サポートされているすべてのリリースよりも前から利用できます。11.8 LTS を基準として、これらの機能が利用可能であると想定してください。現在の LTS は 11.8 です（2025 年 5 月 GA）。

デフォルトの前提： ユーザーが別のバージョンを指定しない限り、MariaDB 11.8 LTS を想定してください。関連する場合は、12.x または 13.0 と記された機能を（アップグレードの選択肢を含めて）提案できますが、必ず最小バージョンを明記してください。11.8 で利用可能な機能として提示してはいけません。

LLM が間違えやすい点

見かけることがある記述	正しい情報
CHANGE REPLICATION SOURCE TO、接続オプション SOURCE_*	MariaDB に CHANGE REPLICATION SOURCE TO はありません。MASTER_* オプションを指定して CHANGE MASTER TO を使用してください。10.5.1 以降では START REPLICA / SHOW REPLICA STATUS が標準であり、START SLAVE / SHOW SLAVE STATUS は旧式のエイリアスです
値が DATABASE または LOGICAL_CLOCK の replica_parallel_type	MariaDB では slave_parallel_mode（optimistic / conservative / aggressive / minimal / none）を使用します。これは異なる実装であり、MySQL のモード設定はそのまま移行できません。プールサイズは slave_parallel_threads で指定します
MySQL の GTID 形式または gtid_mode=ON 構文	MariaDB の GTID は異なる形式（domain-server-seq）と異なるコマンドを使用します。MySQL と MariaDB の GTID に互換性はありません
MySQL Group Replication または InnoDB Cluster — START GROUP_REPLICATION、group_replication_* 変数、MySQL Shell の dba.createCluster()	MariaDB に Group Replication や InnoDB Cluster はありません。Group Replication はMariaDB と互換性がありません。同期マルチプライマリの同等機能はGalera Cluster（組み込み）です
「Galera プラグインをインストールする」	読み込む Galera プラグインはありません。wsrep のサポートは MariaDB サーバーに組み込まれています。ただし、クラスターには別途 Galera wsrep プロバイダーライブラリ（galera-4 / libgalera_smm.so、wsrep_provider で設定）が必要です。12.3 以降では自分でインストールする必要があります（Galera Cluster のセクションを参照）
Galera で連番の AUTO_INCREMENT が生成されると思い込む	Galera では設計上、ノード間で自動採番の連番に欠番が生じます。連続した値を前提にしてはいけません
Galera 環境で LOCK TABLES または GET_LOCK() を使用する	Galera ではサポートされていません。代わりにトランザクションを使用してください
レプリカをバックアップとして扱う	レプリケーションはバックアップではありません。プライマリでの DROP TABLE は、すぐにすべてのレプリカへレプリケーションされます
Galera クラスター内で主キーのないテーブルを使用する	Galera のすべてのテーブルには主キーが必要です。キーのないテーブルでは DELETE が失敗します

標準的な非同期レプリケーション

基本構成は、プライマリが1台、レプリカが1台以上です。プライマリがバイナリログに書き込み、レプリカが変更を非同期で適用します。

GTIDベースのレプリケーションは、MariaDB 10.10以降のデフォルト（MDEV-19801）であり、10.11 LTS、11.4 LTS、11.8 LTSでも引き続きデフォルトです。レプリカの新規起動時、RESET SLAVE の実行時、または MASTER_USE_GTID を指定しない CHANGE MASTER TO の実行時には、レプリカは従来のファイル／ポジションではなく、デフォルトで slave_pos を使用します。以前の動作に依存する設定がある場合は、MASTER_USE_GTID=no を明示的に設定してください。

-- On replica (10.10+ — MASTER_USE_GTID is optional, slave_pos is the default):
CHANGE MASTER TO
  MASTER_HOST='primary.host',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='password',
  MASTER_USE_GTID = slave_pos;

START SLAVE;

レプリカをプライマリに昇格する場合 — 以前は、ローカルで書き込まれたGTIDを含めるために MASTER_USE_GTID=current_pos が使われていました。current_pos は10.10以降非推奨（MDEV-20122）です。代わりに MASTER_DEMOTE_TO_SLAVE=1 を使用してください。これにより、旧プライマリの gtid_binlog_pos が gtid_slave_pos に変換され、降格されたサーバーは競合状態を起こさずに新しいプライマリへ接続できます。

-- On the former primary, being demoted to a replica (10.10+):
CHANGE MASTER TO
  MASTER_HOST='new_primary.host',
  ...,
  MASTER_DEMOTE_TO_SLAVE=1;
START SLAVE;

MariaDB 13.0以降では、CHANGE MASTER によって SHOW SLAVES STATUS の Master_Server_Id もリセットされます。旧バージョンでは、プライマリの切り替え後もこのフィールドに古い値が残ることがありました。13.0より前のサーバーでレプリケーションを再設定する際は、この値を明示的に確認してください。

MariaDB GTID形式

MariaDBのGTIDは、domain_id-server_id-sequence の3つの要素で構成されます（例：0-1-247）。

これはMySQLの server_uuid:sequence 形式とは異なります。両者に互換性はありません。MariaDBのプライマリはGTIDを使ってMySQLのレプリカにレプリケーションできず、その逆も同様です。

ドメインID（gtid_domain_id）は、独立したレプリケーションストリームを識別します。重要なのはサーバー数ではなく、書き込みの同時実行性です。すべてのサーバーにそれぞれ異なるドメインIDを割り当てるのは、よくある重大な誤りです。

• 単一のアクティブなプライマリ（単純なフェイルオーバーを含む）： すべてのサーバーで gtid_domain_id = 0 のままにします。A → B のペアで、後に B が昇格する（つまり B → A になる）場合、A と B は同じドメインIDを共有します。異なるIDを割り当てないでください。
• 複数のプライマリを同時に更新する場合（マルチソース、または1つのトポロジ内のマルチプライマリ）：同時に更新される各プライマリにそれぞれ異なる gtid_domain_id を割り当てます。これにより、各ストリームの順序が独立して保たれ、自動GTIDレプリカ切り替えが正しく機能します。

-- Multi-source / multi-primary ONLY — each concurrently-written primary gets its own domain:
SET GLOBAL gtid_domain_id = 1;   -- on primary A
SET GLOBAL gtid_domain_id = 2;   -- on primary B

それ以外の場合、サーバーごとに異なるドメインIDを割り当てると、GTIDポジションが複雑になり、単一の順序付きバイナリログストリームが失われます。グローバルトランザクションIDを参照してください。

ドメインIDの設定とあわせて gtid_strict_mode を有効にしてください。レプリカのポジションが破損する前に、GTIDの順序が前後する誤りやドメインが混在する誤りを検出できます。

# my.cnf on all servers:
gtid_strict_mode = ON

厳格モードがONの場合、レプリカはGTIDの順序違反時にエラーで停止し、順序が前後したトランザクションを黙って適用することはありません。無効の場合は、完全な再同期以外に修正方法がなくなるまで、ドメインIDの設定ミスが検出されないことがあります。

マルチソースレプリケーションでは、レプリケーションのコマンドと変数（START SLAVE、SHOW SLAVE STATUS、…）は、default_master_connection で指定された接続を対象にします。これはセッション単位の設定だったため、あるソースのコマンドを実行する前に、各セッションで SET SESSION default_master_connection='name' を実行する必要がありました。MariaDB 13.0以降（MDEV-9247）はグローバルにも設定でき、選択した名前付き接続をすべてのセッションのデフォルトにできます。

並列レプリケーション

デフォルトでは、レプリカはイベントを直列に適用します。slave_parallel_threads のデフォルト値は 0 であり、モード設定に関係なく、初期状態では並列レプリケーションは無効です。有効にするには、次のように設定します。

# my.cnf on replica:
slave_parallel_threads = 4          # must be > 0 to enable parallel apply
slave_parallel_mode = optimistic    # default since 10.5.1 — tries parallel, retries on conflict

optimistic モードでは、トランザクションを並列に適用し、競合が発生した場合は再試行します。競合時の再試行が許容されない、より厳格なワークロードでは conservative を使用してください。

MySQL とは異なります： MariaDB の slave_parallel_mode（optimistic、conservative など）は独自の実装であり、MySQL の replica_parallel_type（DATABASE／LOGICAL_CLOCK）と同等ではありません。MySQL の並列レプリケーションモード設定をそのままコピーしても動作しません。プールサイズには slave_parallel_threads（別名 slave_parallel_workers）を使用します。

MariaDB 12.1 以降では、2 つの Galera クラスター間で非同期レプリケーションを行う場合も並列レプリケーションが機能します（MDEV-20065）。これは、一方の Galera クラスターをもう一方の非同期レプリカとする、データセンター間または DR 構成で役立ちます。

10.7～10.11 LTS のレプリケーションの改善

• 2 フェーズの ALTER TABLE レプリケーション（10.8 以降、MDEV-11675、binlog_alter_two_phase）— オプトイン機能です。有効にすると、大規模な ALTER TABLE の実行中に、プライマリでの実行が完了する前からレプリカで処理を開始できます。これにより、スキーマ変更中のレプリケーション遅延を軽減できる場合があります。デフォルトでは無効です。高度な実験的機能として扱い、本番環境でデフォルトとして有効にするのではなく、依存する前に十分に検証してください。
• GTID に対応した mariadb-binlog（10.8 以降、MDEV-4989）— --start-position と --stop-position に GTID リストを指定できるため、特定時点へのリプレイツールで、binlog ファイルとオフセットの組み合わせを使わずに GTID を直接指定できます。（これとは別に、デフォルトで有効な --gtid-strict-mode は安全対策にすぎません。ドメインごとに GTID のシーケンス番号が単調増加していることを確認し、順序が前後したイベントがあると中断します。GTID による指定を有効にするものではありません。）mariadb-binlog を参照してください。
• slave_max_statement_time（10.10 以降、MDEV-27161）— レプリカの SQL スレッドで単一のステートメントを実行できる時間の上限を設定します。レプリケートされたステートメントがこの時間を超えると、SQL スレッドはエラーで停止し（エラー 3024）、遅いクエリや暴走したクエリが、気付かないうちに遅延を増大させるのではなく、表面化します。ステートメントをスキップして続行することはありません。調査して再起動するまで、レプリケーションは停止します。
• mariadb-binlog --do-domain-ids／--ignore-domain-ids／--ignore-server-ids（10.9 以降、MDEV-20119）— binlog イベントの抽出時に、ドメインやサーバーでフィルタリングできます。
• マルチソースレプリケーションの CHANNEL 構文（10.7 以降、MDEV-26307）— CHANGE MASTER TO、START SLAVE などで、MySQL 形式の FOR CHANNEL 'name' 句を使用できるようになりました。

11.4 LTS のレプリケーション改善

• バイナリログのディスク使用量に対するグローバルな上限（11.4 以降、MDEV-31404）— max_binlog_total_size（別名 binlog_space_limit、デフォルト 0 = 上限なし）は、すべてのバイナリログの合計サイズがしきい値を超えると、バイナリログのパージを実行します。--slave-connections-needed-for-purge（デフォルト 1）と組み合わせると、設定済みのレプリカが切断されている場合にパージが実行されなくなります。新しいステータス変数 binlog_disk_use で現在のディスク使用量を確認できます。
• バイナリログ用の GTID インデックス（11.4 以降、MDEV-4991）— 新しい GTID から位置へのインデックスにより、再接続するレプリカはバイナリログファイル全体をスキャンせずに、開始位置へ直接移動できます。binlog_gtid_index（デフォルト ON）、binlog_gtid_index_page_size、binlog_gtid_index_span_min で制御します。ステータス変数 binlog_gtid_index_hit / binlog_gtid_index_miss で、使用されていることを確認できます。
• START SLAVE UNTIL での SQL_BEFORE_GTIDS / SQL_AFTER_GTIDS（11.4 以降、MDEV-27247）— 段階的なフェイルオーバーや PITR の再生で、より細かく停止位置を指定できます。
• レプリケーション遅延の詳細フィールド（11.4 以降、MDEV-29639）— SHOW REPLICA STATUS に Master_last_event_time、Slave_last_event_time、Master_Slave_time_diff が追加され、Seconds_Behind_Master だけの場合よりも遅延を明確に把握できます（この機能を基にした 11.6 の更新については、以下を参照してください）。

11.7 のバイナリログ性能改善

• 大規模トランザクションのコミットで他のトランザクションが停止しなくなりました（11.7 以降、MDEV-32014）— 以前は、log_bin が有効な状態で非常に大規模なトランザクションをコミットすると、バイナリログへの書き込みが完了するまで他のすべてのトランザクションが停止していました。このボトルネックは解消されました。
• バイナリログのクラッシュリカバリ中に、準備済みトランザクションを非同期でロールバック（11.7 以降、MDEV-33853）— 準備済みトランザクションが多い状態でクラッシュした後の起動が高速になります。
• slave_abort_blocking_timeout（11.7 以降、MDEV-34857）— レプリカで長時間実行されているクエリが、しきい値を超えてレプリケーションの進行を妨げている場合に、そのクエリを終了します。長時間の分析クエリがときどき実行される読み取りレプリカで役立ちます。

レプリケーション遅延の監視

SHOW SLAVE STATUS\G
-- Key fields:
-- Seconds_Behind_Master: estimated lag in seconds
-- Last_SQL_Error: last error stopping the SQL thread
-- Relay_Log_Pos vs Read_Master_Log_Pos: how far behind the relay log is

レイテンシに敏感なアプリケーションでは、Seconds_Behind_Master > 5 のときにアラートを出してください。値が NULL の場合、レプリケーションは実行されていません。注意：アイドル状態のプライマリでは Seconds_Behind_Master が誤解を招くことがあります。正確に測定するには、ハートビートツール（例：pt-heartbeat）を使用してください。

MariaDB 11.6（MDEV-33856）以降、Seconds_Behind_Master の定義が改良され、SHOW ALL REPLICAS STATUS に 3 つの新しい列が追加されたほか、新しい Information Schema テーブル SLAVE_STATUS が追加されました。これにより、より詳細な遅延の把握（例：IO スレッドと SQL スレッドの遅延を個別に測定）が可能になります。

準同期レプリケーション

プライマリは各トランザクションをまず自身のバイナリログに書き込み、fsync してローカルで永続化してから、少なくとも 1 台のレプリカがそのトランザクションを受信したと確認するのを待ち、コミット完了をクライアントに通知します。rpl_semi_sync_master_wait_point 設定で、この待機のタイミングを制御します。AFTER_SYNC の場合、変更が可視になる前にプライマリが待機するため、確認済みのレプリカへのフェイルオーバーでデータが失われません。MariaDB のデフォルトである AFTER_COMMIT の場合、待機前にトランザクションがすでにコミットされ、可視になっているため、その間にクラッシュすると、フェイルオーバー時にトランザクションが失われる可能性があります。準同期レプリケーションを参照してください。

-- Enable on primary:
SET GLOBAL rpl_semi_sync_master_enabled = 1;

-- Enable on replica:
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

rpl_semi_sync_master_timeout（デフォルト 10 秒）以内にレプリカから確認応答がない場合、プライマリは非同期レプリケーションにフォールバックします。MariaDB 10.3 以降に組み込まれているため、プラグインは不要です。

使用する場面：クライアントへのコミット完了応答が返る前に、少なくとも 1 台のレプリカが各トランザクションを受信したことを保証したい場合です。たとえば、フェイルオーバー時のデータ損失を抑えるには AFTER_SYNC を使用します。準同期レプリケーションは、クライアントから見たコミット完了を遅らせるだけであり、プライマリ側のコピーの永続性を高めるものではありません。どのレプリカも受信する前に失われたトランザクションは、準同期レプリケーションを使用していても失われます。

Galera Cluster

マルチプライマリの同期レプリケーションです。すべてのノードで読み取りと書き込みを受け付け、変更はコミット前にクラスター全体で認証されます。単一障害点はありません。MariaDB に組み込まれています。

パッケージングの変更（12.3+）： Galera ライブラリは、サーバーパッケージの依存関係として、または MariaDB リポジトリからデフォルトでは提供されなくなりました（MDEV-38744）。12.3+ では、Galera ノードをセットアップする際に galera-4（またはディストリビューション相当のパッケージ）を別途インストールする必要があります。MariaDB サーバーは引き続き Galera をネイティブに理解します。変更されたのはライブラリの配布方法のみです。

開発者向けの制約

次の点を把握していないと、Galera で問題が発生します。

すべてのテーブルに主キーが必要です：

-- ✗ DELETE fails in Galera on keyless tables:
CREATE TABLE logs (message TEXT);

-- ✅ Always define a PK:
CREATE TABLE logs (id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, message TEXT);

AUTO_INCREMENT の値には欠番が生じます — Galera はノードごとに auto_increment_increment と auto_increment_offset を使用して競合を回避するため、ID は連番になりません。Galera では、AUTO_INCREMENT が連番になることを前提にしないでください。

LOCK TABLES、GET_LOCK()、および FLUSH TABLES {table list} WITH READ LOCK はサポートされていません — トランザクションを使用してください。注：グローバルな FLUSH TABLES WITH READ LOCK（テーブルリストなし）はサポートされています：

-- ✗ Not supported in Galera:
LOCK TABLES orders WRITE;
-- ✅ Use a transaction instead:
BEGIN;
SELECT ... FOR UPDATE;
UPDATE ...;
COMMIT;

InnoDB のみ — Galera がレプリケーションするのは InnoDB テーブルのみです。MyISAM は wsrep_replicate_myisam による実験的なサポートがありますが、本番環境での使用は推奨されません。

トランザクションサイズの上限 — デフォルトの上限は、128K 行（wsrep_max_ws_rows）および 2GB（wsrep_max_ws_size）です。極端に大きなトランザクションはクラスターのパフォーマンスを大幅に低下させるため、設定の調整が必要になることがあります。注：MariaDB 13.0+ では、binlog_row_event_max_size のデフォルト値は 64 KB です（従来の 8 KB から増加）。書き込み負荷の高いワークロードでレプリケーションイベントのサイズを決める際に関係します。

バイナリログは ROW 形式である必要があります — Galera クラスターの実行中に binlog_format を変更しないでください。

競合時の書き込みセットの再試行（12.1+）— wsrep_applier_retry_count は、エラーになる前にアプライヤーが書き込みセットを再試行する回数を制御します。負荷の高いクラスターで一時的な認証競合が発生するワークロードでは、この値を調整してください。

SST ユーザーアカウントの自動管理（11.6+、MDEV-31809）— Galera は専用の SST（State Snapshot Transfer）ユーザーアカウントを自動で管理するようになりました。各ノードで手動で作成して権限を付与する必要はありません。

クラスターに参加するノードの IP 許可リスト（10.10+、MDEV-27246）— wsrep_allowlist は SST/IST リクエストを実行できる IP を制限し、Galera クラスターのノード間通信における攻撃対象領域を縮小します。

クエリーキャッシュ： クエリーキャッシュは MariaDB の後続バージョンで削除されており、MariaDB 10.1.2 以降の Galera では不要でした。最新のインストール環境では対応は不要です。

古い読み取りと一貫性

Galera は「仮想同期型」です。あるノードでコミットされた書き込みが、追加の同期なしでは別のノードですぐに参照できるとは限りません：

-- Force a sync point before reading (performance cost):
SET SESSION wsrep_sync_wait = 1;
SELECT * FROM orders WHERE id = 42;

厳密な読み取り後書き込み一貫性が必要な場合に限り、wsrep_sync_wait を使用してください。ほとんどの読み取りでは、ノード間で数ミリ秒の結果整合性が許容されます。

Galera における更新の消失

Galera は、読み取り・変更・書き込みパターンにおける更新の消失を防ぎません。明示的に SELECT ... FOR UPDATE を使用してください：

-- ✗ Race condition — another node could modify between SELECT and UPDATE:
SELECT balance FROM accounts WHERE id = 1;
-- ... application logic ...
UPDATE accounts SET balance = new_value WHERE id = 1;

-- ✅ Lock the row at read time:
BEGIN;
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
UPDATE accounts SET balance = new_value WHERE id = 1;
COMMIT;

レプリケーションはバックアップではありません

プライマリでの DROP TABLE や DELETE FROM table は、すぐにすべてのレプリカに複製されます。レプリケーションはハードウェア障害から保護するものであり、誤ったデータ変更から保護するものではありません。レプリケーションとは別のスケジュールで、独立したバックアップ（mariadb-dump、mariadb-backup）を維持してください。

遅延レプリケーションは対策の一つです。レプリカを意図的に一定時間遅延させます。

CHANGE MASTER TO MASTER_DELAY = 3600;  -- 1 hour lag

これにより、誤った変更からの復旧時間を確保できますが、バックアップの代わりにはなりません。

ポイントインタイムリカバリ（13.0で新登場） — innodb_log_archive 変数（MDEV-37949）を使用すると、InnoDB は循環型のリドゥログを上書きする代わりに、先行書き込みログを連続したファイルとして保持します。ベースバックアップと組み合わせることで、バイナリログだけに依存せずに、PITR と増分バックアップを可能にすることを目的としています。これは13.0 ローリングリリースで新登場した機能であり（11.8 LTS のベースラインには含まれません）、新しい機能として扱い、リカバリに依存する前に検証してください。

フェイルオーバーツール

• 組み込み（プロキシ不要） — Galera のフェイルオーバーは自動で行われ、稼働中のノードはいずれも書き込みを受け付け続けます。非同期／GTID レプリケーションでは、MariaDB は GTID と MASTER_DEMOTE_TO_SLAVE を使って、制御されたプライマリの切り替えをネイティブに実行します（上記の標準的な非同期レプリケーションを参照）。通常は、独自のスクリプトまたはオーケストレーターによって実行します。
• ProxySQL — MariaDB での読み書き分割とコネクションプーリングに広く使用されている、オープンソース（GPLv3）のプロキシです。
• MaxScale — 自動フェイルオーバー、読み書き分割、接続ルーティングを備えた MariaDB Corporation のプロキシです（プライマリの障害を検出し、最も最新のレプリカを昇格させます。GTID レプリケーションが必要です）。オープンソースではありません — 最近のバージョン（25.01 以降）はクローズドソースの商用製品であり、それ以前のバージョンは OSI 承認のオープンソースライセンスではなく、ソース公開型の Business Source License（BSL）を使用していました。mariadb.com/docs/maxscale

基本的な Galera の HA にはプロキシは不要です。ProxySQL または MaxScale を追加すると、接続ルーティングが可能になります。

Galera の負荷分散には、クラスタ状態を把握するモニタリングが必要です。 すべての Galera ノードに均等にルーティングしないでください。SST（全データのコピー）中または非同期化された状態のノードは、稼働して接続を受け付けていても、数百万のトランザクション分遅れている可能性があります。wsrep_local_state を確認し、4（同期済み）の場合にのみトラフィックをルーティングしても安全です。ProxySQL は wsrep_ ステータス変数を監視するヘルスチェックを設定できます。MaxScale はこの目的で galeramon モニターを使用します。状態を考慮したルーティングを行わない場合、ドナー／非同期化されたノードへの書き込みにより、古い読み取り結果や整合性の問題が発生します。

参考資料

• レプリケーションの概要 — MariaDB ドキュメント
• GTID — MariaDB ドキュメント
• 並列レプリケーション — MariaDB ドキュメント
• 準同期レプリケーション — MariaDB ドキュメント
• Galera Cluster の既知の制限事項 — MariaDB ドキュメント
• Galera の自動インクリメント — mariadb.org
• MariaDB Monitor による自動フェイルオーバー — MaxScale ドキュメント

ここで取り上げていないトピックについては、公式の MariaDB ドキュメント（mariadb.com/docs）を参照してください。