トップ  >  Slony-I: PostgreSQL のためのレプリケーションシステム - その実装詳細

Slony-I: PostgreSQL のためのレプリケーションシステム - その実装詳細

Slony-I: A replication system for PostgreSQL - Implementation details

Copyright (c) 2003-2004, PostgreSQL Global Development Group

訳注 (Sat Mar 20 2010): 本稿は、slony1-1-1.2.14 に同梱される "Slony-I: A replication system for PostgreSQL - Implementation details" からの、SIOS Technology, Inc. による翻訳です。原文と和訳との内容に差異が認められる場合には、原文の内容が優先されます。

著者 / Author

ヤン・ヴィーク (米国 ペンシルバニア州 ホーシャム Afilias USA INC.)

Jan Wieck (Afilias USA INC. Horsham, Pennsylvania, USA)

要約 / ABSTRACT

当文書では、Slony-I レプリケーションエンジンとその関連コンポーネントの実装詳細について解説します。

This document describes several implementation details of the Slony-I replication engine and related components.

1. 制御データ / Control data

図 1 (Figure 1) に示される ER 図は、Slony-I システムの、構成情報及び実行時情報を表します。Slony-I はマスタースレーブ型のレプリケーション技術ですが、クラスタを構成する各ノードは、事前には固有の役割を持っていません。すべてのノードは同一の構成情報を持ち、実行時には、複製エンジンによる同一のプロセスに従います。ある時点においては、「セット」と呼ばれるテーブルの集合には、ただ一つの「オリジン」ノードが存在します。通常のクライアントアプリケーションから更新が可能なのは、オリジン上のテーブルだけになります。すべてのノードが機能的には同一であり、なおかつ全体の構成情報を有することで、フェイルオーバやフェイルバックの機能を実現することが容易になります。レプリケーションに関連するオブジェクトは、クラスタの名称に基づいた名前空間(訳注: スキーマ名前空間)の中に保持されます。

Figure 1 shows the Entity Relationship Diagram of the Slony-I configuration and runtime data. Although Slony-I is a master slave replication technology, the nodes building a cluster do not have any par ticular role. All nodes contain the same configuration data and are running the same replication engine process. At any given time, a collection of tables, called set, has one node as its origin. The origin of a table is the only node that permits updates by regular client applications. The fact that all nodes are functionally identical and share the entire configuration data makes failover and failback a lot easier. All the objects are kept in a separate namespace based on the cluster name.

1.1. sl_node テーブル / Table sl_node

クラスタに属するすべてのノードに関する情報を保持します。"no_active" 属性は決して、短期的な稼動・非稼動を意味するものではありません。非稼動状態 (true) から稼動状態 (false) に遷移する際には、クラスタへの完全同期を要し、結果として、全セットの複製オペレーションを実行する可能性があります。

Lists all nodes that belong to the cluster. The attribute no_active is NOT intended for any short term enable/disable games with the node in question. The transition from disable to enable of a node requires full synchronization with the cluster, resulting possibly in a full set copy operation.

1.2. sl_path テーブル / Table sl_path

コネクション情報を保持します。この情報は、"pa_client" のノードが "pa_server" のノードへ接続する際に用いられます。その際、接続失敗のタイムアウトには秒単位のインターバル(訳注: "pa_connretry")が用いられます。このテーブルには、すべてのノード間のコネクション情報を定義をしておくことを推奨します。これらの冗長な設定は、フェイルオーバの際に有用だからです。なお、sl_path テーブルのエントリを設定するだけでは、実際のコネクションは張られません。sl_listen や sl_subscribe の設定も同時に必要になります。

Defines the connection information that the pa_client node would use to connect to pa_server node, and the retry interval in seconds if the connection attempt fails. Not all nodes need to be able to connect to each other. But it is good practice to define all possible connections so that the configuration is in place for an eventual failover. An sl_path entry alone does not actually cause a connection to be established. This requires sl_listen and/or sl_subscribe entries as well.

1.3. sl_listen テーブル / Table sl_listen

"li_receiver" ノードが、"li_provider" ノード上に存在する、"li_origin" ノードを起源とするイベントを選択・処理することを意味します。古典的な階層構造を持つ一般的なマスター・スレーブ構成をとる場合には、イベントの伝播経路は、複製データがとる経路と同一になるでしょう。しかし、クラスタ内に複数のセットが存在し、それぞれが異なる起源ノードを持つ場合には、イベントを、より冗長に伝送する必要が生じます。

