PostgreSQL のレプリケーション
現在は以下の2種類をサポート
- ストリーミングレプリケーション(9.0〜
- ロジカルレプリケーション(10〜
どちらもWALをスタンバイに渡すことでレプリケーションが行われている
今回はストリーミングレプリケーションについて詳しく掘り下げる
PostgreSQL のレプリケーションの歴史
PostgreSQL9.0(2010年)まで、公式のレプリケーション機能は未サポートだった
- それまではサードパーティツールが氾濫
なお、自動フェイルオーバーやリードレプリカへの振り分けは今も未サポート
ストリーミングレプリケーションの特徴
- PostgreSQL9.0からサポート
- 異なるメジャーバージョン間でのレプリケーションは未サポート
- WALのやり取りは、マスタは
wal_senderスタンバイはwal_receiverが行う - 非同期、同期という2つのレプリケーションモードを選択可能(後述
- スタンバイ毎にどちらかを選択可能
非同期レプリケーションの特徴
- PostgreSQL9.0からサポート
- commit後、WALの転送完了を待たない
- そのため...
- その分、同期レプリケーションより性能が良い
- フェイルオーバー時に commit の内容が失われることがある
- スタンバイの内容が古いことがある
同期レプリケーション
- PostgreSQL9.1からサポート
- commit後、WALの転送完了を待つ
- そのため...
- フェイルオーバー時に commit の内容が失われることは無い
- スタンバイからの応答が届くまで、別トランザクションからの参照がブロックされる
- その分、非同期レプリケーションより性能が悪い
- スタンバイの内容が古いことがある
- 転送完了後にスタンバイがWALを読み込むまでは古い。ただし、非同期よりは早い(はず...
- スタンバイが死ぬと、マスタのトランザクションが停止する
- マスタがスタンバイの同期完了のレスポンスを待ち続けるため
- そのため、 スタンバイ死亡時にはマスタのトランザクションをすべて非同期に変更する必要がある
ストリーミングレプリケーションのデータ保護レベル
ストリーミングレプリケーションでは、設定ファイルでデフォルトのデータ保護レベルを設定可能
- off(完全非同期): マスタのWALのHDDへの書き込み(flush)を待たない
- local(スレーブ非同期): マスタのWALのHDDへの書き込み(flush)を待つ。スタンバイは待たない
- remote_write(メモリ同期): スタンバイへのWAL のファイルキャッシュへの書き込みを待つ。HDDへの書き込み(flush)は待たない
- on(同期): スタンバイのWALのHDDへの書き込み(flush)を待つ
なお、トランザクション毎にも設定可能(らしい
カスケードレプリケーション
スタンバイにさらにレプリケーションを貼ることで、レプリケーションのチェインが可能
これをカスケードレプリケーションと言う
- マスタ側で複数のスタンバイへの同期をする必要がなくなるので、多少性能がよくなる(らしい
ロジカルレプリケーションの特徴
- PostgreSQL10からサポート
- 異なるメジャーバージョン間でのレプリケーションもサポート
- ストリーミングレプリケーションより柔軟だが堅牢性が少し低いらしい
- テーブル単位でのレプリケーションや、スタンバイの書き込みも可能
- AWS DMSのような印象?
TODO
- 自動フェイルオーバーや分散のためのツールを調査
- スタンバイが死んだ時の対応方法も調査(自動フェイルオーバーツールで対応可能?
参考
www.slideshare.net
