PostgreSQLのアップグレードを解く

PostgreSQL 9.6がリリースされたばかりで、ほとんどのpostgresユーザーは新しいメジャーバージョンにアップグレードする方法を自問し始めます。この投稿は、PostgreSQLサーバーをアップグレードするためのさまざまな手順を示すことを目的としています。

新しいメジャーバージョンへのアップグレードは、合計実行時間に対する準備の比率が高いタスクです。特に、途中でリリースをスキップする場合、たとえば、バージョン9.3からバージョン9.5にジャンプする場合。

ポイントリリース

一方、ポイントリリースのアップグレードにはそれほど多くの準備は必要ありません。通常、唯一の要件は、postgresサービスを再起動することです。基盤となるデータ構造に変更はないため、ダンプして復元する必要はありません。最悪のシナリオでは、ポイントリリースのアップグレードが完了した後、インデックスの一部を再作成する必要がある場合があります。

常に最新のポイントリリースを維持することは非常に賢明です。そのため、既知の（そしておそらく修正された）バグに遭遇することはありません。これは、最新バージョンがリリースされたら、できるだけ早くアップグレードの時間をスケジュールすることを意味します。

メジャーリリースのアップグレード

このような複雑なタスクを実行するときは、最終結果を達成するために考えられるすべてのオプションを検討することをお勧めします。

メジャーリリースのアップグレードでは、次の3つの方法が考えられます。

論理ダンプからのアップグレード復元
物理的なアップグレード
オンラインアップグレード

それぞれについて詳しく説明します：

1）論理ダンプからのアップグレード復元

これは、クラスターのデータ構造をアップグレードするためのすべての可能な方法の中で最も簡単です。

簡単に言うと、ここでのプロセスでは、古いバージョンのpg_dumpを使用した論理ダンプと、新しくインストールされたバージョンで作成されたクリーンクラスター上のpg_restoreが必要です。

このパスの使用を支持する重要なポイントは次のとおりです。

最もテストされています
互換性は7.0バージョンに戻るため、最終的に7.xから最新リリースの1つにアップグレードできます

このオプションの使用を避けるべき理由：

pg_dumpの実行を開始する前に書き込み接続を停止する必要があるため、大規模なデータベースでの合計ダウンタイムが問題になる可能性があります。
データベースに大きなオブジェクトが多数ある場合、pg_dumpは遅くなります。並行して行う場合でも。データベースに多数の大きなオブジェクトが保存されている場合、復元はpg_dumpよりもさらに遅くなります。
2倍のディスク容量、または復元する前に古いクラスターを削除する必要があります。

複数のCPUコアを搭載したサーバーでは、ディレクトリ形式を使用してpg_dumpを並行して実行できます。完了したら、pg_dumpとpg_restoreの両方で-jスイッチを使用して、並行して復元します。ただし、ダンプ全体が完了するまで、復元プロセスを開始することはできません。

2）物理的なアップグレード

これらの種類のアップグレードは、バージョン9.0以降、8.3までの古いバージョンからインプレースアップグレードを実行するために使用できます。これらは同じサーバー上で、できれば同じデータディレクトリ上で実行されるため、「インプレース」と呼ばれます。

これらの種類のアップグレードの利点：

クラスターの別のコピー用のスペースは必要ありません。
ダウンタイムは、pg_dumpを使用する場合に比べてはるかに短くなります。

かなりの数の欠点があります：

PostgreSQLの新しいバージョンを開始すると、古いバージョンに戻ることはありません（クラスターは、それ以降、新しいバージョンでのみ機能します）。
アップグレード後は統計がゼロになるため、新しいバージョンのPostgreSQLを起動した直後に、クラスター全体の分析を実行する必要があります。
pg_upgradeに関して過去数年間に多くのバグが発見されたため、一部のデータベース管理者はこの方法をアップグレードに使用することを躊躇しています。
バージョン9.2からバージョン9.4に移行するなど、メジャーリリースをスキップするときに問題が発生する人もいます。
カタログが大きいと、パフォーマンスが低下します（多数のデータベースを含むクラスター、または数千のオブジェクトを含むデータベース）。

–linkオプションを指定せずにpg_upgradeを実行することもできます（この場合、pg_upgradeはクラスターのディスク上に2番目のコピーを生成します）。これにより、古いバージョンに戻ることができます。ただし、上記の両方の利点が失われます。

3）オンラインアップグレード

