デベロッパー

pglogical および Database Migration Service で Postgres をアップグレードする

2021年9月30日

Google Cloud Japan Team

※この投稿は米国時間 2021 年 9 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

ご存じの方も多いと思いますが、Postgres は 2021 年 11 月にバージョン 9.6 の長期サポートを終了します。ただし、バージョン 9.6 をまだ使用していてもご心配はいりません。Cloud SQL では、インプレースメジャーバージョンアップグレードが提供されてから 1 年間は、バージョン 9.6 が引き続きサポートされます。それでもすぐにアップグレードしたい場合は、Google Cloud の Database Migration Service（DMS）を使用すると、Cloud SQL のメジャーバージョンのアップグレードが短いダウンタイムで簡単に実施できます。

この方法は Postgres バージョン 9.6 以降のアップグレードに利用できます。また、移行元は Cloud SQL インスタンスでなくてもかまいません。移行元をオンプレミス、セルフマネージド型 Postgres、AWS ソースのいずれかに設定して、Cloud SQL への移行と Postgres のアップグレードを同時に行うことができます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image5_ttarfe5.max-600x600.max-600x600.png

DMS では MySQL の移行とアップグレードもサポートしていますが、このブログ投稿では Postgres に焦点を当てています。MySQL インスタンスのアップグレードを検討している場合は、このトピックに関する Gabe Weiss の投稿を確認してください。

アップグレードの目的

Postgres 9.6 のサポートが終了するということから、この投稿をご覧になっていることと存じます。または、増分ソートやインデックスの並列バキュームなど、最新の Postgres 13 の機能を利用することをお望みかもしれません。Google Cloud SQL への移行を検討していて、同時に最新のメジャーバージョンにアップグレードすることを検討中ということも考えられます。

バージョンの非互換性への対処

まず、アップグレードする前に、メジャーバージョン間での互換性を破る変更について確認する必要があります。特に、目的が一度に複数のバージョンを上げる場合（たとえば、バージョン 9.6 からバージョン 13 へのアップグレード）は、それらのバージョン間のすべての変更点を考慮する必要があります。これらの変更点は、現在のバージョンからターゲットバージョンまでの各バージョンのリリースノートを見ることで確認できます。

たとえば、Postgres 9.6 インスタンスのアップグレードを開始する前に、「xlog」を「wal」に参照する SQL 関数、ツール、オプションの名前の変更、サーバー上の暗号化されていないパスワードを保存する機能の削除、浮動小数点のタイムスタンプとインターバルのサポートの削除など、バージョン 10 の非互換性にまず対処する必要があります。

移行のための移行元の準備

移行元のデータベースエンジンで DMS 移行の準備をするためにいくつかの手順を実行する必要があります。これらの手順の詳細についてはこのガイドをご覧ください。

まず、移行元インスタンスに「postgres」という名前のデータベースを作成する必要があります。移行元が Cloud SQL インスタンスの場合、このデータベースはすでに存在している可能性があります。

次に、pglogical パッケージを移行元インスタンスにインストールします。DMS では、移行元インスタンスと移行先インスタンスの間でデータを転送するために pglogical を使用します。移行元が Cloud SQL インスタンスの場合、この手順は簡単でcloudsql.logical_decoding フラグと cloudsql.enable_pglogical フラグをオンに設定します。これらのフラグを設定したら、インスタンスを再起動してフラグを有効にします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_VJleaZ9.max-1100x1100.max-1100x1100.png

この投稿では Cloud SQL インスタンスを移行元として使用することに焦点を当てていますが、RDS インスタンスの場合の手順はここで参照し、オンプレミス / セルフマネージド型インスタンスの場合の手順はここで参照できます。移行元がセルフマネージド型インスタンス（つまり、Compute Engine 上）、オンプレミスインスタンス、または Amazon RDS/Aurora インスタンスの場合、このプロセスはもう少し複雑になります。

インスタンスの pglogical フラグを有効にした後は、移行元のデータベースがテンプレートデータベース template0、template1 のいずれでもない場合は、拡張機能をインストールする必要があります。移行元が Cloud SQL 以外の場合は、ここをチェックすると除外する必要がある移行元データベースを確認できます。移行元インスタンスで Postgres 9.6 以降を実行している場合は、移行対象の移行元インスタンスの各データベースで CREATE EXTENSION IF NOT EXISTS pglogical; を実行します。

次に、移行時に移行元インスタンスに接続するために使用するユーザーに、移行対象のデータベースに対する権限を付与する必要があります。詳しい手順についてはこちらをご覧ください。移行ジョブを作成する場合、接続プロファイルを作成するときにこのユーザー名とパスワードを入力します。

DMS での移行ジョブの作成

