Slony-I 序文


1. Slony-I 概要

1.1. Slony-I とは

Slony-I はカスケードとスレーブ昇格をサポートする"マスター対マルチスレーブ"レプリケーションシステムです。Slony-I 開発が描く大きな絵は大規模データベースを無理なく限定された台数のスレーブシステムでレプリケートするのに必要な全ての機能と性能を持つマスター・スレーブシステムです。ここで"無理のない"台数とは、数ダースを越えることはないでしょう。もしサーバの台数がそれより増えると、通信コストが許容範囲を越えて高くなります。

たくさんのノードを持つことに関連した更なるコスト分析については 項2 も参照してください。

Slony-I は全てのノードが常に稼働して運用され、かつ全てのノードが保証されるデータセンターやバックアップサイトを対象としたシステムです。定期的にネットワークから落ちたり繋がったりしそうなノードがあったり、保証できないノードがある場合は、Slony-I は理想的なレプリケーションの解決策にはならないでしょう。

と言うことは、以下のような場合には Slony-I は多分うまく行かないでしょう。

  • 接続が実際に"薄弱"なサイト

  • 予測できずに接続されるノードへのレプリケーション

    更新を把握するために定期的に営業部員が接続する価格データベースへのセンターサーバからのレプリケーション

更新がファイルに直列化される ファイルベースのログ送出拡張もあります。仮定としては、ログファイルが"ログ送出"経由でプロバイダノードと購読ノード間でフィードバックがなんら必要なく分配される事です。

とは言っても、それぞれのセットで単一の起源点(オリジン)しか持たない時、Slony-I本来的非同期マルチ方式レプリケーションに対して非常に不安定です。Lotus Notes によって提供されるのと同種の"衝突解決策のある非同期マルチマスタレプリケーション"、もしくは PalmOS システムに見られる"同期"プロトコルを求めるのであれば、他をあたってください。これらのレプリケーションモデルにメリットがないではありませんが、Slony-I が行おうと目指しているレプリケーションとは異なったレプリケーションの筋書きを代表しています。

1.2. なぜ、またしても別のレプリケーションシステムなのか

Slony-I は特定の PostgreSQL のバージョンに縛られることなくレプリケーションシステムを構築するアイデアから生まれたもので、繰り返してデータのダンプ/再ロードを行わず、既存のデータベースの開始と停止ができるようになります。

1.3. Slony-I ではないもの

  • Slony-I はネットワーク管理システムではありません。

  • Slony-I はノード故障を検出する機能、もしくは自動的にあるノードをマスターに昇格させたり他のデータ起源点にさせる機能はありません。

    これを行うために確かに必要なのは、状況下においてローカルポリシーに従い、どのノードが"生きて"いて、どのノードが"死んで"いると判断する自身の満足度を評価するネットワークツールとの統合です。 Slony-I はそのようなポリシーを強要しません。

  • Slony-I はマルチマスターではありません。接続ブローカでもなく、朝にコーヒーとトーストを作ってもくれません。

これまで説明した全ては、これらいくつかをを支援するツールが存在し、次のシステム、Slony-II、で"マルチマスター"機能を提供する計画があります。とは言っても、それは異った別のプロジェクトで、 Slony-I とは違う様式で実装されるので、 Slony-I に対する期待を将来のプロジェクトに賭けてはいけません。

1.4. なぜ Slony-I は自動フェイルオーバ/昇格を行わないか

これはネットワーク監視ソフトウェアの専門の責任範囲で Slony-I ではありません。ネットワーク構成、フェイルオーバ経路、および優先ポリシーはサイト毎に異ります。たとえば、冗長化した NIC での(ノードが)生きているか否かの監視や競争状態防止を生成する知的高可用性スイッチはネットワークアドレスを引継ぎ、故障ノードを分離しますが、これはネットワーク構成、ベンダー選択および使用するハードウェアとソフトウェアに依存します。これは明らかにネットワーク管理の分野で Slony-I の領域ではありません。

