Percona XtraDB Clusterの新しいState Snapshot Transferメソッドについて

Percona XtraDB Cluster(以下PXC) は MySQL界隈のトップリードカンパニーであるPercona社が開発しているMySQL 用の高可用性クラスタリングソリューションです。

MySQLフォーク製品であるPercona ServerにCodership社のGalera Cluster Pluginを組み合わせる事で高可用性を実現しています。

他にGalera Cluster Pluginを使用しているソリューションとして、MariaDB Galera Clusterがあります。

今回は、Percona XtraDB Cluster 8.0.41-32より、Galera Cluster Pluginの機能であるState Snapshot Transfer(SST)に新方式が追加されたという事で、早速試してみたいと思います。

State Snapshot Transfer(SST)について

Galera Clusterは、クラスタ内のmysqldノードがメッシュ状にレプリケーションを行うことで、マルチマスタを実現しています。

MySQLのレプリケーションは 結果整合性 であるため、レプリケーションの開始時点ではクラスタに参加するノードは同じデータを持つ必要があります。

引用: About Percona XtraDB Cluster

同じデータを持つために、新たにノードがクラスタに参加するタイミング、または クラスタ内のノードが停止し、クラスタに再参加するタイミング で、クラスタ内の1つのノードを元に、データ同期処理が行われます。

この同期処理のことを State Snapshot Transfer(SST)と呼びます。

通常SSTは、同期元ノード(Donor)からフルバックアップを取得し、クラスタ参加ノード(Joiner)にリストアするという事を行います。

しかし、Joinerが持つデータがDonorと比べてそれほど古くなっていないケースでは、Incremental State Transfer (IST) が実行され、更新キャッシュに記録された差分データのみを同期する、という動作になります。

引用：Understanding gcache in Galera

SSTの方式は、 wsrep_sst_method 変数で決定します。

オリジナルのCodership Galera Cluster For MySQLや、v5.7以前のPXCでは、rsyncやmysqldump等といった方式が選択できましたが、PXC 8.0から基本的にはxtrabackup-v2に一本化されています。

8.0.41-32よりも以前の8.0バージョンでは以下の方式が選択できます。

value	description
xtrabackup-v2	Percona XtraBackup を使用して同期する(デフォルト)
skip	SST を行わない※8.0.33-25 以降では削除
ist_only	(8.0.33-25以降) ISTのみを許可する。ISTに必要な更新キャッシュがすでに失われた場合は起動を中止する。

skipやist_onlyは、クラスタ参加時に手動でバックアップを参加ノードに同期するケースを想定した設定値で、自動的にSSTが行われることを防ぎます。
skipはマニュアル操作によってデータ整合性が損なわれやすいという理由によって削除されています。
ist_onlyでは、手動バックアップをJoinerにリストアした後は通常grastate.datファイル(クラスタ内でのノードの状態を記録するファイル)がなく、当該ファイルが無いとFull-SSTが行われる、という事を防止するために使う特殊な設定値です。

つまり、これまでは実質的にxtrabackup-v2だけが選択肢でした。

しかしながら、8.0.41-32からは、Clone Plugin が選択肢に加わりました。

https://docs.percona.com/percona-xtradb-cluster/8.0/release-notes/8.0.41-32.html

Percona XtraDB Cluster 8.0.41-32¶
Implements the Clone plugin for State Snapshot Transfer (SST) Method. The Clone SST is a modern and efficient method that leverages MySQL’s native cloning capabilities to transfer data from a donor node to a Joiner node. It is faster and more resource-efficient compared to traditional methods like xtrabackup or rsync.

Clone Pluginは、MySQL 8.0.17で追加された機能で、その名の通り動作中のMySQLインスタンスのコピーを効率的に行うためのPluginです。

引用: https://dev.mysql.com/doc/refman/8.4/en/clone-plugin.html

MySQLのパッケージに同梱されており、Group Replicationにおける分散リカバリ にも使用されています。

本家 Galera Clusterでは、8.0.22の時点ではwsrep_sst_method=cloneが利用できましたが、「ついにPXCにも来たか..!」という感じで嬉しい限りです。

SSTでのClone Plugin利用準備

State Snapshot Transfer (SST) Method using Clone plugin に沿って準備を進めていきます。

前提パッケージ要件としてNetCatがありますので、インストールされていることを確認します。

あとは、my.cnfの[mysqld]セクションにwsrep_sst_method=clone を設定して準備は完了です。

試しに設定を有効化した上で、新規ノードをPXCクラスタに追加してみます。

