ビジネス継続性のためのPostgreSQLの構成

データベースのビジネス継続性

データベースの事業継続性とは、災害時にもデータベースを継続的に運用する必要があることを意味します。災害時でも常に本番データベースをアプリケーションで使用できるようにすることが不可欠です。そうしないと、コストのかかる取引になる可能性があります。 DBA、アーキテクトは、データベース環境が災害に耐えることができ、災害復旧SLAに準拠していることを確認する必要があります。災害がデータベースの可用性に影響を与えないようにするには、データベースをビジネス継続性のために構成する必要があります。

ビジネス継続性のためのデータベースの構成には、多くの設計、計画、設計、およびテストが含まれます。データベースの効果的なディザスタリカバリ戦略を設計および実装する際には、インフラストラクチャの設計を含むデータセンターやその地理的領域などの多くの要素が考慮されます。これは、「ビジネスの継続性=災害時の停止を回避する」という事実を説明しています。」。

本番データベースが災害に耐えられるようにするには、ディザスタリカバリ（DR）サイトを構成する必要があります。本番サイトとDRサイトは、地理的に離れた2つのデータセンターの一部である必要があります。つまり、本番データベースで発生するデータ変更がトランザクションログを介してスタンバイデータベースに即座に同期されるように、本番データベースごとにDRサイトでスタンバイデータベースを構成する必要があります。これは、PostgreSQLの「ストリーミングレプリケーション」機能によって実現できます。

災害が本番（またはプライマリ）データベースに影響を与えた場合、何が必要ですか？

本番（プライマリ）データベースがクラッシュまたは応答しなくなった場合、スタンバイデータベースをプライマリにプロモートし、アプリケーションを新しくプロモートされたスタンバイ（新しいプライマリ）データベースにポイントする必要があります。これらはすべて、指定された停止SLA内で自動的に実行されます。このプロセスはフェイルオーバーと呼ばれます。

高可用性のためのPostgreSQLの構成

上記のように、PostgreSQLがディザスタリカバリに準拠していることを確認するには、最初にストリーミングレプリケーション（マスター+スタンバイデータベース）と自動スタンバイプロモーション/フェイルオーバー機能を使用して構成する必要があります。最初にストリーミングレプリケーションを構成し、次に「フェイルオーバー」プロセスを構成する方法を見てみましょう。

スタンバイデータベースの構成（ストリーミングレプリケーション）

ストリーミングレプリケーションはPostgreSQLの組み込み機能であり、データがWALレコードを介してプライマリデータベースからスタンバイデータベースにレプリケートされ、非同期レプリケーションと同期レプリケーションの両方の方法をサポートします。この複製方法は非常に信頼性が高く、リアルタイムで高性能な複製を必要とする環境に適しています。

ストリーミングスタンバイの設定は非常に簡単です。最初のステップは、プライマリデータベースの構成が次のとおりであることを確認することです。

プライマリデータベースの必須構成

プライマリデータベースのpostgresql.confで次のパラメータが設定されていることを確認してください。次の変更を行うには、データベースを再起動する必要があります。

wal_level=logical

wal_levelパラメーターは、レプリケーションに必要な情報がWALファイルに書き込まれるようにします。

max_wal_senders=1 (or any number more than 0)

WALレコードは、ウォルマートプロセスによってプライマリデータベースからスタンバイデータベースに送信されます。したがって、上記のパラメーターは最小1に構成する必要があります。複数のWalセンダーが必要な場合は、1を超える値が必要です。

WALアーカイブを有効にする

ストリーミングレプリケーションをWALアーカイブに強く依存することはありません。ただし、スタンバイが遅れ、必要なWALファイルがpg_xlog（またはpg_wal）ディレクトリから削除された場合、スタンバイをプライマリと同期させるためにアーカイブファイルが必要になるため、WALアーカイブを設定することを強くお勧めします。そうでない場合は、スタンバイを最初から再構築する必要があります。

archive_mode=on
archive_command=<archive location>

