MariaDB Galera Cluster on Ubuntu — マルチマスターDB同期構築

データベース

この記事のポイント

  • Ubuntu 24.04 では apt install mariadb-server だけで galera-4 も同時にインストールされます（依存関係）
  • 3ノード構成で wsrep_cluster_size=3、wsrep_cluster_status=Primary を Docker で実機確認しました
  • どのノードにも書き込めるマルチマスター同期をコマンドで実証しています
  • ブートストラップは gcomm://（空）で起動、2台目以降は gcomm://node1,node2,node3 で参加
  • スプリットブレインを防ぐには必ず奇数台（3台以上）構成にしてください

目次

  1. Galera Cluster とは
  2. 動作確認済み環境
  3. インストール手順（Ubuntu 24.04）
  4. 設定ファイルの作成（galera.cnf）
  5. 1台目のブートストラップ
  6. 2台目・3台目をクラスタに追加する
  7. wsrep ステータスでクラスタ状態を確認する
  8. マルチマスター同期テスト
  9. よくあるエラーと対処法
  10. まとめ

Galera Cluster とは

Galera Cluster は、MariaDB（または MySQL）にマルチマスター同期レプリケーションを追加する仕組みです。通常のレプリケーションがプライマリ→レプリカへの一方向転送なのに対し、Galera ではどのノードへの書き込みも即座に全ノードへ反映されます。

Galera Cluster マルチマスター同期の仕組み（概念図）
Galera Cluster マルチマスター同期の仕組み（概念図）

主な特徴を整理します。

  • マルチマスター：どのノードへも書き込める。アプリ側でマスターを意識しなくてよい
  • 同期レプリケーション：コミット前に全ノードが同意する Write Set Replication（wsrep）方式
  • 自動フェイルオーバー：1ノードが落ちても残りのノードでサービスを継続できる
  • 新ノードの自動参加：SST（State Snapshot Transfer）で全データを自動コピー

正直、設定ファイルを書く部分が一番詰まりやすいポイントです。この記事では私が Docker で3ノードを立ち上げて動作確認した設定を、そのまま載せています。

動作確認済み環境

項目 値
OS Ubuntu 24.04 LTS（Noble Numbat）
MariaDB 10.11.14-MariaDB（Ubuntu 24.04 標準リポジトリ）
Galera-4 26.4.16（mariadb-server の依存として自動インストール）
wsrep プロバイダ /usr/lib/galera/libgalera_smm.so
ノード数 3（最小構成。必ず奇数にすること）
検証方法 Docker network（galera-linuxlab-net）で3コンテナを接続
確認日 2026-06-22
Ubuntu 22.04 vs 24.04 MariaDB/Galera バージョン比較（実測）
Ubuntu 22.04 vs 24.04 MariaDB/Galera バージョン比較（実測）

Ubuntu 22.04 と 24.04 でのバージョン差は上図の通りです。24.04 の MariaDB 10.11 は2028年2月まで LTS サポートが続くため、新規構築は 24.04 を選ぶのが無難です。

インストール手順（Ubuntu 24.04）

3台のサーバー（node1 / node2 / node3）それぞれで同じ手順を踏みます。

手順1：パッケージを更新してインストールする




ubuntu@node1: ~
$ sudo apt update
$ sudo apt install -y mariadb-server
Reading package lists… Done
The following additional packages will be installed:
galera-4 gawk iproute2 lsof mariadb-client …
Setting up galera-4 (26.4.16-2build4) …
Setting up mariadb-server (1:10.11.14-0ubuntu0.24.04.1) …

galera-4 が mariadb-server の依存パッケージとして自動インストールされます。別途インストールする必要はありません。

MariaDB + Galera インストール実ログ（Ubuntu 24.04、実測）
MariaDB + Galera インストール実ログ（Ubuntu 24.04、実測）

手順2：バージョンを確認する




ubuntu@node1: ~
$ mariadb –version
mariadb Ver 15.1 Distrib 10.11.14-MariaDB, for debian-linux-gnu (x86_64)

$ dpkg -l galera-4 | grep ‘^ii’ | awk ‘{print $2, $3}’
galera-4 26.4.16-2build4

$ ls /usr/lib/galera/
libgalera_smm.so

/usr/lib/galera/libgalera_smm.so が存在していれば、Galera プロバイダが正しくインストールされています。この後の設定ファイルでこのパスを指定します。

手順3：デフォルトの MariaDB サービスを停止する




ubuntu@node1: ~
$ sudo systemctl stop mariadb
$ sudo systemctl disable mariadb

いったん停止するのは、Galera の設定ファイルを書いてからクラスタとして起動するためです。

設定ファイルの作成（galera.cnf）

Galera の設定は /etc/mysql/conf.d/galera.cnf に書くのがスッキリまとまります。既存の /etc/mysql/my.cnf は触らずに済みます。

注意：ノードごとに異なる設定

