CentOS8でPXCクラスターを構築する

PXCの概要##

PXCは、[Percona XtraDB Cluster]（https://www.percona.com/doc/percona-xtradb-cluster/LATEST/index.html）の略語であり、Perconaによって作成された無料の[MySQL]（https://cloud.tencent.com/product/cdb?from=10680）クラスター製品です。 PXCの機能は、mysqlに付属のGaleraクラスターテクノロジーを介してさまざまなmysqlインスタンスを接続し、マルチマスタークラスターを実現することです。 PXCクラスターでは、各mysqlノードは読み取りと書き込みが可能です。これはマスタースレーブの概念のマスターノードです。読み取り専用ノードはありません。

PXCは、実際にはGaleraに基づくOLTP用のマルチマスター同期レプリケーションプラグインです。PXCは主に、MySQLクラスターでの強力なデータ同期の問題を解決するために使用されます。 PXCは、[MariaDB]（https://cloud.tencent.com/product/tdsql?from=10680）やPercona Serverなど、mysqlの派生バージョンをクラスター化できます。 Percona Serverのパフォーマンスはmysqlエンタープライズバージョンに最も近いため、そのパフォーマンスはmysqlの標準バージョンと比較して大幅に改善されており、基本的にmysqlと互換性があります。したがって、PXCクラスターを構築するときは、通常、Perconaサーバーに基づいて構築することをお勧めします。

データベースクラスターソリューションの選択については、以下を参照してください。

[ データベースクラスターソリューションについて話す]（https://blog.51cto.com/zero01/2464498）

PXC ###の機能

同期レプリケーション、トランザクションは完了するまで送信されるか、すべてのクラスターノードですべて失敗します
マルチマスターレプリケーション、マスタースレーブの役割の分割はありません。読み取り/書き込み操作は任意のノードで実行できます
データ同期の強力な一貫性、すべてのノードのデータはリアルタイムで一貫性があります
PXCクラスターノードが多いほど、データ同期速度が遅くなるため、PXCクラスターを大きくしすぎることはできません。
PXCクラスターのデータ同期の速度は、構成が最も少ないノードに依存するため、PXCクラスター内のすべてのノードのハードウェア構成は可能な限り一貫している必要があります。
PXCクラスターはInnoDBエンジンのみをサポートするため、InnoDBエンジンのデータのみが同期されます

PXCをインストールしてクラスターを形成します##

環境への準備###

環境バージョンの説明：

VMware Workstation Pro 15.5
Percona XtraDB Cluster 5.7
CentOS 8

MySQLにはいくつかの一般的な派生バージョンがあり、PerconaServerはその1つです。 Percona Serverは、MySQLのエンタープライズバージョンに最も近いため、ここで選択されています。各派生バージョンの比較チャートは次のとおりです。

この記事のPXCクラスターの設計を次の図に示します。

**ヒント：**実際には、最小のPXCクラスターには2つのノードがありますが、コースは3つのノード用に設計されています。これは、スプリットブレインを防ぐために、予期しないダウンタイムのためにノードの半分以上にアクセスできなくなると、PXCクラスターの実行が自動的に停止するためです。したがって、2つのノードとして設計されている場合、一方のノードがダウンしていて、ノードの半分以上にアクセスできない場合、クラスターは実行を停止し、もう一方のノードは使用できなくなります。このような耐災害性は不十分であるため、PXCクラスターの可用性を向上させるために少なくとも3つのノードがここで設計されています。

図によると、3ノードのPXCクラスターを構築するには、3つの仮想マシンを作成する必要があります。

ノードの説明：

Node	Host	IP
Node1	PXC-Node1	192.168.190.132
Node2	PXC-Node2	192.168.190.133
Node3	PXC-Node3	192.168.190.134

各仮想マシンの構成は次のとおりです。

PXCクラスターに関しては、強力なデータ整合性を確保するためにパフォーマンスが犠牲になります。 PXCクラスター内のノードが多いほど、データの同期時間が長くなります。クラスターを実行するために使用するデータベースサーバーの数が最も適切であり、比較的言えば、パフォーマンスで最高の結果を達成できるでしょうか。

