この記事では、Percona Live 2019 で私が参加したセッションの感想やまとめを記載したいと思います。
ただし、この日は合計 7 セッションに参加したこともあり、記事を3つに分けて説明しようと思います。
まずは前編ということで午前中に行われた2セッションを取り上げます。
Percona XtraDB Cluster 8.0 (PXC-8.0)
Percona 社で PXC 開発のリードエンジニアを務める、Krunal氏のセッションでした。
MySQL8.0（Percona Server 8.0）で追加された新機能に対し、PXCではどのようにアプローチをしているか、という内容が多く、まだ世に出ていない情報も多くあったように思います。
以下、要点を箇条書きで説明します（個人的に大事だと思う項目を太字にしています）。
- Resource Group 機能を使ったステートメントは、他ノードに伝播しない
- Role 機能の実装に合わせ、SSTユーザ向けのロール（mysql.pxc.sst.role）を初めから用意している
- 8.0からAtomic DDLが実装され、PXCでもDDLと Write-Set がスムーズに実行されるよう工夫している
- しかし、PXCにおいてはデフォルトで TOI 形式でDDLを実行されるため、ブロッキングDDLが発生しないよう注意する
- OPTIMIZE, ANALYZE といった Non-Atomic なDDLもPXCでは依然としてサポートする
- SRS(Spatial Refference System)コマンドもレプリケーション対象にする
- DDL がトランザクション化したことで、MySQLが xid を割り当てるようになった
→ PXC（wsrep）が使用している XID とはロジックが異なる（＝別物） - 上記2つの xid 機能が原因で不整合エラーが発生する可能性がある
→ PXCが cluster-mode で稼働している間は PXC の XID のみを使用してエラーを防ぐ - MySQL8.0でチャンネル単位のレプリケーションフィルターが追加されましたが、wsrep レプリケーションフィルタは設定できない
- PXC5.7 – DONOR から PXC 8.0 – JOINER へのアップグレード（SST）はサポートされる
- 上記のケースでは自動で mysql_upgrade および ノードの再起動も実行される（Auto-Upgrade）
- Auto-Upgrade はマイナーバージョン間でも有効
- PXC5.7.25 以降からのバージョンアップが推奨される
- PXC5.6 – DONOR から PXC 8.0 – JOINER へのアップグレードはサポートされない
- MySQL8.0からREDOログの仕様が変わったため、PXC8.0では原則として Percona XtraBackup 8.0 以上を使用する必要がある（PXB2.4 と PXB8.0 の共存はできない）
- 上記の影響で、wsrep_sst_method = rsync / mysqldump は使用できなくなった
- error/warning/info のメッセージ機能も強化され、ユーザが log_error_service を通して自由にルーティングできるようになった
→ wsrep/galera/wsrep-sst といったモジュールもある - MySQL8.0で Contention Aware Transaction Scheduling アルゴリズム（CATS）が実装されましたが、PXC8.0では同機能はサポートせず、引き続き FIFO スケジューリングを使用される
- Xplugin はノードが SYNCED ステータスになった後にロードされる
- wsrep_force_binlog_format, wsrep_convert_lock_to_trx, wsrep_preordered といった変数が非推奨になった
- PXC8.0では、create table as select（CTAS）文はDDLと同様に TOI 形式でレプリケーションされる
- 新機能である SET PERSIST コマンド（mysqld-auto.cnf）の設定はSSTでコピーされません
- PXCノードを非同期スレーブとして運用している場合、SSTが実行されてもレプリケーション情報が適切に残るようになった
- 今後は cloud friendly な cluster や wsrep 通信の完全な暗号化などを強化する方針
Percona Server for MySQL 8.0 は既にGAリリースされましたが、Percona XtraDB Cluster 8.0はまだGAが出ていません。
しかし、このセッションの内容を聞いて、リリースも間近であるように感じました。今から楽しみです！
New Features in MySQL 8.0 Replication
Oracleで Replication Development Director を務める Luís 氏のセッションです。ブログに写真を載せても良いかを確認したところ、PMに連絡して後日私のところに来て伝えてくれたナイスガイでした。
MySQLのレプリケーション機能は歴史も古く、様々な人・システムに使用されています。
ただ、初めは「非同期」しかなかったレプリケーションも「準同期」が追加され、5.7からは「グループレプリケーション」が追加されました。
MySQL8.0では、特にこのグループレプリケーション周りが大幅に強化されているようです。
グループレプリケーションには以下5つのキーワードがあります（= Clustering Made Practical）
これらはまとめて「RAISE」と呼称されます。
(1) “Replicate”
主に Group Replication という仕組み自体を指しています。
マスタとなり得るノードが複数台存在するため、ダウンタイムを劇的に削減できます。
(2) “Automate”
ノード間通信が切れた後の復旧などが自動で行われるため、運用面でメリットがあります。
(3) “Integrate”
ノード間の同期には従来のレプリケーション同様、GTIDとバイナリログが使用されます。
(4) “Scale”
非同期レプリケーションと組み合わせることで、大規模災害に備えたバックアップ用スレーブを用意したり、遠隔地のクラスタ同士のレプリケーションが可能になります。
(5) “Enhance”
Group Replicationに、ルーティング機能を持った MySQL Router と運用・管理ツールであるMySQL Shell を組み合わせた MySQL InnoDB Cluster が提供されています。
また、8.0ではノード間の整合性をより担保するための機能が強化されています。
例えば、「Relaxed Member Eviction」は一部のノードのネットワークが切れた時に、周りのノードが「該当ノードがPrimary Groupから切り離された」と判断するまでの時間を設定できます。
さらにレプリケーション関連のパラメータ変数のデフォルト値が 8.0 から大きく変わっています。
バイナリログが ON になったことからも、MySQLユーザの間ではレプリケーションがごく当たり前に使用されていることが分かりますね。
最後に、将来的には1つの InnoDB Cluster の中に複数のクラスタグループを包括し、まとめて管理できるような構成を実現しようとしているようです。
セッション内では、8.0での改善点だけでなく、現在メジャーな 5.7 の最新バージョンでもグループレプリケーションの改良が多く実施されていると説明されました。
Oracle社としてもかなり力を入れて開発しているのは間違いないので、今後も目が離せませんね！
