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分のダウンタイムが発生します。したがって、ダウンタイムやデータ損失なしに、本番サーバーまたは大きなマスタースレーブクラスターでデータベースをアップグレードするにはどうすればよいでしょうか。
クラスタリングの魔法がなければ、ダウンタイムは発生しません。
その他の可能性:
pg_upgrade
とともに --link
オプション。このオプションを使用すると、元のDBファイルはコピーされず、新しいディレクトリにハードリンクされるため、プロセスが大幅に高速化されます。これ完全に変更されますソースDBファイルであることに注意してください。pg_dump
と新しいデータベースで復元します。新しいデータベースで同期書き込みを無効にすることで、必要な時間を大幅に短縮できます(fsync = false
新しいPGインスタンスの構成ファイル内)pg_dump
ダンプをネットワーク経由で新しいインスタンスにロードします。完了したら、ポートを交換して新しいインスタンスを使用します。あなたはすでにそれを解決したと思いますので、おそらく同様の問題を持つ他の人のために。
バージョン8.4から最新の9.6までのpostgresqlでの作業の数年後、私はこれらの場合にお勧めします-「アップグレード」しないでください。使用可能なOSの最新バージョン(非常に重要-多くの問題を回避する)と最新のpgバージョンと重複データを使用して、新しいマシンまたは新しいクラウドインスタンスを作成できる場合。
データを複製する方法は、アプリケーション、PostgreSQLのバージョン、および周囲の環境によって異なります。データベース〜10 GBはそれほど大きくないため、適しています。私は400 GBを超えるdbsで作業しているので、ここで多数の問題を想像してください...
私はこれらすべてのシナリオの変形を実際に見ました。楽しんでね!私は指を交差させます:-)
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'
);