MySQLサーバは次期メジャーバージョンのMySQL 8.0を含め全バージョンのマイナーバージョンアップが行われました。PostgreSQLは次期メジャーリリースPostgreSQL 10に向けたベータ2がリリースされました。

［MySQL］2017年7月の主な出来事

7月は多くの製品でマイナーバージョンアップが行われ、コミュニティ版の現行製品はほぼ全ての製品でリリースが行われています。マイナーバージョンアップが行われなかったのはGUIツールのMySQL WorkbenchとPythonで書かれたDevOps向けツールのMySQL Utilitiesとなります。

MySQLサーバは製品版（GA）のMySQL 5.7, 5.6, 5.5および開発途上版（DMR）のMySQL 8.0それぞれのマイナーバージョンアップが行われました。

MySQLの開発チームのブログにて、MySQLサーバならびにMySQL 8.0向けのクライアントプログラムおよびクライアントライブラリMySQL Connectorsのバージョンをよりわかりやすい体系に変更していく旨が発表されました。そして7月には新しいバージョン番号を採用した各クライアントプログラムおよびMySQL Connectorsがリリースされています。

MySQL 8.0以降のバージョン番号の体系について

MySQLサーバについては、最初の桁をメジャーバージョンとして扱います。これまでも一部ドキュメントではこのように書かれていたものもありましたが、実態としてはMySQL 5.6の次のメジャーバージョンがMySQL 5.7となったように、2桁分を実質的なメジャーバージョン番号としていました。ブログの記述によると今後はMySQL 8の次はMySQL 9とする方向になっています（次期メジャーバージョンの表記をMySQL 8とするのかMySQL 8.0とするのかについては現時点では統一されていないようです⁠）⁠。

クライアントプログラム（MySQL Shell、MySQL Workbench、MySQL Enterprise Backupなど）やクライアントライブラリであるMySQL Connectors（Connector/C++、Connector/J、Connector/Netなど）は、MySQL 8.0の機能をサポートするバージョンは基本的に最初の桁をサーバーに合わせて8.x.xとします。ただし、クライアントライブラリはプログラミング言語やフレームワークなどの影響もあり、サーバーのリリースとは異なるタイミングで実装が大きく変更されることがありえます。その場合には8.1.x、8.2.xなどのようなバージョンとなることが想定されています。

なお最初の桁が異なるバージョン間でも接続が可能なレベルでの互換性は保つことになりますが、一方でMySQL 8.0の全機能への対応を担保するのは最初の桁が8になっているクライアントのみとなります。

［PostgreSQL］2017年7月の主な出来事

次期メジャーバージョンのリリースに向けては、2017年7月13日にPostgreSQL 10 ベータ2がリリースされました。このリリースにはベータ1版で見つかった多くのバグの修正を含めたPostgreSQL 10の最終リリースで利用できるすべての機能のプレビューが含まれています。

Quorum-based同期レプリケーション

同期スタンバイについては9.1から導入されており少しずつ機能強化されてきました。今回はPostgreSQL 10で実装されたQuorumベースの同期レプリケーションについて、過去からの変遷を振返りながら紹介させていただきます。

PostgreSQL 9.5まで：同期スタンバイとして指定できるのは1台だけ

スタンバイサーバのうち優先度が一番高いサーバだけ、同期スタンバイ先として扱われました。同期スタンバイがダウンすると次に優先度の高いスタンバイが同期スタンバイ先に昇格することで同期スタンバイ先が１台だけという状態が維持される仕組みでした。

PostgreSQL 9.6：複数のサーバを同期スタンバイとして指定できるようになった

“何台のスタンバイを同期スタンバイとするか⁠”を指定するパラメータNに従い、スタンバイサーバのうち優先度が高い順にN台が同期スタンバイ先として扱われるようになりました。同期スタンバイがダウンすると次に優先度の高いスタンバイが同期スタンバイ先に昇格するところは同じです。

PostgreSQL 10：同期スタンバイ先を固定しない運用が可能になった（Quorum-based）

Quorumとは分散システムにおいて、分散トランザクションが処理を実行するために必要な最低限の票数のことです。これまでの同期スタンバイでは、応答を待つ同期スタンバイ先は固定でした。同期スタンバイ先は優先順位に基づき決められますが、一時的な性能劣化などがあっても、ダウンしたのでなければ同期スタンバイ先から外されたりはしません。そのため、レスポンスが遅い一部の同期スタンバイにDB全体の性能が引きずられる可能性がありました。

PostgreSQL10で導入されたQuorum-based同期レプリケーションでは固定の同期スタンバイ先を待つのではなく、指定された台数分の応答が返ってきたことをもってCOMMITします。これにより、性能劣化を軽減し、安定した性能の発揮に期待が持てるようになりました。

2017年8月開催予定のセミナーやイベント、ユーザ会の活動

オープンソースカンファレンス 2017 Kyoto

オープンデベロッパーズカンファレンス2017 Tokyo

第21回 中国地方DB勉強会 in 山口