Ubuntu16.04サーバーでMariaDB10.1を使用してGaleraクラスターを構成する方法
序章
クラスタリングは、変更をさまざまなサーバーに分散することにより、データベースに高可用性を追加します。 インスタンスの1つに障害が発生した場合、他のインスタンスはすぐにサービスを継続できます。
クラスターには、アクティブ-パッシブとアクティブ-アクティブの2つの一般的な構成があります。 アクティブ-パッシブクラスターでは、すべての書き込みは単一のアクティブサーバーで実行され、アクティブサーバーに障害が発生した場合にのみ引き継ぐ準備ができている1つ以上のパッシブサーバーにコピーされます。 一部のアクティブ-パッシブクラスターでは、パッシブノードでのSELECT操作も可能です。 アクティブ-アクティブクラスターでは、すべてのノードが読み取り/書き込みであり、1つに加えられた変更がすべてに複製されます。
このガイドでは、アクティブ-アクティブMariaDBガレラクラスターを構成します。 デモンストレーションの目的で、構成可能な最小のクラスターである3つのノードを構成してテストします。
前提条件
フォローするには、次のものが必要です。
- 3台のUbuntu16.04サーバー。それぞれに
sudo権限とプライベートネットワーク（利用可能な場合）を持つ非rootユーザーがいます。- これらの権限を持つユーザーの設定については、 Ubuntu16.04を使用したサーバーの初期設定ガイドに従ってください。
- プライベートネットワークの設定については、DigitalOceanプライベートネットワークの設定と使用方法を参照してください。
これらの前提条件がすべて整ったら、MariaDBをインストールする準備が整います。
ステップ1—すべてのサーバーにMariaDB10.1リポジトリを追加する
MariaDB 10.1はデフォルトのUbuntuリポジトリに含まれていないため、MariaDBプロジェクトによって維持されている外部Ubuntuリポジトリを3つのサーバーすべてに追加することから始めます。
注： 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
注：リポジトリを追加した後、updateを実行する必要があります。 それ以外の場合は、Galeraパッケージを含まないUbuntuパッケージからバージョン10.0をインストールします。
3つのサーバーすべてでリポジトリが更新されると、MariaDBをインストールする準備が整います。 MariaDBについて注意すべき点の1つは、MySQLのドロップイン置換として作成されたため、多くの構成ファイルと起動スクリプトで、mariadbではなくmysqlが表示されることです。 一貫性を保つために、このガイドではmysqlを使用しています。どちらでも機能します。
ステップ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をインストールしたら、構成を開始できます。
ステップ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"
- 最初のセクションは、クラスターが正しく機能できるようにするMariaDB/MySQL設定を変更または再アサートします。 たとえば、Galera ClusterはMyISAMまたは同様の非トランザクションストレージエンジンでは機能しません。また、
mysqldをローカルホストのIPアドレスにバインドしないでください。 設定の詳細については、GaleraClusterシステム構成ページを参照してください。 - 「Galeraプロバイダーの構成」セクションは、WriteSetレプリケーションAPIを提供するMariaDBコンポーネントを構成します。 これは、Galeraがwsrep（WriteSet Replication）プロバイダーであるため、この場合はGaleraを意味します。 初期レプリケーション環境を構成するための一般的なパラメーターを指定します。 これにはカスタマイズは必要ありませんが、Galera構成オプションについて詳しく知ることができます。
- 「Galeraクラスター構成」セクションはクラスターを定義し、IPアドレスまたは解決可能なドメイン名でクラスターメンバーを識別し、メンバーが正しいグループに参加できるようにクラスターの名前を作成します。
wsrep_cluster_nameをtest_clusterよりも意味のあるものに変更するか、そのままにしておくことができますが、はwsrep_cluster_addressを3つのアドレスで更新する必要がありますサーバー。 サーバーにプライベートIPアドレスがある場合は、ここでそれらを使用します。 - 「Galera同期構成」セクションは、クラスターがメンバー間でデータを通信および同期する方法を定義します。 これは、ノードがオンラインになったときに発生する状態転送にのみ使用されます。 初期設定では、
rsyncを使用しています。これは、一般的に入手可能であり、現在必要なことを実行するためです。 - 「Galeraノードの構成」セクションは、現在のサーバーのIPアドレスと名前を明確にします。 これは、ログの問題を診断したり、各サーバーを複数の方法で参照したりする場合に役立ちます。
wsrep_node_addressは、使用しているマシンのアドレスと一致する必要がありますが、ログファイルでノードを識別しやすくするために、任意の名前を選択できます。
クラスタ構成ファイルに問題がなければ、内容をクリップボードにコピーし、ファイルを保存して閉じます。
ステップ4—残りのノードを構成する
残りの各ノードで、構成ファイルを開きます。
sudo nano /etc/mysql/conf.d/galera.cnf
最初のノードからコピーした構成を貼り付けてから、「ガレラノード構成」を更新して、設定している特定のノードのIPアドレスまたは解決可能なドメイン名を使用します。 最後に、その名前を更新します。これは、ログファイルでノードを識別するのに役立つ名前に設定できます。
/etc/mysql/conf.d/galera.cnf
. . . # Galera Node Configuration wsrep_node_address="this_node_ip" wsrep_node_name="this_node_name" . . .
各サーバーでファイルを保存して終了します。 クラスタを起動する準備がほぼ整いましたが、起動する前に、適切なポートが開いていることを確認する必要があります。
ステップ5—すべてのサーバーでファイアウォールを開く
すべてのサーバーで、ファイアウォールのステータスを確認しましょう。
sudo ufw status
この場合、SSHのみが許可されます。
OutputStatus: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)
この場合、sshトラフィックのみが許可されるため、MySQLおよびGaleraトラフィックのルールを追加する必要があります。 クラスタを起動しようとすると、ファイアウォールルールが原因で失敗します。
Galeraは4つのポートを利用できます。
- 3306mysqldumpメソッドを使用するMySQLクライアント接続および状態スナップショット転送の場合。
- 4567 Galera Clusterレプリケーショントラフィックの場合、マルチキャストレプリケーションはこのポートでUDPトランスポートとTCPの両方を使用します。
- 4568インクリメンタルステート転送の場合。
- 4444他のすべての状態スナップショット転送の場合。
この例では、セットアップ中に4つのポートすべてを開きます。 レプリケーションが機能していることを確認したら、実際に使用していないポートをすべて閉じて、トラフィックをクラスター内のサーバーのみに制限します。
次のコマンドでポートを開きます。
sudo ufw allow 3306,4567,4568,4444/tcp sudo ufw allow 4567/udp
注：サーバーで実行されている他の機能によっては、すぐにアクセスを制限したい場合があります。 UFW Essentials：Common Firewall Rules andCommandsガイドがこれに役立ちます。
ステップ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つ注意すべき構成の詳細があります。
ステップ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
ファイルの上部に「触れないでください」という警告が表示されますが、 クラスタが機能するように変更を加える必要があります。 自信を持って現在の情報を削除し、最初のノードの構成から内容を貼り付けることができます。 それらは今ではまったく同じであるはずです。 ファイルを保存して閉じます。
3番目のノードを更新します。
3番目のノードで、同じファイルを開きます。
sudo nano /etc/mysql/debian.cnf
現在の情報を削除し、最初のノードの構成から内容を貼り付けます。 ファイルを保存して閉じます。
不一致はレプリケーションをテストする機能に影響を与えませんが、後で失敗しないように、早い段階で対処するのが最善です。
注：完了したら、次のようにローカル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';
繰り返して残りのノードをテストします。
ステップ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」などのその他の状態スナップショット転送（sst）エージェントを確認することをお勧めします。これにより、アクティブなユーザーに大きな中断を与えることなく、新しいノードを非常に迅速にセットアップできます。ノード。 これは実際のレプリケーションには影響しませんが、ノードが初期化されるときに問題になります。
最後に、クラスターメンバーがプライベートネットワーク上にない場合は、サーバー間を移動するときにデータを保護するためにSSLも設定する必要があります。
