19.3 マスターおよびクローン・メタデータの同期

MDC間でのメタデータの同期のプロセスでは、まずAccess Manager UDMメタデータを同期し、次にレプリケーション承諾を作成します。

「レプリケーション承諾の理解」を参照してください。

次の各トピックでは、マスターおよびクローン・メタデータの同期方法について説明します。

19.3.1 UDMメタデータの同期

レプリケーション承諾を作成するには、UDMメタデータを同期する必要があります。

マスターに格納されているAccess Manager UDMメタデータをすべてのクローンと同期するには、次のようにします。

マスター・データ・センターでexportAccessStore WLSTコマンドを実行して、UDMメタデータを含むZIPファイルを作成します。
```
exportAccessStore(toFile="/master/location/dc1metadata.zip", 
   namePath="/")
```
dc1metadata.zipをクローンDCの場所にコピーします。
クローン・データ・センターでimportAccessStore WLSTコマンドを実行して、UDMメタデータをインポートします。
```
importAccessStore(fromFile="/clone/location/dc1metadata.zip", 
   namePath="/")
```
すべてのクローンDCで、同じ手順を繰り返します。

19.3.2 レプリケーション承諾の作成

レプリケーション承諾の作成は、クローン・データ・センターがマスター・データ・センターから変更内容をプルできるようにする1回かぎりの操作です。

レプリケーション承諾は、任意のRESTクライアントを使用して作成できます。この手順では、標準のcurlユーティリティを使用します。

このコマンドを実行すると、次のような結果になります。

変更内容をプルするクローンに関する詳細が格納されているマスターのレプリケーション承諾ストアにエントリが挿入されます。
変更内容をプルするマスターに関する詳細が格納されているクローンのレプリケーション承諾ストアにエントリが挿入されます。ポーリング間隔などのレプリケーション構成値も設定されます。

レプリケーション承諾を作成するには、次のようにします。

マスターとクローンのDC RESTエンドポイントが稼働中であることを確認します。
マスターDCで次のコマンドを実行します。
このコマンドでは、マスターからクローンへのレプリケーション問合せに指定されているrepluserが使用されます。関連するすべてのDCのデフォルト・アイデンティティ・ストアで、repluserが使用可能であることが期待されます。
```
curl -u <repluser> -H 'Content-Type: application/json' -X POST
 'https://supplier.example.com:7002/oam/services/rest/
  _replication/setup' -d '{"name":"DC12DC2", 
 "source":"DC1","target":"DC2","documentType":"ENTITY"}'
```
コマンドの出力例を次に示します。
```
{"enabled":"true","identifier":"201409231329353668","ok":"true",
  "pollInterval":"900","startingSequenceNumber":"110","state"  :"READY"}
```
レプリケーション識別子pollIntervalおよびstartingSequence Numberの値に注意してください。この識別子は、このレプリケーション承諾に固有の参照であり、レプリケーション関連の問合せに使用されます。pollIntervalの値(秒)が経過すると、クローンはマスターに対して変更をポーリングします。(通常、ポリシーや構成が頻繁に変更されることはないため、この番号はデフォルト値の900秒程度の高い値に設定してかまいません。)startingSequenceNumberの値より前のすべてのレコードは使用不可になります。この例では、110の値より前のレコードはすべて使用不可です。暗黙的に、レプリケーション承諾の作成前にブートストラップが行われているため、クローンはシーケンス番号110から変更内容のプルを開始できます。クローンのローカル・レプリケーション表にもエントリが作成されており、ここに最後のシーケンス番号が記録されます。図19-2は、開始シーケンス・プロセスを示しています。

図19-2 示されている開始シーケンス

「図19-2 示されている開始シーケンス」の説明

