なぜMariaDB Galera Clusterが本番環境において最適な選択肢なのか?
システム運用担当者にとって、午前2時にデータベースのエラーを知らせる電話がかかってくることは、まさに悪夢です。従来のマスター・スレーブ(Master-Slave)構成では、マスターに障害が発生した場合、スレーブへの切り替え(フェイルオーバー)に時間がかかります。このプロセスはダウンタイムを発生させるだけでなく、レプリケーションの遅延によるデータ消失のリスクも孕んでいます。
MariaDB Galera Clusterは、マルチマスター(Multi-master)アーキテクチャによってこの状況を根本から変えます。どのノードに対してもデータを書き込むことができ、そのデータは即座に他のすべてのノードに同期されます。1台のサーバーがダウンしても、手動の介入なしに他のノード経由でアプリケーションは正常に動作し続けます。これは、真の高可用性(HA)を実現するための最短ルートです。
非同期レプリケーションとは異なり、Galeraは同期(Synchronous)メカニズムを使用します。これにより、サーバー間でのデータ遅延が発生しないことが保証されます。トランザクションがコミットされた時点で、そのデータはクラスター全体に確実に存在することになります。
インフラとリソースの準備
「スプリットブレイン(Split-brain)」(ノード間の通信が途絶え、各ノードが自分をマスターだと誤認する状態)を避けるため、常に奇数のノード数を使用してください。まずは最低3ノードからの開始をお勧めします。ここでは、以下の3台のUbuntu 22.04サーバーがあると仮定します。
- ノード 1: 192.168.1.10
- ノード 2: 192.168.1.11
- ノード 3: 192.168.1.12
ステップ 1:MariaDBのインストール
以下のコマンドを使用して、3台すべてのサーバーにMariaDBサーバーとGaleraライブラリをインストールします。
sudo apt update
sudo apt install -y mariadb-server mariadb-client galera-4
次に、MariaDBのデフォルトスクリプトを使用してデータベースのセキュリティ設定を行います。
sudo mysql_secure_installation
ステップ 2:ファイアウォールの設定
Galera Clusterは、接続の維持とデータ同期のために4つの専用ポートを必要とします。UFWを使用している場合は、以下のポートを解放してください。
- 3306: MySQL/MariaDB トラフィック用。
- 4567: Galera Cluster レプリケーション・トラフィック用。
- 4568: 差分状態転送(IST)用。
- 4444: 全状態転送(SST)用。
sudo ufw allow 3306,4567,4568,4444/tcp
sudo ufw allow 4567/udp
Galera Clusterの設定
設定ファイルを編集する前に、3台すべてのノードでMariaDBサービスを停止します。
sudo systemctl stop mariadb
ノード 1で /etc/mysql/conf.d/galera.cnf に新しい設定ファイルを作成します。サンプル内容は以下の通りです。
[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
# Galeraプロバイダーの設定
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
# クラスターの設定
wsrep_cluster_name="prod_cluster_01"
wsrep_cluster_address="gcomm://192.168.1.10,192.168.1.11,192.168.1.12"
# ノード識別子の設定
wsrep_node_address="192.168.1.10"
wsrep_node_name="node1"
wsrep_sst_method=rsync
このファイルをノード 2とノード 3にコピーします。注意:各サーバーのIPと名前に合わせて、wsrep_node_address と wsrep_node_name を適宜修正してください。
実務でのヒント: rsync 方式は小規模なデータベースでは非常に安定しています。しかし、データサイズが100GBを超える場合は、mariabackup の使用を検討してください。これにより、テーブルロックの時間を最小限に抑えてノードをクラスターに参加させることができます。
クラスターの起動(ブートストラップ)
すべてのサーバーで通常通りMariaDBを起動しないでください。クラスターには開始点となる「シード(seed)」が必要です。ノード 1で、初期化コマンドを実行します。
sudo galera_new_cluster
ノード 1の準備ができたら、順次ノード 2とノード 3でMariaDBを起動します。
sudo systemctl start mariadb
これらのノードは、設定ファイル内のIPリストに基づいて自動的にノード 1を見つけ、初期データの同期を行います。
動作ステータスの確認
システムが正常に動作していることを確認するために、MariaDBにアクセスして現在のノード数を確認します。
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
結果が 3 であれば、システムの準備は完了です。ノード 1でデータベースを作成し、ノード 3でそれが反映されているか確認して、即時同期の威力を体験してみてください。
入力データの処理に関するヒント
旧システムからの移行時など、CSVやダンプファイルから大量のデータを処理する必要があることがよくあります。インポート前にデータ構造を素早く標準化するために、私はよくCSVからJSONへの変換ツールを使用します。これにより、ブラウザ上でデータの整合性を確認でき、スクリプト作成の手間を大幅に削減できます。
ダウンタイムを回避するための重要な注意事項
- クォーラム(多数決): 3ノードのうち2ノードが同時にダウンすると、残りのノードはデータの不整合を防ぐために自動的に接続を遮断(Non-primary状態)します。そのため、ノード数は常に3、5、7といった奇数にすることを優先してください。
- Syncedステータス: 常に
wsrep_local_state_comment指標を監視してください。理想的な状態はSyncedです。 - トラフィック管理: マルチマスター構成であっても、複数のノードから同一行へ同時に書き込みを行うとデッドロックが発生しやすくなります。最善の解決策は、前段に ProxySQL や HAProxy を配置し、書き込みトラフィックを特定の1ノードに集約し、他のノードを読み取り専用およびバックアップとして運用することです。
Galera Clusterの構築自体は難しくありませんが、ネットワーク設定における細心の注意が必要です。このガイドが、皆さんのプロジェクトにおける堅牢なデータベースインフラ構築の助けになれば幸いです。