プライマリデータベースは、スタンバイからの接続を受け入れるように構成する必要があります。

以下の構成がpg_hba.confにある必要があります

host    replication     postgres        <standby-database-host-ip>/32            trust

次に、プライマリデータベースのバックアップを取り、DRサイトで同じものを復元します。復元が完了したら、以下の内容でデータディレクトリにrecovery.confファイルを作成します。

standby_mode=’on’
primary_conninfo=’host=<master-database-host-ip>, port=<master-database-port>, user=<replication-user>’
restore_command=’cp /database/wal_restore/%f %p’
trigger_file=’/database/promote_trigfile’
recovery_target_timeline=’latest’

ここで、スタンバイデータベースを起動します。ストリーミングレプリケーションを有効にする必要があります。スタンバイデータベースのpostgresqlログファイルにある以下のメッセージは、ストリーミングレプリケーションが正常に機能していることを確認します。

2018-01-13 00:22:44 AEDT [4432]: [1] user=,db=,app=,client= LOG:  started streaming WAL from primary at 127/CD000000 on timeline 1
2018-01-13 00:22:44 AEDT [4268]: [5] user=,db=,app=,client= LOG:  redo starts at 127/CD380170

これで、完全に機能するストリーミングレプリケーションが実施されたと結論付けられます。 repmgrをインストール/構成する次のステップ。その前に、フェイルオーバープロセスについて理解しましょう。

今日のホワイトペーパーをダウンロードするClusterControlを使用したPostgreSQLの管理と自動化PostgreSQLの導入、監視、管理、スケーリングを行うために知っておくべきことについて学ぶホワイトペーパーをダウンロードする

フェイルオーバーとは何ですか？

フェイルオーバーは、災害のためにプライマリデータベースが完全に使用できなくなったときに発生します。フェイルオーバープロセス中に、スタンバイデータベースは新しいプライマリデータベースに昇格し、アプリケーションがビジネスオペレーションを継続できるようにします。

自動フェイルオーバー

効果的なビジネス継続性を確保するには、フェイルオーバープロセス全体を自動的に実行する必要があります。これは、一部のミドルウェアツールでのみ実現できます。全体的なアイデアは、DBA、開発者の手動介入を回避することです。

自動フェイルオーバーの実行に役立つそのようなツールの1つに、「repmgr」があります。

repmgrとその機能を見てみましょう。

Repmgr

Repmgrは、第2象限によって開発されたオープンソースツールです。このツールは、災害発生時の自動フェイルオーバーアクティビティの実行を含むPostgreSQLレプリケーションの構築と監視など、さまざまなデータベース管理アクティビティの実行に役立ち、スイッチオーバー操作の実行にも役立ちます。

Repmgrはインストールが簡単なツールであり、構成も複雑ではありません。最初にインストールを見てみましょう：

repmgrのインストール

ここからツールをダウンロードします。

tarballのtarを解除し、以下に示すようにインストールを実行します。

CentOS 7ホストにrepmgr-4.2.0をインストールし、PostgreSQL-11.1に対してrepmgrをインストールしました。インストールする前に、PostgreSQLのbinディレクトリが$ PATHの一部であり、PostgreSQLのlibディレクトリが$LD_LIBRARY_PATHの一部であることを確認してください。 repmgrがPostgreSQL-11.1に対してインストールされていることを理解するために、以下に「makeinstall」の出力を表示しています。

[[email protected] repmgr-4.2.0]# ./configure --prefix=/opt/repmgr-4.2
[[email protected] repmgr-4.2.0]# make
[[email protected] repmgr-4.2.0]# make install
Building against PostgreSQL 11
/bin/mkdir -p '/opt/pgsql-11.1/lib'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/bin'
/bin/install -c -m 755  repmgr.so '/opt/pgsql-11.1/lib/repmgr.so'
/bin/install -c -m 644 .//repmgr.control '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 644 .//repmgr--unpackaged--4.0.sql .//repmgr--4.0.sql .//repmgr--4.0--4.1.sql .//repmgr--4.1.sql .//repmgr--4.1--4.2.sql .//repmgr--4.2.sql  '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 755 repmgr repmgrd '/opt/pgsql-11.1/bin/'

