はじめに

こんにちは。
NTTテクノクロス株式会社でPostgreSQLの技術支援をやっている原田と申します。

普段は別の名前（ぬこ＠横浜）でPostgreSQLに関するネタをQiita等に投稿しているのですが、今回、数年ぶりに会社の中の人の立場で記事を書くことになりました。

今回のお題/サマリ

Azure Database for PostgreSQL Flexible Serverとは

Azureでも以前から、Azure Database for PostgreSQL Single Server（以下、Single Serverと表記します）というデータベースサービスを扱っていました。
少し前に、PostgreSQLの新たなデータベースサービスとして、Flexible Serverというサービスが利用可能になりました。
この2つのサービスともPostgreSQLを使うことは変わりないのですが、以下のような細かい違いがあります。

Flexible Serverは、Single Serverの後継サービスという位置づけになります。実際、現時点でSingle Serverのインスタンスを構築しようとすると「Flexible Server」にしない？とおススメされたりします。

Single ServerとFlexible Serverはバージョンや基盤OS以外にもゾーン冗長化の有無などの違いがあります。こうした違いについては、Azure公式の文書にも記載されています。

比較表 - Azure Database for PostgreSQL の単一サーバーとフレキシブル サーバー

サーバパラメータの差分

今回は、Azure Database for PostgreSQL Flexible ServerのPostgreSQL 13版と、コミュニティ版PostgreSQL 13（RPMインストールしたもの）のサーバパラメータを簡単に比べてみようと思います。

拡張機能に関するパラメータ

Flexible Serverでは、データベース管理のための拡張機能が最初からいくつか組み込まれています。
Azure Database for PostgreSQL Flexible Serverのインスタンス生成時に、最初から作成されているpostgresデータベースには、以下の拡張機能が組み込まれています。

上記の拡張機能は、PostgreSQLパラメータshared_preload_librariesの設定値でも確認できます。

Azure Database for PostgreSQL Flexible Serverが使用する拡張機能用の独自サーバパラメータも存在しており、それがサーバパラメータの差分となってでてきます。

その他の独自追加パラメータ

拡張機能に依存するパラメータ以外にも、以下のパラメータが独自に追加されています。

async_standbys_wait_for_sync_replication

このパラメータは、非同期スタンバイ先にWAL送信するwalsenderの挙動を変更するもののようです。このパラメータをonにすると、同期スタンバイ先がプライマリにフラッシュLSNを報告するまで待つようになるとのこと。
このパラメータはデフォルトでonに設定されていました。

このパラメータは、PostgreSQLの開発者メーリングリストで議論中のパラメータで、まだPostgreSQL 15 betaバージョンにもコミットしていないパラメータのようです。まだ、PostgreSQL 15にもコミットしていない機能をFlexible Serverに追加しているのは驚きです。

sync_commit_cancel_wait

SHOW ALLコマンドで、このパラメータの説明を見ると、

> Allow cancellation of waiting for synchronous replication of a transaction committed locally.

と記載されています。機械翻訳すると「ローカルでコミットしたトランザクションの同期レプリケーションの待ち時間をキャンセルできるようにする」という意味のようですが、これだけだと正直言って、どういう機能なのかはわかりません。

なお、このパラメータの設定値はデフォルトでは-1となっており、おそらくデフォルトだとこの機能は無効化されていると推測していますが、このパラメータを説明している公式のFlixble Serverの文書が見つかっていません。また、PostgreSQL開発コミュニティでも、この名前のパラメータに関する議論が見つかっておらず、Flexible Server固有のパラメータのようですが、現状はパラメータの意味は謎のままです・・・。

remove_temp_files_after_crash

PostgreSQLのバックエンドプロセスがクラッシュした後に一時ファイルを自動的に削除するかどうかを制御するパラメータです。on（デフォルト値）の場合、一時ファイルは自動的に削除されます。offの場合、一時ファイルを残します。でも、Flexible Serverで、残った一時ファイルを収集すること自体できるのかな・・・？基本的にはonのままにしておくのが安全そうなパラメータですね。

なお、このパラメータは、コミュニティ版PostgreSQL 14から導入されたパラメータです。

設定値が変更されたサーバパラメータ

コミュニティ版PostgreSQL 13（コミュニティ版）と、Flexible Serverの設定値の差も思ったよりも多いです。
なお、configファイルのパスや、インスタンススペックに依存して変更される設定などは含んでいません。

本記事ではパラメータ設定の差分を全て説明しませんが、気になったものを数点ピックアップしてみます。

アーカイブ関連のパラメータ

アーカイブに関連するパラメータは3つあり、それぞれ以下のように設定されています。

Flexible Serverではアーカイブファイルを使ったリカバリを行っている、ということがわかります。
また、900秒ごとにアーカイブファイルを必ず作成する、ということもわかります。逆にいえば、リカバリ時にアーカイブファイルだけを使ってリカバリしているなら、最大で直近900秒の間のトランザクションはリカバリできないのかもしれません。このあたりはきちんと検証して確認しておきたいですね。

JIT関連のパラメータ

PostgreSQL 11から実行時コンパイル(JIT, just-in-time compilation)という機能が導入されました。これはLLVMの機能を使って、一部のSQL式の評価を汎用的なコードではなく専用の関数を使うように展開し、処理を高速化するという機能です。コミュニティ版PostgreSQL 12以降では、このJITを有効かするパラメータ jit はonになっていますが、Flexible Serverではoffになっています。

JITを前提にした処理を行うことはFlexible Serverではできないので注意が必要ということですね。

サーバログ関連のパラメータ

PostgreSQLのエラーや様々な動作はサーバログに書き込まれます。Flexible Serverを運用する場合にも、何か発生した場合にはサーバログを確認して、対策を検討することになると思います。

このサーバログに関するパラメータのデフォルト値もいろいろ変わっているようですね。

まずサーバログのファイル名の付与規則を設定するlog_filenameが異なります。Flexible Serverの場合、ログが生成されたときのタイムスタンプをファイル名に付与するという方針のようですね。

次にサーバログの先頭につく文字列を規定するlog_line_prefixについても差があります。それぞれデフォルト値で設定されているlog_line_prefixのエスケープ文字の意味は以下のようになります。

コミュニティ版の場合には、プロセス識別子をデフォルト展開するようになっていましたが、データベースサービスとして提供しているFlexible Serverの場合には、サーバ内にsshログインしてpsコマンド等でプロセスIDを確認することはできません。なので、log_line_prefixの設定値からも外れたのだと思います。

Flexible Serverでは代わりにセッションIDをlog_line_prefixとして展開するようになっています。このセッションIDは、pg_stat_activityビューのような監視用のビューにも表示されている情報ですが、その情報と突き合わせて解析できるようになっています。

おわりに

今回はAzure PostgreSQL Flexible Serverを立てて、ちょっとだけパラメータを確認してみただけですが、これからどんどんとAzure PostgreSQL Flexible Serverを使って、このサービスならではの良いところを学んでいきたいと思います。

PostgreSQLのことならNTTテクノクロスにおまかせください！
NTTテクノクロス株式会社ではPostgreSQLに関する各種のお問い合わせを受け付けています。
システムの導入、開発、維持管理の際にご活用ください。