Specifies that the li_receiver node will select and process events originating on li_origin over the database connection to the node li_provider. In a normal master slave scenario with a classical hierarchy, events will travel along the same paths as the replication data. But scenarios where multiple sets originate on different nodes can make it necessary to distribute events more redundant.

1.4. sl_set テーブル / Table sl_set

セット (set) はテーブルおよびシーケンスの集合であす。それぞれが、一つずつの起源ノードを持ちます。セットは、ノード間で購読 (subscribe) をする際の、複製対象の最小単位となります。

A set is a collection of tables and sequences that originate on one node and is the smallest unit that can be subscribed to by any other node in the cluster.

1.5. sl_table テーブル / Table sl_table

複製されるテーブルと、それぞれが属するセットとの関係を保持します。また、レプリケーション・トリガがログのアップデート情報を構築する際に必用な属性(訳注: プライマリキー名など)も有します。

Lists the tables and their set relationship. It also specifies the attribute kinds of the table, used by the replication trigger to construct the update infor mation for the log data.

1.6. sl_subscribe テーブル / Table sl_subscribe

どのノードがどのデータセットを購読しており、実際にどこからログデータを取得するかの情報が保持されます。各ノードはデータを、セットのオリジンから直接に取得することもありますし、あるいは、フォワード(カスケーディング)オプション付きで購読をおこなっている他のノードから(間接的に)取得することもあります。

Specifies what nodes are subscribed to what data sets and where they actually get the log data from. A node can receive the data from the set origin or any other node that is subscribed with forwarding (cascading).

1.7. sl_event テーブル / Table sl_event

メッセージの受け渡しに用いられるテーブルです。イベントは、構成変更やデータ同期が必用な際に生成されます。あるノードがイベントを生成し、それをこのテーブルへ、新しい行として挿入します。そしてこれを、イベントを "LISTEN" している全てのノードに対して "NOTIFY" します。イベントを LISTEN しているリモートのノードは、これらのレコードを SELECT して読み出し、ローカル側で設定変更やデータ複製をしたり、あるいは sl_event の行をローカル側の sl_event テーブルにコピー保存し、さらにローカル側で NOTIFY をおこないます。このようにして、イベントはカスケード状にクラスタ内を伝播します。SYNC イベントの際、"ev_minxid", "ev_maxxid", "ev_xip" はトランザクションの直列化可能な (serializable な) スナップショットの情報を保持します。これは PostgreSQL の MVCC で用いられるのと同じ情報であり、当該トランザクションにとって、ある変更がすでに可視であるかどうか、あるいはいずれ可視になるかどうかの情報を保持しています。Slony-I はデータを行単位のオペレーションに基づいて複製しますが、それらの変更データは、2 度の SYNC イベントの間に起こった変更ごとにグループ化され、1 つのトランザクションとして他のノードへ適用されます。直前の SYNC イベントと現行の SYNC イベントからなるトランザクション情報を MVCC の可視化ルールに基づいて適用することで、このグルーピングのためのフィルター機構は実現されています(訳注: 詳細については、「コンセプト」の 2.4.1 や 2.4.5 を参照してください)。

This is the message passing table. A node generating an event (configuration change or data sync event) is inserting a new row into this table and does Notify all other nodes listening for events. A remote node listening for events will then select these records, change the local configuration or replicate data, store the sl_event row in its own, local sl_event table and Notify there. This way, the event cascades through the whole cluster. For SYNC events, the columns ev_minxid, ev_maxxid and ev_xip contain the transactions serializable snapshot information. This is the same information used by MVCC in PostgreSQL, to tell if a particular change is already visible to the transaction or considered to be in the future. Data is replicated in Slony-I as single operations on the row level, but grouped into one transaction containing all the changes that happened between two SYNC events. Applying the last and the actual SYNC events transaction information according to the MVCC visibility rules is the filter mechanism that does this grouping.

1.8. sl_confirm テーブル / Table sl_confirm

ノード上で処理済みとなったイベントは、このテーブル上でコンファーム(検証)されます。コンファームそのものも、イベントと同様、カスケード状にシステム内を伝播します。ローカルで走るクリーンアップ用スレッドが定期的にこのテーブルを検査し、sl_event テーブル上のエントリの内で、すでに全てのノードによってコンファームが済んだものを削除します。

Every event processed by a node is confirmed in this table. The confirmations cascade through the system similar to the events. The local cleanup thread of the replication engine periodically condenses this information and then removes all entries in sl_event that have been confirmed by all nodes.

1.9. sl_setsync テーブル / Table sl_setsync

