ダウンタイムなしでPostgreSQL11をPostgreSQL12にアップグレードする方法

wal_level = logical

archive_mode = on

これらのパラメータは、新しいレプリカを追加する場合、またはPITRバックアップを使用する場合に役立ちます。

パブリッシャーでは、サブスクライバーが接続するユーザーを作成する必要があります：

world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '*****' REPLICATION;

CREATE ROLE

レプリケーション接続に使用されるロールには、REPLICATION属性が必要です。ロールへのアクセスはpg_hba.confで構成する必要があり、LOGIN属性を持っている必要があります。

初期データをコピーできるようにするには、レプリケーション接続に使用されるロールに、公開されたテーブルに対するSELECT権限が必要です。

world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;

GRANT

すべてのテーブルについて、パブリッシャーノードにpub1パブリケーションを作成します：

world=# CREATE PUBLICATION pub1 FOR ALL TABLES;

CREATE PUBLICATION

パブリケーションを作成するユーザーは、データベースでCREATE権限を持っている必要がありますが、すべてのテーブルを自動的に公開するパブリケーションを作成するには、ユーザーはスーパーユーザーである必要があります。

作成されたパブリケーションを確認するために、pg_publicationカタログを使用します。このカタログには、データベースで作成されたすべての出版物に関する情報が含まれています。

world=# SELECT * FROM pg_publication;

-[ RECORD 1 ]+-----

pubname      | pub1

pubowner     | 10

puballtables | t

pubinsert    | t

pubupdate    | t

pubdelete    | t

pubtruncate  | t

列の説明：

• パブ名 ：出版物の名前。
• 公開者 ：出版物の所有者。
• puballtables ：trueの場合、このパブリケーションには、将来作成されるテーブルを含む、データベース内のすべてのテーブルが自動的に含まれます。
• pubinsert ：trueの場合、INSERT操作はパブリケーション内のテーブルに複製されます。
• pubupdate ：trueの場合、UPDATE操作はパブリケーション内のテーブルに複製されます。
• pubdelete ：trueの場合、DELETE操作はパブリケーション内のテーブルに複製されます。
• pubtruncate ：trueの場合、TRUNCATE操作はパブリケーション内のテーブルに複製されます。

スキーマは複製されないため、PostgreSQL 11でバックアップを取り、PostgreSQL 12で復元する必要があります。情報は最初に複製されるため、バックアップはスキーマに対してのみ行われます。転送。

PostgreSQL 11の場合：

$ pg_dumpall -s > schema.sql

PostgreSQL 12の場合：

$ psql -d postgres -f schema.sql

PostgreSQL 12でスキーマを作成したら、サブスクリプションを作成し、host、dbname、user、およびpasswordの値を環境に対応する値に置き換える必要があります。

PostgreSQL 12：

world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.130 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                 | 16422

subname               | sub1

pid                   | 476

relid                 |

received_lsn          | 0/1771668

last_msg_send_time    | 2020-09-29 17:40:34.711411+00

last_msg_receipt_time | 2020-09-29 17:40:34.711533+00

latest_end_lsn        | 0/1771668

latest_end_time       | 2020-09-29 17:40:34.711411+00

列の説明：

• subid ：サブスクリプションのOID。
• サブネーム ：サブスクリプションの名前。
• pid ：サブスクリプションワーカープロセスのプロセスID。
• 安心 ：ワーカーが同期している関係のOID。メインの適用ワーカーの場合はnull。
• received_lsn ：最後に受信したログ先行書き込みの場所。このフィールドの初期値は0です。
• last_msg_send_time ：発信元のWAL送信者から最後に受信したメッセージの送信時刻。
• last_msg_receipt_time ：発信元のWAL送信者から最後に受信したメッセージの受信時刻。
• latest_end_lsn ：発信元のWAL送信者に報告された最後の先行書き込みログの場所。
• latest_end_time ：発信元のWAL送信者に報告された最後の先行書き込みログの場所の時刻。

プライマリノードでのレプリケーションのステータスを確認するには、pg_stat_replicationを使用できます：

world=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid              | 527

usesysid         | 16428

usename          | rep1

application_name | sub1

client_addr      | 10.10.10.131

client_hostname  |

client_port      | 35570

backend_start    | 2020-09-29 17:40:04.404905+00

backend_xmin     |

state            | streaming

sent_lsn         | 0/1771668

write_lsn        | 0/1771668

flush_lsn        | 0/1771668

replay_lsn       | 0/1771668

write_lag        |

flush_lag        |

replay_lag       |

sync_priority    | 0

sync_state       | async

列の説明：

