以下の手順でセットアップを行います。
“第2章 フェイルオーバ運用のセットアップ”とほぼ同様ですが、一部異なる手順について記載します。
本節ではレプリケーション元のサーバとしてプライマリサーバという単語を使用しますが、カスケードスタンバイ環境を構築する場合は、プライマリサーバを上流サーバと読み替えてください。
手順 | 作業項目 | 参照先 | |
|---|---|---|---|
運用系 | 待機系 | ||
1 | PRIMECLUSTERとFujitsu Enterprise Postgresのインストール | ||
2 | PRIMECLUSTERの設定 | ||
3 | GDSボリュームの作成(注) | 注) バックアップデータ格納先ディレクトリの作成は必須ではありません。 | |
4 | ファイルシステムの作成(注) | ||
5 | Fujitsu Enterprise Postgresを起動するオペレーティングシステムのユーザーの作成 | ||
6 | ファイルシステムの | ||
7 | データベースクラスタの作成(注) | ||
8 | Fujitsu Enterprise Postgresのデータベースクラスタのリソース情報の登録 | ||
9 | 透過的データ暗号化による格納データの保護設定(注) | ||
10 | ファイルシステムの | ||
11 | クラスタアプリケーションの作成 | ||
12 | アプリケーションの作成 | ||
13 | 動作確認 | “動作確認” | |
注) 一部の設定・操作については待機系ノードでも行う必要があります。詳細については参照先で確認してください。
データベースクラスタの作成
“2.7 データベースクラスタの作成”を参照し、以下を考慮したセットアップを行ってください。
スタンバイサーバのための設定をプライマリサーバに追加
スタンバイサーバのための設定項目を、プライマリサーバで作成したデータベースクラスタの設定ファイルに追加します。
スタンバイサーバからの接続を認証するために、pg_hba.confファイルに以下のエントリーを追加します。
# TYPE DATABASE USER ADDRESS METHOD host replication ユーザー名 スタンバイサーバの運用系のアドレス 認証方式 host replication ユーザー名 スタンバイサーバの待機系のアドレス 認証方式
ユーザー名には、スタンバイサーバから接続するユーザー名を指定します。
スタンバイサーバのアドレスを記載する際に、引継ぎIPアドレスからではなく、それぞれのノードのIPアドレスからの接続を許可するように設定します。
ポイント
スタンバイサーバからインスタンス管理者ユーザーで接続する場合、プライマリサーバへの接続で自動認証を行うためにインスタンス管理者ユーザーのホームディレクトリに、.pgpassファイルを作成してreplicationデータベースに対するパスワードを指定します。これにより、インスタンス管理者ユーザーのOSユーザーとデータベースに登録したユーザーが同一となり、不特定のユーザーによる接続ではないことが検証できます。また、事前に設定したパスワードが認証に用いられて、自動的に接続できます。
注意
trust認証に設定すると、プライマリサーバにログイン可能なすべてのOSユーザーが接続できてしまうため、悪意のあるユーザーがいた場合には、誤ったトランザクションログを送信することで、スタンバイサーバのデータを破壊したり、業務システムをクラッシュさせたりしてしまいます。そのため、ストリーミングレプリケーション運用を行うシステムのセキュリティ要件に応じて、認証方式を決定してください。
なお、認証方式の詳細は、“PostgreSQL Documentation”の“Authentication Methods”を参照してください。
ストリーミングレプリケーションを行うためにpostgresql.confファイルに以下のパラメータを指定します。postgresql.confファイルはスタンバイサーバのインスタンス作成時に複製されます。したがって、スタンバイサーバに複製する前に、必要なパラメータについてプライマリサーバのpostgresql.confに設定します。プライマリサーバのセットアップ時に同内容を設定している場合は追加の設定は不要です。
パラメータ | 指定内容 | 備考 |
|---|---|---|
wal_level | replicaまたはlogical | ロジカルデコーディングも使用する場合にはlogicalを指定します。 |
max_wal_senders | スタンバイサーバ数+ 1 | スタンバイサーバの数(n)＋1を指定してください。 |
hot_standby | on | スタンバイサーバで参照系の業務を行うか否かに関わらず、必ずonに設定してください。PRIMECLUSTERによる監視処理がスタンバイサーバに接続するためです。本設定がoffの場合、PRIMECLUSTERはPostgreSQLが停止したと誤認します。 |
wal_keep_size | WALの保存サイズ(メガバイト) | 本パラメータの設定値を越える遅延が発生した場合、プライマリサーバはスタンバイサーバが今後必要とするWALセグメントを削除する可能性があります。 また、保守作業などでスタンバイサーバを停止させる場合、停止時間を考慮してWALセグメントが削除されない値を設定してください。 WALの保存サイズの見積もりの詳細は、“導入ガイド(サーバ編)”の“トランザクションログの容量の見積り”を参照してください。 |
wal_sender_timeout | タイムアウト時間(ミリ秒) | プライマリサーバ側でのトランザクションログの転送に異常が発生したと判断する時間を指定します。本パラメータを指定することで、スタンバイサーバがフェイルオーバ等で一時的に停止した場合でも、スタンバイサーバへのログ転送を再開することが可能となります。 |
wal_receiver_timeout | タイムアウト時間(ミリ秒) | スタンバイサーバ側でのトランザクションログの受信に異常が発生したと判断する時間を指定します。本パラメータを指定することで、プライマリサーバがフェイルオーバ等で一時的に停止した場合でも、プライマリサーバからのログ受信を再開することが可能となります。 |
ポイント
古いWALセグメントの削除を防ぐために、wal_keep_sizeパラメータではなく、レプリケーションスロットを使用することできます。レプリケーションスロットの詳細は“PostgreSQL Documentation”の“Replication Slots”を参照してください。
データベースクラスタの作成
スタンバイサーバでのデータベースクラスタの作成には、pg_basebackupコマンドを実行してプライマリサーバのインスタンスの複製を作成します。
例)
$ pg_basebackup -D スタンバイサーバのデータ格納先ディレクトリ -X fetch --waldir=トランザクションログ格納先ディレクトリ --progress --verbose -R --dbname='application_name=アプリケーション名' -h プライマリサーバの引継ぎIPアドレス -p プライマリサーバのポート番号
注意
pg_basebackupコマンドには、-Rオプションを指定して実行し、standby.signalファイルを作成してください。standby.signalファイルを作成しない場合、スタンバイサーバとして起動できません。
プライマリサーバへの接続がパスワード認証を必要とする方式の場合、自動で認証が行われるようにしておく必要があります。pg_basebackupコマンドの-Rオプションを指定し、--dbnameオプションにpasswordパラメータを指定すると、pg_basebackupコマンドによりpostgresql.auto.confファイルのprimary_conninfoパラメータにパスワードが設定されて自動的に接続できるようになります。
postgresql.auto.confファイルのprimary_conninfoパラメータにパスワードを設定しない場合は、インスタンス管理者ユーザーのホームディレクトリに.pgpassファイルを作成してreplicationデータベースに対するパスワードを設定してください。
pg_basebackupコマンドの実行中に行われるトランザクションログファイルの収集において、考慮が必要な場合があります。
-Xオプションにfetchを指定してコマンドを実行する場合
トランザクションログをバックアップの最後に収集する動作を指定して本コマンドを実行する場合は、バックアップ中に発生したトランザクションログがプライマリサーバで削除されないようにすることが必要です。そのため、postgresql.confファイルのwal_keep_sizeパラメータには十分な値を考慮して設定してください。
参照
pg_basebackupコマンドの詳細は、“PostgreSQL Documentation”の“Reference”の“pg_basebackup”を参照してください。
standby.signalファイルの詳細については、“PostgreSQL Documentation”の“Hot Standby”を参照してください。
透過的データ暗号化による格納データの保護設定
“2.9 透過的データ暗号化による格納データの保護設定”を参照し、以下を考慮したセットアップを行ってください。
キーストア・ファイルの配置場所
運用系ノードおよび待機系ノードで同じパスのローカルディレクトリを指定してください。
キーストア・ファイルの配布
プライマリサーバの運用系ノードのキーストア・ファイルを、スタンバイサーバの運用系ノードおよび待機系ノードにコピーしてください。
キーストアの自動オープンの有効化
スタンバイサーバの運用系ノードおよび待機系ノードぞれぞれで行ってください。
各ノードで起動、接続、停止の確認を行ってください。
動作確認
“2.13 動作確認”を参照して動作確認を行います。ただし、その前にストリーミングレプリケーションが正しくセットアップされていることを確認します。
以下の手順で行います。
プライマリサーバにおいて、統計情報ビューpg_stat_replicationにより、スタンバイサーバからの接続状態が検索できることを確認します。
例) psqlコマンドを使用した場合の出力例を以下に示します。
postgres=# select * from pg_stat_replication; -[ RECORD 1 ]----+------------------------------ pid | 321621 usesysid | 10 usename | fsep application_name | standby client_addr | 192.0.2.210 client_hostname | client_port | 27500 backend_start | 2022-12-01 19:12:53.145639+09 backend_xmin | state | streaming sent_lsn | 0/3000060 write_lsn | 0/3000060 flush_lsn | 0/3000060 replay_lsn | 0/3000060 write_lag | flush_lag | replay_lag | sync_priority | 0 sync_state | async reply_time | 2022-12-01 19:13:11.194744+09
手順1.の検索結果を確認します。
意図したスタンバイサーバと非同期モードでの接続が確立されていることを確認します。
項目 | 確認内容 |
|---|---|
application_name | スタンバイサーバを示すアプリケーション名であること。 |
client_addr | スタンバイサーバの運用系ノードのIPアドレスであること。 |
state | “streaming”であること。 |
sync_state | “async”であること。 |
注意
ストリーミングレプリケーションの状態はPRIMECLUSTERによる監視対象ではありません。ストリーミングレプリケーションの監視が必要な場合は、本項目を参考に監視プログラムを作成して実行してください。
