MariaDBは、2つの異なる高可用性（HA）およびクラスタリングソリューションを提供します。 1つは、標準のMariaDBマスター/スレーブレプリケーションであり、主に負荷分散、HA、およびバックアップの目的でさまざまなトポロジで構成できます。 2つ目は、マルチマスター同期クラスタリングソリューションであるMariaDBGaleraです。その主な機能は次のとおりです。
- マルチマスター：Galeraクラスター内のすべてのノードは、読み取り操作と書き込み操作の両方を実行できるため、スケーラビリティが向上します。
- ノードはクラスターに自動的に参加でき、障害が発生すると削除されます。
- Galeraレプリケーションは同期的です。つまり、1つのノードでの変更は、他のノードに適用されることが保証されます。理論的には、これにより、ノードに障害が発生したときにデータが失われることはありません。
このガイドでは、GaleraクラスターでのMariaDBのインストールとその構成について説明します。デモンストレーションには3つのDebian10ノードを使用しますが、任意の数（≥3）のノードを使用できます。 Galeraクラスターに2つのノードを設定することは技術的には可能ですが、障害が発生したノードによって他のノードが停止するため、フォールトトレランスは提供されません。
- 3つ以上のDebian10インスタンス。
- rootユーザーまたはsudo権限を持つ任意のユーザーへのアクセス。
- $ EDITOR 環境変数を設定する必要があります。
注： GaleraクラスターはWANまたはLAN上で機能します。ノードがプライベートネットワークを共有している場合は、該当する場合はプライベートIPアドレスを使用してください。それ以外の場合は、WANアドレスを使用する必要があります。
sudoユーザーを使用している場合は、以下を使用して、このセットアップの長さのルートシェルを開いて使用します。
sudo -s
ステップ1：MariaDBのインストール
この手順は、すべてのノードで実行する必要があります。
次のコマンドを使用して、MariaDB、Galeraライブラリ、およびRsyncをインストールします。後者はGaleraによって使用されます。
apt updateapt install -y mariadb-server mariadb-client galera-3 rsync
MariaDBサービスが有効になっていることを確認します：
systemctl enable mariadb.service
mysql_secure_installationスクリプトを使用してMariaDBインスタンスを保護します：
mysql_secure_installation
以下に示すように質問に答え、MySQLrootユーザーの強力なパスワードを選択していることを確認してください。
rootの現在のパスワードを入力します（noneの場合はEnter）：を押しますrootパスワードを設定しますか？ [Y / n] y新しいパスワード：your_password新しいパスワードを再入力してください：your_password匿名ユーザーを削除しますか？ [Y / n] yrootログインをリモートで禁止しますか？ [Y / n] yテストデータベースを削除してアクセスしますか？ [Y / n] y今すぐ特権テーブルをリロードしますか？ [Y / n] yすべて完了しました！上記のすべての手順を完了すると、MariaDBのインストールは安全になります。
ステップ2：MariaDBの構成
この手順は、すべてのノードで実行する必要があります。
すべてのノードでMariaDBサービスを停止します：
systemctl stop mariadb.service
デフォルトでは、MariaDBデーモンはローカルホストでのみ接続をリッスンします。クラスタが機能するためには、これを外部からアクセス可能なアドレスに変更する必要があります。これを行うには、オプションファイル/etc/mysql/mariadb.conf.d/50-server.cnfを編集します。
$ EDITOR /etc/mysql/mariadb.conf.d/50-server.cnf
次の行を見つけます：
bind-address =127.0.0.1
クラスタにプライベートネットワークを使用していて、MariaDBを他のネットワーク（WANなど）に公開したくない場合は、各ノードのローカルIPv4アドレスを指定します。それ以外の場合は、すべてのインターフェースでリッスンするようにMariaDBに指示する0.0.0.0を使用します。例：
bind-address =0.0.0.0
変更を保存して、テキストエディタを終了します。
次に、クラスター関連のオプションを構成します。新しいオプションファイルを作成します：
$ EDITOR /etc/mysql/mariadb.conf.d/99-cluster.cnf
次の適切な構成をファイルに入力し、IPアドレスを置き換えます。すべてのノードで同一である必要があります。
[galera]
wsrep_on =on wsrep_provider =/lib/galera/libgalera_smm.so wsrep_cluster_address =gcomm：//192.0.2.1,192.0.2.2,192.0.2.3 wsrep_cluster_name =galera_cluster_0 default_storage_engine =InnoDB innodb_autoinc_lock_mode =2 innodb =1 binlog_format =ROW
- wsrep_on =onは、Galeraが使用する基本的な機能である書き込みセットのレプリケーションを有効にします。
- wsrep_providerは、ガレラライブラリへのパスを指定します。これは、Debian10の/lib/galera/libgalera_smm.soにあるgalera-3パッケージによって提供されます。
- wsrep_cluster_addressには、別のクラスターメンバーのアドレスが少なくとも1つ含まれている必要があります。クラスタのすべてのメンバーを一覧表示することをお勧めします。特別な注文は必要ありません。
- wsrep_cluster_nameはクラスターに固有であり、同じガレラクラスターのすべてのノードで同一である必要があります。
- 残りのオプションはGaleraが正しく機能するために必要であり、変更しないでください。
ステップ3：クラスターのブートストラップ
続行する前に、すべてのノードでMariaDBが停止/非アクティブになっていることを確認してください：
systemctl status mariadb.service
クラスターを開始するには、ノードが最初にクラスターを作成する必要があります。 Debian 10では、これはgalera_new_clusterスクリプトを使用して実行できます。スクリプトは1つのノードでのみ実行し、クラスターを初期化するために1回だけ実行する必要があります。
galera_new_cluster
これにより、現在のノードでMariaDBが起動します。次のコマンドで実行されていることを確認してください：
systemctl status mariadb.service
次に、他のノードで次のコマンドを使用してMariaDBを起動します。
systemctl start mariadb.service
これで、クラスターが動作可能になります。
ステップ4：テスト
クラスタが意図したとおりに機能していることを確認するには、任意のノードを選択してMariaDBにログインします。
mysql -u root -p
次のステートメントを発行して、データベースを作成します。
> CREATE DATABASE test0;> \ q
次に、他のすべてのノードでこの新しいデータベースを確認します。
mysql -u root -p -e "SHOW DATABASES;"
上記のコマンドは、test0を含むリストを返す必要があります：
+ -------------------- + |データベース|+-------------------- + | information_schema || mysql || performance_schema || test0 | + -------------------- +
すべてのノードからクラスターに書き込むことで、より徹底的にテストすることをお勧めします。テストに満足したら、不要なデータベースをクラスターからクリーンアップします。任意のノードを使用できます。
mysql -u root -p -e "DROP DATABASE test0;"
ステップ5：トラブルシューティングのヒント
次のクエリを使用して、ノード/クラスターの現在の状態に関する情報を表示します。
mysql -u root -p -e "SELECT * FROM information_schema.global_status WHERE variable_name IN（'WSREP_CLUSTER_STATUS'、'WSREP_LOCAL_STATE_COMMENT'、'WSREP_CLUSTER_SIZE'、'WSREP_EVS_REPL_LATENCY'、'WSREP_EVS_DELAYED'、'WSREP_READY'）;" pre>正常な3ノードクラスターは次を返す必要があります：
+ --------------------------- + ---------------- + | VARIABLE_NAME | VARIABLE_VALUE | + --------------------------- + ---------------- + | WSREP_CLUSTER_SIZE | 3 || WSREP_CLUSTER_STATUS |プライマリ|| WSREP_EVS_DELAYED | || WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 || WSREP_LOCAL_STATE_COMMENT |同期|| WSREP_READY |オン|+--------------------------- + ---------------- +
- WSREP_CLUSTER_SIZEは、クラスターコンポーネント内の現在のノード数を表します。
- WSREP_CLUSTER_STATUSは、クラスター全体ではなく、クラスターコンポーネントの状態を表します。
- WSREP_EVS_DELAYEDは、遅延しているノードのリストを表示します。正常なクラスターには空の値が期待されます。
- WSREP_EVS_REPL_LATENCYは、レプリケーションの待機時間をmin / avg / max / stddev/samplesizeの形式で示します。値は秒単位で表示されます。待ち時間が非常に長いと、パフォーマンスが低下する可能性があります。
- WSREP_LOCAL_STATE_COMMENTは現在のノードの状態を示します。
- WSREP_READYは、ノードがクエリを受け入れることができるかどうかを示します。
3ノードクラスター内のノードが接続を失うと、クラスターは2つのノードと非プライマリコンポーネントで構成されるプライマリコンポーネントに分割されます。主要コンポーネントは停止の影響を受けず、通常の動作を継続します。非プライマリコンポーネントの観点から、上記のクエリは次を返します。
+ --------------------------- + ------------------ -------------------------------------------------- -------------------------------------------------- ---------- + | VARIABLE_NAME | VARIABLE_VALUE | + --------------------------------------- + ------------------- -------------------------------------------------- -------------------------------------------------- --------- + | WSREP_CLUSTER_SIZE | 1 || WSREP_CLUSTER_STATUS |非プライマリ|| WSREP_EVS_DELAYED | 6b7864f2-fe7d-11e9-84ab-93e58c0d2907：tcp：//192.0.2.1：4567：3、a421be89-fe7d-11e9-a91e-7e62f7562e58：tcp：//192.0.2.3：4567：2 || WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 || WSREP_LOCAL_STATE_COMMENT |初期化|| WSREP_READY |オフ|+--------------------------- + ------------------- -------------------------------------------------- -------------------------------------------------- --------- +
WSREP_EVS_DELAYED値に注意してください。これは、他のノードへの接続の問題を示しています。
プライマリコンポーネントノードでは、同じクエリが次を返します。
+ --------------------------- + ------------------ ---------------------------------------------- + | VARIABLE_NAME | VARIABLE_VALUE | + --------------------------------------- + ------------------- --------------------------------------------- + | WSREP_CLUSTER_SIZE | 2 || WSREP_CLUSTER_STATUS |プライマリ|| WSREP_EVS_DELAYED | a2217526-fe7d-11e9-8692-1f2f0cdb403d：tcp：//192.0.2.2：4567：2 || WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 || WSREP_LOCAL_STATE_COMMENT |同期|| WSREP_READY |オン|+--------------------------- + ------------------- --------------------------------------------- +
単一ノードの障害から回復するために、手動による介入は必要ありません。障害が発生したノードがクラスターに再接続すると、クラスターと自動的に同期します。
高度な構成オプションについては、GaleraClusterシステム変数を参照してください。