PREPARATION
受験対策

前回、レプリケーションにはシングルマスタとマルチマスタがあることについて説明しました。シングルマスタでは、マスタのみが更新可能で、スレーブは更新できないのですが、現実には必ずしもそうとは言えないこともあるので注意しなければなりません。
実は、スレーブが更新可能かどうかは、RDBMSの種類に依存します。更新可能だとしても、シングルマスタレプリケーションですから、スレーブの更新は他のデータベースに反映されません。従って、スレーブに対して更新処理を実施してはいけないことは言うまでもありません。
PostgreSQLのストリーミングレプリケーションでは、スレーブでの更新SQLはエラーになるので、心配は要りませんが、RDBMSの種類によっては、スレーブでの更新がエラーにならず、実行されてしまうものもあり、この場合、マスタとスレーブで回復不可能なデータの差異が発生してしまう可能性があります。利用中のRDBMSで、このあたりの仕様がどうなっているかについても注意しましょう。

レプリケーション機能を使う上で気になることの1つが、データが複製されるタイミングです。
マスタでデータ更新した直後に、スレーブ上で問い合わせを実行したとき、データが既に複製されているかどうかによって、その結果が違ってきます。
また、高可用性のためにレプリケーションを使っているときに、マスタでデータを更新した直後にマスタがダウンしたとすると、その更新がスレーブに複製されておらず、データ更新自体が失われてしまうこともあるかもしれません。
このような観点から、同期レプリケーション、非同期レプリケーション、という分類をすることがあります。
非同期レプリケーションでは、マスタの更新内容は速やかにスレーブに反映されますが、タイミングによってはマスタとスレーブでデータの内容が異なりますし、また、マスタがデータ更新の直後にダウンすると、データ更新が失われる可能性もあります。
一方で、同期レプリケーションでは、スレーブにデータ更新が反映されるのをマスタが待つので、更新性能がややダウンすることになりますが、マスタとスレーブのデータの内容は常に同じになりますし、マスタがダウンしてもデータ更新が失われることはありません。

レプリケーションの内部的な実現方式ですが、大きく分けると、データを転送する方式とSQLを転送する方式があります。
データを転送する場合は、更新後の行データが転送されるので、転送されるデータのサイズが大きくなりますが、確実に同じものが作られます。
SQLを転送する場合は、転送するのが更新用のSQLなのでデータサイズは小さいですが、SQLの内容によっては結果がサーバによって異なる(例えば乱数や現在時刻の関数を使った場合)、という問題もあります。
PostgreSQLのストリーミングレプリケーションはデータを転送する方式で、トランザクションのログを転送しています。

レプリケーション機能自体は、ほとんどのRDBMSにありますが、それで実現される具体的な機能はRDBMSの種類によって差があり、またその設定方法はRDBMSの種類によってまったく異なります。

PostgreSQLではバージョン9.0からサポートされたストリーミングレプリケーションの機能によりレプリケーションを実現できます。具体的な設定方法はマニュアルを参照してください。
http://www.postgresql.jp/document/current/html/high-availability.html
基本的には、ポイントインタイムリカバリ(PITR)と同じ仕組を使っています。つまり、最初にベースバックアップを取得し、それを複製側に展開します。その後は、トランザクションログを複製側に自動的に転送し、データベースに適用する、という処理が繰り返されます。PITRを実行したことのある人なら、拍子抜けするくらい簡単に設定できますから、是非、試してみてください。
PITRと同じ仕組ですので、レプリケーションの対象は、データベースクラスタ全体になります。一部のデータベースやテーブルだけレプリケーションする、といったことはできません。

なお、PostgreSQL 8.4以前のバージョンでも、pgpool-IIなどのソフトウェアを組み合わせることでレプリケーションを実現することができます。

PostgreSQLのストリーミングレプリケーションは、バージョン9.0では非同期レプリケーションのみでしたが、9.1で同期レプリケーションがサポートされ、9.2以降でもカスケードレプリケーションなど、さらなる強化が予定されています。

解説：松田神一