序章

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

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

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

前提条件

フォローするには、次のものが必要です。

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

ステップ1—すべてのサーバーにMariaDB10.1リポジトリを追加する

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

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

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

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

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

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

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

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

ステップ2—すべてのサーバーにMariaDBをインストールする

バージョン10.1以降、MariaDBサーバーとMariaDBガレラサーバーのパッケージが組み合わされているため、 mariadb-serverGaleraといくつかの依存関係を自動的にインストールします。

  1. sudo apt-get install mariadb-server

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

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

  1. sudo apt-get install rsync

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

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

ステップ3—最初のノードを構成する

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

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

  1. 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アドレスと名前を明確にします。 これは、ログの問題を診断したり、各サーバーを複数の方法で参照したりする場合に役立ちます。 The wsrep_node_address 使用しているマシンのアドレスと一致する必要がありますが、ログファイルでノードを識別しやすくするために任意の名前を選択できます。

クラスタ構成ファイルに問題がなければ、内容をクリップボードにコピーし、ファイルを保存して閉じます。

ステップ4—残りのノードを構成する

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

  1. 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—すべてのサーバーでファイアウォールを開く

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

  1. sudo ufw status

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

Output
Status: 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つのポートすべてを開きます。 レプリケーションが機能していることを確認したら、実際に使用していないポートをすべて閉じて、トラフィックをクラスター内のサーバーのみに制限します。

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

  1. sudo ufw allow 3306,4567,4568,4444/tcp
  2. sudo ufw allow 4567/udp

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

ステップ6—クラスターを開始する

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

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

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

  1. sudo systemctl stop mysql

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

  1. sudo systemctl status mysql

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

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

シャットダウンしたら mysql すべてのサーバーで、続行する準備が整いました。

最初のノードを表示します。

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

  1. sudo galera_new_cluster

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

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

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

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

始める mysql:

  1. sudo systemctl start mysql

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

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

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

始める mysql:

  1. sudo systemctl start mysql

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

  1. 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 テキストエディタでファイル:

  1. 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番目のノードで、同じファイルを開きます。

  1. sudo nano /etc/mysql/debian.cnf

ファイルの上部に「触れないでください」という警告が表示されますが、 クラスタが機能するように変更を加える必要があります。 自信を持って現在の情報を削除し、最初のノードの構成から内容を貼り付けることができます。 それらは今ではまったく同じであるはずです。 ファイルを保存して閉じます。

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

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

  1. sudo nano /etc/mysql/debian.cnf

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

不一致はレプリケーションをテストする機能に影響を与えませんが、後で失敗しないように、早い段階で対処するのが最善です。

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

  1. sudo cat /etc/mysql/debian.cnf

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

  1. mysql -u debian-sys-maint -p

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

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

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

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

ステップ8—レプリケーションのテスト

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

最初のノードに書き込みます。

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

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

これで、テーブルに1つの値があります。

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

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

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

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

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

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

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

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

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

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

ここでも、このノードから別の値を追加できます。

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

最初のノードで読む:

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

  1. 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も設定する必要があります。