一般的に、PXCクラスターを形成するノードは15個以下であり、パフォーマンスは非常に優れています。次に、このPXCクラスターがシャードとして使用され、データのセグメンテーションと同時アクセスを処理するために、さらにいくつかのシャードがMyCatに設定されます。

システムの準備###

一部のCentOSバージョンはデフォルトで mariadb-libsにバンドルされており、PXCをインストールする前にアンインストールする必要があります。

[ root@PXC-Node1 ~]# yum -y remove mari*

PXCクラスターは4つのポートを使用します。

ポート	説明
3306	MySQLサービスポート
4444	完全同期（SST）ポートを要求する
4567	データベースノード間の通信ポート
4568	インクリメンタル同期（IST）ポートを要求する

したがって、システムでファイアウォールが有効になっている場合は、次のポートを開く必要があります。

[ root@PXC-Node1 ~]# firewall-cmd --zone=public--add-port=3306/tcp --permanent
[ root@PXC-Node1 ~]# firewall-cmd --zone=public--add-port=4444/tcp --permanent
[ root@PXC-Node1 ~]# firewall-cmd --zone=public--add-port=4567/tcp --permanent
[ root@PXC-Node1 ~]# firewall-cmd --zone=public--add-port=4568/tcp --permanent
[ root@PXC-Node1 ~]# firewall-cmd --reload

PXC ###をインストールします

まず、公式ドキュメントに移動します。

Installing Percona XtraDB Cluster

PXCの簡単なインストール方法は2つあります。1つは公式Webサイトから rpmパッケージをダウンロードしてシステムにローカルにインストールする方法、もう1つは公式の yumリポジトリを使用してオンラインインストールする方法です。この記事では、このローカルインストールの方法を示します。まず、次のURLを開きます。

https://www.percona.com/downloads/Percona-XtraDB-Cluster-LATEST/

適切なバージョンを選択したら、ダウンロードリンクをコピーします。

次に、次の例に示すように、 wgetコマンドを使用してCentOSにダウンロードします。

[ root@PXC-Node1 ~]# cd /usr/local/src
[ root@PXC-Node1 /usr/local/src]# wget https://www.percona.com/downloads/Percona-XtraDB-Cluster-LATEST/Percona-XtraDB-Cluster-5.7.28-31.41/binary/redhat/8/x86_64/Percona-XtraDB-Cluster-5.7.28-31.41-r514-el8-x86_64-bundle.tar

rpmファイルを保存するためのディレクトリを作成し、ダウンロードしたPXCインストールパッケージを新しく作成したディレクトリに解凍します。

[ root@PXC-Node1 /usr/local/src]# mkdir pxc-rpms
[ root@PXC-Node1 /usr/local/src]# tar -xvf Percona-XtraDB-Cluster-5.7.28-31.41-r514-el8-x86_64-bundle.tar -C pxc-rpms
[ root@PXC-Node1 /usr/local/src]# ls pxc-rpms
Percona-XtraDB-Cluster-57-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-57-debuginfo-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-57-debugsource-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-client-57-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-client-57-debuginfo-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-devel-57-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-full-57-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-garbd-57-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-garbd-57-debuginfo-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-server-57-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-server-57-debuginfo-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-shared-57-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-shared-57-debuginfo-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-test-57-5.7.28-31.41.1.el8.x86_64.rpm
Percona-XtraDB-Cluster-test-57-debuginfo-5.7.28-31.41.1.el8.x86_64.rpm

さらに、PXCのインストールは qpressと percona-xtrabackup-24に依存する必要があり、[percona提供の倉庫]（https://repo.percona.com/release/8/RPMS/x86_64/）で対応する rpmパッケージのダウンロードリンクを取得できます。次に、次のように、 pxc-rpmsディレクトリに入り、これら2つのコンポーネントの rpmパッケージをダウンロードします。

