Ubuntu 16.04サーバーでMariaDB 10.1を使用してGaleraクラスタを構成する方法

前書き

クラスタリングは、異なるサーバーに変更を配布することにより、データベースに高可用性を追加します。 インスタンスの1つに障害が発生した場合、他のインスタンスはすぐに利用可能になり、サービスを継続できます。

クラスタには、アクティブ-パッシブとアクティブ-アクティブの2つの一般的な構成があります。 アクティブ/パッシブクラスタでは、すべての書き込みは単一のアクティブサーバーで行われ、アクティブサーバーに障害が発生した場合にのみ引き継ぐ準備ができている1つ以上のパッシブサーバーにコピーされます。 一部のアクティブ/パッシブクラスターでは、パッシブノードでのSELECT操作も可能です。 アクティブ/アクティブクラスターでは、すべてのノードが読み取り/書き込みであり、1つに加えられた変更がすべてに複製されます。

このガイドでは、アクティブ/アクティブMariaDB Galeraクラスターを構成します。 デモンストレーションのために、最小の構成可能なクラスターである3つのノードを構成してテストします。

前提条件

従うには、次のものが必要です。

  • Three Ubuntu 16.04 servers、それぞれがsudo特権とプライベートネットワーク(利用可能な場合)を持つ非rootユーザーを持ちます。

これらの前提条件がすべて整ったら、MariaDBをインストールする準備ができました。

[[step-1 -—- adding-the-mariadb-10-1-repositories-to-all-servers]] ==ステップ1—すべてのサーバーへのMariaDB10.1リポジトリーの追加

MariaDB 10.1はデフォルトのUbuntuリポジトリに含まれていないため、MariaDBプロジェクトが管理する外部Ubuntuリポジトリを3つのサーバーすべてに追加することから始めます。

[.note]#Note: MariaDBは評判の高いプロバイダーですが、すべての外部リポジトリが信頼できるわけではありません。 信頼できるソースからのみインストールしてください。

まず、apt-keyコマンドを使用してMariaDBリポジトリキーを追加します。これは、aptがパッケージが本物であることを確認するために使用します。

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

データベースに信頼できるキーを取得したら、リポジトリを追加できます。 新しいリポジトリからパッケージマニフェストを含めるには、後でapt-get updateを実行する必要があります。

sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu xenial main'
sudo apt-get update

[.note]#Note:リポジトリを追加した後に `update`を実行する必要があります。 それ以外の場合は、Galeraパッケージを含まないUbuntuパッケージからバージョン10.0をインストールします。

3つのサーバーすべてでリポジトリが更新されると、MariaDBをインストールする準備が整います。 MariaDBについて注意すべき点の1つは、MySQLのドロップイン置換として作成されたため、多くの構成ファイルと起動スクリプトで、mariadbではなくmysqlが表示されることです。 一貫性を保つために、このガイドではどちらも機能する可能性のあるmysqlを使用します。

[[step-2 -—- installing-mariadb-on-all-servers]] ==ステップ2—すべてのサーバーへのMariaDBのインストール

バージョン10.1以降、MariaDBサーバーとMariaDB Galeraサーバーのパッケージが結合されているため、 `mariadb-server`をインストールすると、Galeraといくつかの依存関係が自動的にインストールされます。

sudo apt-get install mariadb-server

インストール中に、MariaDB管理ユーザーのパスワードを設定するよう求められます。 何を選択しても、レプリケーションが開始されると、このルートパスワードは最初のノードからのパスワードで上書きされます。

クラスターの構成を開始するために必要なすべての要素が揃っているはずですが、後の手順でrsyncに依存するため、クラスターがインストールされていることを確認しましょう。

sudo apt-get install rsync

これにより、最新バージョンのrsyncがすでに利用可能であることが確認されるか、アップグレードまたはインストールするように求められます。

3つのサーバーのそれぞれにMariaDBをインストールしたら、構成を開始できます。

[[step-3 -—- configuring-the-first-node]] ==ステップ3—最初のノードの構成

クラスター内の各ノードは、ほぼ同一の構成にする必要があります。 このため、最初のマシンですべての設定を行い、それを他のノードにコピーします。

