レプリケーションスロットを使用する際の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領域の肥大化を抑制することができます。

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

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_start_backup関数を使用して取得したベースバックアップにはレプリケーションスロットの情報が残ってしまうためです。

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

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

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

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