このブログ投稿では、PostgreSQLでストリーミングレプリケーション（SR）を設定するための要点について詳しく説明します。ストリーミングレプリケーションは、PostgreSQLホスティングで高可用性を実現するための基本的な構成要素であり、マスタースレーブ構成を実行することで生成されます。

マスタースレーブの用語

マスター/プライマリサーバー

書き込みを実行できるサーバー。
読み取り/書き込みサーバーとも呼ばれます。

スレーブ/スタンバイサーバー

データがマスターと継続的に同期されているサーバー。
バックアップサーバーまたはレプリカとも呼ばれます。
ウォームスタンバイサーバーは、マスターサーバーに昇格するまで接続できないサーバーです。
対照的に、ホットスタンバイサーバーは接続を受け入れ、読み取り専用クエリを提供できます。この説明の残りの部分では、ホットスタンバイサーバーのみに焦点を当てます。

データはマスターサーバーに書き込まれ、スレーブサーバーに伝播されます。既存のマスターサーバーに問題がある場合は、スレーブサーバーの1つが引き継ぎ、書き込みを続行して、システムの可用性を確保します。

WAL配送ベースのレプリケーション

WALとは何ですか？

WALは先行書き込みロギングの略です。
これは、データベースへのすべての変更がデータファイルに適用/書き込まれる前に書き込まれるログファイルです。
WALは、データベースクラッシュ後のリカバリに使用され、データの整合性を確保します。
WALは、原子性と耐久性を実現するためにデータベースシステムで使用されます。

WALはレプリケーションにどのように使用されますか？

先行書き込みログレコードは、データベースサーバー間でデータの同期を維持するために使用されます。これは2つの方法で実現されます：

ファイルベースのログ配布

WALログファイルは、データの同期を維持するためにマスターサーバーからスタンバイサーバーに送信されます。
マスターはログをスタンバイサーバーストレージに直接コピーすることも、スタンバイサーバーとストレージを共有することもできます。
1つのWALログファイルに最大16MBのデータを含めることができます。
WALファイルは、そのしきい値に達した後にのみ出荷されます。
これにより、レプリケーションが遅延し、マスターがクラッシュしてログがアーカイブされていない場合にデータが失われる可能性が高くなります。

WALレコードのストリーミング

WALレコードチャンクは、データの同期を維持するためにデータベースサーバーによってストリーミングされます。
スタンバイサーバーはマスターに接続してWALチャンクを受信します。
WALレコードは生成時にストリーミングされます。
WALレコードのストリーミングは、WALファイルがいっぱいになるのを待つ必要はありません。
これにより、スタンバイサーバーは、ファイルベースのログ配布で可能な場合よりも最新の状態に保つことができます。
デフォルトでは、同期レプリケーションもサポートしていますが、ストリーミングレプリケーションは非同期です。

どちらの方法にも長所と短所があります。ファイルベースの配送を使用すると、ポイントインタイムリカバリと継続的なアーカイブが可能になり、ストリーミングにより、スタンバイサーバーでのデータの即時可用性が保証されます。ただし、両方の方法を同時に使用するようにPostgreSQLを構成して、メリットを享受することができます。このブログでは、PostgreSQLの高可用性を実現するために、主にストリーミングレプリケーションに焦点を当てています。

高可用性のためにPostgreSQLでストリーミングレプリケーションを設定する方法クリックしてツイート

ストリーミングレプリケーションを設定するには？

PostgreSQLでのストリーミングレプリケーションの設定は非常に簡単です。 PostgreSQLがすでにすべてのサーバーにインストールされていると仮定すると、次の手順に従って開始できます。

マスターノードでの構成

initdbユーティリティを使用してマスターノードでデータベースを初期化します。
以下のコマンドを実行して、レプリケーション権限を持つロール/ユーザーを作成します。コマンドの実行後、\ duを実行してコマンドを確認し、psqlにリストすることができます。
- CREATE USER REPLICATION LOGIN ENCRYPTED PASSWORD’’;

マスターPostgreSQL構成（postgresql.conf）ファイルでストリーミングレプリケーションに関連するプロパティを構成します。

＃可能な値は reply | minimum |logic<です。 / em>
wal_level =スタンバイがマスターと同期しなくなったときにpg_rewind機能に必要なreplica＃
wal_log_hints =on＃は、スタンバイサーバーからの同時接続の最大数を設定します。
max_wal_senders =3
＃以下のパラメータは、スタンバイが消費する前に削除されないように、WALログの最小数の
＃セグメントを保持するようにマスターに指示するために使用されます。
＃各セグメントは16MB
wal_keep_segments =8
＃以下のパラメータは、ノードが
＃スタンバイロールにあるときに、ノードで読み取り専用接続を有効にします。サーバーがマスターとして実行されている場合、これは無視されます。
hot_standby =オン

pg_hba.confファイルにレプリケーションエントリを追加して、サーバー間のレプリケーション接続を許可します。

＃ローカルホストからのレプリケーション接続を許可します。
＃ユーザーによるレプリケーション権限を使用します。
＃TYPE DATABASE USER ADDRESS METHOD
host Replication repl_user IPaddress（CIDR）md5

変更を有効にするには、マスターノードでPostgreSQLサービスを再起動します。