レプリケーション承諾作成コマンドは、既存のレプリケーション承諾の詳細を返します(該当する場合)。この場合、okの値がfalseになります。
```
{"enabled":"true","identifier":"201409231329353668","ok":"false",
  "pollInterval":"900","startingSequenceNumber":"110",
  "state":"READY"}
```
ノート:
レプリケーションに特定のユーザーを使用する必要がある場合、そのユーザーの資格証明を"BASIC base64(user:password)"という形式でコマンドに指定できます。たとえば、次のコマンドでは、"BASIC base64(weblogic:welcome1)"を"BASIC d2VibG9naWM6d2VsY29tZTE="として指定しています。
```
curl -u <repluser> -H 'Content-Type: application/json' -X POST 
  'https://supplier.example.com:7002/oam/services/rest/
  _replication/setup' -d 
  '{"source":"DC1","target":"DC2","documentType":"ENTITY","config":
  {"entry":{"key":"authorization","value":"BASIC 
  d2VibG9naWM6d2VsY29tZTE="}}}''
```
レプリケーションREST APIでは、Basic認可がサポートされています。
マスターおよびクローンのAdminServerを再起動します。
レプリケーション承諾が作成され、AdminServerが再起動されると、クローンは変更のポーリングを開始します。デフォルトのポーリング間隔は、'900'秒(15分)です。ポーリング間隔は、レプリケーション承諾編集コマンドを実行することにより変更できます。たとえば、次のコマンドでは、ポーリング間隔が60秒に変更されます。コマンドの実行後に、クローンのAdminServerを再起動します。
```
curl -u <repluser> -H 'Content-Type: application/json' -X PUT 
  'https://supplier.example.com:7002/oam/services/rest/
  _replication/201409231
  329353668' -d '{"pollInterval":"60","replicaType":"CONSUMER"}''
```
クローンのレプリケーション承諾の詳細(ポーリング間隔を含む)を問い合せるには、次のコマンドを使用します。
```
curl -u <repluser>
  'https://supplier.example.com:7002/oam/services/rest/_replication/201409231
  329353668?type=consumer'
```
出力は次のようになります。
```
{"enabled":"true","identifier":"201409231329353668","ok":"true",
  "pollInterval":"60","startingSequenceNumber":"110","state":"READY"}
```
マスターのレプリケーション承諾の詳細(ポーリング間隔を含む)を問い合せるには、次のコマンドを使用します。
```
curl -u <repluser>
  'https://supplier.example.com:7001/oam/services/rest/_replication/201409231
  329353668'
```
出力は次のようになります。(マスターのレプリケーション承諾のポーリング間隔は実際のレプリケーションに影響を与えません。)
```
{"enabled":"true","identifier":"201409231329353668","ok":"true",
  "pollInterval":"3600","startingSequenceNumber":"110","state":"ACTIVE"}
```
R2PS3では、マスターまたはクローンで次のコマンドを使用してレプリケーション承諾の詳細を取得することもできます。レプリケーション承諾識別子が不明の場合、このコマンドを使用して、前のコマンドの入力用のレプリケーション承諾識別子をリストできます。
```
curl -k -u weblogic
'https://oamadmin.example.com:7002/oam/services/rest/_replication/agreements'
 
Sample output 1:
{"featureEnabled":"true","identifiers":"201411211137273612","ok":"true"}
 
Sample output 2:
{"featureEnabled":"true","identifiers":["201411211137273612","201411211137273900"],"ok":"true"}
```
レプリケーション承諾を削除するには、まずクローン側でレプリケーション承諾を無効にしてからマスター側でも無効にし、次に両側で削除します。次のコマンドは、このプロセスを示しています。
```
curl -u <repluser> -H 'Content-Type: application/json' -X PUT
  'https://supplier.example.com:7002/oam/services/rest/_replication/201409231
  329353668' -d '{"enabled":"false","replicaType":"CONSUMER"}''

curl -u <repluser> -H 'Content-Type: application/json' -X PUT
  'https://supplier.example.com:7002/oam/services/rest/_replication/201409231
  329353668' -d '{"enabled":"false","replicaType":"SUPPLIER"}''

curl -u weblogic:welcome1 -H 'Content-Type: application/json' -X DELETE
  'https://supplier.example.com:7001/oam/services/rest/_replication/201409231
  329353668'
```

19.3.3 レプリケーション承諾の変更

レプリケーション承諾識別子を使用して、レプリケーション承諾構成を変更できます。レプリケーション承諾のプロパティ(有効化ステータス、ポーリング間隔など)を更新するには、マスターのエンドポイントでRESTリクエストを実行します。replicaTypeパラメータの値で指定されたとおりに、マスターまたはクローンのレプリケーション承諾が更新されます。クローンは変更をポーリングし、その変更を適用し、pollIntervalとして指定された時間が経過するまで待機します。

この例では、pollIntervalの値が60秒に変更されます。

