はじめに

こんにちは！NTTテクノクロスでPostgreSQLの技術支援をやっています、中村です。

最近は、Azure Database for PostgreSQL フレキシブルサーバ（以下、Azure PostgreSQL）でも さまざまな検証を行うことが増えてきました。

データベース運用の重要な作業といえばバックアップとリカバリですね。
データベースに障害が起きた場合は、復旧手段として、PITR（Point In Time Recovery）を 使用することがありますが、Azure PostgreSQL でも PITR が利用可能です。
（Azureの場合、ポイントインタイムリストアと呼ぶようで、少し違います）

本記事では、PITRを用いて、バックアップ時と同じ環境に復旧したい場合の設定項目について確認をします。
ユーザが意識して設定する必要のある項目を抑えていきましょう。

PITRによる復旧のパターン

復旧する目標には、次のようなケースが考えられます。
（１）可能な限り、障害直前まで復旧するケース
（２）業務上のキリのいいタイミングに復旧するケース(※)
　※例えば、夜間バッチが終了し、営業日の切替えが午前5：00の業務の場合、
　　午前5：00の時点に復旧するといったケース

後述しますが、Azure PostgreSQL でも「復元ポイント」という項目で上記の復旧目標を網羅できます。

Azure PostgreSQL とコミュニティ版の PostgreSQLでのPITR時の違い

データベースの復旧に関しては差分はほとんどありません。
ただし、Azure PostgreSQL の場合、データベースの復旧だけでなく、利用する環境、特に運用部分の再設定も PITRとともに実施する必要があります。

「Azure PostgreSQL は全部自動でやってくれるから、PITR も何も考えなくてもいい感じでやってくれるはず！」 と思っていると、思いがけない落とし穴に落ちることがありますので、本記事ではそういった落とし穴を埋めるための解説をおこなっていきます。

PITR の際に設定項目の値が決まるタイミング

PITRの際に設定項目の値が決まるタイミングは以下の3つになります。

①バックアップ時点

②PITRの実行時

③PITRの実行後

それぞれについて、検証環境で確認した結果を整理していきます。
検証環境は以下の通りです。

■検証環境
・Azure Database for PostgreSQL フレキシブルサーバ（PostgreSQL14）
・自動バックアップは「ローカル冗長」を指定

なお、Azure PostgreSQL では手動バックアップが取得できません。
自動バックアップが取得されるまでしばらく待つ必要があります。

①バックアップ時点

ユーザが意識しなくても、自動的にバックアップ時点の設定で復旧される項目です。
これらは変更することができません。

万が一の障害発生時からの復元の際は同じ設定で戻すことが想定されるため、変更できないことは問題ありませんが、 データベースを複製して検証環境を構築する場合などの場合には復元後にコンピューティングサイズやストレージサイズを 用途に応じて変更するなどの作業が必要になる場合もあります。

復元される項目	復元内容の説明
リージョン	東日本で取得したバックアップは、東日本に復元する
コンピューティングサイズ	D8ds_V4 (8コア、32GBメモリ)の環境をバックアップしたら、D8ds_V4固定で復元する
ストレージサイズ	256GBの環境をバックアップしたら、256GB固定で復元する
PostgreSQLバージョン	PostgreSQL14の環境をバックアップしたら、PostgreSQL14で復元する
ネットワーク接続	プライベートアクセス（VNET統合）環境で利用していた場合は、VNET統合で復元する

以下はPITR時のスクリーンショットですが、コンピューティングサイズやストレージサイズなどは薄い文字になり、PITR時には選択や修正ができなくなっているのがわかりますね。

図：Azure PostgreSQL でのPITR設定画面

②PITRの実行時

バックアップから復元する操作を行うために、ユーザが入力しなければならない項目です。
入力せずにデフォルト値を使用することはできません。

復元する項目	復元内容の説明
サーバー名	既存のサーバー名と重複しない新しいサーバー名を入力する
可用性ゾーン番号	1～3 から選択する（西日本リージョンは1つのみ）
PITRの復元ポイント	最新の復元ポイントまたは日時を入力する