自動フェイルオーバー用のrepmgrの構成

「repmgr」の構成を検討する前に、データベースは、前に見たストリーミングレプリケーションで構成する必要があります。まず、両方のデータベース（プライマリとスタンバイ）をpostgresql.confの次のパラメーターで構成する必要があります：

Primary

[[email protected] log]$ grep "shared_preload" /data/pgdata11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

Standby

[[email protected] log]$ grep "shared_preload" /data/pgdata-standby11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

上記のパラメータは、バックグラウンドで継続的に実行され、ストリーミングレプリケーションを監視する「repmgrd」デーモンを有効にするためのものです。このパラメーターがないと、自動フェイルオーバーを実行できません。このパラメーターを変更するには、データベースを再起動する必要があります。
次に、両方のデータベースのrepmgr構成ファイル（たとえば、repmgr.confという名前）を作成します。プライマリデータベースには、次の内容の構成ファイルが必要です。

node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'

ファイルをデータディレクトリに配置します。この場合は「/data/pgdata11」です。

スタンバイデータベース構成ファイルには、次の内容が含まれている必要があります。

node_id=2
node_name=node2
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2'
data_directory='/data/pgdata-standby11'

failover=automatic
promote_command='repmgr standby promote -f /data/pgdata-standby11/repmgr.conf'
follow_command='repmgr standby follow -f /data/pgdata-standby11/repmgr.conf --upstream-node-id=%n'

monitoring_history=yes
monitor_interval_secs=5

log_file='/data/pgdata-standby11/repmgr_logs/repmgr.log'
log_status_interval=5
log_level=DEBUG

promote_check_timeout=5
promote_check_interval=1

master_response_timeout=5
reconnect_attempts=5
reconnect_interval=10

両方のデータベースをrepmgrに登録する必要があります。
プライマリデータベースを登録する

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata11/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registered

スタンバイデータベースの登録

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf standby register --upstream-node-id=1
INFO: connecting to local node "node2" (ID: 2)
INFO: connecting to primary database
INFO: standby registration complete
NOTICE: standby node "node2" (id: 2) successfully registered

以下のコマンドを実行して、repmgrロギングが機能していることを確認します。

[[email protected] ~]$ repmgrd -f /data/pgdata-standby11/repmgr.conf --verbose --monitoring-history
[2019-02-16 16:31:26] [NOTICE] using provided configuration file "/data/pgdata-standby11/repmgr.conf"
[2019-02-16 16:31:26] [WARNING] master_response_timeout/5: unknown name/value pair provided; ignoring
[2019-02-16 16:31:26] [NOTICE] redirecting logging output to "/data/pgdata-standby11/repmgr_logs/repmgr.log"

ご覧いただける場合は、log_levelをDEBUGに設定して、スタンバイのrepmgr.confファイルに詳細なログを生成しました。ログでレプリケーションステータスを確認します。
repmgrを使用してレプリケーションが期待どおりに機能しているかどうかを確認します：

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf cluster show
 ID | Name  | Role    | Status    | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-------------------------------------------------------------------------------
 1  | node1 | primary | * running |          | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2
 2  | node2 | standby |   running | node1    | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2

上記のメッセージは、レプリケーションが正常に実行されていることを確認します。

これで、プライマリデータベースをシャットダウンすると、repmgrdデーモンがプライマリデータベースの障害を検出し、スタンバイデータベースをプロモートする必要があります。それが発生するかどうかを見てみましょう-プライマリデータベースが停止しています：

