データベースサーバのクラスタの形式を示すノードの定義で、お互いにどのデータを複製するかを決めます。複製されるデータのグループを"セット"と定義します。
レプリケーションセットは以下から成ります。
適切な主キーを持たないレプリケートされるテーブル上のキー
レプリケートされるテーブル
レプリケートされるシーケンス
Slony-I はレプリケートされるそれぞれのテーブル上に主キーもしくはそれの候補を持つことが必要です。PK の値はソースシステムの中で変更されるそれぞれの他プルに対する主識別子として使用されます。Slony-I が主キーを取り扱えるようにするには3つの方法があります。
もしテーブルに以前定義された主キーがある場合、SET ADD TABLE が主キーを参照する必要はなく使用できます。Slony-I はその主キーを手に入れ、それを使用します。
テーブルに主キーがないけれども、何らかの主キーとなる候補がある時、つまり UNIQUE と NOT NULL フィールドの組み合せ上にインデックスが張られている場合、次のようにしてキーを指定できます。
SET ADD TABLE (set id = 1, origin = 1, id = 42, full qualified name = 'public.this_table', key = 'this_by_that', comment='this_table has this_by_that as a candidate primary key');
テーブルに名前空間を指定しなければならないのであれば、テーブルから名前空間を推論するので、キーには名前空間を指定してはいけません。
テーブルに主キー候補がない場合、Slony-I に提供を求めることができます。これを行うには Slony-I シーケンスを使って挿入される列の追加のため、最初に TABLE ADD KEY を使用します。そのあと Slony-I 自身の列を使用させるべく SET ADD TABLE で key=serial 指示文を含ませます。
"真の"主キーを取り上げるか、もしくは単なる"主キー候補"を取り上げるかはそれほど重要ではありません。とは言っても、Slony-I に PK 列を挿入させるのではなく、主キーまたは主キー候補を持っていることをお勧めします。適当な主キーを持たないと言うことは、アプリケーションの観点から一意の値を保持する機構をテーブルが保有していないことです。と言うわけで Slony-I にアプリケーションに対し新規の故障モードを導入させることもあります。このことはデータベースに混同したデータを入力しなければならなくなることを示唆しています。
テーブルが外部キー制約により関連付けられている場合、それらのテーブルを単一のセットにグループ化することは致命的です。このように関連付けられたテーブルは一緒にレプリケートされません。1つのノードから他に"マスタープロバイダ"を切替えようとした時、トラブルに見舞われ、依存するテーブルの内容が見当たらないので"マスター"がまともに更新されないことを発見するでしょう。
全てのテーブルを1つのレプリケーションセットにまとめたくない理由はいくつか存在します。
大規模セットに対する最初の COPY_SET 事象はプロバイダノード上の 時間のかかるトランザクションに陥ります。システムの性能を傷つける時間のかかるトランザクションに起因するいくつか問題はFAQ で概説されています。
大規模セットをいくつかのより小さい部分に分割できれば性能に"傷を負わせる"程度を軽減させ、それぞれのトランザクションの長さを短くします。
これらの"否定的効果"は数十ギガバイトのデータベー容量をサブスクライブする時点で現れます。比較的小規模なデータベースでは資源による要因ではないでしょう。
EXECUTE SCRIPT を呼び出す時はいつでも、レプリケーションセットの中の全てのテーブルにロックを要求します。
EXECUTE SCRIPT 要求がそれ自体完全に完結するように何回も送り出され、デッドロックに陥る"分野の"報告があります。
セット内にテーブルが増えれば増えるほどより多くのテーブルがロックされる必要があり、デッドロックの機会が大きくなります。
同様の特徴として、もし特定の DDL スクリプトが2、3のテーブルにのみ作用する必要がある場合は、それらを新規のレプリケーションセットに一時的に退避させるため SET MOVE TABLE を使います。これは必要とされるロック数を少なくするため、DDL の変更がふさわしい位置になるような機能にゆとりを与えます。
SYNC が処理されるたびに、セット内の全てのシーケンスに対する値が記録されます。もしも数多くのシーケンスがあると、sl_seqlog がやや大きめに成長する原因になります。
このことはテーブルとシーケンスの重要な相違を指摘しています。多くか何らかの活動が見出されないテーブルを追加するとしたら、レプリケーションによって行われる仕事に何らの資源も読み込みません。レプリケートされたシーケンスに対して値はサブスクライバに定期的に伝播されなければなりません。効果を考慮してください。
絶対更新されない複製されたテーブルはシステムに大きな作業を与えません。
更新されていないのであれば、オリジンのテーブルにあるトリガーは起動せず、sl_log_1 にエントリは追加されません。sl_log_1 のエントリにあるかどうかのテーブルのみを探すため、そのテーブルは以降の如何なるレプリケーション問い合わせにも現れることがありません(例えば:複製可能なデータを見つけるのに使用されるFETCH 100 FROM LOG 問い合わせの中)。
対照的に複製されるそれぞれのシーケンスによる SYNC で決まった量の作業が付加されます。
300 シーケンスと 300 行をレプリケートするには定期的に sl_seqlog を追加する必要があります。
最後に検査された後、特定のシーケンスの値が変化しない場合、重ねて同じ値が保存される必要がたぶんないことが確実です。これを安全に行うにはどうしたら良いのかの考慮が必要です。
Bug #1226 はシーケンス単独で成るレプリケーションセットがある場合に引き起こるエラー状況を指摘しています。
これは FAQ に記述されています。シーケンスのみを所有するレプリケーションセットが倍長か単長かを論議するのは特によい考えではありません。