Database Support Blog

  • PostgreSQL
  • EDB
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製品のサポートに従事してきました。このブログではサポート対応で得た知識を元に、お客様がお困りになることが多い問題や各製品の新機能に関する検証結果などを紹介します。


■本記事の内容について
 本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • PostgreSQL
  • EDB
2023.10.30

データベースの健康診断! ~ PostgreSQL DB稼働分析体験 ~

35年以上教育事業を展開しているアシストが新たに取り組み始めた「ポスグレ学園」。連載8回目となる今回の記事では、PostgreSQL DB稼働分析ワークショップの主管である保田 公貴にインタービューしました。

  • PostgreSQL
  • EDB
2023.09.27

PostgreSQL DBチューニングガイド作成プロジェクト

35年以上教育事業を展開しているアシストが新たに取り組み始めた「ポスグレ学園」。連載7回目となる今回の記事では、PostgreSQL DBチューニングガイド作成プロジェクトの主管である我妻 千妃呂にインタービューしました。

  • PostgreSQL
  • EDB
2023.08.21

AWSへのシフトにはPostgreSQLスキルが必要! Amazon RDS for PostgreSQL DB移行体験

35年以上教育事業を展開しているアシストが新たに取り組み始めた「ポスグレ学園」。連載6回目となる今回の記事では、データベース移行体験(AWS編)の主管である小林 栄治にインタービューしました。

ページの先頭へ戻る