スタンバイノードでの構成

pg_basebackupユーティリティを使用してマスターノードのベースバックアップを作成し、それをスタンバイの開始点として使用します。

＃pg_basebackupユーティリティに使用されるいくつかのオプションの説明
＃-Xオプションは、必要なトランザクションログファイル（WALファイル）を
＃バックアップに含めるために使用されます。ストリームを指定すると、サーバーへの2番目の接続が開かれ、
＃バックアップの実行と同時にトランザクションログのストリーミングが開始されます。
＃-cはチェックポイントオプションです。高速に設定すると、チェックポイントが
＃すぐに作成されます。
＃-Wは、データベースに接続する前に
＃パスワードの入力を求めるプロンプトをpg_basebackupに強制します。
pg_basebackup -D -h -X stream -c fast -U repl_user -W

レプリケーション構成ファイルが存在しない場合は作成します（pg_basebackupで-Rオプションが指定されている場合は自動的に作成されます）：

＃サーバーを次のように起動するかどうかを指定しますスタンバイ。ストリーミングレプリケーションでは、
＃このパラメータをオンに設定する必要があります。
standby_mode =‘on’＃スタンバイサーバーがプライマリ/マスターに接続するために使用される接続文字列を指定します
＃
primary_conninfo =‘host = port = user = password = application_name =” host_name”’＃特定のタイムラインへのリカバリを指定します。デフォルトでは、
＃ベースバックアップが作成されたときと同じタイムラインに沿ってリカバリされます。
＃これを最新に設定すると、アーカイブで見つかった最新のタイムラインにリカバリされます
＃スタンバイサーバーで役立ちます。
restorey_target_timeline =「最新」

スタンバイを開始します。

スタンバイ構成は、すべてのスタンバイサーバーで実行する必要があります。構成が完了してスタンバイが開始されると、マスターに接続してログのストリーミングを開始します。これによりレプリケーションがセットアップされ、SQLステートメント「 SELECT * FROM pg_stat_replication;」を実行して確認できます。「。

デフォルトでは、ストリーミングレプリケーションは非同期です。同期させたい場合は、次のパラメーターを使用して構成できます。

＃num_syncは、トランザクションが応答を待機する必要がある同期スタンバイの数です。
＃standby_nameは、recovery.confのapplication_name値と同じです
＃すべてのスタンバイサーバーを同期と見なす必要がある場合は、値'*'を設定します。
＃特定のスタンバイサーバーのみを考慮する必要がある場合は、
＃スタンバイサーバーのカンマ区切りリストとして指定します。。
＃この目的のスタンバイサーバーの名前は、
＃スタンバイのWALレシーバーのprimary_conninfoで設定されている
＃スタンバイのapplication_name設定です。
synchronous_standby_names =‘num_sync（standby_name [、...]）’

Synchronous_commit 同期レプリケーションの場合はonに設定する必要があり、これがデフォルトです。 PostgreSQLは、同期コミットに非常に柔軟なオプションを提供し、ユーザー/データベースレベルで構成できます。有効な値は次のとおりです。

オフ –トランザクションのコミットは、そのトランザクションレコードが実際にそのノードのWALログファイルにフラッシュされる前でも、クライアントに確認されます。
ローカル –トランザクションのコミットは、そのトランザクションレコードがそのノードのWALログファイルにフラッシュされた後にのみクライアントに確認されます。
Remote_write –トランザクションコミットは、synchronous_standby_namesで指定されたサーバーがトランザクションレコードがディスクキャッシュに書き込まれたことを確認した後でのみクライアントに確認されますが、必ずしもWALログファイルにフラッシュされた後ではありません。
オン –トランザクションのコミットは、synchronous_standby_namesで指定されたサーバーがトランザクションレコードがWALログファイルにフラッシュされたことを確認した後でのみ、クライアントに確認されます。
Remote_apply –トランザクションコミットは、synchronous_standby_namesで指定されたサーバーがトランザクションレコードがWALログファイルにフラッシュされ、データベースに適用されたことを確認した後にのみ、クライアントに確認されます。

同期レプリケーションモードでsynchronous_commitをoffまたはlocalに設定すると、非同期のように機能し、書き込みパフォーマンスを向上させることができます。ただし、これにより、スタンバイサーバーでのデータ損失と読み取り遅延のリスクが高くなります。 remote_applyに設定すると、スタンバイサーバーですぐにデータを利用できるようになりますが、上記のすべてのスタンバイサーバーに適用する必要があるため、書き込みパフォーマンスが低下する可能性があります。

継続的なアーカイブとポイントインタイムリカバリを使用する場合は、アーカイブモードを有効にできます。ストリーミングレプリケーションでは必須ではありませんが、アーカイブモードを有効にすると追加のメリットがあります。アーカイブモードがオンになっていない場合は、レプリケーションスロットを使用する必要があります wal_keep_segmentsを機能または確認する値は負荷に基づいて十分に高く設定されます。

PostgreSQLの高可用性の詳細については、この優れたプレゼンテーションを参照してください。次のブログ投稿では、ストリーミングレプリケーションを使用してPostgreSQLの高可用性を管理するために使用されるツールの世界を紹介します。

PostgreSQLストリーミングレプリケーション入門