レプリカ更新ベクトル (RUV) について

レプリケーショントポロジ内のすべてのレプリカは、現在のレプリケーション状態をレプリカ更新ベクトル (RUV) に格納します。RUV は、実行中のプロセスによりメモリー内に格納され、このレプリカが保持する自分自身およびレプリケーショントポロジ内のほかの参加者すべての正確な情報を提供します。指定されたサーバーの RUV エントリの各行には、レプリケーショントポロジに参加しているマスターが含まれます。各行には、いずれかのマスターの識別子、レプリカの URL、およびサーバーで実行された最初と最後の変更の CSN が含まれます。CSN には、サーバーが検出した最初と最後の変更だけが記録されます。マスターにより実行された最新の変更が記録されるとは限りません。

RUV エントリの状態は、次に示すエントリ内で 30 秒ごとに物理的に更新されます。

nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,suffix-name

RUV はメモリーにも格納されます。この RUV にアクセスするには、cn=replica,cn=suffix,cn=mapping tree,cn=config エントリに対して ldapsearch を使用します。たとえば、ldapsearch を ou=people サフィックスに対して実行すると、次のような結果が生成されます。

# ldapsearch -h host1 -p 1389 -D cn=Directory Manager -w secret \
-b cn=replica, 
cn=ou=people,cn=mapping tree,cn=config -s base objectclass=* nsds50ruv
nsds50ruv: {replicageneration} 45e8296c000000010000
nsds50ruv: {replica 1 ldap://server1:1389} 45ed8751000000010000 4600f252000000010000
nsds50ruv: {replica 2 ldap://server1:2389} 45eec0e1000000020000 45f03214000000020000

わかりやすいように、ここからは RUV の構文を CSNchange-number -replica-id に簡略化します。change-number は、マスターで発生した一連の変更のうち、どの変更が RUV に対応するかを示します。たとえば、45ed8751000000010000 は CSN05-1 と記述できます。前の例では、マスター 1 には次の RUV が含まれています。

replica 1: CSN05-1 CSN43-1
replica 2: CSN05-2 CSN40-2

最初の行は、レプリカ ID 1 で示されるこのレプリカ自身 (マスター 1) から入手した、このレプリカが認識している最初と最後の変更の情報を示します。2 番目の行は、マスター 2 から入手した、このレプリカが認識している最初と最後の変更の情報を示します。注目すべき情報は、最後の変更の方です。通常の操作では、受信した更新についてマスター 1 はマスター 2 より多くの情報を持っています。この点をマスター 2 の RUV で確認してみましょう。

replica 2: CSN05-2 CSN50-2
replica 1: CSN01-1 CSN35-1

最後の変更を参照すると、マスター 2 は受信した最後の変更 (CSN50-2) について、マスター 1 (最後の変更が CSN40-2 で発生したとしている) より多くの情報を持っていることがわかります。それに対して、マスター 1 はその最後の変更 (CSN43-1) について、マスター 2 (CSN35-1) より多くの情報を持っています。

レプリケーションの問題のトラブルシューティングでは、CSN は問題を識別するのに役立ちます。マスター 1 は常に、自身のレプリカ ID について、レプリケーショントポロジ内のほかの参加者と同程度以上の情報を持っています。変更は最初にマスター 1 に適用されてからレプリケートされるからです。このため、CSN43-1 は、トポロジ内のレプリカ ID 1 に関連付けられる最大の値になります。

たとえば、30 分後にマスター 1 上の RUV が依然として CSN40-2 であるにもかかわらず、マスター 2 上の RUV が CSN67-2 と大幅に大きくなる場合、問題が発生したと見なされます。これは、マスター 2 からマスター 1 へのレプリケーションが実行されていないことを示します。

障害が発生したため、可能なかぎり多くのデータを保存して、トポロジを再初期化することが必要になった場合は、RUV ピクチャーを使って最新の変更を含むマシンを判別できます。たとえば、前述のレプリケーショントポロジでは、次の RUV を含むハブが存在します。

2: CSN05-2 CSN50-2
1: CSN05-1 CSN43-1

この場合、ハブ 1 は最新の変更を提供する有力な候補と考えられます。

nsds50ruv 属性を使用した 5.x レプリケーションの問題のトラブルシューティング

サーバーが停止すると、nsds50ruv 属性は cn=replica エントリには格納されません。すでに説明したように、これは少なくとも 30 分ごとに、nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff, suffix-name エントリに LDAP サブエントリとして格納されます。この情報をファイルにエクスポートするにはこの方法しか存在しないため、この情報は設定ファイルではなくサフィックスに格納されます。トポロジの初期化時にサーバーがオフラインであると、このことが発生します。データは LDIF ファイルにエクスポートされてから、再インポートされます。この属性がエクスポートされたファイルに格納されていない場合、インポート後に新しいレプリカは正しい情報を保持しません。

db2ldif -r コマンドを使用する場合は、常に nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff, suffix-name エントリが含まれます。

nsds50ruv および ds6ruv 属性を使用した 6.x レプリケーションの問題の解決

Directory Server Version 6.0 以降では、前の節で説明したように、nsds50ruv 属性を使用してコンシューマの内部状態を表示することもできます。レプリケーション優先順位機能を使用している場合は、ds6ruv 属性を使用できます。この属性には優先順位操作に関する情報が含まれます。レプリケーション優先順位を設定する場合は、レプリケーションルールを作成して特定の変更 (ユーザーパスワードの更新など) が高い優先順位でレプリケートされるように指定できます。たとえば、RUV は次のように表示されます。

nsds50ruv: {replicageneration} 4405697d000000010000
nsds50ruv: {replica 2 ldap://server1:2389}
nsds50ruv: {replica 1 ldap://server1:1390} 440569aa000000010000 44056a23000200010000
ds6ruv: {PRIO 2 ldap://server1:2389}
ds6ruv: {PRIO 1 ldap://server1:1390} 440569b6000100010000 44056a30000800010000 

レプリケーション情報を表示するには、次のファイルをエクスポートします。

# dsadm export instance-path suffix-dn [suffix-dn] ldif-file