このテーブルには、現行ノード上で、各購読済みセットの現在の同期状態がどのようになっているかの情報が保持されます。この状態情報は、他のノードへは複製されません。この情報は、2 つの目的のために用いられます。レプリケーションを行なう際、当該ノードは、トランザクションのスナップショット情報を用いて、最後のレプリケーション周期の間にはまだ不可視であったログの行を抽出します。新規に購読されたデータセットの初期データのコピーを行なう際には、現行のスナップショットに、すでにどこまでの同期ポイントやログデータが含まれているかを知るために用いられます。

This table tells for the actual node only what the current local sync situation of every subscribed data set is. This status information is not duplicated to other nodes in the system. This information is used for two purposes. During replication the node uses the transaction snapshot to identify the log rows that have not been visible during the last replication cycle. When a node does the initial data copy of a newly subscribed to data set, it uses this information to know and/or remember what sync points and additional log data is already contained in this actual data snapshot.

1.10. sl_log_1 テーブル / Table sl_log_1

このテーブルには、トリガによって記録された、実際の行レベルの変更情報が含まれます。これらのデータは、対応するイベントが全ノードによってコンファームされ次第、クリーンアップ用のスレッドによって定期的に削除されます。

The table containing the actual row level changes, logged by the replication trigger. The data is frequently removed by the cleanup thread after all nodes have confirmed the corresponding events.

1.11. sl_log_2 テーブル / Table sl_log_2

Slony-I システムには、sl_log_1 テーブルと、このテーブルとを切り替える機能を持ちます。通常の運用下では、一方のテーブルを使い続けることをお薦めします。なぜならば、クリーンアップのスレッドが古いログ情報は消去しますし、vacuum によって、フリースペースマップには開放された領域が追加されるからです。PostgreSQL では、フリースペースマップに複数のブロックがある場合には、挿入オペレーションを並列化して、高い同時実効性を実現しています。しかし、ノードがオフラインになったり、何らかの理由でアクセスできなくなった場合に、テーブルへのログの蓄積が膨大になることがあります。VACUUM FULL を実行する以外に領域を確保する方法が無いものの、それでは排他ロックがかかってしまいアプリケーションの実行に支障をきたす場合、これを避けるために、ログテーブルを切り替えることができます。古い方のログテーブルが論理的に空になったところで、truncate することができるようになります。

The system has the ability to switch between the sl_log_1 and this table. Under normal circumstances it is better to keep the system using the same log table, with the cleanup thread deleting old log information and using vacuum to add the free'd space to the freespace map. PostgreSQL can use multiple blocks found in the freespace map to actually better parallelize insert operations in high concurrency. In the case nodes have been offline or fallen behind very far by other means, log data collecting up in the table might have increased its size significantly. There is no other way than running a full vacuum to reclaim the space in such a case, but this would cause an exclusive table lock and effectively stop the application. To avoid this, the system can be switched to the other log table in this case, and after the old log table is logically empty, it can be truncated.

2. レプリケーションエンジンのアーキテクチャ / Replication Engine Architecture

図 2 (Figure 2) に図示されているのは、Slony-I レプリケーションエンジンの、スレッドアーキテクチャです。まず注意していただきたいことは、Slony-I クラスタを構成する各ノードには、あらかじめ定められた役割は無いということです。このエンジンが、1 つのデータベースごとに 1 つずつ動作することで、全体として 1 つの分散レプリケーションシステムを構成します。

Figure 2 illustrates the thread architecture of the Slony-I replication engine. It is important to keep in mind that there is no predefined role for any of the nodes in a Slony-I cluster. Thus, this engine is running once per database that is a node of any cluster and all the engines together build "one distributed replication system".

2.1. 同期スレッド / Sync Thread

同期スレッド (Sync Thread) は、ローカルのデータベースに対して 1 本のコネクションを張ります。設定されたインターバルごとに、アクションのシーケンスが変更されているか(つまり、データベース上で何らかの複製可能な操作がおこなわれたか)をチェックし、CreateEvent() を呼び出して SYNC イベントを生成します。他のスレッドとは協調動作をしません。

The Sync Thread maintains one connection to the local database. In a configurable interval it checks if the action sequence has been modified which indicates that some replicable database activity has happened. It then generates a SYNC event by calling CreateEvent(). There are no interactions with other threads.

2.2. クリーンアップスレッド / Cleanup Thread

クリーンアップスレッド (Cleanup Thread) は、ローカルデータベースへの 1 本のコネクションを管理します。設定されたインターバルごとに Cleanup() ストアドプロシージャを呼び出し、不要になった古いコンファーム情報、イベント、ログデータを削除します。これとは別のインターバルを用いて、コンファーム、イベント、ログの各テーブルの vacuum も行ないます。他のスレッドとの協調動作はありません。