ログにはSSTが実行されたことが出力されます。
本来Clone Pluginは利用前にインストール作業(INSTALL PLUGIN)や適切な権限を持つユーザの作成(CREATE USERやGRANT)が必要ですが、SSTのプロセスの一部でそれらは実行されます。

以下はSST関連ログのみ抜粋したものです。

Donor側

Joiner側

xtrabackup-v2とcloneの機能比較

Xtrabackupはその歴史も長く、様々な便利オプションが追加されていたり、修正も多く行われていて非常に安定しています。
一方でCloneはMySQLインスタンスの複製に最適化されており、効率的な機能が実装されています。

SST実行時に関連する機能について比較しました。

機能	xtrabackup-v2	clone
並列処理	◯	◯ ※ 自動並列度調整機能あり(–clone_autotune_concurrency)
パケット圧縮	◯ ※ 外部コマンドを使用	◯ ※ ネイティブ機能
並列圧縮	◯	◯
進捗表示	◯	◯
ネットワーク転送制限	◯	◯
I/O制限	◯	◯

clone pluginは後発ツールなだけあり、概ね機能面では同等といえます。

Percona XtrabackupとCloneの速度比較について少し古いですがPercona社の優れた記事があります。

https://www.percona.com/blog/the-mysql-clone-wars-plugin-vs-percona-xtrabackup/

記事では、以下の条件で比較しています。

• sysbenchで124MB*200テーブルを作成 = 24GB
• 4 コア、8 GB RAM、60 GB ストレージ
• clone/xtrabackupの並列数(1,2,3,4)、圧縮有り無しでバックアップを実行
• NW帯域を500Mbps/1000Mbps/4000Mbpsでテスト
• cloneはバックアップ～解凍～リストアまで自動で行われるが、xtrabackupはバックアップ(リモート送信)・解凍・リストア(リカバリ)は個別の処理になる
  • そのため、xtrabackupではnetcat経由で送受信、リモート環境でのリストア、リカバリを実行

記事の結果を簡単にまとめると

• 低いNW帯域・少スレッド数、パケット圧縮ありの場合は、xtrabackupの速度が優れている
• 多スレッド数、パケット圧縮なしの場合は、cloneの速度が優れている

という事で、リソースが十分かつNW帯域をふんだんに利用できる環境においては Clone に速度のメリットがありそうです。

PXCのwsrep_OSU_methodの仕様とClone Pluginのアップデートについて

そもそも今回、本記事を書こうと思ったきっかけは、予てからのPercona XtraDB ClusterのSST(=バックアップ)実行時の機能上の制限を回避できそうと思ったためです。

以下のブログ記事(いつも参考にさせていただいております…)で言及されているように、フルデータコピー(SST)が行われるタイミングで、バックアップロックが取られます。

https://mita2db.hateblo.jp/entry/2020/09/06/135538

ここからがPXCのつらいところで、「DDL実行中はインスタンス全体ですべての更新処理をブロックする」という仕様動作があります。
そのため、SSTによりブロックされたDDLによりその他の更新処理がブロックされるという状態になります。

SST(バックアップロック) <-block- DDL(truncateなど) <-block- その他あらゆる更新処理

これは wsrep_OSU_method=TOI(デフォルト) の動作です。
wsrep_OSU_method には他の設定として、 RSU(Rolling-Schema-Upgrade) があります。
RSUは、DDLのみ同期させない事で1ノードずつ更新をかける方式で、計画的なメンテナンスであればTOIのようにブロックせずに更新がかけられます。
しかし、SST実行中のDDLのようなイレギュラーな実行を対処するものではありません。
wsrep_OSU_method=TOI の進化した方法で、 wsrep_OSU_method=NBO(Non-Blocking-Operations) があります。
NBOでは、変更中のテーブルを除き、更新処理/DDLをブロックしないという動作になります。
これは従来のTOIからすれば非常に嬉しい制限の緩和になりますが、現在サポートされているDDL構文などに制限があります。
また、前述の通り変更中のテーブルの更新処理はやはりブロックされてしまいます。

https://galeracluster.com/library/documentation/schema-upgrades.html#toi

When using Non-Blocking Operations, take the following particularities into consideration:

The supported statements are:

ALTER TABLE table_name LOCK = {SHARED|EXCLUSIVE} , alter_specification
ALTER TABLE table_name LOCK = {SHARED|EXCLUSIVE} PARTITION. The comma after LOCK=SHARED|EXCLUSIVE is not used for partition-management ALTERs.
ANALYZE TABLE
OPTIMIZE TABLE
The unsupported statements are:

