ストリーミングレプリケーション ~ 仕組み、構成のポイント ~
PostgreSQLインサイド

データベースでの「レプリケーション」とは、データベースのレプリカ(複製)を作成することです。レプリケーションにより、障害が発生しても継続して稼働でき、可用性の高いシステムを構築することができます。また、複製されたデータベースを活用し、参照系のSQLを処理させることで、システム全体で、より多くの処理をすることができます。遠隔地にデータベースを複製することで、災害対策にも利用できます。
PostgreSQLのレプリケーションには、データベースクラスタを一括して複製する「ストリーミングレプリケーション(物理レプリケーション)」と、テーブル単位やデータベース単位に複製する「ロジカルレプリケーション(論理レプリケーション)」などがあります。
ここでは、データベースクラスタを一括して複製する「ストリーミングレプリケーション」の仕組みと構成のポイントについて説明します。
なお、本資料では、PostgreSQL 11で設定可能なパラメーターを使用して説明しています。各パラメーターのデフォルト値は、PostgreSQL 11でのデフォルト値を記載しています。

ポイント

PostgreSQL 12では、設定ファイルのrecovery.confに指定するパラメーターが、postgresql.confに統合されました。PostgreSQL 12を使用する場合、recovery.confが存在するとPostgreSQLサーバが起動しないなどの仕様変更があります。本資料のrecovery.confに関する記事は、別途仕様を確認してください。仕様の詳細については、“PostgreSQL Documentation”の“Release Notes”の“Migration to Version 12”を参照してください。

1. ストリーミングレプリケーションとは

PostgreSQLの標準機能であるストリーミングレプリケーションは、プライマリサーバの更新情報を、リアルタイムでスタンバイサーバに転送することで、プライマリサーバとスタンバイサーバのデータベースを同じ状態に保つことができます。
ストリーミングレプリケーションを利用することで、以下のような運用を行うことができます。

フェイルオーバ プライマリサーバに障害が発生してもスタンバイサーバで運用を引き継ぐことができます。
参照負荷分散 参照系のSQL処理を複数のサーバに分散できます。

参考

スタンバイサーバで参照系のSQL処理を実行することで、参照処理の負荷を分散させることができます。ただし、PostgreSQLにクエリやサーバ負荷を考慮した振り分け機能は存在しません。周辺OSSであるPgpool-IIの「負荷分散機能」を利用することによって、参照クエリを各PostgreSQLに効率的に振り分けられるようになり、負荷が軽減できます。

2. ストリーミングレプリケーションの仕組み

ストリーミングレプリケーションの仕組みを理解するために、何を転送するのか、どのように転送するのかを、詳しく説明します。

2.1 何を転送するのか(WAL:Write-Ahead Log)

PostgreSQLは、クラッシュリカバリやロールバックに備え、プライマリサーバの更新情報をトランザクションログ(以降、WALと略します)として保存します。ストリーミングレプリケーションは、リアルタイムにこのWALをスタンバイサーバへ転送し、スタンバイサーバでそのWALを適用する仕組みで動いています。

2.2 どのように転送するのか(wal sender / wal receiverプロセス)

プライマリサーバとスタンバイサーバでのWALのやりとりは、プライマリサーバ側の「wal senderプロセス」と、スタンバイサーバ側の「wal receiverプロセス」で行います。postgresql.conf、pg_hba.conf、recovery.confのパラメーターを設定することにより、これらのプロセスが起動されます。プライマリサーバ/スタンバイサーバで、設定するファイルやパラメーターが異なるので、注意してください。設定するパラメーターについては、本ページ内の「【付録】」を参照してください。

3. 構成

ストリーミングレプリケーションで構築可能な構成、および同期レプリケーションと非同期レプリケーションについて説明します。

3.1 「マルチスタンバイ構成」 と 「カスケード構成」

ストリーミングレプリケーションは、「1対N」の構成で構築することができます。プライマリサーバは1台のみですが、スタンバイサーバは複数台用意することができます。プライマリサーバから全スタンバイサーバにつなぐ(WALを転送する)構成を、「マルチスタンバイ構成」と呼びます。スタンバイサーバにスタンバイサーバをつなぐ(WALを転送する)「カスケード構成」も構築することができます。

3.2 「同期レプリケーション」 と 「非同期レプリケーション」

ストリーミングレプリケーションは、スタンバイサーバごとに「同期レプリケーション」とするのか、「非同期レプリケーション」とするのか、選択することができます。ここでは、同期レプリケーションと非同期レプリケーションの特徴と、設定時のポイントについて説明します。

3.2.1 同期レプリケーションと非同期レプリケーションの特徴について

同期レプリケーションと非同期レプリケーションの違いは、スタンバイサーバからの応答を待ってからプライマリサーバの処理を完了するかしないかです。以下にそれぞれの特徴を示します。SQL処理のレスポンス時間や高可用性の確保に影響するため、運用にあわせて選択してください。

  • 同期レプリケーション
    • スタンバイサーバからの応答を待ってからプライマリサーバは処理を完了します。そのため、レスポンス時間に転送時間が含まれます。
    • スタンバイサーバへのWAL転送の遅延がないため、スタンバイサーバのデータの最新性(信頼性)が向上します。
    • フェイルオーバおよび参照負荷分散の運用に向いています。
  • 非同期レプリケーション(デフォルト)
    • スタンバイサーバからの応答を待たずにプライマリサーバの処理を完了します。そのため、ストリーミングレプリケーションを利用しない場合と同等程度のレスポンスです。
    • スタンバイサーバへのWAL転送および適用(データ更新)が非同期で行われるため、プライマリサーバで更新された結果がスタンバイサーバで即座に参照できない(データの状態が古い)場合があります。そのため、フェイルオーバのタイミング次第で、データが損失する可能性があります。
    • 遠隔地へのレプリケーション(災害対策システム)に向いています。