[ root@PXC-Node1 /usr/local/src]# cd pxc-rpms
[ root@PXC-Node1 /usr/local/src/pxc-rpms]# wget https://repo.percona.com/release/8/RPMS/x86_64/qpress-11-1.el8.x86_64.rpm
[ root@PXC-Node1 /usr/local/src/pxc-rpms]# wget https://repo.percona.com/release/8/RPMS/x86_64/percona-xtrabackup-24-2.4.18-1.el8.x86_64.rpm

上記の手順を完了すると、 yumコマンドを使用してPXCをローカルにインストールできるようになります。

[ root@PXC-Node1 /usr/local/src/pxc-rpms]# yum localinstall -y *.rpm

インストールが正常に完了すると、システムに mysqlの関連コマンドがあります。以下のように、バージョン情報を正常に表示できれば、インストールは成功です。

[ root@PXC-Node1 /usr/local/src/pxc-rpms]# mysql --version
mysql  Ver 14.14 Distrib 5.7.28-31,forLinux(x86_64) using  7.0[root@PXC-Node1 /usr/local/src/pxc-rpms]#

PXCクラスターを構成します###

インストール後、クラスターを起動するためにいくつかの構成が必要です。PXC構成ファイルはデフォルトで / etc / percona-xtradb-cluster.conf.d /ディレクトリにあり、 / etc / my.cnfファイルはそれへの単なる参照です。

[ root@PXC-Node1 ~]# cd /etc/percona-xtradb-cluster.conf.d/[root@PXC-Node1 /etc/percona-xtradb-cluster.conf.d]# ll
合計金額12-rw-r--r--1ルートルート38112 1317:19 mysqld.cnf  #mysql関連の構成
- rw-r--r--1ルートルート44012 1317年12月:19 mysqld_safe.cnf  # mysqld_安全な関連構成
- rw-r--r--1ルートルート106612 1317年5月:19 wsrep.cnf  #PXCクラスター関連の構成

文字セットなどのいくつかの基本的な構成を mysqld.cnfファイルに追加します。

[ root@PXC-Node1 /etc/percona-xtradb-cluster.conf.d]# vim mysqld.cnf
[ mysqld]...

# キャラクターセットを設定する
character_set_server=utf8
# リスニングIPを設定する
bind-address=0.0.0.0
# DNS解決をスキップする
skip-name-resolve

次に、PXCクラスターを構成し、 wsrep.cnfファイルの次の構成項目を変更します。

[ root@PXC-Node1 /etc/percona-xtradb-cluster.conf.d]# vim wsrep.cnf
[ mysqld]
# PXCクラスター内のMySQLインスタンスの一意のID。繰り返すことはできず、数字である必要があります。
server-id=1
# ガレラライブラリファイルへのパス
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
# PXCクラスターの名前
wsrep_cluster_name=pxc-cluster
# クラスタ内のすべてのノードのIP
wsrep_cluster_address=gcomm://192.168.190.132,192.168.190.133,192.168.190.134
# 現在のノードの名前
wsrep_node_name=pxc-node-01
# 現在のノードのIP
wsrep_node_address=192.168.190.132
# 同期方法(mysqldump、 rsync、 xtrabackup)
wsrep_sst_method=xtrabackup-v2
# 同期中に使用されるアカウントパスワード
wsrep_sst_auth=admin:Abc_123456
# 厳密な同期モードを採用する
pxc_strict_mode=ENFORCING
# ROWに基づいてコピー(安全で信頼できる)
binlog_format=ROW
# デフォルトのエンジン
default_storage_engine=InnoDB
# 主キーの自己成長はテーブルをロックしません
innodb_autoinc_lock_mode=2

PXCクラスターを開始します###

これで、仮想マシン PXC-Node1へのPXCのインストールと構成が完了しました。次に、他の2つのノードで同じ手順を実行するため、ここでは繰り返しません。

すべてのノードの準備ができたら、次のコマンドを使用してPXCクラスターを開始します。このコマンドは最初のノードを開始するために使用されることに注意してください。最初のノードは、クラスターが最初に開始されたときの3つのノードのいずれかです。ここでは最初のノードとして PXC-Node1を使用します。したがって、仮想マシンで次のコマンドを実行します。

