この連載はOSSコンソーシアム データベース部会のメンバーがオープンソースデータベースの毎月の出来事をお伝えしています。

Project Tsurugi（劔）の経過報告会が開催

前回に開催をお知らせした，国産の新DBエンジンを開発するプロジェクト Project Tsurugi（劔）のユーザー会兼経過報告会が10月11日に開催されました。

Project Tsurugiは，メニーコア・大容量メモリの現在のハードウェア環境に合致したモダンアーキテクチャなRDBをOSSでつくるプロジェクトです。また複数の大学の研究者も参画しており，OLTPやOLAPの高速化，メニーコアを前提とした高速インデックスなどの研究も同時並行で行われています。さらに，Tsurugiの特徴を活かすプロトタイプアプリケーションの開発も行われています。報告会ではこれら同時並行で進んでいる各種サブプロジェクトの状況が一同に報告されました。

前回のこの連載で「外部インタフェースはPostgreSQL互換になるようです」と書きましたが，これはちょっと正しい書き方ではありませんでした。TsurugiはPostgreSQLと互換なDBMSとして使えるわけではありませんので注意が必要です。Tsurugiを操作するインタフェースの1つとしてPostgreSQLを使うことができます。そしてPostgreSQLが標準で持っている機能であるFDW（Foreign Data Wrapper）を使ってTsurugiのDBエンジンに接続します。したがって，ユーザが操作する部分はたしかにPostgreSQLそのものです。

しかし，DBエンジンの動作ではトランザクションの扱いの違いなどで，挙動が異なる部分があり，すべてがPostgreSQLと完全に互換もののとして使えるわけではありません。また，Tsurugiの全ての特徴をPostgreSQLのFDWから使えるわけでは無いため，超高性能なOLTPを実現するには，Tsurugi独自のAPI（Tsurugi Direct）を使用する必要があります。ただ，これらは併存して使えるので，用途によって使い分けることはできるでしょう。

Project Tsurugiは，国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）のプロジェクトとして，2023年2月までを期間として進行中です。そして，プロジェクトが終了する2023年2月の時点で成果が公開されることになっています。TsurugiのRDBの部分はOSSとして公開になります。その他の部分はどの様な公開の仕方になるのかは未確定の部分もあるようですが，一部のアプリケーションはOSS公開の範囲になりそうです。研究成果については論文としての発表だけになるのか，一部は実装までされるのかは今後の状況次第となる面もあるようです。

なお，以前の報告会で話されていた，α版の段階で2022年に公開予定については，今回の報告会では特に触れられていませんでした。プロジェクト終了が2022年度のほぼ年度末ですので，このタイミングまで待つことになるのかもしれません。

今回の報告会の発表資料はOSSコンソーシアム分散コンピューティング部会のWebページにて公開されています。2時間半で12セッションの超高レベルで高密度な発表が行われました。発表に着いていくのがたいへんな報告会でしたので，筆者もこの公開資料でまだ復習中です。もしかしたら今回も一部に正しくない記述があるかもしれませんがご容赦ください。

［MySQL］2021年10月の主な出来事

2021年10月のMySQLの製品リリースは，MySQLサーバー8.0.27，5.7.36の各マイナーバージョンをはじめ，MySQL NDB Clusterや各種Connector, MySQL Shell, MySQL Workbenchなどのクライアントプログラムの商用版およびコミュニティ版のほぼ全ての製品のマイナーバージョンアップが行われました。MySQLのマネージドサービスMySQL Database Serviceのイメージも8.0.27にアップデートされています。原稿作成時点ではHeatWaveのアップデートは行われていません。

MySQL InnoDB ClusterSet ―災害対策構成を簡単に実現

2021年10月にリリースされたMySQL 8.0.27およびMySQL Shell 8.0.27では，MySQL InnoDB ClusterSetが新機能として追加されています。MySQL InnoDB ClusterSetは，MySQLのクラスタリング機能であるMySQL InnoDB Clusterを複数のデータセンターで運用し，クラスター間を非同期レプリケーションで連携させることによってデータベースの災害対策（DR）構成を実現する機能です。

MySQL Shellからのコマンドだけで非同期レプリケーションの構成を構築できるMySQL ReplicaSetやクラスタリング機能のInnoDB Clusterと同様に，InnoDB ClusterSetもMySQL Shellからのコマンドだけで災害対策構成の構築が可能です。

MySQLプロトコルに対応したソフトウェアルーターであるMySQL Routerの設定もMySQL Shellから可能なため，複雑になりがちな災害対策構成の運用負荷を抑えることができます。

InnoDB Clusterによってデータセンター内でのノード障害時にはトランザクションを損失することなく自動フェールオーバーが行われます。災害などによってデータセンターに障害が発生した場合，現在のInnoDB ClusterSetでは自動フェールオーバーは行われないため，プライマリー・クラスターとよばれる更新処理を担当するクラスターの強制的な切り替えを行います。なおデータセンター間では非同期レプリケーションが利用されているため，場合によっては更新トランザクションが損失する可能性があります。

データセンター規模の障害が発生した場合でもトランザクションの損失が許容できないようなシステムでの対策としては，InnoDB Clusterの各ノードを別のデータセンターに配置する構成が考えられます。InnoDB Clusterではコミットごとに各メンバーノードとトランザクションの「合意形成」を行うために，この構成ではデータセンター間での通信によるレイテンシーが更新処理へのオーバーヘッドとなる点に注意が必要です。InnoDB ClusterSetでコミット時の通信がデータセンター内のみのためオーバーヘッドは限定的です。

MySQL 8.0.27時点でのInnoDB ClusterSetのおもな制限事項は以下の通りです。

• スプリット・ブレイン・シンドロームへの対策機能は未実装
• 非同期レプリケーションのみサポート
• 準同期レプリケーションは非サポート
• データセンター間での自動でのフェールオーバー未実装
• InnoDB Clusterのマルチ・プライマリー・モードは未サポート

MySQL 8.0.27ではInnoDB ClusterSet以外にも，多要素認証（MFA）サポートが追加され，コミュニティ版では複数パスワードの利用が可能になっています。商用版のEnterprise Editionでは，指紋認証デバイスやセキュリティ・キーなどFIDO（Fast IDentity Online）対応デバイスを利用可能するプラグインが提供されます。なおクライアントプログラムにはコミュニティ版でもFIDOデバイスが利用可能なプラグインが提供されています。

レプリケーションの機能拡張としては，レプリカサーバーでのマルチスレッドがデフォルト（スレッド数4）になったほか，レプリケーションの非同期接続フェールオーバーが拡張されています。