はじめに
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の使い方
上記の公式マニュアルにも記載がありますが、Galera Arbitrator の導入手順はとてもシンプルです。
1. Perconaリポジトリをインストール
|
1 |
# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm |
2. Galera Arbitrator をインストール
|
1 |
# yum install Percona-XtraDB-Cluster-garbd-57 |
※ 下記サイトから rpm パッケージを個別にダウンロード → インストール でも構いません
Download Percona XtraDB Cluster 5.7
3. 設定ファイルを編集
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
# vi /etc/sysconfig/garb # Copyright (C) 2012 Codership Oy # This config file is to be sourced by garb service script. # REMOVE THIS AFTER CONFIGURATION → この行は削除します # A comma-separated list of node addresses (address[:port]) in the cluster GALERA_NODES="192.168.40.10:4567, 192.168.40.20:4567, 192.168.40.30:4567" → node1～node3のIPアドレス（+Galeraレプリケーションで使用するポート）を指定します # Galera cluster name, should be the same as on the rest of the nodes. GALERA_GROUP="DBCLUSTER" → ノード側のmy.cnfで、wsrep_cluster_name変数に設定した名前を指定します # Optional Galera internal options string (e.g. SSL settings) # see http://galeracluster.com/documentation-webpages/galeraparameters.html # GALERA_OPTIONS="" → 用途に応じていくつかのオプションを利用できます # Log file for garbd. Optional, by default logs to syslog # Deprecated for CentOS7, use journalctl to query the log for garbd # LOG_FILE="" → Arbitratorのログをsyslogに出力させたくない場合は任意のログを指定します |
4. Galera Arbitratorを起動
|
1 |
# service garb start |
ちなみにインストール先としては「ノード間の通信が必須」という条件から WEBサーバ にインストールするケースが多い印象です。
複数のGalera Arbitratorを起動する方法
“gmcast.listen_addr”というオプションを使用することで、1台のサーバ上に複数のGalera Arbitratorを起動することができます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# vi /etc/garbd_cluster1.cnf address = gcomm://192.168.40.10:4567,192.168.40.20:4567,192.168.40.30:4567 group = CLUSTER1 log = /tmp/garbd_cluster1.log # vi /etc/garbd_cluster2.cnf address = gcomm://192.168.40.40:4567,192.168.40.50:4567,192.168.40.60:4567 group = CLUSTER2 log = /tmp/garbd_cluster2.log options="gmcast.listen_addr=tcp://0.0.0.0:4500;" → garbd_cluster1がデフォルトのwsrepポート（=4567）を使用してしまうので、 2つ目以降は別のポートを指定する必要があります # garbd -c /etc/garbd_cluster1.cnf -d # garbd -c /etc/garbd_cluster2.cnf -d |
メリット・デメリット
Galera Arbitrator を利用するメリット・デメリットは以下の通りです。
メリット
- PXCノードの可用性が上がる（Split Brain発生の可能性が下がる）
- 通常のノードを追加するよりもコストが安い（ノードと同等のスペックは不要）
デメリット
- トランザクション（Write-Set）は Arbitrator にも伝播するため、Arbitrator と ノード間のネットワークが遅いとパフォーマンスに影響が出る
Galera Arbitrator の簡易検証
最後に私が手元の環境で Galera Arbitrator の検証を実施した時の手順を掲載します。
もし興味があれば試してみて下さい。
なお、この検証では以下の記事で取り上げた「Dockerで構築したPXC3ノード環境」を使用しています。
Dockerで Percona XtraDB Cluster 環境を構築する方法
1. 上述の手順でホスト上に Galera Arbitrator をインストールする
|
1 2 3 4 5 6 7 8 |
# yum install Percona-XtraDB-Cluster-garbd-57 # cat << EOT > /etc/sysconfig/garb GALERA_NODES = "127.0.0.1:14567,127.0.0.1:14568,127.0.0.1:14569" GALERA_GROUP = "pxctest" LOG_FILE = "/tmp/garbd.log" GALERA_OPTIONS = "gmcast.listen_addr=tcp://127.0.0.1:14570" EOT # systemctl start garb |
2. 3ノード + garbd が問題なく稼働していることを確認
|
1 2 |
# mysql -u root -ppassword -h 127.0.0.1 -P13306 -sN -e "show global status like 'wsrep_cluster_size'" wsrep_cluster_size 4 |
3. Node3 のコンテナを停止する
|
1 2 3 |
# docker-compose stop node03 # mysql -u root -ppassword -h 127.0.0.1 -P13306 -sN -e "show global status like 'wsrep_cluster_size'" wsrep_cluster_size 3 |
4. Node2のネットワークを切断
docker networkコマンドで、Node1～Node2間のネットワークを切断します。
2ノードしか残っていない状況であれば Split-brain が発生して Node1 も NON-PRIAMRY になりますが、Node1 + garbd のおかげで PRIMARY を維持できます。
|
1 2 3 4 5 6 7 8 |
# docker network ls NETWORK ID NAME DRIVER SCOPE f7046f52667c bridge bridge local f4210ae4f8fd host host local ba62e3793ef4 none null local 48e3796c4e16 root_cluster bridge local # docker network disconnect root_cluster root_node02_1 |
5. Node1のステータスを確認
Node1 ＋ Arbitrator で wsrep_cluster_size が「2」になっています。元々が 3ノード なので、過半数を超えているため PRIMARY として稼働を継続できます。
|
1 2 3 4 5 6 |
# mysql -u root -ppassword -h 127.0.0.1 -P13306 -sN -e "show global status like 'wsrep_cluster_%'" mysql: [Warning] Using a password on the command line interface can be insecure. wsrep_cluster_conf_id 6 wsrep_cluster_size 2 wsrep_cluster_state_uuid 8e01b405-9368-11e7-a7ed-435254b9522e wsrep_cluster_status Primary |
6. Node2のステータスを確認
Node2はPRIMARYグループから切り離されてしまったため、NON-PRIMARYとなります。通常のクエリ実行は受け付けてくれなくなります。
|
1 2 3 4 5 6 7 8 9 |
# docker exec -it root_node02_1 mysql -u root -ppassword -sN -e " show global status like 'wsrep_cluster_%' " mysql: [Warning] Using a password on the command line interface can be insecure. wsrep_cluster_conf_id 18446744073709551615 wsrep_cluster_size 1 wsrep_cluster_state_uuid 8e01b405-9368-11e7-a7ed-435254b9522e wsrep_cluster_status non-Primary # docker exec -it root_node02_1 mysql -u root -ppassword -sN -e " CREATE DATABASE test_db; " ERROR 1047 (08S01): WSREP has not yet prepared node for application use when I create database or use database. |
Percona XtraDB Cluster を使用する場合は、是非 Galera Arbitrator の導入を検討してみて下さい。
Let’s Enjoy Galera Life !!
