3ノード構成のPXCでは「Galera Arbitrator」を使おう

この記事は最終更新から7年以上経過しています。内容が古くなっている可能性があります。

はじめに

Percona XtraDB Cluster(以下、PXC)を使う場合、以下のような3ノードの構成で利用するケースが多いと思います。

▲ 基本構成。Web Serverの部分は、HAProxyなどのLBを挟むケースも。

しかし、この基本構成の場合、1ノードがダウンしてしまうと2ノードの構成になってしまう難点があります。2ノード構成のPXC環境では、ノード間のネットワークが切断、もしくは不安定だと “Split-Brain” が発生し、両ノードとも NON-PRIMARY 状態になって利用できなくなってしまいます。

▲ Node3がダウンすると2ノード構成になってしまう。


▲ Node2のネットワークがダウンすると、”Split-Brain” が発生し正常なNode1もアクセス不可になる。

そうした場合に有効なのが、「Galera Arbitrator」です。本記事では、同ツールの概要とメリット・デメリットについて紹介します。

目次

Galera Arbitratorとは?

「Galera Arbitrator」は、Arbitrator(仲裁者)の名前の通り Galera Cluster 内に仲裁ノードを作成するためのツールです。仲裁ノードは通常ノードと同じくノード間で絶えず通信を行っていますが、テーブルデータを一切保持していないため「疑似ノード」とも呼ばれます。テーブルデータの更新を行わないため、仲裁ノードが要因でパフォーマンスが悪化するケースは殆どありません(例外あり ※後述)。

既存の3ノード構成に Arbitrator ノードを加えると、全体として4ノード構成(wsrep_cluster_size = 4)として扱われます。この状態で1ノードがダウンしても、残りは3ノードとなり Split-Brain が発生する確率はかなり低くなります。そのため、ダウンタイムなくサービスを継続することが可能となります。

もちろん、PXC以外の Galera Cluster for MySQL や MariaDB Galera Cluster でも利用できます。

▲ Node3がダウンしても、実質的には3ノード構成となる。


▲ Node2のネットワークがダウンしても、正常なNode1にアクセス可能。”Split-Brain”は発生しない。

Galera Arbitratorの使い方

Setting up Galera Arbitrator

上記の公式マニュアルにも記載がありますが、Galera Arbitrator の導入手順はとてもシンプルです。

1. Perconaリポジトリをインストール

2. Galera Arbitrator をインストール

※ 下記サイトから rpm パッケージを個別にダウンロード → インストール でも構いません
Download Percona XtraDB Cluster 5.7

3. 設定ファイルを編集

4. Galera Arbitratorを起動

ちなみにインストール先としては「ノード間の通信が必須」という条件から WEBサーバ にインストールするケースが多い印象です。

複数のGalera Arbitratorを起動する方法

“gmcast.listen_addr”というオプションを使用することで、1台のサーバ上に複数のGalera Arbitratorを起動することができます。

メリット・デメリット

Galera Arbitrator を利用するメリット・デメリットは以下の通りです。

メリット

  • PXCノードの可用性が上がる(Split Brain発生の可能性が下がる)
  • 通常のノードを追加するよりもコストが安い(ノードと同等のスペックは不要)

デメリット

  • トランザクション(Write-Set)は Arbitrator にも伝播するため、Arbitrator と ノード間のネットワークが遅いとパフォーマンスに影響が出る

Galera Arbitrator の簡易検証

最後に私が手元の環境で Galera Arbitrator の検証を実施した時の手順を掲載します。
もし興味があれば試してみて下さい。

なお、この検証では以下の記事で取り上げた「Dockerで構築したPXC3ノード環境」を使用しています。
Dockerで Percona XtraDB Cluster 環境を構築する方法

1. 上述の手順でホスト上に Galera Arbitrator をインストールする

2. 3ノード + garbd が問題なく稼働していることを確認

3. Node3 のコンテナを停止する

4. Node2のネットワークを切断

docker networkコマンドで、Node1~Node2間のネットワークを切断します。
2ノードしか残っていない状況であれば Split-brain が発生して Node1 も NON-PRIAMRY になりますが、Node1 + garbd のおかげで PRIMARY を維持できます。

5. Node1のステータスを確認

Node1 + Arbitrator で wsrep_cluster_size が「2」になっています。元々が 3ノード なので、過半数を超えているため PRIMARY として稼働を継続できます。

6. Node2のステータスを確認

Node2はPRIMARYグループから切り離されてしまったため、NON-PRIMARYとなります。通常のクエリ実行は受け付けてくれなくなります。

Percona XtraDB Cluster を使用する場合は、是非 Galera Arbitrator の導入を検討してみて下さい。

Let’s Enjoy Galera Life !!


Percona

 

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがPerconaに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次