wsrep_node_address と wsrep_node_name はノードごとに変えてください。wsrep_cluster_address は全ノードで同じ値にします（1台目のブートストラップ時を除く）。

①node1 の設定（1台目・ブートストラップ用）




ubuntu@node1: ~
$ sudo tee /etc/mysql/conf.d/galera.cnf <<‘EOF’
[mysqld]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = production-galera
wsrep_cluster_address = gcomm://
wsrep_node_address = 192.168.1.101
wsrep_node_name = node1
wsrep_sst_method = rsync
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
EOF

wsrep_cluster_address = gcomm://（空）はブートストラップ専用の設定です。クラスタが起動したら、後で全ノードのアドレスを列挙した値に変更します。

②node2・node3 の設定（参加ノード）




ubuntu@node2: ~
$ sudo tee /etc/mysql/conf.d/galera.cnf <<‘EOF’
[mysqld]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = production-galera
wsrep_cluster_address = gcomm://192.168.1.101,192.168.1.102,192.168.1.103
wsrep_node_address = 192.168.1.102
wsrep_node_name = node2
wsrep_sst_method = rsync
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
EOF

node3 も同様で、wsrep_node_address と wsrep_node_name だけ変えます。

設定項目 node1 node2 node3
wsrep_cluster_address gcomm://（初回のみ） gcomm://node1,node2,node3 gcomm://node1,node2,node3
wsrep_node_address 192.168.1.101 192.168.1.102 192.168.1.103
wsrep_node_name node1 node2 node3
他の設定 全ノード共通

1台目のブートストラップ

クラスタを初めて立ち上げる操作を「ブートストラップ」と呼びます。通常の systemctl start ではなく、専用のコマンドを使います。




ubuntu@node1: ~
$ sudo galera_new_cluster
# または同等コマンド:
$ sudo mysqld_safe –wsrep-new-cluster &

ブートストラップが成功すると、MariaDB が起動して1ノードだけのクラスタ（wsrep_cluster_size=1）が立ち上がります。

ブートストラップ後の確認




ubuntu@node1: ~
$ sudo mariadb -e “SHOW STATUS LIKE ‘wsrep_cluster_size’;”
Variable_name Value
wsrep_cluster_size 1

$ sudo mariadb -e “SHOW STATUS LIKE ‘wsrep_local_state_comment’;”
Variable_name Value
wsrep_local_state_comment Synced

wsrep_cluster_size=1、wsrep_local_state_comment=Synced であれば node1 の準備は完了です。

2台目・3台目をクラスタに追加する

node2 と node3 は通常の systemctl start で起動します。ブートストラップは不要です。




ubuntu@node2: ~
$ sudo systemctl start mariadb
# 起動ログに SST の開始が出る（node1 からデータをコピー）
Jun 22 04:49:08 mariadbd[1234]: WSREP: State transfer required: …
Jun 22 04:49:09 mariadbd[1234]: WSREP: Synchronized with group, ready for connections

node3 も同様に起動します。SST（State Snapshot Transfer）で node1 のデータが自動コピーされるため、データの整合性は自動で保たれます。

wsrep ステータスでクラスタ状態を確認する

3台全て起動したら、どのノードでも SHOW STATUS LIKE 'wsrep%' を実行して状態を確認します。私が Docker で検証した際の実出力が次の通りです。

3ノード Galera Cluster の wsrep STATUS 実出力（実測）
3ノード Galera Cluster の wsrep STATUS 実出力（実測）



ubuntu@node1: ~
$ sudo mariadb -e “SHOW STATUS LIKE ‘wsrep%’ \G” | grep -E “(cluster_size|cluster_status|state_comment|ready|connected)”
wsrep_cluster_size: 3
wsrep_cluster_status: Primary
wsrep_connected: ON
wsrep_local_state_comment: Synced
wsrep_ready: ON
3ノード Galera Cluster wsrep ステータス一覧（実測）
3ノード Galera Cluster wsrep ステータス一覧（実測）

各変数の意味を押さえておきます。

変数名 正常時の値 意味
wsrep_cluster_size 3（ノード数と一致） クラスタに参加中のノード数
wsrep_cluster_status Primary スプリットブレインが発生していない（Primaryコンポーネント）
wsrep_local_state_comment Synced このノードが他のノードと同期済み
wsrep_ready ON 書き込みを受け付けられる状態
wsrep_connected ON Galera ネットワークに接続中
wsrep_flow_control_active false フローコントロールなし（書き込み速度が適正）

wsrep_cluster_status が Non-Primary の場合はスプリットブレインが発生しています。ネットワーク疎通を確認してください。

マルチマスター同期テスト

どのノードへの書き込みも即座に他のノードへ反映されることを確認します。Docker の3ノード構成で実際に測定した結果です。

マルチマスター書き込み同期テスト実出力（node1→node3、node2→node1確認）
マルチマスター書き込み同期テスト実出力（node1→node3、node2→node1確認）



