クラウド内のPostgreSQLクラスターのほぼゼロのダウンタイム自動アップグレード（パートI）

先週、私はNordic PGDay 2018に参加し、自分が作成したツール、つまり pglupgradeについてかなりの数の会話をしました。、レプリケーションクラスタセットアップでPostgreSQLメジャーバージョンのアップグレードを自動化するため。さまざまなコミュニティの何人かの人々が、論理レプリケーションを使用したほぼゼロのダウンタイムのアップグレードについて、ミートアップや他の会議で講演していることを聞いて、とてもうれしく思いました。 PGDAY'17ロシア、ワルシャワでのPGConf.EU 2017、そして最後にブリュッセルで開催されたFOSDEM PGDay 2018で私が行った講演があることを考えると、このプレゼンテーションをできる人たちが利用できるように、ブログ投稿を作成する方が良いと思いました。前述のどの会議にも参加しないでください。直接話をして、このブログ投稿をスキップしたい場合は、ここにあなたのリンクがあります：クラウドでのPostgreSQLクラスターのゼロに近いダウンタイムの自動アップグレード

このツールの開発の背後にある主な動機は、残念ながらPostgreSQLを使用するほとんどすべての人に影響を与えるメジャーバージョンのアップグレード中のダウンタイムを最小限に抑えるソリューションを提案することでした。現在、PostgreSQLユーザーがダウンタイムなしでデータベースをアップグレードできるツールはありません。これは、多くのユーザー、特に企業にとって明らかに問題です。また、アップグレードの問題を解決する場合は、複数のサーバー（今後はクラスターと呼びます）を検討する必要があります。これは、データベースサーバーを1つだけ使用する人が少なくなっているためです。最も一般的なシナリオは、高可用性を目的とした物理ストリーミングレプリケーションのセットアップ、または読み取りクエリのスケーリングです。

データベースのアップグレード

ソリューションに飛び込む前に、データベースのアップグレードが一般的にどのように機能するかについて少し説明しましょう。データベースのアップグレードには、主に4つのアプローチがあります。

最初のアプローチは、データベースがストレージ形式を同じにするか、少なくともバージョン間で互換性を保つことです。ただし、新機能ではデータの保存方法を変更したり、正しく機能するためにメタデータ情報を追加したりする必要があるため、これを長期的に保証することは困難です。また、多くの場合、データ構造を最適化することでパフォーマンスが向上します。
2番目のアプローチは、古いサーバーの論理コピー（ダンプ）を作成し、それを新しいサーバーにロードすることです。これは最も伝統的なアプローチであり、プロセス中に古いサーバーが更新を受信しないようにする必要があり、その結果、ダウンタイムが長くなります 大規模なデータベースでは数時間または数日です。
3番目のオプションは、データを古い形式から新しい形式に変換することです。これは、新しいシステムの実行中にオンザフライで実行できますが、データアクセスパターンに依存するため予測が難しいパフォーマンスの低下が発生するか、サーバーがダウンしているときにオフラインで実行して、長時間発生する可能性があります。ダウンタイム （多くの場合、2番目の方法よりも短いですが）
4番目の方法は、論理ダンプを使用してデータベースを保存および復元し、その間に発生する変更をキャプチャすることです。最初の復元が完了したら、それらを新しいデータベースに論理的に複製します。この方法では、いくつかのコンポーネントのオーケストレーションが必要ですが、データベースがクエリに応答できない時間も短縮されます。

PostgreSQLのメソッドのアップグレード

PostgreSQLのアップグレードは、上記の4つの方法と一致させることができます。たとえば、PostgreSQLのマイナーリリースは、新機能は含まれていませんが、修正のみが含まれていますが、既存のデータ形式を変更せず、最初のアプローチに適合します。 2番目のアプローチでは、PostgreSQLは論理的なバックアップと復元を行うpg_dumpおよびpg_restoreと呼ばれるツールを提供します。古いデータディレクトリから新しいデータディレクトリへのオフライン（サーバーが実行されていない）変換を行うpg_upgradeツール（これはcontribモジュールであり、PostgreSQL 9.5のメインツリーに移動されました）もあります。これは3番目のオプションに適合します。 4番目のアプローチには、アップグレード用のSlonyなどのサードパーティのトリガーベースのソリューションがありますが、いくつかの注意点があります。これについては後で説明します。