• pid ：WAL送信者プロセスのプロセスID。
• usesysid ：このWAL送信者プロセスにログインしたユーザーのOID。
• 使用名 ：このWAL送信者プロセスにログインしているユーザーの名前。
• application_name ：このWAL送信者に接続されているアプリケーションの名前。
• client_addr ：このWAL送信者に接続されているクライアントのIPアドレス。このフィールドがnullの場合、クライアントがサーバーマシンのUnixソケットを介して接続されていることを示します。
• client_hostname ：client_addrの逆引きDNSルックアップによって報告された、接続されたクライアントのホスト名。このフィールドは、IP接続の場合、およびlog_hostnameが有効になっている場合にのみnull以外になります。
• client_port ：クライアントがこのWAL送信者との通信に使用しているTCPポート番号。Unixソケットが使用されている場合は-1。
• backend_start ：このプロセスが開始された時刻。
• backend_xmin ：hot_standby_feedbackによって報告されたこのスタンバイのxminホライズン。
• 状態 ：現在のWAL送信者の状態。可能な値は、起動、キャッチアップ、ストリーミング、バックアップ、および停止です。
• send_lsn ：この接続で送信された最後の先行書き込みログの場所。
• write_lsn ：このスタンバイサーバーによってディスクに書き込まれた最後の先行書き込みログの場所。
• flush_lsn ：このスタンバイサーバーによってディスクにフラッシュされた最後の先行書き込みログの場所。
• replay_lsn ：このスタンバイサーバー上のデータベースに再生された最後の先行書き込みログの場所。
• write_lag ：最近のWALをローカルでフラッシュしてから、このスタンバイサーバーがWALを書き込んだ（ただし、まだフラッシュまたは適用していない）という通知を受信するまでの経過時間。
• flush_lag ：最近のWALをローカルでフラッシュしてから、このスタンバイサーバーがWALを書き込んでフラッシュした（ただしまだ適用していない）という通知を受信するまでの経過時間。
• replay_lag ：最近のWALをローカルでフラッシュしてから、このスタンバイサーバーが書き込み、フラッシュ、および適用したという通知を受信するまでの経過時間。
• sync_priority ：優先度ベースの同期レプリケーションで同期スタンバイとして選択されるこのスタンバイサーバーの優先度。
• sync_state ：このスタンバイサーバーの同期状態。可能な値は、async、potential、sync、quorumです。

最初の転送がいつ終了したかを確認するには、サブスクライバーのPostgreSQLログを確認します。

2020-09-29 17:40:04.403 UTC [476] LOG:  logical replication apply worker for subscription "sub1" has started

2020-09-29 17:40:04.411 UTC [477] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has started

2020-09-29 17:40:04.422 UTC [478] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has started

2020-09-29 17:40:04.516 UTC [477] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has finished

2020-09-29 17:40:04.522 UTC [479] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has started

2020-09-29 17:40:04.570 UTC [478] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has finished

2020-09-29 17:40:04.676 UTC [479] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has finished

または、pg_subscription_relカタログのsrsubstate変数を確認します。このカタログには、各サブスクリプションで複製された各リレーションの状態が含まれています。

world=# SELECT * FROM pg_subscription_rel;

 srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+-----------

   16422 |   16386 | r          | 0/1771630

   16422 |   16392 | r          | 0/1771630

   16422 |   16399 | r          | 0/1771668

(3 rows)

列の説明：

• srsubid ：サブスクリプションへの参照。
• srrelid ：関係への参照。
• srsubstate ：状態コード：i =初期化、d =データのコピー中、s =同期、r =準備完了（通常のレプリケーション）。
• srsublsn ：sおよびr状態のLSNを終了します。

PostgreSQL 11にいくつかのテストレコードを挿入し、PostgreSQL12にそれらがあることを検証できます。

PostgreSQL 11：

world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5001,'city1','USA','District1',10000);

INSERT 0 1

world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5002,'city2','ITA','District2',20000);

INSERT 0 1

world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5003,'city3','CHN','District3',30000);

INSERT 0 1

PostgreSQL 12：

world=# SELECT * FROM city WHERE id>5000;

  id  | name  | countrycode | district  | population

------+-------+-------------+-----------+------------

 5001 | city1 | USA         | District1 |      10000

 5002 | city2 | ITA         | District2 |      20000

 5003 | city3 | CHN         | District3 |      30000

(3 rows)

この時点で、アプリケーションをPostgreSQL12にポイントする準備が整いました。

このためには、まず、レプリケーションの遅延がないことを確認する必要があります。

プライマリノード：

world=# SELECT  application_name,  pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) lag FROM pg_stat_replication;

-[ RECORD 1 ]----+-----

application_name | sub1

lag              | 0

これで、エンドポイントをアプリケーションまたはロードバランサー（ある場合）から新しいPostgreSQL12サーバーに変更するだけで済みます。

HAProxyのようなロードバランサーがある場合は、次のようにPostgreSQL 11をアクティブとして、PostgreSQL12をバックアップとして使用して構成できます。

つまり、PostgreSQL11で古いプライマリノードをシャットダウンした場合バックアップサーバー（この場合はPostgreSQL 12）は、ユーザー/アプリケーションに対して透過的な方法でトラフィックの受信を開始します。

移行の最後に、PostgreSQL12の新しいプライマリノードのサブスクリプションを削除できます。

world=# DROP SUBSCRIPTION sub1;

NOTICE:  dropped replication slot "sub1" on publisher

DROP SUBSCRIPTION

そして、正しく削除されていることを確認します：

world=# SELECT * FROM pg_subscription_rel;

(0 rows)

world=# SELECT * FROM pg_stat_subscription;

(0 rows)