PostgreSQLレプリケーションを使ったバックアップ（その１）

はじめに

　データベースといえばMySQLというくらいにMySQLが使われる事が多いと思いますが、用途によってはPostgreSQLが使用される事も少なくはありません。PostgreSQLだと最近よく使われる位置情報（地図データ）を扱うPostGISや時系列データを扱うTimescaleDBなど、標準機能を超えた拡張が可能です。特にトランザクション処理やデータの制約が厳格で、不正なデータが入り込む事を防いだりと、大規模で堅牢なシステムを構築したい場合等に使われる事が多いようです。
　そこでより堅牢なシステムを構築する為にレプリケーションの構築と構築したレプリケーションを使ったバックアップ環境を作成したいと思います。

PostgreSQLのレプリケーションの種類

PostgreSQLのレプリケーションには大きく３つの方式があります。

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

　最も一般的な方式で、仕組みとしては WAL（Write-Ahead Log）をそのまま送ります。構成としては Primary ⇒ Standby となり高速でシンプルな構成ですが、Standby側は読み取り専用となります。

論理レプリケーション

　SQLレベル（論理データ）で複製が行われます。テーブル単位で複製が出来る為、特定のアクセスが多いテーブルだけを分散させるといった事ができ、双方向レプリケーションとして構築する事もできます。（但し、双方向レプリケーションはプログラムレベルで考えて設計しないと逆にパフォーマンス低下やデータの不整合などを招く恐れもあり、慎重な設計が求められます。）

ログシッピング

　WALファイルを定期的に転送して同期を行う。方式としてはシンプルですが、リアルタイム性は無く、DR（Disaster Recovery）に向いた方式です。

簡単にまとめると

　論理ストリーミングは双方向レプリケーションが出来るなどリアルタイム性が高いように感じますが、SQLをそのまま実行する為、実行されるSQLによっては時間が掛かる場合があります。
　

最後に

　一見すると論理ストリーミングが柔軟性もあって色々なことが出来て良さそうに感じますが、設計や運用等で考慮しなければならない点が多いのがデメリットと言えるでしょう。
　今回の目的のようなバックアップとしてのレプリケーションの場合には、設定がシンプルでデータ同期のリアルタイム性やトラブルも少ないストリーミングレプリケーションが良いでしょう。
　次回は実際にストリーミングでのレプリケーションを設定して見たいとお思います。