変更の追跡とデータの復元
同期が必要なアプリケーションでは、変更の追跡が有効になっているデータベースが以前のバージョンのデータに戻るケースを考える必要があります。この状況は、非同期データベース ミラーへのフェールオーバーや、ログ配布の使用時のエラーに伴い、データベースがバックアップから復元された後に発生する可能性があります。この問題を説明するシナリオを次に示します。
テーブル T1 は変更の追跡の対象になっており、このテーブルの有効な最小バージョンは 50 になっています。
クライアント アプリケーションはバージョン 100 でデータを同期し、バージョン 50 とバージョン 100 の間で発生したすべての変更に関する情報を取得します。
テーブル T1 には、バージョン 100 以降もさらに変更が加えられます。
バージョン 120 でエラーが発生し、データベース管理者がデータベースを復元しますが、これに伴ってデータ損失が発生します。復元操作の後、テーブルにはバージョン 70 までのデータが格納され、最小同期バージョンは 50 のままになります。
これは、プライマリ データ ストアには存在しないデータが同期データ ストアに含まれることを意味します。
T1 は何度も更新されます。その結果、現在のバージョンは 130 になります。
クライアント アプリケーションが再び同期を実行します。このとき、クライアント アプリケーションの最終同期バージョンは 100 になっています。100 は 50 より大きいため、この番号はクライアントの検証を通過します。
クライアントはバージョン 100 と 130 の間の変更を取得します。この時点で、クライアントは 70 と 100 の間の変更が以前と同じではないことを認識していません。クライアントとサーバーのデータは同期されません。
データベースがバージョン 100 より後の時点の状態に復旧された場合は、同期の問題は発生しません。クライアントとサーバーのデータは、次の同期間隔の間に正しく同期されます。
変更の追跡では、データ損失からの復旧はサポートされていません。ただし、この種の同期の問題を検出する方法は 2 つあります。
データベース バージョン ID をサーバーに保存し、データベースの復旧などでデータが失われるたびに、この値を更新する方法。この ID を各クライアント アプリケーションに保存し、各クライアントがデータを同期する際に必ず検証されるようにします。データ損失が発生した場合は ID が一致しなくなり、クライアントが再初期化されます。1 つの欠点は、データ損失が最後に同期された範囲に及んでいない場合に、不要な再初期化が行われる可能性があることです。
クライアントが変更クエリを実行した時点で、最終同期バージョンの番号をクライアントごとにサーバー上に記録する方法。データに問題がある場合は、最終同期バージョンの番号が一致しません。これによって、再初期化が必要であることがわかります。