コンテナーオーケストレーションツールは、コンテナーをデプロイおよび再デプロイし、発生した障害を処理することにより、分散システムの実行を簡素化します。たとえば、更新、スケーリング、または根本的なホスト障害を処理するために、アプリケーションを移動する必要がある場合があります。これは素晴らしいことのように聞こえますが、Galeraのような一貫性の高いデータベースクラスターでは常にうまく機能するとは限りません。データベースノードを移動するだけでなく、ステートレスアプリケーションではありません。また、クラスターで操作を実行する順序は非常に重要です。たとえば、Galeraクラスターの再起動は、最も高度なノードから開始する必要があります。そうしないと、データが失われます。したがって、コンテナオーケストレーションツールを使用せずにDockerでGalera Clusterを実行する方法を説明します。これにより、完全に制御できます。
このブログ投稿では、SwarmやKubernetesなどのオーケストレーションツールを使用せずに、複数のDockerホストで標準のDockerイメージを使用してDockerコンテナーでMariaDBGaleraClusterを実行する方法について説明します。このアプローチは、標準ホストでGalera Clusterを実行するのと似ていますが、プロセス管理はDockerを介して構成されます。
詳細に進む前に、Dockerをインストールし、SElinux / AppArmorを無効にし、iptables、firewalld、ufw（どちらを使用している場合でも）内のルールをクリアしたと仮定します。以下は、データベースクラスター専用の3つのDockerホストです。
- host1.local-192.168.55.161
- host2.local-192.168.55.162
- host3.local-192.168.55.163
マルチホストネットワーキング
まず、デフォルトのDockerネットワークがローカルホストにバインドされています。 Docker Swarmは、オーバーレイネットワークと呼ばれる別のネットワークレイヤーを導入します。これは、コンテナーインターネットワーキングをSwarmと呼ばれるクラスター内の複数のDockerホストに拡張します。この統合が実施されるずっと前から、これをサポートするために開発された多くのネットワークプラグインがありました。Flannel、Calico、Weaveなどがその一部です。
ここでは、マルチホストネットワーク用のDockerネットワークプラグインとしてWeaveを使用します。これは主に、インストールと実行が簡単で、DNSリゾルバーがサポートされているためです（このネットワークで実行されているコンテナーは、互いのホスト名を解決できます）。 Weaveを実行するには、systemdまたはDockerを使用する2つの方法があります。 systemdユニットとしてインストールするため、Dockerデーモンから独立しています（そうでない場合は、Weaveがアクティブ化される前にDockerを最初に起動する必要があります）。
-
Weaveをダウンロードしてインストールします：
$ curl -L git.io/weave -o /usr/local/bin/weave $ chmod a+x /usr/local/bin/weave -
Weaveのsystemdユニットファイルを作成します：
$ cat > /etc/systemd/system/weave.service << EOF [Unit] Description=Weave Network Documentation=http://docs.weave.works/weave/latest_release/ Requires=docker.service After=docker.service [Service] EnvironmentFile=-/etc/sysconfig/weave ExecStartPre=/usr/local/bin/weave launch --no-restart $PEERS ExecStart=/usr/bin/docker attach weave ExecStop=/usr/local/bin/weave stop [Install] WantedBy=multi-user.target EOF -
/ etc / sysconfig / weave内のピアのIPアドレスまたはホスト名を定義します：
$ echo 'PEERS="192.168.55.161 192.168.55.162 192.168.55.163"' > /etc/sysconfig/weave -
起動時にWeaveを開始して有効にします：
$ systemctl start weave $ systemctl enable weave
すべてのDockerホストで上記の4つの手順を繰り返します。完了したら、次のコマンドで確認します。
$ weave statusピアの数は私たちが世話をしているものです。 3：
である必要があります ...
Peers: 3 (with 6 established connections)
...ガレラクラスターの実行
これでネットワークの準備が整いました。データベースコンテナを起動してクラスタを形成します。基本的なルールは次のとおりです。
- マルチホスト接続を使用するには、コンテナを--net=weaveの下に作成する必要があります。
- 公開する必要のあるコンテナポートは、3306、4444、4567、4568です。
- DockerイメージはGaleraをサポートしている必要があります。 Oracle MySQLを使用する場合は、Codershipバージョンを入手してください。 Perconaが必要な場合は、代わりにこの画像を使用してください。このブログ投稿では、MariaDBを使用しています。
GaleraクラスターベンダーとしてMariaDBを選択した理由は次のとおりです。
- GaleraはMariaDB10.1以降、MariaDBに組み込まれています。
- MariaDBイメージは、DockerチームとMariaDBチームによって維持されています。
- 最も人気のあるDockerイメージの1つ。
ガレラクラスターのブートストラップは、順番に実行する必要があります。まず、最新のノードは「wsrep_cluster_address =gcomm：//」で開始する必要があります。次に、残りのノードを、クラスター内のすべてのノードで構成される完全なアドレスで開始します（例：「wsrep_cluster_address =gcomm：// node1、node2、node3」）。コンテナを使用してこれらの手順を実行するには、すべてのコンテナが均一に実行されていることを確認するために、いくつかの追加の手順を実行する必要があります。したがって、計画は次のとおりです。
- この順序で4つのコンテナ（mariadb0（ブートストラップ）、mariadb2、mariadb3、mariadb1）から始める必要があります。
- コンテナmariadb0は、mariadb1と同じdatadirとconfigdirを使用します。
- 最初のブートストラップにhost1でmariadb0を使用してから、host2でmariadb2を起動し、host3でmariadb3を起動します。
- host1のmariadb0を削除して、mariadb1に道を譲ります。
- 最後に、host1でmariadb1を起動します。
1日の終わりには、3ノードのGaleraクラスター（mariadb1、mariadb2、mariadb3）が作成されます。最初のコンテナ（mariadb0）は、クラスタアドレス「gcomm：//」を使用する、ブートストラップのみを目的とした一時的なコンテナです。これは、mariadb1と同じdatadirおよびconfigdirを共有し、クラスターが形成され（mariadb2およびmariadb3が稼働している）、ノードが同期されると削除されます。
デフォルトでは、GaleraはMariaDBでオフになっており、 wsrep_onというフラグで有効にする必要があります。 （オンに設定）および wsrep_provider （Galeraライブラリパスに設定）に加えて、Galera関連のパラメータの数。したがって、Galeraを正しく構成するには、コンテナーのカスタム構成ファイルを定義する必要があります。
最初のコンテナ、mariadb0から始めましょう。 /containers/mariadb1/conf.d/my.cnfの下にファイルを作成し、次の行を追加します。
$ mkdir -p /containers/mariadb1/conf.d
$ cat /containers/mariadb1/conf.d/my.cnf
[mysqld]
default_storage_engine = InnoDB
binlog_format = ROW
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_file_per_table = 1
innodb_autoinc_lock_mode = 2
innodb_lock_schedule_algorithm = FCFS # MariaDB >10.1.19 and >10.2.3 only
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method = xtrabackup-v2イメージにはMariaDBバックアップ（MariaDB10.1およびMariaDB10.2で推奨されるSSTメソッド）が付属していないため、当面はxtrabackup-v2を使用します。
クラスタの最初のブートストラップを実行するには、ホスト1でmariadb1の「datadir」と「conf.d」を使用してブートストラップコンテナ（mariadb0）を実行します。
$ docker run -d \
--name mariadb0 \
--hostname mariadb0.weave.local \
--net weave \
--publish "3306" \
--publish "4444" \
--publish "4567" \
--publish "4568" \
$(weave dns-args) \
--env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
--env MYSQL_USER=proxysql \
--env MYSQL_PASSWORD=proxysqlpassword \
--volume /containers/mariadb1/datadir:/var/lib/mysql \
--volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
mariadb:10.2.15 \
--wsrep_cluster_address=gcomm:// \
--wsrep_sst_auth="root:PM7%[email protected]^1" \
--wsrep_node_address=mariadb0.weave.local上記のコマンドで使用されるパラメーターは次のとおりです。
- -名前 、「mariadb0」という名前のコンテナを作成します。
- -ホスト名 、コンテナにホスト名「mariadb0.weave.local」を割り当てます。
- -net 、マルチホストネットワークサポートのためにコンテナをウィーブネットワークに配置します。
- -公開 、コンテナのポート3306、4444、4567、4568をホストに公開します。
- $（weave dns-args） 、このコンテナのDNSリゾルバを構成します。このコマンドは、「-dns =172.17.0.1--dns-search=weave.local。」としてDocker実行に変換できます。
- -env MYSQL_ROOT_PASSWORD 、MySQLルートパスワード
- -env MYSQL_USER 、データベースルーティングのためにProxySQLで後で使用する「proxysql」ユーザーを作成します。
- -env MYSQL_PASSWORD 、「proxysql」ユーザーパスワード、
- -volume / containers / mariadb1 / datadir：/ var / lib / mysql 、存在しない場合は/ containers / mariadb1 / datadirを作成し、コンテナーの/ var / lib / mysql（MySQL datadir）にマップします（ブートストラップノードの場合、これはスキップできます）。
- -volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d 、Dockerホストのディレクトリ/containers/mariadb1/conf.dの下にあるファイルを/etc/mysql/mariadb.conf.dのコンテナにマウントします。
- mariadb：10.2.15 、ここからMariaDB10.2.15イメージを使用します
- -wsrep_cluster_address 、クラスターのGalera接続文字列。 「gcomm：//」はブートストラップを意味します。残りのコンテナについては、代わりに完全なアドレスを使用します。
- -wsrep_sst_auth 、SSTユーザーの認証文字列。 rootと同じユーザーを使用します
- -wsrep_node_address 、ノードのホスト名。この場合、Weaveによって提供されるFQDNを使用します。
ブートストラップコンテナには、いくつかの重要なものが含まれています。
- 名前、ホスト名、およびwsrep_node_addressはmariadb0ですが、mariadb1のボリュームを使用します。
- クラスターアドレスは「gcomm：//」です
- 2つの追加の--envパラメーターがあります-MYSQL_USERとMYSQL_PASSWORD。このパラメータは、proxysqlモニタリングの目的で追加のユーザーを作成します。
次のコマンドで確認します：
$ docker ps
$ docker logs -f mariadb0次の行が表示されたら、ブートストラッププロセスが完了し、Galeraがアクティブであることを示しています。
2018-05-30 23:19:30 139816524539648 [Note] WSREP: Synchronized with group, ready for connections残りのホストにカスタム構成ファイルをロードするためのディレクトリを作成します：
$ mkdir -p /containers/mariadb2/conf.d # on host2
$ mkdir -p /containers/mariadb3/conf.d # on host3次に、mariadb0とmariadb1用に作成したmy.cnfをそれぞれmariadb2とmariadb3にコピーします。
$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb2/conf.d/ # on host1
$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb3/conf.d/ # on host1次に、host2とhost3にそれぞれ別の2つのデータベースコンテナ（mariadb2とmariadb3）を作成します。
$ docker run -d \
--name ${NAME} \
--hostname ${NAME}.weave.local \
--net weave \
--publish "3306:3306" \
--publish "4444" \
--publish "4567" \
--publish "4568" \
$(weave dns-args) \
--env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
--volume /containers/${NAME}/datadir:/var/lib/mysql \
--volume /containers/${NAME}/conf.d:/etc/mysql/mariadb.conf.d \
mariadb:10.2.15 \
--wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
--wsrep_sst_auth="root:PM7%[email protected]^1" \
--wsrep_node_address=${NAME}.weave.local**${NAME}をそれぞれmariadb2またはmariadb3に置き換えます。
ただし、落とし穴があります。エントリポイントスクリプトは、パスワードなしでMySQL rootユーザーを使用して、データベースの初期化後にバックグラウンドでmysqldサービスをチェックします。 Galeraは起動時にSSTまたはISTを介して自動的に同期を実行するため、MySQLのrootユーザーのパスワードが変更され、ブートストラップされたノードがミラーリングされます。したがって、最初の起動時に次のエラーが表示されます。
018-05-30 23:27:13 140003794790144 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
MySQL init process in progress…
MySQL init process failed.トリックは、失敗したコンテナをもう一度再起動することです。今回は、MySQL datadirが（最初の実行試行で）作成され、データベースの初期化部分をスキップするためです。
$ docker start mariadb2 # on host2
$ docker start mariadb3 # on host3開始したら、次の行を見て確認します。
$ docker logs -f mariadb2
…
2018-05-30 23:28:39 139808069601024 [Note] WSREP: Synchronized with group, ready for connectionsこの時点で、mariadb0、mariadb2、mariadb3の3つのコンテナが実行されています。 mariadb0はbootstrapコマンド（gcomm：//）を使用して開始されることに注意してください。つまり、コンテナーが将来Dockerによって自動的に再起動されると、プライマリコンポーネントと切り離される可能性があります。したがって、このコンテナを削除して、他のコンテナと同じGalera接続文字列を使用してmariadb1に置き換え、mariadb0で同じdatadirとconfigdirを使用する必要があります。
まず、SIGTERMを送信してmariadb0を停止します（ノードが正常にシャットダウンされるようにするため）：
$ docker kill -s 15 mariadb0次に、mariadb2またはmariadb3と同様のコマンドを使用して、host1でmariadb1を起動します。
$ docker run -d \
--name mariadb1 \
--hostname mariadb1.weave.local \
--net weave \
--publish "3306:3306" \
--publish "4444" \
--publish "4567" \
--publish "4568" \
$(weave dns-args) \
--env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
--volume /containers/mariadb1/datadir:/var/lib/mysql \
--volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
mariadb:10.2.15 \
--wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
--wsrep_sst_auth="root:PM7%[email protected]^1" \
--wsrep_node_address=mariadb1.weave.local今回は、MySQL datadirがすでに存在する（mariadb0によって作成される）ため、再起動のトリックを実行する必要はありません。コンテナが起動したら、クラスタサイズが3であることを確認します。ステータスはプライマリであり、ローカル状態が同期されている必要があります。
$ docker exec -it mariadb3 mysql -uroot "-pPM7%[email protected]^1" -e 'select variable_name, variable_value from information_schema.global_status where variable_name in ("wsrep_cluster_size", "wsrep_local_state_comment", "wsrep_cluster_status", "wsrep_incoming_addresses")'
+---------------------------+-------------------------------------------------------------------------------+
| variable_name | variable_value |
+---------------------------+-------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE | 3 |
| WSREP_CLUSTER_STATUS | Primary |
| WSREP_INCOMING_ADDRESSES | mariadb1.weave.local:3306,mariadb3.weave.local:3306,mariadb2.weave.local:3306 |
| WSREP_LOCAL_STATE_COMMENT | Synced |
+---------------------------+-------------------------------------------------------------------------------+この時点で、私たちのアーキテクチャは次のようになっています。
runコマンドはかなり長いですが、コンテナの特性をよく表しています。コマンドをスクリプトでラップして実行手順を簡略化するか、代わりに作成ファイルを使用することをお勧めします。
ProxySQLを使用したデータベースルーティング
これで、3つのデータベースコンテナが実行されました。現在、クラスターにアクセスする唯一の方法は、個々のDockerホストの公開されたMySQLのポートである3306（コンテナーへの3306へのマップ）にアクセスすることです。では、データベースコンテナの1つに障害が発生した場合はどうなりますか？クライアントの接続を次に使用可能なノードに手動でフェイルオーバーする必要があります。アプリケーションコネクタによっては、ノードのリストを指定して、コネクタにフェイルオーバーとクエリルーティングを実行させることもできます（Connector / J、PHP mysqlnd）。それ以外の場合は、データベースリソースをサービスと呼ばれる単一のリソースに統合することをお勧めします。
ここでProxySQLが登場します。 ProxySQLはクエリルーターとして機能し、SwarmまたはKubernetesの世界の「サービス」と同様にデータベース接続の負荷を分散します。この目的のためにProxySQLDockerイメージを構築し、最善を尽くしてすべての新しいバージョンのイメージを維持します。
ProxySQLコンテナを実行する前に、構成ファイルを準備する必要があります。以下は、proxysql1用に構成したものです。 host1の/containers/proxysql1/proxysql.cnfの下にカスタム構成ファイルを作成します：
$ cat /containers/proxysql1/proxysql.cnf
datadir="/var/lib/proxysql"
admin_variables=
{
admin_credentials="admin:admin"
mysql_ifaces="0.0.0.0:6032"
refresh_interval=2000
}
mysql_variables=
{
threads=4
max_connections=2048
default_query_delay=0
default_query_timeout=36000000
have_compress=true
poll_timeout=2000
interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
default_schema="information_schema"
stacksize=1048576
server_version="5.1.30"
connect_timeout_server=10000
monitor_history=60000
monitor_connect_interval=200000
monitor_ping_interval=200000
ping_interval_server=10000
ping_timeout_server=200
commands_stats=true
sessions_sort=true
monitor_username="proxysql"
monitor_password="proxysqlpassword"
}
mysql_servers =
(
{ address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
{ address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
{ address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)
mysql_users =
(
{ username = "sbtest" , password = "password" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
{
rule_id=100
active=1
match_pattern="^SELECT .* FOR UPDATE"
destination_hostgroup=10
apply=1
},
{
rule_id=200
active=1
match_pattern="^SELECT .*"
destination_hostgroup=20
apply=1
},
{
rule_id=300
active=1
match_pattern=".*"
destination_hostgroup=10
apply=1
}
)
scheduler =
(
{
id = 1
filename = "/usr/share/proxysql/tools/proxysql_galera_checker.sh"
active = 1
interval_ms = 2000
arg1 = "10"
arg2 = "20"
arg3 = "1"
arg4 = "1"
arg5 = "/var/lib/proxysql/proxysql_galera_checker.log"
}
)上記の構成は次のようになります：
- 「mysql_servers」セクションで定義されているように、シングルライターグループとマルチライターグループの2つのホストグループを構成します。
- 読み取りをすべてのGaleraノード（ホストグループ20）に送信し、書き込み操作は単一のGaleraサーバー（ホストグループ10）に送信します。
- proxysql_galera_checker.shをスケジュールします。
- 最初にクラスター（mariadb0）をブートストラップしたときに作成された監視資格情報としてmonitor_usernameとmonitor_passwordを使用します。
ProxySQLの冗長性のために、構成ファイルをhost2にコピーします。
$ mkdir -p /containers/proxysql2/ # on host2
$ scp /containers/proxysql1/proxysql.cnf /container/proxysql2/ # on host1次に、host1とhost2でそれぞれProxySQLコンテナを実行します。
$ docker run -d \
--name=${NAME} \
--publish 6033 \
--publish 6032 \
--restart always \
--net=weave \
$(weave dns-args) \
--hostname ${NAME}.weave.local \
-v /containers/${NAME}/proxysql.cnf:/etc/proxysql.cnf \
-v /containers/${NAME}/data:/var/lib/proxysql \
severalnines/proxysql**${NAME}をそれぞれproxysql1またはproxysql2に置き換えます。
-restart =alwaysを指定しました 終了ステータスに関係なく常に使用可能にし、Dockerデーモンの起動時に自動起動します。これにより、ProxySQLコンテナがデーモンのように機能するようになります。
両方のProxySQLインスタンスによって監視されているMySQLサーバーのステータスを確認します（シングルライターホストグループにはOFFLINE_SOFTが必要です）：
$ docker exec -it proxysql1 mysql -uadmin -padmin -h127.0.0.1 -P6032 -e 'select hostgroup_id,hostname,status from mysql_servers'
+--------------+----------------------+--------------+
| hostgroup_id | hostname | status |
+--------------+----------------------+--------------+
| 10 | mariadb1.weave.local | ONLINE |
| 10 | mariadb2.weave.local | OFFLINE_SOFT |
| 10 | mariadb3.weave.local | OFFLINE_SOFT |
| 20 | mariadb1.weave.local | ONLINE |
| 20 | mariadb2.weave.local | ONLINE |
| 20 | mariadb3.weave.local | ONLINE |
+--------------+----------------------+--------------+この時点で、私たちのアーキテクチャは次のようになっています。
6033（host1、host2、またはコンテナーのネットワークのいずれか）からのすべての接続は、ProxySQLを使用してバックエンドデータベースコンテナーに負荷分散されます。個々のデータベースサーバーにアクセスする場合は、代わりに物理ホストのポート3306を使用してください。 ProxySQLサービス用に構成された単一のエンドポイントとして仮想IPアドレスはありませんが、次のセクションで説明するKeepalivedを使用して仮想IPアドレスを設定できます。
キープアライブを使用した仮想IPアドレス
ProxySQLコンテナをhost1とhost2で実行するように構成したので、Keepalivedコンテナを使用してこれらのホストを結び付け、ホストネットワークを介して仮想IPアドレスを提供します。これにより、アプリケーションまたはクライアントの単一のエンドポイントが、ProxySQLに基づく負荷分散レイヤーに接続できるようになります。
いつものように、Keepalivedサービスのカスタム構成ファイルを作成します。 /containers/keepalived1/keepalived.confの内容は次のとおりです：
vrrp_instance VI_DOCKER {
interface ens33 # interface to monitor
state MASTER
virtual_router_id 52 # Assign one ID for this route
priority 101
unicast_src_ip 192.168.55.161
unicast_peer {
192.168.55.162
}
virtual_ipaddress {
192.168.55.160 # the virtual IP
}2番目のインスタンスの構成ファイルをhost2にコピーします：
$ mkdir -p /containers/keepalived2/ # on host2
$ scp /containers/keepalived1/keepalived.conf /container/keepalived2/ # on host1host2にコピーされた構成ファイル内で優先度を101から100に変更します：
$ sed -i 's/101/100/g' /containers/keepalived2/keepalived.conf**優先度の高いインスタンスは、VRRP通信が中断されるまで（host1がダウンした場合）、仮想IPアドレス（この場合はhost1）を保持します。
次に、host1とhost2でそれぞれ次のコマンドを実行します。
$ docker run -d \
--name=${NAME} \
--cap-add=NET_ADMIN \
--net=host \
--restart=always \
--volume /containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf \ osixia/keepalived:1.4.4**${NAME}をkeepalived1とkeepalived2に置き換えます。
runコマンドは、Dockerに次のように指示します。
- -名前 、でコンテナを作成します
- -cap-add =NET_ADMIN 、ネットワーク管理スコープにLinux機能を追加する
- -net =host 、コンテナをホストネットワークに接続します。これにより、ホストインターフェイスens33に仮想IPアドレスが提供されます
- -restart =always 、常にコンテナを実行し続けます。
- -volume =/ containers / $ {NAME} /keepalived.conf:/usr/local/etc/keepalived/keepalived.conf 、コンテナの使用に合わせてカスタム構成ファイルをマップします。
両方のコンテナが起動したら、MASTERノードの物理ネットワークインターフェイスを確認して、仮想IPアドレスの存在を確認します。
$ ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 192.168.55.161/24 brd 192.168.55.255 scope global ens33
inet 192.168.55.160/32 scope global ens33クライアントとアプリケーションは、仮想IPアドレス192.168.55.160を使用してデータベースサービスにアクセスできるようになりました。この仮想IPアドレスは、現時点ではhost1に存在します。 host1がダウンした場合、keepalived2がIPアドレスを引き継ぎ、host2で起動します。このキープアライブの構成はProxySQLコンテナーを監視しないことに注意してください。 KeepalivedピアのVRRPアドバタイズメントのみを監視します。
この時点で、私たちのアーキテクチャは次のようになっています。
概要
これで、高可用性ProxySQLサービスが前面にあるMariaDB Galeraクラスターができ、すべてDockerコンテナーで実行されます。
パート2では、このセットアップを管理する方法を調べます。グレースフルシャットダウン、ブートストラップ、最先端のノードの検出、フェイルオーバー、リカバリ、スケールアップ/ダウン、アップグレード、バックアップなどの操作を実行する方法を見ていきます。また、クラスター化データベースサービスに対してこのセットアップを行うことの長所と短所についても説明します。
コンテナ化をお楽しみください！