MariaDBは、Spiderストレージエンジンに組み込まれたマルチホストシャーディング機能を提供します。 SpiderはパーティショニングとXAトランザクションをサポートし、異なるMariaDBインスタンスのリモートテーブルを同じインスタンス上にあるかのように処理できるようにします。リモートテーブルは、任意のストレージエンジンにすることができます。テーブルのリンクは、ローカルのMariaDBサーバーからリモートのMariaDBサーバーへの接続を確立することで実現され、リンクは同じトランザクションの一部であるすべてのテーブルで共有されます。
このブログ投稿では、ClusterControlを使用した2つのMariaDBシャードのクラスターのデプロイについて説明します。選択したシャードキーの範囲に基づいてパーティション化されたテーブルをホストするために、少数のMariaDBサーバー（冗長性と可用性のため）をデプロイします。選択されたシャードキーは、基本的に下限と上限の値を格納する列です。この場合、0〜1,000,000の整数値であるため、2つのシャード間のデータ分散のバランスをとるのに最適な候補キーになります。したがって、範囲を2つのパーティションに分割します。
-
0-499999：シャード1
-
500000-1000000：シャード2
次の図は、展開するものの高レベルのアーキテクチャを示しています。
図の説明：
-
mariadb-gw-1：スパイダーストレージエンジンを実行するMariaDBインスタンスは、シャードルーターのように機能します。このホストにMariaDBGateway1という名前を付けます。これは、シャードに到達するためのプライマリ（アクティブ）MariaDBサーバーになります。アプリケーションは、標準のMariaDB接続のようにこのホストに接続します。このノードは、127.0.0.1ポート3307（shard1）および3308（shard2）でリッスンしているHAProxyを介してシャードに接続します。
-
mariadb-gw-2：スパイダーストレージエンジンを実行するMariaDBインスタンスは、シャードルーターのように機能します。このホストにMariaDBGateway2という名前を付けます。これは、シャードに到達するためのセカンダリ（パッシブ）MariaDBサーバーになります。 mariadb-gw-1と同じ設定になります。アプリケーションは、プライマリMariaDBがダウンしている場合にのみこのホストに接続します。このノードは、127.0.0.1ポート3307（shard1）および3308（shard2）でリッスンしているHAProxyを介してシャードに接続します。
-
mariadb-shard-1a：最初のパーティションのプライマリデータノードとして機能するMariaDBマスター。 MariaDBゲートウェイサーバーは、シャードのマスターにのみ書き込む必要があります。
-
mariadb-shard-1b：最初のパーティションのセカンダリデータノードとして機能するMariaDBレプリカ。シャードのマスターがダウンした場合にマスターの役割を引き継ぎます（自動フェイルオーバーはClusterControlによって管理されます）。
-
mariadb-shard-2a：2番目のパーティションのプライマリデータノードとして機能するMariaDBマスター。 MariaDBゲートウェイサーバーは、シャードのマスターにのみ書き込みます。
-
mariadb-shard-2b：2番目のパーティションのセカンダリデータノードとして機能するMariaDBレプリカ。シャードのマスターがダウンした場合にマスターの役割を引き継ぎます（自動フェイルオーバーはClusterControlによって管理されます）。
-
ClusterControl：MariaDBシャード/クラスター用の一元化されたデプロイメント、管理、および監視ツール。
ClusterControlを使用したデータベースクラスターの展開
ClusterControlは、オープンソースのデータベース管理システムのライフサイクルを管理するための自動化ツールです。このブログ投稿では、ClusterControlをクラスターの展開、トポロジ管理、および監視のための一元化されたツールとして使用します。
1）ClusterControlをインストールします。
2）ClusterControlサーバーからすべてのデータベースノードへのパスワードなしのSSHを構成します。 ClusterControlノードの場合：
(clustercontrol)$ whoami
root
$ ssh-keygen -t rsa
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]3）4セットのクラスターをデプロイするため、この特定のタスクにはClusterControl CLIツールを使用して、デプロイメントプロセスを迅速化および簡素化することをお勧めします。最初に、次のコマンドを実行してデフォルトのクレデンシャルに接続できるかどうかを確認しましょう（デフォルトのクレデンシャルは/etc/s9s.confで自動構成されます）：
(clustercontrol)$ s9s cluster --list --long
Total: 0エラーが発生せず、上記と同様の出力が表示された場合は、問題ありません。
4）ClusterControlは並列展開をサポートしているため、ステップ4、5、6、および7を一度に実行できることに注意してください。まず、ClusterControlCLIを使用して最初のMariaDBゲートウェイサーバーをデプロイします。
(clustercontrol)$ s9s cluster --create \
--cluster-type=mysqlreplication \
--nodes="192.168.22.101?master" \
--vendor=mariadb \
--provider-version=10.5 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin="root" \
--db-admin-passwd="SuperS3cr3tPassw0rd" \
--cluster-name="MariaDB Gateway 1"5）2番目のMariaDBゲートウェイサーバーをデプロイします：
(clustercontrol)$ s9s cluster --create \
--cluster-type=mysqlreplication \
--nodes="192.168.22.102?master" \
--vendor=mariadb \
--provider-version=10.5 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin="root" \
--db-admin-passwd="SuperS3cr3tPassw0rd" \
--cluster-name="MariaDB Gateway 2"6）最初のシャードに2ノードのMariaDBレプリケーションをデプロイします：
(clustercontrol)$ s9s cluster --create \
--cluster-type=mysqlreplication \
--nodes="192.168.22.111?master;192.168.22.112?slave" \
--vendor=mariadb \
--provider-version=10.5 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin="root" \
--db-admin-passwd="SuperS3cr3tPassw0rd" \
--cluster-name="MariaDB - Shard 1"7）2番目のシャードに2ノードのMariaDBレプリケーションをデプロイします：
(clustercontrol)$ s9s cluster --create \
--cluster-type=mysqlreplication \
--nodes="192.168.22.121?master;192.168.22.122?slave" \
--vendor=mariadb \
--provider-version=10.5 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin="root" \
--db-admin-passwd="SuperS3cr3tPassw0rd" \
--cluster-name="MariaDB - Shard 2"デプロイの進行中、CLIからのジョブ出力を監視できます：
(clustercontrol)$ s9s job --list --show-running
ID CID STATE OWNER GROUP CREATED RDY TITLE
25 0 RUNNING admin admins 07:19:28 45% Create MySQL Replication Cluster
26 0 RUNNING admin admins 07:19:38 45% Create MySQL Replication Cluster
27 0 RUNNING admin admins 07:20:06 30% Create MySQL Replication Cluster
28 0 RUNNING admin admins 07:20:14 30% Create MySQL Replication Clusterまた、ClusterControl UIから：
展開が完了すると、データベースクラスターが一覧表示されます。 ClusterControlダッシュボードでは次のようになります：
クラスターがデプロイされ、最新のMariaDB10.5が実行されます。次に、MariaDBシャードに単一のエンドポイントを提供するようにHAProxyを構成する必要があります。
HAProxyは、シャードのマスタースレーブレプリケーションへの単一エンドポイントとして必要です。それ以外の場合、マスターがダウンした場合は、ゲートウェイサーバーでCREATE OR REPLACE SERVERステートメントを使用してSpiderのサーバーリストを更新し、ALTERTABLEを実行して新しい接続パラメーターを渡す必要があります。 HAProxyを使用すると、ゲートウェイサーバーのローカルホストでリッスンし、さまざまなポートでさまざまなMariaDBシャードを監視するように設定できます。両方のゲートウェイサーバーでHAProxyを次のように構成します。
-
127.0.0.1：3307-> Shard1（バックエンドサーバーはmariadb-shard-1aとmariadb-shard- 1b）
-
127.0.0.1：3308-> Shard2（バックエンドサーバーはmariadb-shard-2aとmariadb-shard- 2b）
シャードのマスターがダウンした場合、ClusterControlは新しいマスターとしてシャードのスレーブをフェイルオーバーし、HAProxyはそれに応じて接続を新しいマスターに再ルーティングします。以下に示すように、いくつかのトリックでバックエンドサーバー（mysqlchkセットアップ、ユーザー許可、xinetdインストール）を自動的に構成するため、ClusterControlを使用してゲートウェイサーバー（mariadb-gw-1およびmariadb-gw-2）にHAProxyをインストールします。
まず、ClusterControl UIで、最初のシャード、MariaDB-シャード1->管理->ロードバランサー-> HAProxy-> HAProxyを選択し、サーバーアドレスを192.168.22.101（ mariadb-gw-1）、次のスクリーンショットのように：
同様ですが、これはシャード2の場合で、MariaDBに移動します-シャード2 ->管理->ロードバランサー->HAProxy->HAProxyをデプロイし、サーバーアドレスを192.168.22.102（mariadb-gw-2）として指定します。両方のHAProxyノードの展開が完了するまで待ちます。
次に、すべてのシャードを一度に負荷分散するために、mariadb-gw-1とmariadb-gw-2でHAProxyサービスを構成する必要があります。テキストエディタ（またはClusterControlUI->管理->構成）を使用して、/ etc / haproxy/haproxy.cfgの最後の2つの「listen」ディレクティブを次のように編集します。
listen haproxy_3307_shard1
bind *:3307
mode tcp
timeout client 10800s
timeout server 10800s
tcp-check connect port 9200
tcp-check expect string master\ is\ running
balance leastconn
option tcp-check
default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
server 192.168.22.111 192.168.22.111:3306 check # mariadb-shard-1a-master
server 192.168.22.112 192.168.22.112:3306 check # mariadb-shard-1b-slave
listen haproxy_3308_shard2
bind *:3308
mode tcp
timeout client 10800s
timeout server 10800s
tcp-check connect port 9200
tcp-check expect string master\ is\ running
balance leastconn
option tcp-check
default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
server 192.168.22.121 192.168.22.121:3306 check # mariadb-shard-2a-master
server 192.168.22.122 192.168.22.122:3306 check # mariadb-shard-2b-slaveHAProxyサービスを再起動して変更をロードします（またはClusterControl->ノード-> HAProxy->ノードの再起動を使用します）：
$ systemctl restart haproxyClusterControl UIから、以下に示すように、シャードごとに1つのバックエンドサーバーのみがアクティブであることを確認できます（緑色の線で示されています）。
この時点で、データベースクラスターの展開は完了です。 Spiderストレージエンジンを使用してMariaDBシャーディングの構成に進むことができます。
両方のMariaDBゲートウェイサーバー（mariadb-gw-1とmariadb-gw-2）で、次のタスクを実行します。
MariaDB> INSTALL PLUGIN spider SONAME 'ha_spider.so';MariaDB> SELECT engine,support FROM information_schema.engines WHERE engine = 'spider';
+--------+---------+
| engine | support |
+--------+---------+
| SPIDER | YES |
+--------+---------+オプションで、プラグインがinformation_schemaデータベースから正しくロードされているかどうかを確認することもできます。
MariaDB> SELECT PLUGIN_NAME,PLUGIN_VERSION,PLUGIN_STATUS,PLUGIN_TYPE FROM information_schema.plugins WHERE plugin_name LIKE 'SPIDER%';
+--------------------------+----------------+---------------+--------------------+
| PLUGIN_NAME | PLUGIN_VERSION | PLUGIN_STATUS | PLUGIN_TYPE |
+--------------------------+----------------+---------------+--------------------+
| SPIDER | 3.3 | ACTIVE | STORAGE ENGINE |
| SPIDER_ALLOC_MEM | 1.0 | ACTIVE | INFORMATION SCHEMA |
| SPIDER_WRAPPER_PROTOCOLS | 1.0 | ACTIVE | INFORMATION SCHEMA |
+--------------------------+----------------+---------------+--------------------+MariaDB構成ファイル内の[mysqld]セクションの下に次の行を追加します：
plugin-load-add = ha_spiderMariaDB> CREATE OR REPLACE SERVER Shard1
FOREIGN DATA WRAPPER mysql
OPTIONS (
HOST '127.0.0.1',
DATABASE 'sbtest',
USER 'spider',
PASSWORD 'SpiderP455',
PORT 3307);CREATE OR REPLACE SERVER Shard2
FOREIGN DATA WRAPPER mysql
OPTIONS (
HOST '127.0.0.1',
DATABASE 'sbtest',
USER 'spider',
PASSWORD 'SpiderP455',
PORT 3308);これで、パーティション化する必要のあるSpiderテーブルを作成できます。この例では、データベースsbtest内にsbtest1というテーブルを作成し、列'k'の整数値でパーティション化します。
MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE TABLE sbtest.sbtest1 (
`id` int(11) NOT NULL AUTO_INCREMENT,
`k` int(11) NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`, `k`)
)
ENGINE=Spider
COMMENT 'wrapper "mysql", table "sbtest1"'
PARTITION BY RANGE (k) (
PARTITION shard1 VALUES LESS THAN (499999) COMMENT = 'srv "Shard1"',
PARTITION shard2 VALUES LESS THAN MAXVALUE COMMENT = 'srv "Shard2"'
);CREATETABLEステートメントのCOMMENT='srv"ShardX"'句は重要であり、リモートサーバーに関する接続情報を渡します。値は、CREATESERVERステートメントの場合と同じサーバー名である必要があります。以下に示すように、Sysbenchロードジェネレーターを使用してこのテーブルを埋めます。
データベースにアクセスするためのアプリケーションデータベースユーザーを作成し、アプリケーションサーバーからのアクセスを許可します。
MariaDB> CREATE USER [email protected]'192.168.22.%' IDENTIFIED BY 'passw0rd';
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'192.168.22.%';この例では、これは信頼できる内部ネットワークであるため、ステートメントでワイルドカードを使用して、同じ範囲192.168.22.0/24のすべてのIPアドレスを許可します。
両方のMariaDBシャードマスターサーバー（mariadb-shard-1aとmariadb-shard-2a）で、次のタスクを実行します。
1）宛先データベースを作成します：
MariaDB> CREATE SCHEMA sbtest;2）「スパイダー」ユーザーを作成し、ゲートウェイサーバー（mariadb-gw-1およびmariadb-gw2）からの接続を許可します。このユーザーは、シャードテーブルとMySQLシステムデータベースに対するすべての権限を持っている必要があります：
MariaDB> CREATE USER 'spider'@'192.168.22.%' IDENTIFIED BY 'SpiderP455';
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'192.168.22.%';
MariaDB> GRANT ALL ON mysql.* TO [email protected]'192.168.22.%';この例では、これは信頼できる内部ネットワークであるため、ステートメントでワイルドカードを使用して、同じ範囲192.168.22.0/24のすべてのIPアドレスを許可します。
3）スパイダーストレージエンジンを介してゲートウェイサーバーからデータを受信するテーブルを作成します。この「レシーバー」テーブルは、MariaDBでサポートされている任意のストレージエンジンに配置できます。この例では、InnoDBストレージエンジンを使用しています：
MariaDB> CREATE TABLE sbtest.sbtest1 (
`id` int(11) NOT NULL AUTO_INCREMENT,
`k` int(11) NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`, `k`)
) ENGINE = INNODB;Sysbenchを使用してデータベースワークロードを生成するテストを行うには、アプリケーションサーバーに事前にSysbenchをインストールする必要があります。
$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbenchいくつかのテストワークロードを生成し、それらを最初のゲートウェイサーバーであるmariadb-gw-1（192.168.11.101）に送信します：
$ sysbench \
/usr/share/sysbench/oltp_insert.lua \
--report-interval=2 \
--threads=4 \
--rate=20 \
--time=9999 \
--db-driver=mysql \
--mysql-host=192.168.11.101 \
--mysql-port=3306 \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=passw0rd \
--tables=1 \
--table-size=1000000 \
runmariadb-gw-2（192.168.11.102）で上記のテストを繰り返すことができ、それに応じてデータベース接続を適切なシャードにルーティングする必要があります。
最初のシャード（mariadb-shard-1aまたはmariadb-shard-1b）を見ると、このパーティションはシャードキー（列k）が500000より小さい行のみを保持していることがわかります。
MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 200175 | 499963 |
+--------+--------+別のシャード（mariadb-shard-2aまたはmariadb-shard-2b）では、予想どおり500000から999999までのデータを保持します：
MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 500067 | 999948 |
+--------+--------+MariaDBゲートウェイサーバー（mariadb-gw-1またはmariadb-gw-2）の場合、テーブルがこのMariaDBインスタンス内に存在する場合と同様のすべての行を表示できます。
MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 200175 | 999948 |
+--------+--------+高可用性の側面をテストするために、シャードマスターが利用できない場合、たとえば、シャード2のマスター（mariadb-shard-2a）がダウンした場合、ClusterControlは自動的にスレーブプロモーションを実行します。マスターになるスレーブ（mariadb-shard-2b）。この期間中に、おそらくこのエラーが表示される可能性があります：
ERROR 1429 (HY000) at line 1: Unable to connect to foreign data source: Shard2使用できない場合は、次のエラーが発生します。
ERROR 1158 (08S01) at line 1: Got an error reading communication packets私たちの測定では、フェイルオーバーはフェイルオーバーが開始されてから約23秒かかり、新しいマスターが昇格すると、通常どおりゲートウェイサーバーからテーブルに書き込むことができるはずです。
>上記のセットアップは、ClusterControlを使用してMariaDBシャードセットアップをデプロイする方法に関する原則の証明です。また、自動ノードおよびクラスター回復機能に加えて、データベースインフラストラクチャ全体をサポートするための業界標準の管理および監視機能をすべて備えた、MariaDBシャーディングセットアップのサービス可用性を向上させることもできます。