Google Cloudの新DBMS、AlloyDB for PostgreSQLを触ってみた Vol.3

まえがき

こんにちは。開発部の高井(Peacock)です。

前回に引き続きAlloyDB連載の第3回として、バックアップ周りの機能を試していきます。

直近でGAとなった「Continuous backup and recovery (拙訳: 継続的バックアップとリカバリー)」も試していきます。

バックアップ画面

上記のように画面左のメニューからバックアップ画面に遷移できます。

開くと下のような画面になり、バックアップの一覧を見ることができます。

バックアップ作成・復元

実際にバックアップを作成・復元してみます。

先程の画面の上の方に「バックアップの作成」ボタンがあるのでそれを押します。右側に以下のようなダイアログが出てきて作成できます。

しばらく待つと作成完了になりました。ではここから復元してみましょう。右端の「復元」ボタンを押します。

先程と同じように右側にダイアログが出てきて、名前などを設定したら復元できます。

しばらく待つと復元が終わって、新しいクラスタが作成されています。インスタンスは何も作成されないようです。

ではプライマリインスタンスを作成、同様にpsqlコマンドで繋いでみます。

gcloud compute ssh --zone "asia-northeast1-b" "bastion"  --project "techblog-alloydb"

yoichi@bastion:~$ psql -h <インスタンスのIP>
psql (14.7 (Debian 14.7-1.pgdg110+1), server 14.4)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=> SELECT * FROM payment LIMIT 10;
 payment_id | customer_id | staff_id | rental_id | amount |         payment_date
------------+-------------+----------+-----------+--------+-------------------------------
      16051 |         269 |        1 |        98 |   0.99 | 2022-01-29 01:58:52.222594+00
      16065 |         274 |        1 |       147 |   2.99 | 2022-01-25 12:14:16.895377+00
      16109 |         297 |        2 |       143 |   0.99 | 2022-01-28 00:49:49.128218+00
      16195 |         344 |        2 |       157 |   2.99 | 2022-01-31 05:58:51.176578+00
      16202 |         348 |        2 |       821 |   0.99 | 2022-01-26 16:52:41.359433+00
      16216 |         357 |        2 |       945 |   0.99 | 2022-01-24 00:39:09.052005+00
      16237 |         369 |        1 |        31 |   4.99 | 2022-01-31 00:12:16.422091+00
      16247 |         372 |        1 |       617 |   2.99 | 2022-01-29 12:51:46.565326+00
      16249 |         373 |        2 |       257 |   4.99 | 2022-01-29 05:33:33.142744+00
      16259 |         379 |        2 |       209 |   4.99 | 2022-01-30 23:02:06.818362+00
(10 rows)

postgres=>

無事バックアップが取れていそうです。

プライマリインスタンスを消した状態で試してみる

ここで「プライマリインスタンスがない状態でもバックアップが取れるのか」という実験もしてみます。

では先程作成したプライマリインスタンスを削除します。

踏み台用インスタンスからpsqlコマンドで接続できないことを確認して、先程と同様にバックアップを取ってみます。

作成ボタンを押すとエラーメッセージが出ました。どうやらプライマリインスタンスなしではバックアップを作成できないことが判明しました。

Continuous backup and recovery (拙訳: 継続的バックアップとリカバリー)

最後に、つい最近GAとなったContinuous backup and recovery(直訳:継続的バックアップと復元)を見ていきます。

以下に公式ドキュメントを簡単に訳してまとめたものを引用として記載します。

- 機能概要
    - 任意の時点にマイクロ秒単位でリストア可能
    - 最大35日前のポイントを選択可能
    - 大規模なデータ削除後の復元やクラスタの状態の再現に有用
    - 健全なクラスタの独立したクローンを作成可能

- 有効化方法とバックグラウンドタスク
    - 新しいクラスタではデフォルトで無効
    - 有効化すると、継続的なバックグラウンドタスクが開始
        - 毎日の追加バックアップ
        - すべてのデータ変更に対する内部ログの保持

- ポイントインタイム・リストア
    - ストアドバックアップとデータチェンジログを使用してリストアされたクラスタを作成

- リカバリウィンドウとクリーンアップ
    - リカバリウィンドウは1～35日間で選択
    - 連続バックアップとログがウィンドウより古くなった後、自動的にクリーンアップ

- ストレージコスト
    - プレビュー期間中、連続バックアップによって作成されたファイルはプロジェクトのストレージコストにカウントされない

要するに、最大35日前までの任意の時点へ復元できる機能のようです。実際に試してみましょう。

まだWebコンソールからは有効にすることができないのでgcloud CLIを使います。

コマンドのリファレンスはこちらです。

gcloud beta alloydb clusters update CLUSTER_ID \
    --enable-continuous-backup \
    --continuous-backup-recovery-window-days=WINDOW_LENGTH \
    --region=REGION_ID \
    --project=PROJECT_ID

機能の有効化に伴う追加バックアップについてはこんな事が書かれています。まずは24時間程度待ちます。

• 毎日1つの追加バックアップが取得される
• クラスタのバックアップリストでは「Continuous」ラベルが付与される
• 最初の連続バックアップは機能有効化後24時間以内に取得される

数日待ってみました。このように contin-とprefixがついたバックアップが自動的に取られるようです。

ここから任意の時間へリストアができればよいのですが、コンソールからはまだできないbeta機能のため、CLIで操作してみます。

$ gcloud beta alloydb clusters restore contin-bk-20230409-hello-world \
    --source-cluster=hello-world \
    --point-in-time=2023-04-9T10:30:00Z \
    --region=asia-northeast1 \
    --project=techblog-alloydb
Operation ID: operation-xxxxx-yyyyy-zzzzz
Restoring cluster...done.

できました。先程と同様にプライマリインスタンスは作られないようです。

まとめ

今回はバックアップ編ということで、標準のバックアップ機能と新しくGAとなった継続的バックアップとリカバリーを試してみました。特に後者の継続的バックアップとリカバリーは、障害発生時やオペレーションミスをしたときの回復に役立ちそうです。実際の現場ごとにそのフローと手順を予めしっかり決めて運用する事が肝要ですね。

次回は「エンジン設定編」ということで、こちらも目玉機能の一つであるカラムナーエンジンなどを試していきたいと思います。