サーバー名

サーバー名は重複して作成できないため、バックアップ時の名前とは異なる名前を つける必要があります。

可用性ゾーン

可用性ゾーンは、日本だと東日本リージョンにしかありません。
西日本には可用性ゾーンが存在しないため、冗長化の構成が取れないことになります。

■参考（Azure ドキュメント）
ニーズに適した Azure 地域を見つける

復元ポイント

復元ポイントは以下の3つから選択します。
・最新の復元ポイント
・カスタム復元ポイント（日時指定）
・高速復元ポイント（自動バックアップから選択）

最新の復元ポイント、カスタム復元ポイント

「最新の復元ポイント」「カスタム復元ポイント」は、ともに自動バックアップを復元してから、更新ログを適用して指定した時間までロールフォワードします。
例えば、自動バックアップが0：00に行われており、カスタム復元ポイントを12：00にしようとした場合、 12時間分の更新ログを適用する必要があるため、ログ適用にもそれなりに時間がかかることが想定されます。

高速復元ポイント

「高速復元ポイント」は自動バックアップをリストアして終了します。更新ログ適用の時間を省くことで高速に復元するという仕組みです。
※高速かもしれませんが目的に合わない復元は意味がありませんので、実際の運用で「高速復元ポイント」を選択する機会は少ないと考えます。
ただし、リストアしたデータベースを見ることで自動バックアップがいつ取得されたのかをチェックすることができますので、「最新の復元ポイント」「カスタム復元ポイント」を選択しようとした際にどのくらいのログ適用が必要になるかの目安を知ることができます。

■参考（Azure ドキュメント）
フレキシブル サーバーのポイントインタイム リストア

③PITRの実行後

PITRの完了後にユーザが実施する項目です。
ほとんどが運用に関する設定ですが、重要な設定ばかりです。
サーバーパラメータも含まれているので、デフォルト設定から変更している場合には必ず作業が必要になります。

復元されない項目	手動設定が必要な内容の説明
冗長化設定	高可用性の設定を有効にする
サーバーパラメータ	postgresql.conf 相当の内容を設定する
診断設定	ログ収集の log analytics との連携を追加する
タスク	自動化タスクを追加する
アラートルール	アラートルール（メトリクス等の条件による通知）を追加する
メンテナンススケジュール	サービスの更新を自動で行う時間帯を再設定する

運用関連の設定はすべて解除されますので、PITRの実行後に再設定が必要です。

設定の反映にも時間が必要になりますので、復旧して利用可能になるまでの時間に影響します。 運用再設定の時間と、設定反映の時間についても事前に確認しておく必要があります。

■参考（Azure ドキュメント）
復元後のタスク

最後にもう一つ、Azure PostgreSQL の項目ではありませんが、PITRの後に必要な作業があります。

復元されない項目	手動設定が必要な内容の説明
稼働統計情報	ANALYZEコマンドを実施する

稼働統計情報は、SQL実行計画を最適化するために必要な情報です。PITR後はこの作業も忘れずに実施しましょう。

まとめ

Azure PostgreSQL で PITR を行う場合に気を付ける点について説明しました。
知らなければ見落とし、運用の再開に影響を与えてしまいますが、知っていれば特に難しい話はありません。

ただし、再設定する項目についてはシステムごとに異なるため、 あらかじめ整理しておき、本番運用時には手順に従って作業するだけにしておくと 慌てずにすみます。

また、Azure PostgreSQL のドキュメントだけでは肌感覚がつかみづらいと思いますので、 本番運用と想定しながら PITRの検証を行ってみるのが良いと思います。

それでは、本記事は以上となります！

PostgreSQLのことならNTTテクノクロスにおまかせください！

NTTテクノクロス株式会社ではPostgreSQLに関する各種のお問い合わせを受け付けています。
オンプレだけではなく、Azure、AWSなどのクラウド上でのシステムの導入、開発、維持管理の際にご活用ください。

定額制チケットサービスはこちら