sql >> データベース >  >> RDS >> PostgreSQL

PostgreSQL13へのアップグレード

    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
    そこでサブスクライバーIPアドレスを使用します。

    次に、サブスクライバー(この場合はPostgreSQL 13サーバー)を次のように構成する必要があります。

    postgresql.conf構成ファイルを編集します:

    listen_addresses = '*'
    max_replication_slots = 4
    max_logical_replication_workers = 4
    max_worker_processes = 8
    このPostgreSQL13はまもなく新しいプライマリノードになるため、後でサービスが新たに再起動しないように、このステップでwal_levelパラメーターとarchive_modeパラメーターを追加することを検討する必要があります。

    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には、要件とダウンタイムの許容範囲に応じて、アップグレードするためのさまざまなオプションがあります。

    使用しているテクノロジーの種類に関係なく、定期的なアップグレードを実行してデータベースサーバーを最新の状態に保つことは、データが失われないようにする必要があるため、必要ですが難しい作業です。またはアップグレード後のデータの不整合。ここでは、詳細でテスト済みの計画が重要です。もちろん、万が一の場合に備えて、ロールバックオプションを含める必要があります。


    1. SQLでGROUPBY句を使用する方法

    2. 外部キーとして列を追加すると、外部キー制約で参照されているERROR列が存在しません

    3. SQLServerの末尾のスペースを含まないLEN関数

    4. PostgreSQLでのPOSITION()のしくみ