Database Support Blog

Database Support Blog>レプリケーションスロットを使用する際の4つの注意点

  • PostgreSQL
  • EDB Postgres
2018.12.12

レプリケーションスロットを使用する際の4つの注意点

レプリケーションスロットを使用する際の4つの注意点

これは PostgreSQL Advent Calendar 2018 の12日目の記事です。

以前、 【SR+HS環境の落とし穴】スタンバイのリカバリに必要なWALが上書きされる障害の予防策 および pg_basebackup/pg_receivexlog実行中にWALが上書きされる障害の予防策 の記事でレプリケーションスロットの紹介をしました。今回は、レプリケーションスロットを使用する際の注意点についてご紹介します。


レプリケーションスロットとは

レプリケーションスロットは、PostgreSQL 9.4で追加されたスタンバイへ転送するWALを管理する仕組みです。レプリケーションスロットを利用することで、スタンバイのリカバリに必要なWALをプライマリで保持し続けるように制御できます。

レプリケーションスロットでは、スタンバイのリカバリに必要と判断されたWALのみをpg_xlog/pg_wal配下に保存するため、その他のWAL管理方法( wal_keep_segments の設定やアーカイブ運用)と比べてWAL領域の肥大化を抑制することができます。

なお、レプリケーションスロットの作成方法やさらに詳細な内容については マニュアル もご参考になさってください。


レプリケーションスロットを使用する際の4つの注意点

SR+HS環境でスイッチオーバーをする前にプライマリのレプリケーションスロットを削除する

Streaming Replication + Hot Standby(SR+HS)環境のプライマリにレプリケーションスロットが作成された状態でスイッチオーバーを行う場合、スイッチオーバー前にプライマリ上のすべてのレプリケーションスロットを pg_drop_replication_slot 関数で削除する必要があります。スイッチオーバーを実施しても、新スタンバイ(旧プライマリ)にはレプリケーションスロットの情報が残り続けているためです。

スイッチオーバー前にプライマリのレプリケーションスロットを削除しなければ、新スタンバイ(旧プライマリ)のpg_xlog/pg_wal配下にWALが溜まり続け、ディスクフルにつながります。


スタンバイをプライマリに昇格する際には新プライマリでレプリケーションスロットを作成する

レプリケーションスロットの内容は、 pg_ctl promote コマンドで旧プライマリから新プライマリに引き継がれません。そのため、新プライマリでもレプリケーションスロットを使用する場合は、新プライマリにてレプリケーションスロットを作成する必要があります。

それに伴い、新スタンバイにてpostgresql.confの hot_standby_feedback パラメータをonに設定すること、全てのスタンバイにてrecovery.confの primary_slot_name パラメータに新たに作成したレプリケーションスロット名を設定することも必要になります。


スタンバイを削除する場合はプライマリの当該レプリケーションスロットを削除する

スタンバイの停止後に、そのスタンバイを復帰させる予定がない/スタンバイを削除する場合にはプライマリからレプリケーションスロットを削除する必要があります。スタンバイを停止/削除しても、プライマリにはレプリケーションスロットの情報が残り続けているためです。

プライマリでレプリケーションスロットを削除しなければ、プライマリのpg_xlog/pg_wal配下にWALが溜まり続けたり、VACUUMが効かず不要領域が増えたりすることでディスクフルにつながります。


ベースバックアップの取得はpg_basebackupコマンドを使用する

レプリケーションスロットが存在するプライマリのベースバックアップは、pg_basebackupコマンドで取得することをオススメします。pg_start_backup関数を使用して取得したベースバックアップにはレプリケーションスロットの情報が残ってしまうためです。

そのベースバックアップを基にPostgreSQLを起動した場合も、スタンバイを停止/削除した時と同じ理由でディスクフルにつながる恐れがあります。

なお、上述したプライマリのベースバックアップを取得する際には、WALが上書きされる障害を予防するために、--slotオプションを付けてpg_basebackupコマンドを実行することをオススメします。この詳細は、 pg_basebackup/pg_receivexlog実行中にWALが上書きされる障害の予防策 をご確認ください。


まとめ

今回は、レプリケーションスロットを使用する際の注意点について紹介しました。レプリケーションスロットは、スタンバイへ転送するWALを管理する優れた機能である一方で、スタンバイをプライマリに昇格したり、スタンバイを長期間停止したり削除したりする際に運用上の注意が必要な機能でもあります。

今回ご紹介したレプリケーションスロットを使用する際の注意点を認識した上で、SR+HS環境やpg_basebackupによるバックアップ取得時などでレプリケーションスロットをご利用ください。


執筆者情報

家島 拓也

サービス事業部 サポートセンター

2007年にアシストに入社して以来、ORACLE製品やPostgreSQL・EDB Postgres製品のサポートに従事してきました。このブログではサポート対応で得た知識を元に、お客様がお困りになることが多い問題や各製品の新機能に関する検証結果などを紹介します。


データベースのサポートならアシスト

関連している記事

  • PostgreSQL
  • EDB Postgres
2019.04.16

【PostgreSQL/EPAS11 新機能】autoprewarmでPostgreSQL再起動後の性能劣化を予防しよう

PostgreSQL/EDB Postgres Advanced Server 11にて、PostgreSQL/EPAS停止前の共有バッファの内容を復元する autoprewarm機能が実装されました。

  • PostgreSQL
  • EDB Postgres
2018.10.19

【PostgreSQL/EPAS11 新機能】バックアップと同時にデータ破損チェック!

pg_basebackupにチェックサムの検証機能が付きました。

  • PostgreSQL
  • EDB Postgres
2018.07.26

EPASやPostgreSQLをメジャーバージョンアップする方法(pg_dumpall編)

pg_dumpallを使用してEPASやPostgreSQLをメジャーバージョンアップする方法をご紹介します。

アシストサポートセンターのご紹介

ページの先頭へ戻る