The Cleanup Thread maintains one connection to the local database. In a configurable interval it calls the Cleanup() stored procedure that will remove old confirm, event and log data. In another interval it vacuums the confirm, event and log tables. There are no interactions with other threads.

2.3. ローカル LISTEN スレッド / Local Listen Thread

ローカル LISTEN スレッド (Local Listen Thread) は、ローカルのデータベースへ 1 本のコネクションを張ります。"EVENT" の "NOTIFY" を待ち、ローカルノードに起源を持つイベントを検出します。管理用のプログラムを用いて設定変更用のストアドプロシージャが呼ばれると、新たに設定変更のイベントが受信されます。その結果このスレッドは、イベント情報に従い、レプリケーションエンジンのメモリ上の設定を変更します。

The Local Listen Thread maintains one connection to the local database. It waits for "Event" notification and scans for events that originate at the local node. When receiving new configuration events, caused by administrative programs calling the stored procedures to change the cluster configuration, it will modify the in-memory configuration of the replication engine accordingly.

2.4. リモート LISTEN スレッド / Remote Listen Threads

リモートノード 1 つに対して 1 つのリモート LISTEN スレッド (Remote Listen Threads) が稼動し、イベントプロバイダからイベントを受け取る役割を果たします。クラスタ内に何個のノードがあったとしても、リーフのノードは 1 つしかリモート LISTEN ノードを持ちません。なぜならば、そのノードはオリジンからのすべてのイベントを、一つのプロバイダからしか受け取らないからです。リモート LISTEN スレッドは、イベントプロバイダへコネクションを張ります。イベントやコンファームの NOTIFY 情報を受け取りつつ、対応するテーブルから関連する情報を SELECT し、ローカルの対応するワーカースレッドのキューに入れます。Slony-I エンジンは、リモートノード 1 つに対して、ワーカースレッド 1 つを起動します(次項参照)。メッセージは内部のメッセージキューを経て、対応するワーカースレッドへ渡され、処理とコンファームがおこなわれます。

There is one Remote Listen Thread per remote node, the local node receives events from (event provider). Regardless of the number of nodes in the cluster, a typical leaf node will only have one Remote Listen Thread since it receives events from all origins through the same provider. A Remote Listen Thread maintains one database connection to its event provider. Upon receiving notifications for events or confirmations, it selects the new information from the respective tables and feeds them into the respective internal message queues for the worker threads. The engine starts one remote node specific worker thread (see below) per remote node. Messages are forwarded on an internal message queue to this node specific worker for processing and confirmation.

2.5. リモートワーカースレッド / Remote Worker Threads

リモートノード 1 つごとに、1 つのリモートワーカースレッド (Remote Worker Threads) が起動されます。リモートワーカースレッドからは、ローカルのデータベースへも 1 本のコネクションが張られ、実際の複製データ送信、イベントの転送、コンファームの転送がおこなわれます。1 つのワーカーが受け持つリモートノードをオリジンとするデータセットには、1 つのデータプロバイダが存在します(これは、イベントプロバイダと同一にすることもできますが、してはいけません(訳注: 「イベントプロバイダと同一である可能性もありますが、必ずしもそうである必要はありません」の間違いか?))。これらのセットのデータプロバイダごとに、ワーカースレッドは 1 本ずつのデータベースコネクションを張り、実際のレプリケーションデータの SELECT をします。リモートワーカースレッドは内部のメッセージキューでリモート LISTEN スレッドからイベントが送られてくるのを待ちます。データを受け取ると、これらイベント・データ選択と適用・コンファームを処理します。また、このスレッドは、エンジンのメモリ上の設定情報の変更も行います。

There is one Remote Worker Thread per remote node. A qremote worker thread maintains one local database connection to do the actual replication data application, the event storing and confirmation. Every Set originating on the remote node the worker is handling, has one data provider (which can but must not be identical to the event provider). Per distinct data provider over these sets, the worker thread maintains one database connection to perform the actual replication data selection. A remote worker thread waits on its internal message queue for events forwarded by the remote listen thread(s). It then processes these events, including data selection and application, and confirmation. This also includes maintaining the engines in-memory configuration information.

プリンタ用画面
友達に伝える
ログイン
ユーザー名:

パスワード:



パスワード要求 | 新規登録

検索
メインメニュー
 


Copyright(C) SIOS Technology, Inc. All Rights Reserved