Database JUNKY

MySQL,MariaDBを中心としたブログです

トップ > Galera Cluster > Galera Cluster for MySQLでクラスタ環境を構築する

Galera Cluster for MySQLでクラスタ環境を構築する

Galera Cluster MySQL 5.7 クラスタリング ELB route53 内部DNS 内部ロードバランサー ポート SG rsync

Galara Cluster for MySQL 5.7 でクラスタ環境を構築する

前回のMariaDBでのGalera Clusterの構築は手違いで消してしまった（−＿−；）今回は、MySQL5.7でGalera Clusterを構築、運用することをやっていきたいと思います。以外と簡単ではあるのですが、今回ELBとINTERNAL DNSを駆使して更新負荷分散を試してみようと思います

f:id:hit10231023:20180309104656p:plain

インストール

MariaDBのGalara Clusterは標準でインプリメントされているが、MySQLはアドオンでインストールすることになります。といってもアドオンでインストールするとあとあとの運用や、サーバ追加の際に面倒になりそうなので、できれば、yumで、もしくはrpmでインストールしたいと思いつつ探してたら、あった（汗）

galeracluster.com

ここから、以下の２つをダウンロードすることであっさりインストールできます。 あ、この中ってMySQL入っておりますので。別途MySQLをインストール必要はありません。

f:id:hit10231023:20170905145748j:plain

また、このサイト、たまたまなのかもしれませんが、やたらと不安定なので、yumは使わずに、必要なrpmを一気にダウンロードしてから、yum localinstall でインストールしました。今回私のダウンロードしたファイルは以下の通りです。

# ll
total 191956
-rw-r--r-- 1 ec2-user ec2-user  10510616 Sep  1 06:55 galera-3-25.3.21-2.el6.x86_64.rpm
-rw-r--r-- 1 ec2-user ec2-user     44428 Sep  1 06:55 mysql-wsrep-5.7-5.7.18-25.12.el6.x86_64.rpm
-rw-r--r-- 1 ec2-user ec2-user  24062392 Sep  1 06:55 mysql-wsrep-client-5.7-5.7.18-25.12.el6.x86_64.rpm
-rw-r--r-- 1 ec2-user ec2-user    338576 Sep  1 06:55 mysql-wsrep-common-5.7-5.7.18-25.12.el6.x86_64.rpm
-rw-r--r-- 1 ec2-user ec2-user   3749592 Sep  1 06:55 mysql-wsrep-devel-5.7-5.7.18-25.12.el6.x86_64.rpm
-rw-r--r-- 1 ec2-user ec2-user   2179996 Sep  1 06:55 mysql-wsrep-libs-5.7-5.7.18-25.12.el6.x86_64.rpm
-rw-r--r-- 1 ec2-user ec2-user   1749540 Sep  1 06:55 mysql-wsrep-libs-compat-5.7-5.7.18-25.12.el6.x86_64.rpm
-rw-r--r-- 1 ec2-user ec2-user 127266148 Sep  1 06:55 mysql-wsrep-server-5.7-5.7.18-25.12.el6.x86_64.rpm
-rw-r--r-- 1 ec2-user ec2-user  26640532 Sep  1 06:55 mysql-wsrep-test-5.7-5.7.18-25.12.el6.x86_64.rpm

・・と書きましたが、今回はインストール方法については説明を省きますね

aws ec2の設定について

今回も、前回同様、amazon linuxで行いました、前回同様最小３台構成で構築しております。

SG （セキュリティグループ）の設定について

Galera Clusterを利用する際、SGには以下３つのポートを開いておく必要があります

f:id:hit10231023:20170905145845j:plain

my.cnf について

前回

hit.hateblo.jp

ここでも書きましたので割愛しますが、こんな設定にしております。

  • 10.0.1.150
# wsrep
wsrep_on=ON
wsrep_provider=/usr/lib64/galera-3/libgalera_smm.so
# wsrep_cluster_address='gcomm://'
wsrep_cluster_address='gcomm://10.0.1.151,10.0.1.152'
wsrep_cluster_name='CLUSTERGRP'
wsrep_node_name='V4-NODE01'
wsrep_node_address = 10.0.1.150
#wsrep_slave_threads=1
innodb_flush_log_at_trx_commit=0
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
  • 10.0.1.151
# wsrep
bind-address=0.0.0.0
wsrep_on=ON
wsrep_provider=/usr/lib64/galera-3/libgalera_smm.so
wsrep_cluster_address='gcomm://10.0.1.150,10.0.1.152'
wsrep_cluster_name='CLUSTERGRP'
wsrep_node_name='V4-NODE02'
wsrep_node_address = 10.0.1.151
#wsrep_slave_threads=1
innodb_flush_log_at_trx_commit=0
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
  • 10.0.1.152
# wsrep
bind-address=0.0.0.0
wsrep_on=ON
wsrep_provider=/usr/lib64/galera-3/libgalera_smm.so
wsrep_cluster_address='gcomm://10.0.1.150,10.0.1.151'
wsrep_cluster_name='CLUSTERGRP'
wsrep_node_name='V4-NODE03'
wsrep_node_address = 10.0.1.152
#wsrep_slave_threads=1
innodb_flush_log_at_trx_commit=0
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2

