標準のカスタム プロバイダーのデザインに関する注意事項
実稼働データ ストアと同様、同期にかかわるデータ ストアは定期的にバックアップする必要があります。バックアップからデータ ストアを復元する必要がある場合、以下の問題に注意してください。
復元後にデータ ストアで行われた変更は他のレプリカに反映されない可能性があります。
この現象は、同期元レプリカで行われた変更にバージョンを割り当てるために使用されるティック数に基づいて、変更が期限切れと見なされることがあるために発生します。たとえば、同期元プロバイダーから同期先プロバイダーに変更が送信されるとします。この同期先プロバイダーによって変更が適用され、そのナレッジが更新されます。同期元レプリカはそれよりも前のバックアップから復元されたもので、以前のティック数が含まれています。同期元レプリカで行われた変更には、この以前のティック数に基づいてバージョンが割り当てられます。この状況でもう一度同期を実行すると、同期元プロバイダーから列挙された一部の変更については、同期先ナレッジに正しいティック数が存在しないため期限切れと見なされ、それらの変更が同期先レプリカに適用されません。
この状況で推奨される解決方法は、バックアップからレプリカを復元するたびに新しいレプリカ ID を割り当てることです。その結果、復元されたレプリカは、バックアップされたレプリカからすべてのデータを受け取った新しいレプリカとして処理され、バックアップされたレプリカは、同期コミュニティからリタイアしたレプリカとして処理されます。レプリカ ID が新しいので、同期コミュニティ内のその他のレプリカには復元されたレプリカのナレッジはありません。したがって、復元されたレプリカに追加された新しい項目は同期中に正しく送信されます。
Metadata Storage Service を使用してメタデータを格納する場合、レプリカ ID を変更するには追加の手順を実行する必要があります。追加の手順を以下に示します。
バックアップからの復元用に設計された特別なモードで実行できるようにプロバイダーを実装します。復元モードでは、同期先プロバイダーは、メタデータの変更だけを同期先レプリカに適用します。プロバイダーは、ローカルの変更を検出せず、変更データをレプリカに適用しません。
バックアップからレプリカを復元します。バックアップからレプリカを復元した後、プロバイダーの 2 つのインスタンスを作成します。同期元プロバイダーは、古いレプリカ ID を持つ復元されたレプリカを表し、同期先プロバイダーは、新しいレプリカ ID および新しいメタデータ ストアを持つ復元されたレプリカを表します。同期先プロバイダーを復元モードにします。
同期元プロバイダーから同期先プロバイダーに同期します。新しいレプリカ ID で新しいメタデータ ストアが挿入されます。
古いメタデータ ストアを削除して、新しいメタデータ ストアおよびレプリカを表す新しいレプリカ ID を使用します。これで同期コミュニティの残りの部分と同期する準備が整いました。
以前に作成して同期した項目と同じ名前の新しい項目を復元後に作成した場合、名前の競合が発生する可能性があります。
たとえば、同期元レプリカにファイルを格納するとします。同期元プロバイダーから、"MyChange.txt" という名前のファイルを作成する変更が送信されました。同期元レプリカはそれよりも前のバックアップから復元されたもので、MyChange.txt は含まれていません。同期元プロバイダーによって、新しい MyChange.txt ファイルが作成され、新しい項目 ID が割り当てられます。この状況でもう一度同期を実行すると、MyChange.txt の変更が送信されたときに、同期先プロバイダーで 2 つの MyChange.txt ファイル間の制約の競合が検出されます。名前が同じで項目 ID が異なるためです。
この状況で推奨される解決方法は、プロバイダーの制約の競合を処理することです。この方法により、名前の競合が発生した場合、制約の競合として報告され、正しく解決されます。制約の競合の詳細については、「制約の競合の検出および解決」を参照してください。