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

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

2021年1月のMySQLの製品リリースは，MySQLサーバー8.0.23，5.7.31，5.6.51の各マイナーバージョンをはじめ，MySQL NDB Clusterや各種Connector, MySQL Shell, MySQL Workbenchなどのクライアントプログラムの商用版およびコミュニティ版のほぼ全ての製品のマイナーバージョンアップが行われました。なおMySQL 5.6はこのマイナーバージョンが最終のメンテナンスリリースとなり，今後はごく例外的な状況を除いてセキュリティパッチなども提供されなくなりますので，ご利用中の方はMySQL 8.0などへのバージョンアップをご検討ください。

バージョンアップの際には本連載の第36回でもご紹介したMySQL ShellのUpgrade Checkerのご利用をお勧めします。また，バージョンアップの際の注意点や手順などは以前行われたMySQLバージョンアップ対策セミナーの資料や，本連載の第59回でご紹介した日本MySQLユーザ会代表のとみたまさひろさんが公開されているMySQLのバージョンごとの設定などを比較するツールもあわせて参照してください。

MySQL 8.0.23の新機能

MySQL 8.0.23の主な新機能は下記の通りです。MySQLサーバー開発チームのブログでもMySQL 8.0.23の新機能の紹介がされています。

Invisible Column（非表示）の追加

他のRDBMSでも実装されている機能ですが，列の属性にINVISIBLEを設定すると，列を指定せずにSELECT * FROM テーブル のようにSELECT文を実行した場合には該当の列が返されないようになります。

MySQL 8.0 Reference Manual :13.1.20.10 Invisible Columns

Query attributes（クエリ属性）の追加

Facebookからのコントリビューションで実装された機能です。SQLコメントの追加などアプリケーションが発行するSQL文自体には手を入れずに，実行されるSQL文にメタデータを追加する仕組みです。たとえばどのURLのアクセスによって実行されて，SQL文かをMySQLサーバー側に認識させるなどの利用が想定されています。

MySQL 8.0 Reference Manual :9.6 Query Attributes

レプリケーションのソースのリストと自動切り替え

MySQL 8.0.22で加わったレプリケーションソースの自動的な切り替え機能が強化されています。グループレプリケーションをソースとして，非同期レプリケーションを組み合わせた場合の自動フェールオーバーが改良されました。グループレプリケーション内のノード構成に変更があった場合は，レプリカ側で持っているノードのリストも更新され，確実に接続のフェールオーバーが行われるように改良されています。

MySQL 8.0 Reference Manual :17.4.9 Switching Sources with Asynchronous Connection Failover

テーブルごとのAUTOEXTEND_SIZEの指定

これまではページサイズに応じて表領域ファイルの拡張サイズは固定されていましたが，CREATE TABLE文やALTER TABLE文でAUTOEXTEND_SIZEオプションを指定することで拡張サイズが設定できます。

MySQL 8.0 Reference Manual :15.6.3.9 Tablespace AUTOEXTEND_SIZE Configuration

このほか，InnoDBのユーザー表領域や一時表領域の削除の高速化，InnoDBのダブルライトバッファのファイルの暗号化などの改良が行われているほか，MySQL 8.0.22から始まったレプリケーションに関する用語の改訂に応じてCHANGE MASTER文はCHANGE REPLICATION SOURCE文が推奨となっています。

［PostgreSQL］2021年1月の主な出来事

PostgreSQLエンタープライズ・コンソーシアムでは技術勉強会が開催されました。また，2月の事例セミナー開催が発表されました。

PGECons勉強会 #3 「新解釈・PaaS型PostgreSQL」

PostgreSQLエンタープライズ・コンソーシアム（PGECons）の技術部会による勉強会が1月21日に開催されました。PGEConsでは年度ごとに成果発表会を開催していますが，「⁠テーマを絞ってより深く理解する場が欲しい」という要望にこたえるために，非定期で勉強会という形で実施しています。今回はパブリッククラウド上で提供されるPaaS型のPostgreSQLを複数パターンで比較および検証した結果が紹介されました。

対象となったPaaSですが，AWS（Amazon Web Service）のRDS（Relational Database Service）とAuroraでのPostgreSQLを，コミュニティ版のPostgreSQLと比較，また，Azure Database for PostgresのSingle ServerとHyperscale（Citus）を検証しています。AWSとAzureのガチンコ勝負というわけではありません。AWSもAzureも，機能や非機能要求について机上調査にて比較をしていることに加えて，実環境にて性能測定も行っています。

今回のような比較検証報告の活用の仕方は，単にどちらが優れているかを見て製品選択の参考にするというだけではありません。仮に自分たちが採用するものが既に決まっていたとしても，他のものとの比較は特徴を理解するのにとても役立ちます。また，実環境による検証ではいろいろと試行錯誤をしていますので，結果を得るまでのプロセスやつまずいた点などの情報が，システム構築時に参考になることが多くあります。今回の発表でも「しくじった点」を提示してくれていて，参考になると思います。報告の概要を以下に記しますが，たいへんに詳しい発表資料が公開されていますのでご参照ください。

AWS机上調査から

AuroraとRDSのPostgreSQL，および，オンプレミス環境上のコミュニティ版PostgreSQLについて，可用性／拡張性／保守・運用性などのいわゆる非機能要求を評価しています。

可用性の面では，AuroraやRDSではAZ（Availability Zone）間でのレプリケーションや，ストレージサービスへの自動バックアップなど，クラウドサービスのメリットを活かした機能を実現していて，比較的容易に高可用性を実現することが可能なことがよくわかります。

拡張性の面もクラウドサービスにメリットがあることがよく知られています。ただ，AuroraやRDSのPostgreSQLサーバの場合には注意点もあり，CPUやメモリを増やす場合にはインスタンスタイプの変更になるのでサーバ停止を伴います。データベースサーバとしては注意が必要な点でしょう。一方，ストレージの増設は無停止による拡張が可能です。特にAuroraは自動拡張になります。

保守運用やセキュリティの面では，自由度が少ない（制約が多い）点がいろいろあります。これはクラウド事業者から提供されるサービスであるPaaSのため当然と言えば当然かもしれません。