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 フレキシブルサーバーでレプリケーションを設定します。
レプリカの追加から新規レプリカサーバーを作成します。
レプリカサーバー名とレプリケーション先(リージョン)を指定するだけで、簡単にレプリカサーバーを作成することができます。
レプリケーション後のサーバーリソース設定を確認
レプリケーション設定後に作成されたレプリカサーバーと、プライマリサーバーのリソース設定を確認します。
—広告—
PostgreSQL上でレプリケーションの状態を確認
サーバー接続情報
今回はpgAdmin 4を使用して各サーバーに接続します。
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
- パスワード:プライマリと同じ
- プライマリ(test-postgresql-flexible-server)
pgAdmin 4でサーバーへの接続を設定
各サーバーへの接続を設定します。
※今回は検証用の設定です。通常運用時には、セキュリティ(SSLなど)を考慮した接続設定とします。
PostgreSQLのレプリケーションに関する設定値を確認
PostgreSQLでレプリケーションに関する設定を確認します。
設定されている内容の確認は、PostgreSQLの日本語訳資料を参照しています。
PostgreSQLの設定値を確認 | ||
プライマリ(test-postgresql-flexible-server)でsynchronous_standby_namesを確認します。
|
【SQL文】
|
|
プライマリ(test-postgresql-flexible-server)でtransaction_read_onlyを確認すると、設定値がoffとなっています。 |
【SQL文】
【SQL実行結果】 |
|
レプリカ(test-postgresql-flexible-server-replica)でtransaction_read_onlyを確認します。 |
【SQL文】
【SQL実行結果】 |
テーブルを作成してレプリケーションを確認
プライマリでテーブルを作成し、レプリケーションの動作を確認します。
今回は検証のため、スキーマは指定せず、データベースもpostgresを使用しています。
プライマリでテーブルを作成 | ||
プライマリ(test-postgresql-flexible-server)でreplica_test_tableという名前のテーブルを作成します。
|
【SQL文】
【SQL実行結果】 |
|
レプリカ(test-postgresql-flexible-server-replica)でテーブルが作成されているかを確認します。 |
【SQL文】
【SQL実行結果】 |
|
レプリカ(test-postgresql-flexible-server-replica)でテーブルに値を挿入しようとすると、読み取り専用レプリカのためエラーとなります。 |
【SQL文】
【SQL実行結果】 |
—広告—
レプリカサーバーをプライマリサーバーへ昇格させる手順
レプリカをプライマリへ昇格
Azure Database for PostgreSQL フレキシブルサーバーの場合、レプリケーションの設定から、レプリカをプライマリに昇格させることができます。
昇格操作は、プライマリサーバーまたはレプリカサーバーのどちらからでも実行できます。
プライマリ昇格後にデータベースへ書き込みして確認
プライマリに昇格したtest-postgresql-flexible-server-replicaでSQLを実行し、読み取り専用の状態が解除されていることを確認します。
昇格後後の確認 | ||
プライマリに昇格したtest-postgresql-flexible-server-replicaで、パラメータtransaction_read_onlyを確認します。 |
【SQL文】
【SQL実行結果】 |
|
プライマリに昇格したtest-postgresql-flexible-server-replicaで値を追加します。 |
【SQL文】
【SQL実行結果】 |
最後に
Azure Database for PostgreSQL フレキシブルサーバーのレプリケーション設定について確認しました。
レプリケーションはサーバー名と場所(リージョン)を指定するだけで、非常に簡単に設定することができました。
プライマリへの昇格もボタンひとつで実行でき、レプリケーション設定時と同様に特別なSQLを実行する必要もありませんでした。
引き続き、いろいろ試してみたいと思います。
Azure Database for PostgreSQL フレキシブルサーバーのバックアップ、リストア手順については、こちらで紹介しています。