従来のアップグレード方法はのみレプリカサーバーを後で再構築する必要があるときにプライマリサーバーをアップグレードする（オフライン変換） 。これにより、クラスターの可用性と容量の両方に追加の問題が発生するため、認識されるダウンタイムが効果的に増加します。アプリケーションとユーザーの両方の観点からデータベースの論理レプリケーションはレプリケーションを可能にします システムが稼働中である間その間にテスト作業を処理できます（オンライン変換） 。

さまざまな環境に適用できるさまざまなアップグレード方法があります。例： pg_dump 非常に古いバージョン（7.0など）からのアップグレードが可能 最近のリリースでは、PostgreSQLの旧バージョンを実行している場合、最良の方法は pg_dump / restoreを使用することです。（そして今それをする方が良いです！）。 PostgreSQLのバージョンが8.4以降の場合 pg_upgradeを使用できます。 PostgreSQLを使用している場合9.4以降 これは、コア内の「論理デコード」があることを意味します pglogicalを使用できますアップグレードの手段としての拡張。最後に、 PostgreSQL 10を使用している場合、データベースをPostgreSQL11以降にアップグレードする機会があります（利用可能になったら）コア内の「論理レプリケーション」を使用する（イェーイ！）

アップグレードのための論理レプリケーション

論理レプリケーションを使用してPostgreSQLをアップグレードするアイデアはどこにありますかから来ていますか？明らかに、 pglogical pg_upgradeのようにアップグレードの目的を公然と主張していません（これは会議パーティーでのpglogicalに対する1つの議論でした ）、ただし、これは、アップグレードにツールを使用できないことを意味するものではありません。実際、pglogicalが設計されたとき、ダウンタイムがほぼゼロのアップグレードは、拡張機能の開発者が期待するユースケースの1つと見なされていました。

ディスク上の生データへの変更をキャプチャする物理レプリケーションとは異なり、論理レプリケーションはデータベース内の個々のレコードへの論理変更をキャプチャし、それらをレプリケートします。論理レコードはメジャーリリース間で機能します 、したがって、論理レプリケーションはアップグレードに使用できます あるリリースから別のリリースへ。バージョンアップグレードの手段として論理レプリケーションを使用するという考えは、新しいものとはほど遠いものです。トリガーベースのレプリケーションツールは、トリガーを介して変更をキャプチャして送信することにより、論理的な方法でアップグレードを行ってきました（トリガーはデータベースのバージョンに関係なく機能するためです！。

ダウンタイムのアップグレードを最小限に抑えるためにトリガーベースのレプリケーションソリューションを使用できる場合、代わりに論理レプリケーションを選択する必要があるのはなぜですか？トリガーベースのメカニズムでは、すべての変更がトリガーを使用してキャプチャされ、キューテーブルに書き込まれます。この手順では、すべての変更を2回書き込む必要があるため、書き込み操作が2倍になり、ログファイルが2倍になり、システムの速度が低下します。その結果、より多くのディスクI/Oとソースサーバーの負荷が発生します。対照的に、コア内論理レプリケーション（pglogical拡張についても同じ）は、論理デコードの上に構築されます。論理デコードは、WALファイルから論理変更（INSERT / UPDATE / DELETE）に情報を抽出するメカニズムです。 WALメカニズムからのデータはトランザクションログのデコードによって使用されるため、ライトアンプリフィケーションはありません トリガーベースのレプリケーションソリューションの場合と同様に、この方法はパフォーマンスが向上します 。その結果、論理デコードベースのソリューションは、トリガーベースのソリューションよりもシステムへの影響が少ないだけです。

結論

この紹介記事では、メジャーバージョンのアップグレード中にダウンタイムを最小限に抑えるために論理レプリケーションの使用を検討する必要がある理由を説明したいと思います。今後の投稿で、ツールのアーキテクチャと実装の詳細を継続します。