Azure Database For PostgreSQLフレキシブルサーバーのレプリケーション設定手順

Azure,Database for PostgreSQL

Azure Database for PostgreSQL フレキシブルサーバーのレプリケーション設定手順です。

Azure Database for PostgreSQLのフレキシブルサーバーでは、読み取り専用レプリカがサポートされています。
今回は、Azure Database for PostgreSQL フレキシブルサーバーにおけるレプリケーションの設定、読み取り専用レプリカの動作確認、レプリケーション解除によるプライマリ昇格までの手順について確認します。

※本記事では、Azure Database for PostgreSQL Flexible ServerをAzure Database for PostgreSQL フレキシブルサーバーとして記載しています。

目次 

スポンサーリンク

Azure Database for PostgreSQL フレキシブルサーバーのレプリケーション設定の概要

読み取り専用レプリカをサポート

Azure Database for PostgreSQLのフレキシブルサーバーでは、読み取り専用レプリカがサポートされています。

Azure Database for PostgreSQL – フレキシブル サーバーの読み取りレプリカ

読み取り専用レプリカは、Azureで提供されているレプリケーション機能を利用して作成します。
レプリカは同一リージョン内だけでなく、別リージョンにも作成することが可能です。
複数(最大5つ)のレプリカを作成できます。

読み取りトラフィックの分散や参照系クエリのパフォーマンス向上に利用できます。
一方で、読み取り専用レプリカであるため、プライマリサーバーの書き込み負荷を軽減することはできません。

Compute tierで汎用もしくはメモリ最適化を選択している場合に利用可能

読み取り専用レプリカは、Compute tierで汎用またはメモリ最適化を選択している場合のみ利用可能です。
Compute tierでバースト可能を選択している場合は、読み取り専用レプリカは利用できません。

レプリカもプライマリサーバーと同じだけの課金が発生

読み取り専用レプリカのサーバーにも、プライマリサーバーと同様に、選択したCompute tierやストレージ容量、バックアップ保持期間などに応じて課金されます。
独立したサーバーとして管理されるため、レプリカしているサーバー台数分の課金が発生します。

レプリケーションは非同期

Azure Database for PostgreSQL フレキシブルサーバーのレプリケーションは非同期レプリケーションです。
通常時は、読み取りレプリカはプライマリからほぼリアルタイムで更新されますが、書き込みが集中した場合などにはタイムラグが発生することがあります。

考慮事項(Azure Database for PostgreSQL – フレキシブル サーバーの読み取りレプリカ)

※タイムラグは、数分から数時間に及ぶ場合があると記載されています。大量のデータを一括して書き込む場合やネットワークが遅延しやすい環境などでは、特に注意が必要です。

論理レプリケーションや論理デコードもサポート

PostgreSQLのネイティブ論理レプリケーションや論理デコードもサポートされています。

Azure Database for PostgreSQL – フレキシブル サーバーでの論理レプリケーションと論理デコード

※今回は、Azureのサービスで提供されるレプリケーション機能を利用しています。

プライマリをゾーン冗長している場合は注意

プライマリサーバーでゾーン冗長を有効にしている場合、レプリカ先のリージョンでもゾーン冗長が利用可能である必要があります。
ゾーン冗長に対応していないリージョンを選択すると、レプリケーション設定時にエラーとなります。

Azure Azure リージョン(概要 – Azure Database for PostgreSQL – フレキシブル サーバー)

※記事記載時点では、レプリカサーバー自体はゾーン冗長にできませんでした。
※ゾーン冗長オプションを無効にしてからレプリカサーバーの設定をすることで、ゾーン冗長非対応リージョンにもレプリカを作成できます。

サーバーを停止する場合の順序

プライマリサーバー、レプリカサーバー共に停止できますが、停止順序があります。
停止順序は、必ずプライマリを先に停止し、その後レプリカを停止する必要があります。
起動順序は停止順序と逆になります。レプリカを先に起動し、その後プライマリを起動する必要があります。

考慮事項

Azure Database for PostgreSQL フレキシブルサーバーの起動停止手順については、こちらで紹介しています。

一度設定を解除した後に同じサーバー同士で再レプリケーション設定はできない

レプリカサーバーは、新規にサーバー作成を行います。
既存のサーバーを対象に、後からレプリカ設定を行うことはできません。
一度レプリケーション設定を解除すると、同じサーバー同士で再度レプリケーションを構成することはできません。

新しいレプリカ 

レプリカサーバーを新規に作成する必要があります。

プライマリサーバーとレプリカサーバー間でネットワーク接続できる必要がある