この方法の手順は次のようになります。

両方のバージョンをインストールして、並行して動作させることができます。これは、同じサーバー上で実行することも、2台の物理サーバーを使用して実行することもできます。
初期コピーを作成し、ソースノードでコピーを開始した瞬間から変更を複製します（これは初期pg_dumpに似ています）。
ラグがゼロに近づくまで、変更を論理的に複製し続けます。
アプリケーションサーバーからの接続情報を再ポイントして、新しいサーバーに接続します。

このタイプのアップグレードは、最初のトリガーベースのレプリケーションソリューションが登場して以来利用可能です。言い換えれば、Slony-Iがいたので。

トリガーベースのレプリケーションソリューションは、サポートされているSQLコマンドを使用して変更をコピーするため、どちらのバージョンを使用していてもかまいません。

推奨されるトリガーベースのレプリケーションツールは、表示される順序で次のとおりです。

skytools：PgQ + londiste
Slony-I

これは、アップグレードに適した方法です。この方法を使用する利点を見てみましょう：

ダウンタイムゼロ！
新しいハードウェアへのアップグレードにも最適です。
新しいバージョンを使用したクラスターのオンラインテスト（読み取り専用クエリ、または競合が発生する可能性があります）。
すべてのテーブルとインデックスの膨張を大幅に減らします。

いくつかの欠点があります：

データの2番目のコピーを保存する必要があるため、2倍のストレージスペースが必要です。
トリガーに基づいているため、システムは各変更を2回書き込む必要があります。つまり、ソースサーバー（古いバージョンのクラスター）でのディスクI/Oが増えます。
すべてのテーブルに主キーが必要であるため、レプリケーションツールは更新または削除されたタプルを個別化できます
カタログテーブルを複製しないため、大きなオブジェクトを複製しません。
基本的な使用法はスキーマの変更をカバーしていません。実行できますが、透過的ではありません。

pglogicalの新しいフロンティア

PostgreSQL 9.4以降、トランザクションログの論理的なデコードが可能になりました。これは、WALからトランザクションをデコードし、出力を操作できることを意味します。

複製の分野では、まったく新しい可能性の世界が現れました。論理レプリケーションを実行するためにトリガーは不要になりました！

これは基本的に、トリガーを使用してすべての挿入、更新、削除の個別のコピーを保存する必要がないことを意味します。これらのデータ操作操作は、デコードすることでトランザクションログから取得できます。次に、出力を操作してサブスクライブされたダウンストリームノードに送信する必要があるのは、使用しているツールです。この場合、そのツールはpglogicalです。

では、これはどういう意味ですか？

PostgreSQLのバージョン9.4または9.5を使用していて、9.6にアップグレードする場合は、上記のようなオンラインアップグレードを実行できますが、トリガーベースのレプリケーションソリューションの代わりにpglogicalを使用します。

この特定のトピックに関する他のブログがあるため、これ以上詳しくは説明しません。たとえば、Petr Jelinekが書いたブログ：PostgreSQL9.6beta1用のPGLogical1.1パッケージ

結論

データベースのスキーマ、データサイズ、考えられるダウンタイムウィンドウ、現在のPostgreSQLインストールのバージョンに応じて、あるオプションを別のオプションから選択するか、最適なオプションを選択できます。

データベースが小さく、使用できる適切なメンテナンスウィンドウがある場合は、pg_dumpとpg_restoreの実行を選択できます。データセットのサイズによっては、オプションが実行できなくなるポイントがあります。
大規模なデータベース（数百GB、さらにはTBのデータ）がある場合は、pg_upgradeを使用したインプレースアップグレードやオンラインアップグレードなどの他のオプションを探す必要があります。
- バージョン8.3以降から任意の9.xバージョンにアップグレードする場合は、pg_upgradeを使用できます。
- 8.3より古いバージョンの場合、londisteやslonyなどの論理レプリケーションソリューションのいずれかを選択する必要があります。
- 9.4または9.5データベースの場合は、pglogicalを使用することをお勧めします。

論理レプリケーションの場合、テーブルには主キーが必要であることを常に忘れないでください。

pglogicalでは、そのルールはそれほど厳密ではありません。挿入専用テーブルを複製できます。ただし、更新と削除の場合でも、テーブルに主キーまたはレプリカIDが必要です。

PostgreSQLデータベースのアップグレードについてサポートが必要な場合は、
2ndQuadrantアップグレードサービスを確認してください。