PostgreSQL 13の新機能に関する最近のブログで、このバージョンの新機能のいくつかを確認しましたが、ここで、これらすべての機能を利用できるようにアップグレードする方法を見てみましょう。 。
PostgreSQL13へのアップグレード
現在のPostgreSQLバージョンをこの新しいバージョンにアップグレードする場合は、このタスクを実行するための3つの主要なネイティブオプションがあります。
-
Pg_dump / pg_dumpall:これは、データをダンプして、新しいPostgreSQLバージョン。ここでは、データサイズに応じて異なるダウンタイム期間があります。システムを停止するか、プライマリノードで新しいデータを回避し、pg_dumpを実行し、生成されたダンプを新しいデータベースノードに移動して、復元する必要があります。この間、データの不整合を回避するためにプライマリPostgreSQLデータベースに書き込むことはできません。
-
Pg_upgrade:PostgreSQLのバージョンをインプレースでアップグレードするためのPostgreSQLツールです。実稼働環境では危険である可能性があるため、その場合はこの方法をお勧めしません。この方法を使用すると、ダウンタイムも発生しますが、おそらく以前のpg_dump方法を使用した場合よりも大幅に少なくなります。
-
論理レプリケーション:PostgreSQL 10以降、このレプリケーション方法を使用して、メジャーバージョンのアップグレードを実行できます。ゼロ(またはほぼゼロ)のダウンタイム。このようにして、最新のPostgreSQLバージョンでスタンバイノードを追加できます。レプリケーションが最新の場合は、フェイルオーバープロセスを実行して、新しいPostgreSQLノードを昇格させることができます。
では、これらのメソッドを1つずつ見ていきましょう。
pg_dump/pg_dumpallの使用
ダウンタイムが問題にならない場合は、この方法で簡単にアップグレードできます。
ダンプを作成するには、次のコマンドを実行できます:
$ pg_dumpall > dump_pg12.out
または、単一のデータベースのダンプを作成するには:
$ pg_dump world > dump_world_pg12.out
次に、このダンプを新しいPostgreSQLバージョンのサーバーにコピーして復元できます。
$ psql -f dump_pg12.out postgres
このプロセス中は、アプリケーションを停止するか、データベースへの書き込みを回避する必要があることに注意してください。そうしないと、データの不整合やデータの損失が発生する可能性があります。
pg_upgradeの使用
まず、サーバーに新しいバージョンと古いバージョンの両方のPostgreSQLをインストールする必要があります。
$ rpm -qa |grep postgres
postgresql13-contrib-13.3-2PGDG.rhel8.x86_64
postgresql13-server-13.3-2PGDG.rhel8.x86_64
postgresql13-libs-13.3-2PGDG.rhel8.x86_64
postgresql13-13.3-2PGDG.rhel8.x86_64
postgresql12-libs-12.7-2PGDG.rhel8.x86_64
postgresql12-server-12.7-2PGDG.rhel8.x86_64
postgresql12-12.7-2PGDG.rhel8.x86_64
postgresql12-contrib-12.7-2PGDG.rhel8.x86_64
次に、-cフラグを追加することで、アップグレードをテストするためにpg_upgradeを実行できます。
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data -c
Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
*Clusters are compatible*
-
-b:古いPostgreSQL実行可能ディレクトリ
-
-B:新しいPostgreSQL実行可能ディレクトリ
-
-d:古いデータベースクラスター構成ディレクトリ
-
-D:新しいデータベースクラスター構成ディレクトリ
-
-c:クラスターのみをチェックします。データは変更されません
すべてが正常に見える場合は、-cフラグなしで同じコマンドを実行すると、PostgreSQLサーバーがアップグレードされます。このためには、最初に現在のバージョンを停止して、前述のコマンドを実行する必要があります。
$ systemctl stop postgresql-12
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data
...
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so, once you start the new server, consider running:
./analyze_new_cluster.sh
Running this script will delete the old cluster's data files:
./delete_old_cluster.sh
メッセージが示すように、完了すると、これらのスクリプトを使用して、新しいPostgreSQLサーバーを分析し、安全なときに古いサーバーを削除できます。
論理レプリケーションは、レプリケーションIDに基づいて、データオブジェクトとその変更をレプリケートする方法です。これは、1つ以上のサブスクライバーがパブリッシャーノード上の1つ以上のパブリケーションをサブスクライブするパブリッシュアンドサブスクライブモードに基づいています。
これに基づいて、パブリッシャー(この場合はPostgreSQL 12サーバー)を次のように構成しましょう。
postgresql.conf構成ファイルを編集します:
listen_addresses = '*'
wal_level = logical
max_wal_senders = 8
max_replication_slots = 4
pg_hba.conf構成ファイルを編集します:
# TYPE DATABASE USER ADDRESS METHOD
host all rep1 10.10.10.141/32 md5
次に、サブスクライバー(この場合はPostgreSQL 13サーバー)を次のように構成する必要があります。
postgresql.conf構成ファイルを編集します:
listen_addresses = '*'
max_replication_slots = 4
max_logical_replication_workers = 4
max_worker_processes = 8
wal_level = logical
archive_mode = on
これらのパラメーターは、新しいレプリカを追加する場合、またはPITRバックアップを使用する場合に役立ちます。
これらの変更の一部はサーバーの再起動が必要なため、パブリッシャーとサブスクライバーの両方を再起動します。
これで、パブリッシャーで、サブスクライバーがアクセスするために使用するユーザーを作成する必要があります。レプリケーション接続に使用されるロールにはREPLICATION属性が必要であり、初期データをコピーできるようにするには、公開されたテーブルに対するSELECT権限も必要です。
world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '********' REPLICATION;
CREATE ROLE
world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;
GRANT
すべてのテーブルについて、パブリッシャーノードでpub1パブリケーションを作成しましょう:
world=# CREATE PUBLICATION pub1 FOR ALL TABLES;
CREATE PUBLICATION
スキーマは複製されないため、PostgreSQL 12でバックアップを取り、PostgreSQL 13で復元する必要があります。情報は最初に複製されるため、バックアップはスキーマに対してのみ行われます。転送。
PostgreSQL 12では、次のコマンドを実行します:
$ pg_dumpall -s > schema.sql
PostgreSQL 13では、次のコマンドを実行します:
$ psql -d postgres -f schema.sql
PostgreSQL 13でスキーマを作成したら、サブスクリプションを作成し、host、dbname、user、およびpasswordの値を環境に対応する値に置き換える必要があります。
world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.140 dbname=world user=rep1 password=********' PUBLICATION pub1;
NOTICE: created replication slot "sub1" on publisher
CREATE SUBSCRIPTION
上記はレプリケーションプロセスを開始します。レプリケーションプロセスは、パブリケーション内のテーブルの初期テーブルコンテンツを同期してから、それらのテーブルへの増分変更のレプリケーションを開始します。
作成されたサブスクリプションを確認するには、pg_stat_subscriptionカタログを使用できます。このビューには、メインワーカーのサブスクリプションごとに1つの行(ワーカーが実行されていない場合はnull PID)と、サブスクライブされたテーブルの初期データコピーを処理するワーカーの追加の行が含まれます。
world=# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+------------------------------
subid | 16421
subname | sub1
pid | 464
relid |
received_lsn | 0/23A8490
last_msg_send_time | 2021-07-23 22:42:26.358605+00
last_msg_receipt_time | 2021-07-23 22:42:26.358842+00
latest_end_lsn | 0/23A8490
latest_end_time | 2021-07-23 22:42:26.358605+00
最初の転送がいつ終了したかを確認するには、pg_subscription_relカタログのsrsubstate変数を確認します。このカタログには、各サブスクリプションで複製された各リレーションの状態が含まれています。
world=# SELECT * FROM pg_subscription_rel;
srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+-----------
16421 | 16408 | r | 0/23B1738
16421 | 16411 | r | 0/23B17A8
16421 | 16405 | r | 0/23B17E0
16421 | 16402 | r | 0/23B17E0
(4 rows)
列の説明:
-
srsubid:サブスクリプションへの参照。
-
srrelid:関係への参照。
-
srsubstate:状態コード:i =初期化、d =データのコピー中、s =同期、r =準備完了(通常のレプリケーション)。
-
srsublsn:sおよびr状態のLSNを終了します。
最初の転送が完了すると、アプリケーションを新しいPostgreSQL13サーバーにポイントする準備が整います。
ご覧のとおり、PostgreSQLには、要件とダウンタイムの許容範囲に応じて、アップグレードするためのさまざまなオプションがあります。
使用しているテクノロジーの種類に関係なく、定期的なアップグレードを実行してデータベースサーバーを最新の状態に保つことは、データが失われないようにする必要があるため、必要ですが難しい作業です。またはアップグレード後のデータの不整合。ここでは、詳細でテスト済みの計画が重要です。もちろん、万が一の場合に備えて、ロールバックオプションを含める必要があります。