[ root@PXC-Node1 ~]# systemctl start [email protected]

他のノードは、MySQLサービスを正常に開始するだけでよく、起動後、 wsrep.cnfファイルの構成に従って自動的にクラスターに参加します。

[ root@PXC-Node2 ~]# systemctl start mysqld

Perconaサーバーの自動起動を無効にします：

[ root@localhost ~]# systemctl disable mysqld
Removed /etc/systemd/system/multi-user.target.wants/mysqld.service.
Removed /etc/systemd/system/mysql.service.[root@localhost ~]#

**ヒント：**セルフスタートアップを無効にする理由は、PXCクラスターでは、ノードがダウンして再起動すると、データがPXCノードとランダムに同期されるためです。ノードのダウン時間が長すぎると、同期する必要のあるデータの量が比較的多くなります。大量のデータ同期が発生すると、PXCクラスターは、すべてのデータが正常に同期されるまで、他の書き込み操作を制限します。したがって、長いダウンタイムの後、正しいアプローチは、ノードをすぐに起動するのではなく、最初に他のノードからノードにデータファイルをコピーしてから起動することです。このようにして、同期する必要のあるデータがはるかに少なくなり、長期的な速度制限が発生することはありません。

データベースアカウントを作成します###

次に、rootアカウントのデフォルトのパスワードを変更します。初期のデフォルトパスワードはmysqlログファイルにあります。次の図の赤いボックスは、デフォルトのパスワードを示しています。

**ヒント：**デフォルトのパスワードは、MySQLサービスが初めて開始された後にのみ生成されます

デフォルトのパスワードをコピーしてから、 mysql_secure_installationコマンドを使用してルートアカウントのパスワードを変更します。

[ root@localhost ~]# mysql_secure_installation

セキュリティ上の理由から、ルートアカウントでは通常、リモートログインが許可されていないため、リモートアクセス用に別のデータベースアカウントを作成する必要があります。このアカウントは、PXCクラスター内のデータを同期するために使用されるアカウントでもあり、 wsrep.cnfファイルの wsrep_sst_auth構成アイテムに対応します。

[ root@localhost ~]# mysql -uroot -p
mysql> create user 'admin'@'%' identified by 'Abc_123456';
mysql> grant all privileges on *.* to 'admin'@'%';
mysql> flush privileges;

アカウントを作成したら、クライアントツールを使用してリモート接続テストを実行し、接続が成功したかどうかを確認します。

これまでに、PXCクラスターの構築が完了しました。上記のルートパスワードの変更と新しいアカウントの作成の操作は他の2つのノードに同期されるため、PXCクラスターの同期効果を確認できるはずです。つまり、この時点で、他の2つのノードのルートアカウントのパスワードはすでに変更されており、管理者アカウントも存在します。これは自分で確認できます。

さらに、次のステートメントを使用して、クラスターのステータスを確認することもできます。

show status like 'wsrep_cluster%';

結果：

変数の説明：

wsrep_cluster_weight：クラスター内のノードの重み値
wsrep_cluster_conf_id：クラスターノード間の関係が変更された回数（追加/削除ごとに+1）
wsrep_cluster_size：クラスター内のノードの数
wsrep_cluster_state_uuid：クラスターの現在の状態のUUID。これは、クラスターの現在の状態と、クラスターが受けた一連の変更の一意の識別子です。また、2つ以上のノードが同じクラスター内にあるかどうかを比較するためにも使用されます。2つのノードの変数の値が同じである場合は、それらが同じクラスター内にあることを意味します。値に一貫性がない場合は、それらが同じクラスター内にないことを意味します。
wsrep_cluster_status：クラスターの現在のステータス

クラスターデータの同期を確認します##

1、作成したデータベースを同期できることを確認します

ノード1に testライブラリを作成します。

作成が完了したら、他のノードをクリックすると、ライブラリ testも表示されます。

2、作成したデータテーブルを同期できることを確認します