負荷分散(ロードバランサー）について

上記３台の更新・参照負荷分散を内部ロードバランサー（INTERNAL ELB）で行なっております。

基本構成

f:id:hit10231023:20170905151434j:plain

インスタンスノード一覧

f:id:hit10231023:20170905151448j:plain

注意：ELBのヘルスチェックで、MySQLの3306ポートをチェックしてしまますと、それぞれのコネクションが枯渇して、MySQLでエラーを出してしまいます。こちらですが、ポート８０で稼働する、簡単なプログラムを作成して、そのプログラムの中で、MySQLの稼働チェックをしたほうがいいと思います

route53 (DNS)

INTERNAL DNS名をCNAMEで名前付けしました。

f:id:hit10231023:20170905152114j:plain

以上が、awsで運用する際の基本的な設定かと思います。その他のMySQLのチューニングに関しては、環境により変わってくると思いますので、お任せで。。

起動

色々と前回とかぶってしまいますが。。初回起動(初期ノード起動）方法

10.0.1.150

初回起動

/etc/init.d/mysqld start --wsrep_cluster_address=gcomm://

こうすることで、my.cnfに他ノードの記載があったとしても参照しないで起動することが可能

２回目以降も同じ

オプションをつける必要はありません

/etc/init.d/mysqld start

10.0.1.151,152

上記がマスターノードとするのであれば、151,152は追加ノードという感じになると思います。 起動手順は同じですが、追加ノードの場合の初回起動については、まず、シングルで立ち上げて、マスターノードとの足並みを揃えておく（マスターノードからdump/restore）という意味合いで書いてます。なので、追加ノードに関しては、個人的には、初回起動を2回目以降起動の２回をやったほうがいいかな？って考えています（間違っていたらすみません）

初回起動

/etc/init.d/mysqld start --wsrep_cluster_address=gcomm://

こうすることで、my.cnfに他ノードの記載があったとしても参照しないで起動することが可能

２回目以降も同じ

オプションをつける必要はありません

/etc/init.d/mysqld start

動作確認

無事に３台のクラスタリングが完了したらチェックしてみましょう。

ELBはちゃんと分散しているかチェック

さきほど作成したINTERNAL ELBを介して分散されているかをwsrep_local_indexで確認してみます

$ mysql -helb-internal.yourdomain.12345squad.com -usysadm -psysadmpasswd -e "SHOW STATUS LIKE 'wsrep_local_index';"
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| wsrep_local_index | 0     |
+-------------------+-------+
$ mysql -helb-internal.yourdomain.12345squad.com -usysadm -psysadmpasswd -e "SHOW STATUS LIKE 'wsrep_local_index';"
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| wsrep_local_index | 1     |
+-------------------+-------+
$ mysql -helb-internal.yourdomain.12345squad.com -usysadm -psysadmpasswd -e "SHOW STATUS LIKE 'wsrep_local_index';"
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| wsrep_local_index | 2     |
+-------------------+-------+

ラウンドロビンっぽいですが、振り分けて接続していることを確認しました

クラスタリングするか確認

  • マスターノード以外でデータ更新したものが、反映されるか確認
mysql -h10.0.1.152 -usysadm -psysadmpasswd -e "CREATE DATABASE test_database;"

以下のように、他のノードにも反映されていることを確認

$ mysql -helb-internal.yourdomain.12345squad.com -usysadm -psysadmpasswd -e "SHOW DATABASES like 'test_data%'; SHOW STATUS LIKE 'wsrep_local_index';"
+-----------------------+
| Database (test_data%) |
+-----------------------+
| test_database         |
+-----------------------+
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| wsrep_local_index | 2     |
+-------------------+-------+
$ mysql -helb-internal.yourdomain.12345squad.com -usysadm -psysadmpasswd -e "SHOW DATABASES like 'test_data%'; SHOW STATUS LIKE 'wsrep_local_index';"
+-----------------------+
| Database (test_data%) |
+-----------------------+
| test_database         |
+-----------------------+
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| wsrep_local_index | 0     |
+-------------------+-------+

一瞬だかどーだか確認する手段はないですが、ちゃんと全てのノードに設定が反映されました。

障害対応について

クラスタリングで一番気になるのは障害時どうするの？ってところですね。基本クラスタリングは、１台でも生き残っていれば処理はできるのですが、たとえば障害が発生した１台を元のノードグループに戻す時とかどーすんの？ってあたりを中心にやっていきます

10.0.1.151 を停止してみる

全然障害ではないですがw　普通に10.0.1.151 を停止してみます、停止したあとで、10.0.1.152のtest_databaseスキーマにテーブルを作成してみようと思います。

10.0.1.151

MySQLの停止

$ sudo /etc/init.d/mysqld stop
-----
Stopping mysqld:                                           [  OK  ]

10.0.1.152

テーブルを作成、そしてデータをINSERT

$ mysql -usysadm -p -e "use test_database ; CREATE TABLE t1 (id int not null,primary key (id));"
$ mysql -usysadm -p test_database -e "INSERT INTO t1 VALUES (1) ;"

上記の状態から、10.0.1.151のMySQLを起動、そして検索

$ sudo /etc/init.d/mysqld start
mysql -usysadm -p -e "SELECT * FROM test_database.t1;"
Enter password:
+----+
| id |
+----+
|  1 |
+----+

起動したと同時に同期もされていることが確認できました！！