プライマリサーバーとレプリカサーバー間でネットワーク接続ができない場合は、レプリケーションの同期処理に失敗します。
仮想ネットワークやファイアウォール、ネットワークセキュリティグループ(NSG)などの設定を確認する必要があります。

ネットワーク
プライベート ネットワークを使用した Azure リージョンと仮想ネットワーク間のレプリケーション

—広告—

Azure Database for PostgreSQL フレキシブルサーバーのレプリケーション設定手順

レプリケーションで利用したサーバーの構成

別リージョンへのレプリケーションを設定します。
East USに作成したtest-postgresql-flexible-serverをプライマリとし、レプリカをSouth Central USにサーバー名test-postgresql-flexible-server-replicaとして新規作成します。
今回は検証目的なので、ネットワークは、パブリックアクセスを許可する設定としています。

区分 項目 設定値
サーバーの詳細 サーバー名 test-postgresql-flexible-server-replica
場所 South Central US(米国中南部)

レプリカサーバーを追加

プライマリ側のAzure Database for PostgreSQL フレキシブルサーバーでレプリケーションを設定します。
レプリカの追加から新規レプリカサーバーを作成します。
レプリカサーバー名とレプリケーション先(リージョン)を指定するだけで、簡単にレプリカサーバーを作成することができます。

レプリカサーバーを追加

レプリケーションのリソースメニューを選択します。
レプリカの追加を選択します。

レプリカサーバーの作成画面が表示されます。
サーバー名と場所(リージョン)を選択します。
コンピューティング、ストレージ、認証の設定は変更できません。

ネットワーク設定です。
接続方法は変更できません。
プライマリのファイアウォール規則がレプリカにも引き継がれます。

※プライマリがプライベートアクセスの場合、レプリカもプライベートアクセスである必要があります。

プライマリでGeo復元バックアップが有効になっているため、セキュリティ設定は変更できません。
そのまま次に進みます。

確認画面が表示されます。
プライマリサーバー名とレプリカサーバー名を確認し、間違いがなければ作成します。

レプリケーション後のサーバーリソース設定を確認

レプリケーション設定後に作成されたレプリカサーバーと、プライマリサーバーのリソース設定を確認します。

レプリケーションの設定状況を確認

プライマリ(test-postgresql-flexible-server)とレプリカ(test-postgresql-flexible-server-replica)の2つのリソースが確認できます。

プライマリ(test-postgresql-flexible-server)でレプリケーション設定を確認します。
プライマリかレプリカかはロール欄に表示されます。
レプリカ(test-postgresql-flexible-server-replica)が表示されていることも確認できます。

同様に、レプリカ(test-postgresql-flexible-server-replica)側でレプリケーション設定を確認します。
プライマリ(test-postgresql-flexible-server)が表示されていることが確認できます。

レプリカ(test-postgresql-flexible-server-replica)のサーバー設定を確認します。
プライマリと同様のコンピューティングおよびストレージ設定であることが確認できます。

※レプリケーション設定後でもコンピューティングサイズの変更は可能です。

レプリカは高可用性設定を有効にすることができません。

※レプリケーション設定を解除してレプリカをプライマリに昇格させると、高可用性を有効にすることができます。

レプリカではバックアップは取得されません。

※レプリケーション設定を解除してレプリカを昇格させた時点で、初回バックアップが取得されます。

—広告—

PostgreSQL上でレプリケーションの状態を確認

サーバー接続情報

今回はpgAdmin 4を使用して各サーバーに接続します。
pgAdmin 4は公式サイトからダウンロードして利用しています。
今回はWindows版を使用しています。

pgAdmin 4 (Windows)

    • プライマリ(test-postgresql-flexible-server)
      • Hostname/address:test-postgresql-flexible-server.postgres.database.azure.com
      • Username:設定したユーザー名
      • Port:5432
      • パスワード:設定した値
    • レプリカ(test-postgresql-flexible-server-replica)
      • Hostname/address:test-postgresql-flexible-server-replica.postgres.database.azure.com
      • Username:プライマリと同じ
      • Port:5432
      • パスワード:プライマリと同じ

pgAdmin 4でサーバーへの接続を設定

各サーバーへの接続を設定します。

pgAdmin 4でサーバーへの接続を設定

pgAdmin 4を起動します。
Object→Register→Serverと選択します。

接続先のサーバー設定です。
Nameは接続設定名になります。
任意で設定します。

※今回はプライマリをoriginal、レプリカをreplicaとしています。

Connectionのタブで接続設定します。
Hostname/address、Username、Passwordを設定します。
Saveを選択して接続設定を保存します。