3.2.2 同期/非同期の設定のポイント

同期 / 非同期の設定、および、同期レベルの設定は、postgresql.confのパラメーターで行います。それぞれの設定方法について説明します。

同期 / 非同期の設定(synchronous_standby_names)

同期の設定は、プライマリサーバのpostgresql.confのsynchronous_standby_namesパラメーターで行います。スタンバイサーバが複数ある場合は、同期する対象サーバ、COMMIT待ちの優先順などを柔軟に指定できます。このパラメーターで指定されないスタンバイは非同期になります。

設定値の例 概要
'FIRST 2 (s1,s2,s3)' 同期レプリケーションを行うスタンバイサーバのリストを指定します。「FIRST n(リスト)」や「ANY n(リスト)」のように、リスト中のサーバから同期スタンバイを選ぶ方法も指定できます。スタンバイサーバが、s1、s2、s3、s4と稼働していた場合、左記例のように指定すると、s1とs2が同期レプリケーションとなります。この2つのスタンバイサーバの完了を待ってから、プライマリサーバはCOMMITします。s3は、s1またはs2が故障した場合、同期レプリケーションとなります。s4は、非同期レプリケーションとなります。


図:「synchronous_standby_names = 'FIRST 2 (s1,s2,s3)'」設定している場合

ポイント

synchronous_standby_namesパラメーターに設定する名前と、スタンバイサーバのrecovery.confのprimary_conninfoパラメーターのapplication_nameに設定する名前は、一致させてください。

同期レベルの設定(synchronous_commit)

スタンバイサーバの同期レベルの設定は、プライマリサーバのpostgresql.confのsynchronous_commitパラメーターで行います。設定できる値と、それぞれの概要について説明します。表中の「保証する範囲」における丸付き数字の番号は表直下の図中の番号を意味しています。

同期レベル 設定値 概要 保証する範囲
完全同期 remote_apply スタンバイサーバでのWALの適用(データ更新)が終わり、スタンバイサーバ上での参照が可能になってからCOMMITの応答を返します。データの同期が完全に保証されているため、データの最新性を求める参照業務を負荷分散する場合に適しています。 ①から⑨
同期 on(デフォルト) スタンバイサーバでのWALの書き込みが終わってからCOMMITの応答を返します。性能と信頼性のバランスが一番取れています。 ①から⑥
準同期 remote_write スタンバイサーバへのWALの転送が終わってからCOMMITの応答を返します。 ①から⑤
非同期 local プライマリサーバのWALの書き込みが終わってからCOMMITの応答を返します。 ①から②
非同期 off プライマリサーバのWALの書き込みが終わるのを待たずにCOMMITの応答を返します。本パラメーターの設定はお勧めできません。

PostgreSQLのストリーミングレプリケーションの仕組みと構成のポイントについて解説しました。ストリーミングレプリケーションの運用をするための機能のポイントについては、「ストリーミングレプリケーション ~ 運用のための機能 ~」を参照してください。

【付録】

ストリーミングレプリケーション機能を利用する場合に必要なパラメーターについて説明します。ここでは、同期レプリケーションおよびWALをアーカイブする場合を例にしています。

プライマリサーバ側の設定

ファイル名 パラメーター 概要
postgresql.conf listen_addresses 利用可能なすべてのIPインターフェースに対応する「'*'」を設定します。
wal_level 「replica(デフォルト)」を設定します。
max_wal_senders 「スタンバイサーバの数+1」を指定します。ただし、max_connectionsを超える値は設定できません。
max_connections データベースサーバに同時接続する最大数を設定します。max_wal_sendersより大きな値を設定します。
wal_keep_segments pg_walディレクトリに保持しておくファイルセグメント数の最小値を設定します。アーカイブしない場合は、少し増やした値を設定します。
wal_sender_timeout wal receiverプロセスが異常な状態になったと判断する時間を設定します。
synchronous_standby_names 同期レプリケーションをするスタンバイサーバを設定します。非同期レプリケーションの場合は設定不要です。
例:'s1'
synchronous_commit スタンバイサーバの同期レベルを設定します。データの最新性を求める場合は「remote_apply」を、性能と信頼性を求める場合は「on」を設定します。
archive_mode 「on」を設定します。
archive_command WALをアーカイブする際のコマンドを設定します。
例:'cp %p /mnt/server/archivedir/%f'
pg_hba.conf DATABASE列に「replication」を設定します。
例:host replication postgres スタンバイサーバのアドレス password

スタンバイサーバ側の設定

ファイル名 パラメーター 概要
postgresql.conf hot_standby 「on(デフォルト)」を設定します。
wal_receiver_timeout wal senderプロセスが異常な状態になったと判断する時間を設定します。
recovery.conf standby_mode 「on」を設定します。
primary_conninfo プライマリサーバへの接続情報を設定します。
application_nameと、プライマリサーバのpostgresql.confのsynchronous_standby_namesには、同じ名前を設定します。
例:'host=プライマリサーバのアドレス port=5432 user=postgres password=pass application_name=s1'
restore_command WALアーカイブを取得するコマンドを設定します。
例:'scp [プライマリサーバのアドレス]:/mnt/server/archivedir/%f %p'

ポイント

障害時に、スタンバイサーバをプライマリサーバにする場合に備え、プライマリサーバに設定したパラメーターは、スタンバイサーバでも事前に設定しておくことを推奨します。

2020年2月14日更新

本コンテンツに関するお問い合わせ

お電話でのお問い合わせ

Webでのお問い合わせ

当社はセキュリティ保護の観点からSSL技術を使用しております。

ページの先頭へ