web-dev-qa-db-ja.com

ダウンタイムなしで本番サーバーのPostgresを更新する

Postgres 9.4を実行している運用サーバーがあります。データベースは> 10 GBです。ダウンタイムやデータを失うことなくPostgres 9.5にアップグレードできますか？

アップグレードチュートリアルでは、Sudo pg_upgradecluster 9.4 mainの実行中にPostgresを停止することを推奨していますが、これには時間がかかる場合があります。 10 GBクラスターの更新には数時間かかる場合があります。

私もpg_dump mydb > db.sqlを試しました。データベースを削除し、PG 9.4（psql -d mydb -f db.sql）でダンプを再度挿入すると、約50分かかりました。

しかし、PG 9.5へのダンプの挿入は、7時間以上経過しないと完了しませんでした。特にインデックスの作成は非常に遅かった...

2016-07-18 00:13:55 CEST [60358-5] ERROR:  canceling autovacuum task
2016-07-18 00:13:55 CEST [60358-6] CONTEXT:  automatic analyze of table ...
2016-07-18 00:36:20 CEST [60366-1] ERROR:  canceling autovacuum task
2016-07-18 00:36:20 CEST [60366-2] CONTEXT:  automatic analyze of table ...
2016-07-18 04:21:40 CEST [60361-1] ERROR:  canceling autovacuum task
2016-07-18 04:21:40 CEST [60361-2] CONTEXT:  automatic analyze of table ...
2016-07-18 07:55:19 CEST [61316-1] ERROR:  canceling autovacuum task
2016-07-18 07:55:19 CEST [61316-2] CONTEXT:  automatic analyze of table ...

したがって、pg_upgradeclusterもpg_dumpも許容できるソリューションではありません。 PG 4を使用しても、少なくとも50分のダウンタイムが発生します。したがって、ダウンタイムやデータ損失なしに、本番サーバーまたは大きなマスタースレーブクラスターでデータベースをアップグレードするにはどうすればよいでしょうか。

postgresqlupgradedata-loss
7
Barmi

クラスタリングの魔法がなければ、ダウンタイムは発生しません。

その他の可能性：

  1. 使用する pg_upgrade とともに --linkオプション。このオプションを使用すると、元のDBファイルはコピーされず、新しいディレクトリにハードリンクされるため、プロセスが大幅に高速化されます。これ完全に変更されますソースDBファイルであることに注意してください。
  2. 使用する pg_dumpと新しいデータベースで復元します。新しいデータベースで同期書き込みを無効にすることで、必要な時間を大幅に短縮できます（fsync = false新しいPGインスタンスの構成ファイル内）
  3. 新しいPGインスタンスをサイドインストールし、別のポートで実行できるようにします。次に、pg_dumpダンプをネットワーク経由で新しいインスタンスにロードします。完了したら、ポートを交換して新しいインスタンスを使用します。
6
shodanshok

あなたはすでにそれを解決したと思いますので、おそらく同様の問題を持つ他の人のために。

バージョン8.4から最新の9.6までのpostgresqlでの作業の数年後、私はこれらの場合にお勧めします-「アップグレード」しないでください。使用可能なOSの最新バージョン（非常に重要-多くの問題を回避する）と最新のpgバージョンと重複データを使用して、新しいマシンまたは新しいクラウドインスタンスを作成できる場合。

データを複製する方法は、アプリケーション、PostgreSQLのバージョン、および周囲の環境によって異なります。データベース〜10 GBはそれほど大きくないため、適しています。私は400 GBを超えるdbsで作業しているので、ここで多数の問題を想像してください...

  • Pg_dump 9.4では、複数のCPUコアを使用して複数のジョブでディレクトリ形式にダンプできます。1つの大きなテーブルにすべてが含まれていない限り、ダンプ時間を大幅に短縮できます:-)
  • または、pg 9.4以降では、前述のpglogical拡張機能を使用できますが、これは非常に優れたソリューションですが、注意してください。マスターでpglogicalを実行するには、postgresql.confファイルのshared_preload_libraries = 'pglogical'に拡張機能を追加する必要があるため、postgresを再起動する必要があります。ここを参照してください： http://postgresql.freeideas.cz/pglogical-postgresql-9-6-small-hints-debian/ したがって、以前に同じバージョンの他のインスタンスでテストすることを強くお勧めします！そして、新しいインスタンスに切り替えるには、クライアントを新しいデータベースに切り替えるための短いメンテナンスウィンドウをスケジュールします-接続文字列がアプリケーションにハードコードされていない場合:-)-その場合、新しいマシンに接続が設定されている古いマシンでpgbouncerを準備できます。古いデータベースを停止し、pgポート（推定5432）をpgbouncerに切り替え、可能であれば接続文字列を後で処理します...
  • または、アプリケーションに新しいデータがそれほど多くないため、最新のバックアップとフォークインサート/アップデートをアプリケーションで両方のマシンに使用できますか？そして、すべてが機能していると確信しているときにクライアントを切り替えますか？

私はこれらすべてのシナリオの変形を実際に見ました。楽しんでね！私は指を交差させます:-)

2
JosMac

pglogical を使用すると、（ほとんど）ダウンタイムなしのアップグレードが可能になります。少なくともPostgreSQL> = 9.4以降では動作するはずです。

PostgreSQLの双方向レプリケーション のコードに基づく比較的新しいプロジェクト（2016）です。インストールには 2ndQuadrantリポジトリ が必要です。

使用法は説明されています README内 、DBの再起動が必要です（レプリケーション構成を更新する必要があります）が、少なくとも数時間のダウンタイムが発生することはありません。

repmgr とは異なり、pglogicalは1回限りのDBレプリケーション用であり、バイナリWALファイルのコピーよりもはるかに時間がかかります。

まず、コピー（アップグレード）する必要がある各DBの拡張機能を有効にします。

CREATE EXTENSION pglogical;

現在、すべてのコマンドはスーパーユーザー（postgres）として実行する必要があります。 「マスターノード」（provider）の作成から始めます。

SELECT pglogical.create_node(
    node_name := 'provider1',
    dsn := 'Host=providerhost port=5432 dbname=db'
);

スキーマを複製用にマークします。

SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']);

シーケンス複製：

SELECT pglogical.replication_set_add_all_sequences('default', ARRAY['public']);

各テーブルには主キーが必要であることに注意してください。そうしないと、レプリケーションが開始されません。ここの他のバックアップ方法とは異なり、テーブルの一貫性が重要です。

「スタンバイノード」（subscriber）に進みます

SELECT pglogical.create_node(
    node_name := 'subscriber1',
    dsn := 'Host=thishost port=5432 dbname=db'
);

最後にレプリケーションを開始します。

SELECT pglogical.create_subscription(
    subscription_name := 'subscription1',
    provider_dsn := 'Host=providerhost port=5432 dbname=db'
);
1
Tombart