DMS で移行ジョブを作成するための最初のステップは、移行元と移行先を定義することです。移行元を定義する場合は、以前に権限を付与した移行ユーザーのユーザー名とパスワード、および移行元インスタンスの IP アドレスを指定して、接続プロファイルを作成する必要があります。移行元が Cloud SQL インスタンスの場合は、IP アドレスは自動入力されます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image3_z24iAWU.max-900x900.max-900x900.png

次に、移行先を作成する場合、Postgres のターゲットバージョンを選択していることを確認する必要があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image4_rMbTGt5.max-1100x1100.max-1100x1100.png

移行元と移行先を選択してから接続方法を選択し（接続方法の詳細については、こちらの Gabe Weiss による詳細な投稿をご覧ください）、テストを実行して移行元が移行先に接続できることを確認します。テストが成功すると、アップグレードの準備が整ったことになります。移行ジョブを起動すると、2 つのインスタンスに保存されているデータの同期が開始されます。2 つのインスタンスが完全に同期がとれるまで時間がかかる場合があります。このリンクの手順を使用すると、すべてのデータが同期されているかを定期的に確認できます。その間、アップグレードされた移行先インスタンスを昇格する準備ができるまで、移行元データベースへのトラフィックに対応し続けることができます。

移行先インスタンスの昇格と最終調整

移行実行後、移行先インスタンスが本番環境に対応する前にいくつかのことを実施する必要があります。まず、移行元インスタンスで有効にした設定が、移行先インスタンスにも適用されていることを確認します。たとえば、組織で本番インスタンスが SSL 接続のみを受け入れる必要がある場合は、インスタンスの enforce-SSL をオンにします。

高可用性や読み取りレプリカなど、一部のシステム構成は、インスタンスの昇格後にしか設定できません。

ダウンタイムを短縮するために、アプリケーションが移行元データベースを使用している間も DMS 移行は継続的に実行されます。ただし、移行先をプライマリインスタンスに昇格させる前に、移行元へのクライアント接続をすべてシャットダウンして、それ以降の変更を防止する必要があります。すべての変更が移行先インスタンスにレプリケートされたら、移行先を昇格させて移行ジョブを終了できます。昇格の際のベストプラクティスについて詳しくは、こちらをご覧ください。

最後に、DMS ではデータ移行を pglogical に依存しているため、DMS が継承する pglogical にはいくつかの制限があります。

第一に pglogical は、主キーを持つテーブルのみを移行するということです。それ以外のテーブルは手動で移行する必要があります。主キーのないテーブルを特定するには、このクエリを実行します。こちらで説明されているように、主キーなしでテーブルを移行するために使用できる方法がいくつかあります。
第二に、pglogical はマテリアライズドビューについてはスキーマのみを移行し、データは移行しません。データを移行するには、最初に SELECT schemaname、matviewnameFROM pg_matviews を実行して、マテリアライズドビュー名をすべて一覧表示します。次に、ビューごとに REFRESH MATERIALIZED VIEW <view_name> を実行します。
第三に、pglogical は大きなオブジェクトを移行できません。大きなオブジェクトが含まれるテーブルは、手動で転送する必要があります。大きなオブジェクトを転送する 1 つの方法は、pg_dump を使用して、大きなオブジェクトが含まれる 1 つまたは複数のテーブルをエクスポートし、それを Cloud SQL にインポートすることです。これを最も安全に実施できるのは、大きなオブジェクトが含まれるテーブルが変更されないことがわかっているときです。移行先インスタンスが昇格されてから大きなオブジェクトをインポートすることをおすすめしますが、ダンプとインポートの手順はいつでも実行可能です。
最後に、pglogical はユーザーを自動的に移行しません。移行元インスタンスのすべてのユーザーを一覧表示するには、\du を実行します。次に、こちらのリンクで示されている手順に沿って、移行先インスタンスに各ユーザーを作成します。

移行先を昇格させ、必要な手動手順を実施してから、新しいインスタンスを指すようにアプリケーション、サービス、ロードバランサなどを更新する必要があります。可能であれば、アプリケーションの開発 / ステージングバージョンでテストして、すべてが想定どおりに機能することを確認します。

セルフマネージド型インスタンスまたはオンプレミスインスタンスから移行する場合は、アプリケーションのすぐ隣にない Cloud SQL データベースとの連携によりレイテンシが増加することを考慮して、アプリケーションを調整する必要があります。また、状況に応じて Cloud SQL インスタンスへの接続方法を把握する必要もあります。Cloud SQL Auth プロキシ、Python、Java、Go に接続するためのライブラリ、VPC コネクタでプライベート IP アドレスを使用するなど、Cloud SQL に接続するパスは数多くあります。これらすべての接続方法の詳細については、Cloud SQL 接続の概要ドキュメントをご覧ください。