[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stopped

スタンバイデータベースは自動的にプロモートする必要があります。 repmgrログにも同じことが表示されます：

fallback_application_name=repmgr is 2
[2019-02-14 17:09:23] [WARNING] unable to reconnect to node 1 after 5 attempts
[2019-02-14 17:09:23] [DEBUG] is_server_available(): ping status for host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2 is 0
[2019-02-14 17:09:23] [DEBUG] do_election(): electoral term is 1
[2019-02-14 17:09:23] [DEBUG] get_active_sibling_node_records():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name     FROM repmgr.nodes n    WHERE n.upstream_node_id = 1      AND n.node_id != 2      AND n.active IS TRUE ORDER BY n.node_id
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - closing open connections
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - unlinking
[2019-02-14 17:09:23] [DEBUG] do_election(): primary location is "default", standby location is "default"
[2019-02-14 17:09:23] [DEBUG] no other nodes - we win by default
[2019-02-14 17:09:23] [DEBUG] election result: WON
[2019-02-14 17:09:23] [NOTICE] this node is the only available candidate and will now promote itself
[2019-02-14 17:09:23] [DEBUG] get_node_record():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name   FROM repmgr.nodes n  WHERE n.node_id = 1
[2019-02-14 17:09:23] [INFO] promote_command is:
  "repmgr standby promote -f /data/pgdata-standby11/repmgr.conf"
WARNING: master_response_timeout/5: unknown name/value pair provided; ignoring
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl  -w -D '/data/pgdata-standby11' promote"
DETAIL: waiting up to 5 seconds (parameter "promote_check_timeout") for promotion to complete
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primary

上記は正確には、repmgrがプライマリデータベースに接続できず、5回の試行が失敗した後、スタンバイが新しいプライマリデータベースにプロモートされることを意味します。以下は、プロモートされたスタンバイ（新しいプライマリ）データベースログを表示するものです。


2019-02-14 17:09:21 AEDT [20789]: [1] user=,db=,app=,client= FATAL:  could not connect to the primary server: could not connect to server: Connection refused
                Is the server running on host "xxx.xxx.xx.xx" and accepting
                TCP/IP connections on port 5432?
2019-02-14 17:09:23 AEDT [20506]: [7] user=,db=,app=,client= LOG:  received promote request
2019-02-14 17:09:23 AEDT [20506]: [8] user=,db=,app=,client= LOG:  redo done at 10F/5A335FF0
2019-02-14 17:09:23 AEDT [20506]: [9] user=,db=,app=,client= LOG:  last completed transaction was at log time 2019-02-14 17:08:38.350695+11
2019-02-14 17:09:23 AEDT [20506]: [10] user=,db=,app=,client= LOG:  selected new timeline ID: 2
2019-02-14 17:09:23 AEDT [20506]: [11] user=,db=,app=,client= LOG:  archive recovery complete
2019-02-14 17:09:24 AEDT [20507]: [1] user=,db=,app=,client= LOG:  checkpoint starting: force
2019-02-14 17:09:24 AEDT [20504]: [7] user=,db=,app=,client= LOG:  database system is ready to accept connections

repmgr構成ファイルの重要なパラメーターについてのみ説明しました。さまざまな要件を満たすために変更できる他の多くのパラメーターがあります。その他の重要なパラメータは、以下に示すように、replication_lag_*パラメータです。

#replication_lag_warning=300            # repmgr node check --replication-lag
#replication_lag_critical=600           #

Repmgrは、スタンバイをプロモートする前に、上記のパラメーターのしきい値をチェックします。レプリケーションの遅延が重要な場合、プロモーションは先に進みません。データ損失につながるラグがあるときにスタンバイが昇格すると、これは本当に良いことです。

アプリケーションは、予想される時間枠内に、新しく昇格したスタンバイに正常に再接続することを確認する必要があります。ロードバランサーには、プライマリデータベースが応答しなくなったときにアプリ接続を迂回させる機能があります。もう1つの方法は、PgPool-IIなどのミドルウェアツールを使用して、すべての接続が正常に迂回されるようにすることです。

高可用性アーキテクチャを本番環境に導入するには、プロセス全体のエンドツーエンドの徹底的なテストを実行する必要があります。私の経験では、この演習をDRDRILLと呼んでいます。つまり、約6か月ごとに、スタンバイが正常にプロモートされ、アプリ接続がプロモートされたスタンバイに正常に再接続されるように、スイッチオーバー操作が実行されます。既存のプライマリが新しいスタンバイになります。スイッチオーバー操作が成功すると、SLAが満たされていることを確認するためにメトリックが削除されます。

スイッチオーバーとは何ですか？

上で説明したように、スイッチオーバーは、プライマリデータベースとスタンバイデータベースの役割が切り替えられる計画されたアクティビティです。つまり、スタンバイがプライマリになり、プライマリがスタンバイになります。 repmgrを使用すると、これを実現できます。以下は、switchoverコマンドが発行されたときにrepmgrが行うことです。

$ repmgr -f /etc/repmgr.conf standby switchover
    NOTICE: executing switchover on node "node2" (ID: 2)
    INFO: searching for primary node
    INFO: checking if node 1 is primary
    INFO: current primary node is 1
    INFO: SSH connection to host "node1" succeeded
    INFO: archive mode is "off"
    INFO: replication lag on this standby is 0 seconds
    NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
    NOTICE: stopping current primary node "node1" (ID: 1)
    NOTICE: issuing CHECKPOINT
    DETAIL: executing server command "pg_ctl -D '/data/pgdata11' -m fast -W stop"
    INFO: checking primary status; 1 of 6 attempts
    NOTICE: current primary has been cleanly shut down at location 0/0501460
    NOTICE: promoting standby to primary
    DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -D '/data/pgdata-standby11' promote"
    server promoting
    NOTICE: STANDBY PROMOTE successful
    DETAIL: server "node2" (ID: 2) was successfully promoted to primary
    INFO: setting node 1's primary to node 2
    NOTICE: starting server using  "pg_ctl -D '/data/pgdata11' restart"
    NOTICE: NODE REJOIN successful
    DETAIL: node 1 is now attached to node 2
    NOTICE: switchover was successful
    DETAIL: node "node2" is now primary
    NOTICE: STANDBY SWITCHOVER is complete

他のrepmgrでできること

Repmgrは、スタンバイデータベースを最初から構築するのに役立ちます
1つのマスターを実行して複数のスタンバイデータベースを構築できます
カスケードスタンバイを構築できます。これは、1つのマスターデータベースに複数のスタンバイを構成するよりも有益だと思います。

プライマリとスタンバイの両方がなくなった場合はどうなりますか？

さて、これはビジネスが複数のスタンバイインスタンスを持つことを考えている状況です。それらがすべてなくなった場合、唯一の解決策はバックアップからデータベースを復元することです。これが、優れたバックアップ戦略が不可欠である理由です。バックアップの信頼性を確保するために、バックアップはテストで復元し、定期的に検証する必要があります。バックアップのインフラストラクチャ設計は、バックアップの復元と回復に時間がかからないようにする必要があります。バックアップの復元と回復のプロセスは、指定されたSLA内で完了する必要があります。バックアップのSLAは、RTO（目標復旧時間）およびRPO（目標復旧時点）の観点から設計されています。つまり、RTO：バックアップの復元と復旧にかかる時間は-SLAとRPOの範囲内である必要があります：復旧が行われた時点までは許容範囲内である必要があります。言い換えると、データ損失の許容範囲であり、一般に企業はデータ損失が0と言います。許容範囲。

結論

PostgreSQLのビジネス継続性は、ミッションクリティカルなデータベース環境にとって重要な要件です。これを達成するには、多くの計画とコストがかかります。
効率的なディザスタリカバリ戦略を確実に実施するには、リソースとインフラストラクチャを最適に活用する必要があります。
コストの観点から、注意が必要な課題が発生する可能性があります
予算が許せば、フェイルオーバーするDRサイトが複数あることを確認してください
バックアップを復元する場合は、適切なバックアップ戦略が実施されていることを確認してください。