※今回は検証用の設定です。通常運用時には、セキュリティ(SSLなど)を考慮した接続設定とします。

PostgreSQLのレプリケーションに関する設定値を確認

PostgreSQLでレプリケーションに関する設定を確認します。
設定されている内容の確認は、PostgreSQLの日本語訳資料を参照しています。

PostgreSQL 14.5文書

PostgreSQLの設定値を確認

プライマリ(test-postgresql-flexible-server)でsynchronous_standby_namesを確認します。
Settingでレプリケーションに関する値を確認できます。

 

【SQL文】

select name,setting from pg_settings where name like 'synchronous_standby_names’;

【SQL実行結果】

プライマリ(test-postgresql-flexible-server)でtransaction_read_onlyを確認すると、設定値がoffとなっています。
読み書き可能な状態であることが分かります。

【SQL文】

select name,setting from pg_settings where name like 'transaction_read_only’;

【SQL実行結果】

レプリカ(test-postgresql-flexible-server-replica)でtransaction_read_onlyを確認します。
設定値がonになっており、読み取り専用の状態であることが確認できます。

【SQL文】

select name,setting from pg_settings where name like 'transaction_read_only’;

【SQL実行結果】

テーブルを作成してレプリケーションを確認

プライマリでテーブルを作成し、レプリケーションの動作を確認します。
今回は検証のため、スキーマは指定せず、データベースもpostgresを使用しています。

プライマリでテーブルを作成

プライマリ(test-postgresql-flexible-server)でreplica_test_tableという名前のテーブルを作成します。
あわせて1件のサンプルレコードを挿入します。

 

【SQL文】

create table replica_test_table (
 id integer,
 name varchar(8)
);
insert into replica_test_table values (1, 'reptest’);
Select * from replica_test_table;

【SQL実行結果】

レプリカ(test-postgresql-flexible-server-replica)でテーブルが作成されているかを確認します。
テーブルおよびレコードが表示されており、レプリケーションが正常に行われていることが分かります。

【SQL文】

Select * from replica_test_table;

【SQL実行結果】

レプリカ(test-postgresql-flexible-server-replica)でテーブルに値を挿入しようとすると、読み取り専用レプリカのためエラーとなります。

【SQL文】

insert into replica_test_table values (2, 'reptest2’);

【SQL実行結果】

—広告—

レプリカサーバーをプライマリサーバーへ昇格させる手順

レプリカをプライマリへ昇格

Azure Database for PostgreSQL フレキシブルサーバーの場合、レプリケーションの設定から、レプリカをプライマリに昇格させることができます。
昇格操作は、プライマリサーバーまたはレプリカサーバーのどちらからでも実行できます。

レプリカを昇格

レプリカ(test-postgresql-flexible-server-replica)でレプリケーションのリソースメニューを選択します。
昇格を選択します。

確認メッセージが表示されます。
同じサーバーを再度レプリカとして設定できないことを確認する旨のメッセージも表示されます。
内容を確認し、チェックボックスにチェックを入れてから、昇格を選択します。

プライマリ(test-postgresql-flexible-server)でレプリケーション設定を確認します。
レプリカが表示されません。

レプリカ(test-postgresql-flexible-server-replica)でも、レプリカが表示されないことを確認できました。

プライマリ昇格後にデータベースへ書き込みして確認

プライマリに昇格したtest-postgresql-flexible-server-replicaでSQLを実行し、読み取り専用の状態が解除されていることを確認します。

昇格後後の確認

プライマリに昇格したtest-postgresql-flexible-server-replicaで、パラメータtransaction_read_onlyを確認します。
値がoffに変わっており、読み書きが可能な状態であることが確認できます。

【SQL文】

select name,setting from pg_settings where name like 'transaction_read_only’;

【SQL実行結果】

プライマリに昇格したtest-postgresql-flexible-server-replicaで値を追加します。
読み取り専用が解除されているため、エラーは発生せず、値が正常に挿入されていることが確認できます。

【SQL文】

insert into replica_test_table values (2, 'reptest2’);
Select * from replica_test_table;

【SQL実行結果】

最後に

Azure Database for PostgreSQL フレキシブルサーバーのレプリケーション設定について確認しました。
レプリケーションはサーバー名と場所(リージョン)を指定するだけで、非常に簡単に設定することができました。
プライマリへの昇格もボタンひとつで実行でき、レプリケーション設定時と同様に特別なSQLを実行する必要もありませんでした。

引き続き、いろいろ試してみたいと思います。

Azure Database for PostgreSQL フレキシブルサーバーのバックアップ、リストア手順については、こちらで紹介しています。

スポンサーリンク