ノード1の testライブラリに studentテーブルを作成します。

作成後、他のノードでこの studentテーブルを見ることができるはずです。

3、テーブルデータを同期できることを確認します

ノード1の studentテーブルにデータを挿入します。

この時点で、他のノードもこのデータを表示できるはずです。

クラスターステータスパラメーターの説明##

クラスタのステータスパラメータは、次のようにSQLステートメントを介してクエリできます。

show status like '%wsrep%';

照会できる状態パラメーター変数は非常に多いため、ここでは一般的に使用される変数について説明します。 PXCクラスターパラメーターは、次のカテゴリに分類できます。

キュー関連
wsrep_local_send_queue：送信キューの長さ
wsrep_local_send_queue_max：送信キューの最大長
wsrep_local_send_queue_min：送信キューの最小長
wsrep_local_send_queue_avg：送信キューの平均の長さ
wsrep_local_recv_queue：受信キューの長さ
wsrep_local_recv_queue_max：受信キューの最大長
wsrep_local_recv_queue_min：受信キューの最小長
wsrep_local_recv_queue_avg：受信キューの平均の長さ
コピー関連
wsrep_replicated：データを他のノードに同期する回数
wsrep_replicated_bytes：他のノードに同期されたデータの合計量（バイト単位）
wsrep_received：他のノードからの同期要求が受信された回数
wsrep_received_bytes：他のノードから受信した同期データの合計量（バイト単位）
wsrep_last_applied：同時アプリケーションの数
wsrep_last_committed：トランザクションコミットの数
フロー制御関連
wsrep_flow_control_paused_ns：フロー制御の一時停止状態で費やされた合計時間（ナノ秒）
wsrep_flow_control_paused：フロー制御一時停止時間のパーセンテージ（0〜1）
wsrep_flow_control_sent：送信されたフロー制御一時停止イベントの数、つまり、現在のノードがフロー制御をトリガーした回数
wsrep_flow_control_recv：受信したフロー制御一時停止イベントの数
wsrep_flow_control_interval：フロー制御の下限と上限。上限は、キューで許可されるリクエストの最大数です。キューが上限に達すると、新しい要求は拒否されます。つまり、フロー制御がトリガーされます。既存のリクエストを処理する場合、キューは削減されます。下限に達すると、新しいリクエストが再び許可されます。つまり、フロー制御が解除されます。
wsrep_flow_control_status：フロー制御スイッチのステータス（オープン：オン、クローズ：オフ）
事務関連
wsrep_cert_deps_distance：実行された同時トランザクションの数
wsrep_apply_oooe：受信キュー内のトランザクションの割合
wsrep_apply_oool：受信キューでのトランザクションの順不同実行の頻度
wsrep_apply_window：受信キュー内のトランザクションの平均数
wsrep_commit_oooe：送信キュー内のトランザクションの割合
wsrep_commit_oool：意味がありません（ローカルの順不同のコミットはありません）
wsrep_commit_window：送信キュー内のトランザクションの平均数
ステータス関連
wsrep_local_state_comment：ノードの現在の状態
wsrep_cluster_status：クラスターの現在のステータス
wsrep_connected：ノードがクラスターに接続されているかどうか
wsrep_readyクラスターは正しく機能していますか
wsrep_cluster_size：クラスター内のノードの数
wsrep_desync_count：遅延ノードの数
wsrep_incoming_addresses：クラスター内のすべてのノードのIPアドレス

PXCノードの状態図：

OPEN：ノードは正常に開始されました
PRIMARY：ノードは正常にクラスターに参加しました
JOINER：データを他のノードと同期します
JOINED：データを他のノードと正常に同期します
SYNCED：クラスターとの完全な同期、および外部にサービスを提供できます
DONER：他のノードから完全なデータ同期を受信しますが、これは利用できません

PXCクラスター状態図：

PRIMARY：通常の状態
NON_PRIMARY：クラスター内の分割脳
DISCONNECTED：クラスターは接続不可能な状態です

公式文書：

PXCノードのオンラインとオフラインについて##