デフォルトでは、MariaDBは/etc/mysql/conf.dディレクトリをチェックして、.cnfで終わることから追加の構成設定を取得するように構成されています。 すべてのクラスター固有のディレクティブを使用して、このディレクトリにファイルを作成します。

sudo nano /etc/mysql/conf.d/galera.cnf

次の構成をコピーしてファイルに貼り付けます。 赤で強調表示されている設定を変更する必要があります。 各セクションの意味を以下に説明します。

/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 Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://first_ip,second_ip,third_ip"

# Galera Synchronization Configuration
wsrep_sst_method=rsync

# Galera Node Configuration
wsrep_node_address="this_node_ip"
wsrep_node_name="this_node_name"
  • The first sectionは、クラスターが正しく機能できるようにするMariaDB / MySQL設定を変更または再アサートします。 たとえば、Galera ClusterはMyISAMまたは同様の非トランザクションストレージエンジンでは機能しません。また、mysqldをローカルホストのIPアドレスにバインドしないでください。 設定については、Galera Clustersystem configuration pageで詳しく知ることができます。

  • The “Galera Provider Configuration” sectionは、WriteSetレプリケーションAPIを提供するMariaDBコンポーネントを構成します。 Galeraはwsrep(WriteSet Replication)プロバイダーであるため、これはこの場合Galeraを意味します。 一般的なパラメーターを指定して、初期レプリケーション環境を構成します。 これにはカスタマイズは必要ありませんが、Galera configuration optionsについて詳しく知ることができます。

  • The “Galera Cluster Configuration” sectionはクラスターを定義し、IPアドレスまたは解決可能なドメイン名でクラスターメンバーを識別し、クラスターの名前を作成して、メンバーが正しいグループに参加するようにします。 wsrep_cluster_nametest_clusterよりも意味のあるものに変更するか、そのままにしておくことができますが、mustは3つのサーバーのアドレスでwsrep_cluster_addressを更新します。 サーバーにプライベートIPアドレスがある場合は、ここで使用します。

  • The “Galera Synchronization Configuration” sectionは、クラスターがメンバー間でデータを通信および同期する方法を定義します。 これは、ノードがオンラインになったときに発生する状態転送にのみ使用されます。 初期設定では、rsyncを使用しています。これは、一般的に利用可能であり、今のところ必要なことを実行するためです。

  • The “Galera Node Configuration” sectionは、現在のサーバーのIPアドレスと名前を明確にします。 これは、ログの問題を診断したり、複数の方法で各サーバーを参照したりするときに役立ちます。 wsrep_node_addressは、使用しているマシンのアドレスと一致する必要がありますが、ログファイルでノードを識別しやすくするために、任意の名前を選択できます。

クラスター構成ファイルに満足したら、内容をクリップボードにコピーし、ファイルを保存して閉じます。

[[step-4 -—- configuring-the-remaining-nodes]] ==ステップ4—残りのノードの構成

残りの各ノードで、構成ファイルを開きます。

sudo nano /etc/mysql/conf.d/galera.cnf

最初のノードからコピーした構成を貼り付け、「Galera Node Configuration」を更新して、セットアップする特定のノードのIPアドレスまたは解決可能なドメイン名を使用します。 最後に、名前を更新します。ログファイル内のノードを識別するのに役立つ任意の名前に設定できます。

/etc/mysql/conf.d/galera.cnf

. . .
# Galera Node Configuration
wsrep_node_address="this_node_ip"
wsrep_node_name="this_node_name"
. . .

各サーバーでファイルを保存して終了します。 クラスタを起動する準備はほぼ整いましたが、実行する前に、適切なポートが開いていることを確認する必要があります。

[[step-5 -—- opening-the-firewall-on-every-server]] ==ステップ5—すべてのサーバーでファイアウォールを開く

すべてのサーバーで、ファイアウォールのステータスを確認しましょう。

sudo ufw status

この場合、SSHのみが許可されます:

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

この場合、sshトラフィックのみが許可されるため、MySQLおよびGaleraトラフィックのルールを追加する必要があります。 クラスターを起動しようとすると、ファイアウォールルールが原因で失敗します。