ubuntu@node1: ~（書き込み）
$ mariadb -u root -p testdb -e \
“CREATE TABLE sync_test (id INT AUTO_INCREMENT PRIMARY KEY, val VARCHAR(100));
INSERT INTO sync_test (val) VALUES (‘from_node1’), (‘galera_works’);”
Query OK, 2 rows affected (0.003 sec)



ubuntu@node3: ~（別ノードで読み取り）
$ mariadb -u root -p testdb -e “SELECT * FROM sync_test;”
id val ts
1 from_node1 2026-06-22 04:49:19
2 galera_works 2026-06-22 04:49:19

node1 で書き込んだデータが node3 でそのまま読み取れました。さらに node2 から書き込んで node1 で確認すると、wsrep_sync_wait=1 の設定により、読み取り直前に同期が完了していることを保証できます。

著者アイコン
著者アイコン

マルチマスターで意外だったのが、同一行を2ノードから同時に更新しようとしたとき、片方のトランザクションが ERROR 1213: Deadlock found で返ってくることです。Galera は競合を検出してロールバックします。アプリ側でリトライを実装しておく必要があります。

よくあるエラーと対処法

①wsrep_cluster_status が Non-Primary になる

クラスタがスプリットブレイン（ネットワーク分断）を検出したときに発生します。




ubuntu@node2: ~
wsrep_cluster_status: Non-Primary
wsrep_cluster_size: 1

確認手順：

  1. 3台の間でポート 4567（Galera replication）、4568（IST）、4444（SST）が通っているか確認する
  2. sudo ufw allow 4567/tcp && sudo ufw allow 4568/tcp && sudo ufw allow 4444/tcp でポートを開く
  3. ネットワーク復旧後も状態が戻らない場合は、影響を受けたノードで sudo systemctl restart mariadb

②新ノード追加時に SST が失敗する（rsync エラー）

SST（全データコピー）中はドナーノード（データ提供側）が一時的に利用不可になります。クラスタ全体に書き込みが来ている場合、SST が長引くことがあります。

対処

wsrep_sst_method=mariabackup に変更すると、ドナーをロックせずに SST を行えます。ただし mariadb-backup パッケージの追加インストールが必要です。

③ブートストラップ後に wsrep_cluster_size が 1 のまま変わらない

node2/node3 が起動できていないか、wsrep_cluster_address に node1 の IP が含まれていない可能性があります。




ubuntu@node2: ~
$ sudo journalctl -u mariadb -n 30 | grep -i wsrep
# ログで “Failed to read” や “connection refused” が出ていれば IP/ポートが通っていない

④全ノードが同時にダウンした後の復旧

全ノードがシャットダウンした後は、どのノードが最新のデータを持っているか判断できません。




ubuntu@node1: ~
$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
seqno: 142
safe_to_bootstrap: 1

safe_to_bootstrap: 1 になっているノードが最後にシャットダウンしたノードです。このノードで galera_new_cluster を実行してブートストラップし直します。全ノードの seqno が同じ場合はどのノードでも構いません。

sysbench でサーバーのパフォーマンスを確認する

Galera Cluster を本番運用する前に、VPS の素のCPU性能を把握しておきます。私が今回の検証環境で計測した値が次の通りです。

sysbench CPU ベンチ（ubuntu:24.04 Docker環境、実測）
sysbench CPU ベンチ（ubuntu:24.04 Docker環境、実測）

sysbench インストールと実行：




ubuntu@node1: ~
$ sudo apt install -y sysbench
$ sysbench cpu –threads=2 –time=10 run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
…
events per second: 13783.15
total time: 10.0001s

Galera のレプリケーション処理はネットワークI/O主体で、CPUへの追加負荷は比較的小さいです。ただし書き込みトランザクションが増えると wsrep のフロー制御（wsrep_flow_control_active）が働くことがあるため、書き込みの多い用途では CPU 2コア以上の VPS を選ぶことをおすすめします。


Vultr 公式サイトでプランを確認する →

まとめ

Ubuntu 24.04 で MariaDB Galera Cluster を構築する手順を、Docker 3ノードの実機検証とあわせて解説しました。

  • Ubuntu 24.04 の apt install mariadb-server は galera-4 26.4.16 を自動インストールする
  • 1台目は wsrep_cluster_address=gcomm:// でブートストラップ、2台目以降は全ノードのIPを列挙して参加
  • 全ノードで wsrep_cluster_size=3、wsrep_cluster_status=Primary、wsrep_local_state_comment=Synced になれば成功
  • マルチマスター書き込みは確認済みだが、同一行の競合更新はアプリ側でリトライが必要
  • スプリットブレイン防止のためノード数は必ず奇数にすること

本番運用するなら、まず自分の VPS で1台 MariaDB を動かしてみるのが近道です。


Vultr で Ubuntu 24.04 VPS を始める →

MariaDB のシングルノードインストールから始めたい方は https://linuxlab.jp/ubuntu-server-setup/ も参考にしてください。

コメント

タイトルとURLをコピーしました