主要なPostgreSQLクラスタ
3. Streaming Replication
Streaming Replication（ストリーミング・レプリケーション）は、PostgreSQL本体がサポートした、最初のレプリケーションです。PostgreSQL 9.0で、リリースされました（関連URL）。Streaming Replicationがどのように動作するのかを調べることで、適用領域を理解できます。
Streaming Replicationは、PostgreSQLのHA機能として提案されました（関連URL）。
従来、組み込みのHA機能を持たないデータベースでは、第1回で紹介したような、共有ディスクを用いたコールド・スタンバイ型のクラスタが一般的でした。しかし、この方法は、障害の検出からデータベースの再起動までの時間が数分から十数分と長いのが欠点でした。共有ディスクが必須であることも、ハードウエア・コストを押し上げていました。
一方、PostgreSQLの機能だけでも、リカバリは可能です。図4は、その方法です。バックアップを取得し、バックアップ後にデータベースになされた変更のログも蓄積しておきます。クラッシュしたら、最初に取得したバックアップと、その後の変更データを使って、データベースの状態を復元します。
|
|
| 図4: PostgreSQL単体のリカバリ |
2つのPostgreSQLデータベースを使えば、図5に示したように、更新ログの取得と、ログをバックアップに適用することが、同時並列に可能になります。こうすることで、スレーブ側のデータベースの状態を最新の状態に保つことができます。これが、Streaming Replicationです。マスターがクラッシュした場合でも、即座にスレーブに運転を切り替えることができます。
|
|
| 図5: WAL（Write Ahead Logging）を使ったレプリケーションの作成 |
現在リリースされているPostgreSQLのStreaming Replicationは、非同期型と呼ばれるものです。マスターで更新ログ（WAL）を作成した後で、これをスレーブに転送するようになっています。この間、わずかに時間差があるため、クラッシュする直前に作られたWALがスレーブに届かないというリスクは残ります。
スレーブ側は、常にデータベースのリカバリを実行していることになります。このままでは、スレーブ側でSQL文を処理することはできません。しかも、利用するWALはデータベースの格納構造そのものなので、マスターとスレーブのPostgreSQLは同一バージョンである必要があり、アーキテクチャも双方で同じでなければなりません。
4. Hot Standby
Hot Standbyは、Streaming Replicationと同時にPostgreSQL本体に採用された機能です。Streaming Replicationを行っている間でも、スレーブ側で参照用のSQLが使えるようにします（図6）。
Hot Standbyが動作しているスレーブでは、PostgreSQLの格納構造をそのまま適用しつづけているので、これと矛盾するような更新用のSQLを処理することはできません。しかし、データベースの内容を書き換えない参照用のSQL文は、処理が可能になります。
|
|
| 図6: Hot Standbyを使い、スレーブで参照SQLを処理 |
スレーブ側で参照SQLを処理することにより、マスターの負荷を軽減し、性能向上を図ることができます。
Streaming ReplicationによってWALがマスターからスレーブに送られ、これが実際にスレーブのデータベースに適用されるまでには、わずかな時間差があります。これが問題にならないような場合に使うとよいでしょう。
5. 第3回まとめ
今回は、代表的なPostgreSQLクラスタを紹介しました。可用性、性能、リカバリの点から、PostgreSQLをクラスタで利用するのは、もはや当然になってきています。一方、具体的なアプリケーションの要件によって、どのクラスタを使うべきかをきちんと選択することが重要です。
次回は、現在開発中のPostgres-XCクラスタを紹介します。