Galeraは4つのポートを使用できます。

  • 3306 mysqldumpメソッドを使用するMySQLクライアント接続および状態スナップショット転送の場合。

  • 4567 Galera Clusterレプリケーショントラフィックの場合、マルチキャストレプリケーションはこのポートでUDPトランスポートとTCPの両方を使用します。

  • 4568増分状態転送の場合。

  • 4444他のすべての状態スナップショット転送の場合。

この例では、セットアップ中に4つのポートすべてを開きます。 レプリケーションが機能していることを確認したら、実際に使用していないポートをすべて閉じ、クラスター内のサーバーのみにトラフィックを制限します。

次のコマンドでポートを開きます。

sudo ufw allow 3306,4567,4568,4444/tcp
sudo ufw allow 4567/udp

[.note]#Note:サーバーで実行されている他の機能によっては、アクセスをすぐに制限したい場合があります。 UFW Essentials: Common Firewall Rules and Commandsガイドがこれに役立ちます。

[[step-6 -—- starting-the-cluster]] ==ステップ6—クラスターの開始

まず、実行中のMariaDBサービスを停止して、クラスターをオンラインにできるようにする必要があります。

3つのサーバーすべてでMariaDBを停止します。

3つのサーバーすべてで以下のコマンドを使用してmysqlを停止し、クラスター内でサーバーを復旧できるようにします。

sudo systemctl stop mysql

systemctlは、すべてのサービス管理コマンドの結果を表示するわけではないため、成功したことを確認するために、次のコマンドを使用します。

sudo systemctl status mysql

最後の行が次のようになっている場合、コマンドは成功しています。

Output . . .
Aug 19 02:55:15 galera-01 systemd[1]: Stopped MariaDB database server.

すべてのサーバーでmysqlをシャットダウンしたら、次に進む準備ができています。

最初のノードを起動します。

最初のノードを起動するには、特別な起動スクリプトを使用する必要があります。 クラスタを構成した方法で、オンラインになる各ノードは、galera.cnfファイルで指定された少なくとも1つの他のノードに接続して、初期状態を取得しようとします。 systemdが--wsrep-new-clusterパラメーターを渡すことを可能にするgalera_new_clusterスクリプトを使用しないと、最初のノードが接続するために実行されているノードがないため、通常のsystemctl start mysqlは失敗します。

sudo galera_new_cluster

このスクリプトが成功すると、ノードはクラスターの一部として登録され、次のコマンドで確認できます。

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

残りのノードでは、通常どおりmysqlを開始できます。 オンラインのクラスターリストのメンバーを検索するため、メンバーが見つかるとクラスターに参加します。

2番目のノードを起動します。

mysqlを開始します。

sudo systemctl start mysql

各ノードがオンラインになると、クラスターサイズが増加します。

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+

3番目のノードを起動します。

mysqlを開始します。

sudo systemctl start mysql

すべてが正常に機能している場合は、クラスターサイズを3に設定する必要があります。

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

この時点で、クラスター全体がオンラインで通信しているはずです。 ただし、レプリケーションをテストする前に、もう1つの構成の詳細があります。

[[step-7 -—- configuring-the-debian-maintenance-user]] ==ステップ7—Debianメンテナンスユーザーの設定

現在、UbuntuおよびDebianのMariaDBサーバーは、特別なメンテナンスユーザーとしてログローテーションなどの定期的なメンテナンスを行っています。 MariaDBをインストールすると、そのユーザーの資格情報がランダムに生成され、/etc/mysql/debian.cnfに保存され、MariaDBのmysqlデータベースに挿入されました。

クラスタを起動するとすぐに、最初のノードのパスワードが他のノードに複製されたため、debian.cnfの値はデータベースのパスワードと一致しなくなりました。 つまり、メンテナンスアカウントを使用するものはすべて、構成ファイル内のパスワードを使用してデータベースに接続しようとし、最初のノードを除くすべてで失敗します。

これを修正するために、最初のノードのdebian.cnfを残りのノードにコピーします。

最初のノードからコピー:

テキストエディタでdebian.cnfファイルを開きます。

sudo nano /etc/mysql/debian.cnf

ファイルは次のようになります。

[client]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

情報をクリップボードにコピーします。