更にクラスタの"形状"に基づいたやるべきことの選択はローカルの業務方針を代表します。もし Slony-I がフェイルオーバポリシーを無理強いすれば、業務上の要求と対立することもあり、Slony-I を許容できない選択枝とするかもしれません。

結果として、Slony-I が最善とすることをやらせることにしますが、それはデータベースのレプリケーションです。

1.5. 現在の制約

Slony-I は自動的にスキーマ変更を伝播させたりラージオブジェクトをレプリケートする機能がありません。これらの制約には共通の理由が存在します。それは Slony-I がトリガーを使った操作を行うためで、スキーマ変更もラージオブジェクト操作もそれらの変更があった場合に Slony-I に伝える適切なトリガーを立ち上げられないからです。

Slony-I には slonikEXECUTE SCRIPT 操作を経由してスクリプトとして提出すれば DDL 変更を伝播させる機能があります。"自動的"ではありません。SQL DDL スクリプトを構文化し提出しなければなりません。それでもなお、更なる危険が数多く存在します。

もしこの種の要求があるのであれば、PostgreSQL 8.0 の PITR(ポイントインタイムリカバリ)を試してみてはどうでしょう。そこでは WAL ログがリモートノードに複製されます。残念ながらこれには2つの付随した制約があります。

  • PITR は全てのデータベースの全ての変更を複製します。 関連のないものを排除することができません。

  • PITR レプリカはログを適用しデータベースを起動するまで休眠状態で存続します。同時にデータベースを使用し、更新を加える事ができません。"待機状態"を解かない限り使用できない"待機サーバ"を持つことに似ています。

1.6. レプリケーションモデル

独立した数多くのデータベースレプリケーションモデルがあり、全ての人々に対し1つのレプリケーションシステムが対応することは不可能です。

Slony-I は特定のモデル、すなわち非同期レプリケーションを実装します。そこではカスケードされたサブスクライバを含む複数"サブスクライバ"に、単一の"オリジン"からレプリケートするのにトリガーを使用するものです。

数多くの異る他のレプリケーションモデルがあります。存在する他の手法について指摘する価値があります。 Slony-I が唯一の手法ではなく、アプリケーションによっては最適の手法ではありません

  • 同期シングルオリジン・マルチサブスクライバレプリケーション

    同期システムではサブスクライバノードが引き受け完了するまでオリジンでの更新はコミットされません。これはいずれかで確認されるまで更新がコミットされないので拒否されないという安全性を向上させます。残念ながら、複数箇所で変更が適用されると言う要求は性能的なボトルネックを生じます。

    この手法は XA トランザクション処理プロトコルにおける2相コミット処理に似ています。

  • 同期複数オリジン・複数購読ノードレプリケーション

    次の Slony-II システムで採用されるモデルです。同期レプリケーションシステム全ては、更新がどこかでコミットされる以前に全てのノードで引き受け完了していなければならないと言う性能上のボトルネックを"被ります"

  • 衝突回避/解決付き非同期マルチマスタレプリケーション

    この種の多分最も広く使用されているレプリケーションシステムは PalmOS HotSync システムです。Lotus Notes™ もこの様式で多く機能するレプリケーションシステムを提供しています。

    この形式に特徴的な"厄介な問題点"は、ユーザが異ったやりかたで、異ったノード上で同一のレコードを更新するため、衝突が引き起こされる可能性があることです。

    HotSync の場合、複数ノードでレコードが更新された事に起因する衝突が起こると、"解決"としては単も2つの変更を反映した重複したレコードを生成し、ユーザに手動で衝突解決を行わせます。

    いくつかの非同期マルチマスタシステムは部分的レコード更新を適用し衝突を解決しようと試みます。たとえば、住所録の更新の場合、ひとりのユーザが、1つのノードである住所録の電話番号を更新するかも知れません。そしてほかのユーザが番地を更新したとすると、衝突解決システムはこれらの更新を衝突しない順序で更新を掛けます。

    衝突解決システムは殆ど全ての場合、使用されているアプリケーションの何らかのドメイン知識を必要とします。