ALTER TABLE LOCK = {DEFAULT|NONE}. This also means that ALTER TABLE without a LOCK clause is not supported, as is defaults to DEFAULT.
CREATE
RENAME
DROP
REPAIR

ところがなんと、MySQL 8.4のClone pluginでは、ドナーインスタンスでの同時DDLが許可されたというアップデートがありました。

https://dev.mysql.com/doc/refman/8.4/en/clone-plugin-concurrent-ddl.html

7.6.7.4 Cloning and Concurrent DDL
In MySQL 8.4, concurrent DDL is permitted on the donor by default. Concurrent DDL support on the donor is controlled by the clone_block_ddl variable. Concurrent DDL support can be enabled and disabled dynamically using a SET statement like this one:

SET GLOBAL clone_block_ddl={OFF|ON}
The default setting is clone_block_ddl=OFF, which permits concurrent DDL on the donor.

Whether the effect of a concurrent DDL operation is cloned or not depends on whether the DDL operation finishes before the dynamic snapshot is taken by the cloning operation.

DDL operations that are not permitted during a cloning operation regardless of the clone_block_ddl setting include:

ALTER TABLE tbl_name DISCARD TABLESPACE;

ALTER TABLE tbl_name IMPORT TABLESPACE;

ALTER INSTANCE DISABLE INNODB REDO_LOG;

つまり、Percona XtraDB Cluster 8.4からは

1. SST(Clone) を実行
2. SST(Clone) 中もDDLは実行される
3. DDLは妥当な時間実行され、その間他のDMLをブロックするが、バックアップに長時間ブロックされ全面的に更新処理が止まることは無い

となるはずです。

じゃあ、早速8.4で検証をといきたいところですが、なんと wsrep_sst_method=clone はv8.0に先行実装され、v8.4系(v8.4.3)では未実装のようでした😢

そこで今回は、8.4にwsrep_sst_method=cloneがやってきたらこうなるはず、というPoCをしてみました。

• Percona XtraDB Cluster 8.4を構築
• Percona Server for MySQL 8.4 を構築し、Percona XtraDB Cluster 8.4のノードをDONERとしてCloneを実行
  ※ Percona Server for MySQL はMySQL完全互換のPerconaフォーク製品
• Cloneを実行中にPercona XtraDB Cluster 8.4のプライマリでDDLを流し続ける
• DDLがブロックされなければ成功！

wsrep_sst_clone.sh スクリプトを参考に事前にPXCノードにユーザを作成しておきます。
Cloneで実行するコマンドも同スクリプトのものを参考にします。

CLONEユーザ作成(DONER)

CLONE実行コマンド(JOINER※今回の場合はcloneを実行するPercona Server)

まずは、改めてDDLがSST(xtrabackup)中にはブロックされるという動作について再現します。
SST実行中に、1秒ごとにTRUNCATEを実行し、時間を表示するスクリプトを実行すると、以下のように空き時間を確認できます。

SSTがxtrabackupの場合のバックアップログは、 [datadir]/innobackup.backup.log として出力されており、空いている時間はxtrabackupが実行されていたことがわかります。

CLONEの場合は、DDLが切れ目なく実行されるはずですので、試してみます。
CLONEは概ね以下の期間に実行されていました。

トータルで5分くらいなので、上記のログと整合します。

1秒ごとのtruncate実行時の時刻のログの差分を取得しても、最大で2秒の差分でしたので誤差の範囲といえます。

ということで、上記結果からPXCにおいてもCLONE PLUGINはDDLをブロックせず、定期ジョブ等で実行されているDDLの影響をうける事なく安心してSSTを実行する事ができるようになりそうです。

また、CLONE PLUGINの用途としては一般的には他のサーバへのオンライン複製にはなりますが、ローカルにバックアップとして出力することも可能となっています。

https://dev.mysql.com/doc/refman/8.4/en/clone-plugin-local.html

PXCのバックアップ時間中のDDL実行にお悩みのユーザはCLONEを検討してみても良いかもしれません。

まとめ

Percona XtraDB Cluster 8.4.4 のリリースで、wsrep_sst_method にcloneが加えられることが大いに期待できそうだという事がわかりました。
これは大幅な制限の緩和につながるので、待ち望んでいるユーザもいらっしゃるのではと思います。

MySQL 8.4系のリリース状況は以下の通りです。

対してPercona XtraDB Clusterは、約3ヶ月遅れくらいのタイミングに同バージョンがリリースされていますので、もうそろそろ 8.4.4がリリースされることが推測できます。

最後に注意点として、 wsrep_sst_method=cloneは v8.0.41 においては Technical Preview です。

楽しみに8.4でのリリース、並びに本機能のGAを待ちましょう！