サービスは、変更を行う前に、レプリケーション承諾のステータスであるJSONオブジェクトを使用して応答します。更新済の構成を確認するには、レプリケーション承諾ステータスを再度フェッチする必要があります。

次のコマンドを使用して既存のレプリケーション承諾を問い合せ、次のステップで使用する必要のあるレプリケーション識別子replIdを取得します。
```
curl -k -u weblogic:password 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/agreements'
```
ノート:
レプリケーション承諾が複数ある場合には、対応するクローン・データ・センターを問い合わせてレプリケーション承諾を変更する必要のある識別子を選択します。

次のコマンドを実行して、クローン・マシンでレプリケーション承諾の現在のステータスを取得します。

curl -k -u weblogic:password 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409040157218184?type=consumer'

JSONレスポンスは次のようになります。

{“enabled":"true","identifier":"201409040157218184","ok":"true","pollInterval":"900","startingSequenceNumber":"101","state":"READY"}

次のコマンドを実行して、クローン・マシンでpollIntervalの値を変更します。

curl -k -u weblogic:password 'Content-Type: application/json' -X PUT 
'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409040157218184' -d '{“pollInterval":"60","replicaType":"CONSUMER"}'

JSONレスポンスは次のようになります。

{“enabled":"true","identifier":"201409040157218184","ok":"true","pollInterval":"60","startingSequenceNumber":"101","state":"READY"}

クローン・マシンでAdminServerを再起動します。

次のコマンドを実行して、レプリケーション承諾の現在のステータスを取得します。

これにより、変更が行われたことが検証されます。JSONレスポンスのpollIntervalの値は、この手順の最初のステップで返される値と異なるので注意してください。

curl -k -u weblogic:password 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409040157218184?type=consumer'

JSONレスポンスは次のようになります。

{“enabled":"true","identifier":"201409040157218184?,"ok":"true","pollInterval":"60","startingSequenceNumber":"101","state":"READY"}

表19-2 レプリケーション承諾プロパティの変更

プロパティ	変更コマンド
BatchSize	クローンによるgetChanges問合せの結果として、マスターによって返される変更レコード(ジャーナル)の数。フェッチの一部として複数のバッチですべての変更がプルされるため、理想としては、デフォルトのバッチ・サイズの32で十分です。ただし、大きいバッチ・サイズが設定で必要な場合は、次のコマンドを実行します。 curl -k -u weblogic:password -H 'Content-Type: application/json' -X PUT 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/<replid>' -d '{"batchSize":"100","replicaType":"SUPPLIER"}'
ユーザー・コンテキスト	まれな例ですが、レプリケーション・ポーリングのユーザー・コンテキストの変更が必要になる場合があります。 curl -k -u weblogic:password -H 'Content-Type: application/json' -X PUT 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409231329353668' -d '{"replicaType":"CONSUMER", "config":{"entry":{"key":"authorization","value":" BASIC cG9sbHVzZXI6c2VjcmV0"}}}' 'cG9sbHVzZXI6c2VjcmV0'は、polluser資格証明のベース64のエンコード値です。ここでは、コマンドの実行に使用されるrepluserではなく、任意のユーザー資格証明を使用できます。

プロパティ

変更コマンド

BatchSize

クローンによるgetChanges問合せの結果として、マスターによって返される変更レコード(ジャーナル)の数。フェッチの一部として複数のバッチですべての変更がプルされるため、理想としては、デフォルトのバッチ・サイズの32で十分です。ただし、大きいバッチ・サイズが設定で必要な場合は、次のコマンドを実行します。

curl -k -u weblogic:password -H 'Content-Type: application/json' -X PUT 
 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/<replid>' 
 -d '{"batchSize":"100","replicaType":"SUPPLIER"}'

ユーザー・コンテキスト

まれな例ですが、レプリケーション・ポーリングのユーザー・コンテキストの変更が必要になる場合があります。

curl -k -u weblogic:password -H 'Content-Type: application/json' -X PUT 
 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409231329353668' 
 -d '{"replicaType":"CONSUMER",
"config":{"entry":{"key":"authorization","value":" 
 BASIC cG9sbHVzZXI6c2VjcmV0"}}}'

'cG9sbHVzZXI6c2VjcmV0'は、polluser資格証明のベース64のエンコード値です。ここでは、コマンドの実行に使用されるrepluserではなく、任意のユーザー資格証明を使用できます。