1、 PXCノードの安全なオフラインポスチャ

ノードを起動する方法、対応するコマンドを使用してシャットダウンするだけです

最初のノードの例：
最初のノードを開始するコマンドは次のとおりです。systemctlstartmysql@ bootstrap.service
次に、対応するシャットダウンコマンドは次のとおりです。 systemctl stop mysql @ bootstrap.service
他のノードの例：
他のノードを開始するコマンドは次のとおりです。systemctlstartmysqld
次に、対応するシャットダウンコマンドは次のとおりです。 systemctl stop mysqld

2、すべてのPXCノードが安全にオフラインになっている場合は、クラスターを開始するときに、最初に最後のオフラインノードを開始する必要があります

クラスターを初めて起動するときは、任意のノードを最初のノードとして起動できます。ただし、すでに開始されているクラスターの場合、クラスターがオフラインになってからオンラインになると、最後のオフラインノードを最初のノードとして開始する必要があります。実際、ノードを最初のノードとして開始できるかどうかについては、 grastate.datファイルを確認することで確認できます。

[ root@PXC-Node1 ~]# cat /var/lib/mysql/grastate.dat 
# GALERA saved state
version:2.1
uuid:    2c915504-39ac-11ea-bba7-a294386c4285
seqno:-1
safe_to_bootstrap:0[root@PXC-Node1 ~]#

注： safe_to_bootstrapは、値が 0の場合、最初のノードとして開始できないことを意味し、 1の場合、最初のノードとして開始できることを意味します。 PXCクラスターの最後のオフラインノードは safe_to_bootstrapの値を 1に変更します。次回クラスターを起動するときに、このノードを最初のノードとして起動する必要があります。これは、最後のオフラインノードのデータが最新であるためです。最初のノードとして開始し、他のノードにこのノードとデータを同期させて、クラスター内のデータが最新であることを確認します。そうしないと、クラスター内のデータが特定の時点より前の古いデータになる可能性があります。

3、 PXCノードがすべて誤って終了し、同時にではない場合

この記事の冒頭で述べたように、予期しないダウンタイムのためにPXCクラスター内のノードの半分以上にアクセスできない場合、PXCクラスターは実行を停止します。ただし、これらのPXCノードが安全なオフラインで終了する場合、クラスターの実行が自動的に停止することはなく、クラスターのサイズが縮小されるだけです。クラスターは、ノードの半分以上が予期せずオフラインになった場合にのみ自動的に停止します。予期しないオフライン状況には、次のものがあります。

ダウンタイム、サスペンド、シャットダウン、再起動、電源障害、ネットワーク切断など。とにかく、対応する停止コマンドを使用せずに安全にオフラインになっているノードは、すべて偶発的にオフラインになります。

PXCクラスター内のノードが同時に予期せず終了しない限り、クラスター内にノードが1つ残っていると、ノードは grastate.datファイルの safe_to_bootstrapの値を自動的に 1に変更します。したがって、クラスターを再起動すると、最後に終了したノードも最初に開始されます。

4、すべてのPXCノードが同時に予期せず終了する場合は、 grastate.datファイルを変更する必要があります

予期しない状況が原因でクラスター内のすべてのノードが同時に終了した場合、 safe_to_bootstrapの値を変更する時間がないため、すべてのノードの safe_to_bootstrapは 0になります。すべてのノードの safe_to_bootstrapが 0の場合、PXCクラスターを起動できません。

この場合、手動でノードを選択し、 safe_to_bootstrapを 1に変更してから、このノードを最初のノードとして開始することしかできません。

[ root@PXC-Node1 ~]# vim /var/lib/mysql/grastate.dat 
...
safe_to_bootstrap:1[root@PXC-Node1 ~]# systemctl start [email protected]

次に、他のノードを順番に開始します。

[ root@PXC-Node2 ~]# systemctl start mysqld

5、クラスター内に実行可能なノードがまだある場合、他のオフラインノードは通常のノードとしてオンラインにするだけで済みます

[ root@PXC-Node2 ~]# systemctl start mysqld