2番目のノードを更新します。

2番目のノードで、同じファイルを開きます。

sudo nano /etc/mysql/debian.cnf

ファイルの上部にある「DO NOT TOUCH!」という警告にもかかわらず、クラスターが機能するように変更する必要があります。 現在の情報を確実に削除し、最初のノードの構成からコンテンツを貼り付けることができます。 今はまったく同じであるはずです。 ファイルを保存して閉じます。

3番目のノードを更新します。

3番目のノードで、同じファイルを開きます。

sudo nano /etc/mysql/debian.cnf

現在の情報を削除し、最初のノードの構成からコンテンツを貼り付けます。 ファイルを保存して閉じます。

ミスマッチは複製をテストする機能には影響しませんでしたが、後で障害が発生しないように早期に対処するのが最善です。

[。注意]##

Note:完了したら、次のようにローカルdebian.confからパスワードを入力することにより、メンテナンスアカウントが接続できることをテストできます。

sudo cat /etc/mysql/debian.cnf

出力からパスワードをコピーします。 次に、mysqlに接続します。

mysql -u debian-sys-maint -p

プロンプトで、コピーしたパスワードを入力します。 接続できれば、すべて順調です。

そうでない場合は、ファイル内のパスワードが最初のノードと同じであることを確認してから、以下を置き換えます。

update mysql.user set password=PASSWORD('password_from_debian.cnf') where User='debian-sys-maint';

繰り返して残りのノードをテストします。

[[step-8 -—- testing-replication]] ==ステップ8—レプリケーションのテスト

ここまでの手順を経て、クラスターが任意のノードから他のノードへの複製を実行できるようにしました。これは、アクティブ/アクティブまたはマスター/マスター複製と呼ばれます。 レプリケーションが期待どおりに機能しているかどうかをテストしてみましょう。

最初のノードへの書き込み:

最初のノードでデータベースを変更することから始めます。 次のコマンドは、playgroundというデータベースと、その中にequipmentというテーブルを作成します。

mysql -u root -p -e 'CREATE DATABASE playground;
CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");'

テーブルに1つの値があります。

2番目のノードでの読み取りと書き込み:

次に、2番目のノードを見て、レプリケーションが機能していることを確認します。

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

レプリケーションが機能している場合、最初のノードで入力したデータは2番目のノードでここに表示されます。

Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+

この同じノードから、クラスターにデータを書き込むことができます。

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");'

3番目のノードでの読み取りと書き込み:

3番目のノードから、再度クエリを実行して、このデータをすべて読み取ることができます。

mysql -u root -p -e 'SELECT * FROM playground.equipment;'
Output   +----+-------+-------+--------+
   | id | type  | quant | color  |
   +----+-------+-------+--------+
   |  1 | slide |     2 | blue   |
   |  2 | swing |    10 | yellow |
   +----+-------+-------+--------+

繰り返しますが、このノードから別の値を追加できます。

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");'

最初のノードで読む:

最初のノードに戻って、データがどこでも利用できることを確認できます。

mysql -u root -p -e 'SELECT * FROM playground.equipment;'
Output   +----+--------+-------+--------+
   | id | type   | quant | color  |
   +----+--------+-------+--------+
   |  1 | slide  |     2 | blue   |
   |  2 | swing  |    10 | yellow |
   |  3 | seesaw |     3 | green  |
   +----+--------+-------+--------+

すべてのノードに書き込み可能で、レプリケーションが適切に実行されていることをテストしました。

結論

この時点で、動作中の3ノードGaleraテストクラスターが構成されているはずです。 実稼働環境でGaleraクラスターを使用する予定がある場合は、5つ以上のノードから始めることをお勧めします。

本番環境で使用する前に、「xtrabackup」などのother state snapshot transfer (sst) agentsのいくつかを確認することをお勧めします。これにより、アクティブノードを大幅に中断することなく、新しいノードを非常に迅速にセットアップできます。 これは実際のレプリケーションには影響しませんが、ノードが初期化される際の懸念事項です。

最後に、クラスターメンバーがプライベートネットワーク上にない場合は、サーバー間を移動するときにデータを保護するためにSSLを設定する必要もあります。

Related