次の方法で共有

データベースのバックアップと復元

  • [アーティクル]

実稼働データベースと同様、同期にかかわるデータベースは定期的にバックアップする必要があります。バックアップからデータベースを復元する必要がある場合は、主に 2 つの注意事項があります。

  • 復元後にデータベースで行われた変更は、クライアントまたはその他のピアに反映されていない可能性があります。これは、データベースから変更が選択される際に使用される timestamp 値が原因です。

    たとえば、クライアントとサーバーの同期中、Sync Framework は、サーバー データベースから新しいアンカー値を取得し、その値をクライアント データベースに格納します。この値は、現在同期中の一連の変更の上限として使用されます。詳細については、「サーバー データベースの変更の追跡」を参照してください。サーバー データベースが復元された後、クライアント データベースに格納されている値は、論理的に、サーバー データベースによって返される値よりも進んでいる場合があります。

  • アップロードおよび双方向のシナリオの場合、クライアントまたはその他のピアには、新しく復元されたデータベースにない変更が含まれている場合があります。

このトピックでは、例としてクライアントとサーバーの同期を使用しています。同様の原理がピア ツー ピア同期にも当てはまり、ピア ツー ピアでの考慮事項としてもこの説明を応用できます。サーバー データベースをリモート ピア、クライアント データベースをローカル ピアとして考えることができます。SqlSyncProvider を使用して同期される SQL Server データベースのバックアップと復元の詳細については、「データベースのバックアップと復元方法 (SQL Server)」を参照してください。

サーバー データベース

Sync Framework サンプル データベース内の Sales.Customer テーブルで更新がどのように追跡されるかを見てみると、クライアント データベースがサーバー データベースよりも論理的に進んだ状態になる場合があることを理解できます。UpdateTimestamp 列には timestamp 値が格納され、新しいアンカー コマンドは SQL Server の MIN_ACTIVE_ROWVERSION 関数から値を返します。わかりやすくするために、この例では、16 進数値ではなく整数を使用します。

  1. データベースの復元前は、MIN_ACTIVE_ROWVERSION は値 31 を返します。この値は、最後に受け取ったアンカーとしてクライアント データベースに格納されたものです。

  2. データベースが復元されると、MIN_ACTIVE_ROWVERSION は値 19 を返します。

  3. 更新が行われ、UpdateTimestamp 列の timestamp 値が 32 になります。

  4. 同期が発生すると、MIN_ACTIVE_ROWVERSION は値 32 を返します。32 は最後に受け取ったアンカー値 31 を超えるので、Sales.Customer に対する最後の更新がダウンロードされます。19 から 31 までの更新は変更として認識されません。

タイムスタンプなどの論理クロックを使用する追跡方法は、こうした認識されない変更という問題の影響を受けやすくなります。日時に基づいたデータ型を使用する追跡方法は影響を受けません。これは、ウォール クロックがデータベースの状態とは無関係に進むためです。ピア ツー ピア同期では、変更追跡にタイムスタンプが必要です。

タイムスタンプによって生じる問題に対処するには、次の方法のいずれかを使用します。

  • サーバーのタイムスタンプを復元操作の前の時点まで戻します。上記の例では、MIN_ACTIVE_ROWVERSION が 31 を返すまで、個別のテーブルに対してダミー更新を実行します。

    これは、ピア ツー ピア同期を行う場合に推奨される方法です。

  • 各クライアントのアンカーをサーバーに格納します。上記の例では、バックアップから最後に受け取ったアンカーが 19 になります。したがって、その後の更新が認識され、19 から 32 までのすべての変更がダウンロードされます。Sync Framework では、これに対する組み込みのサポートを提供していませんが、次の方法でサーバー上にシステムを作成できます。

    1. 各クライアントの行を含むサーバー データベース内にテーブルを作成します。テーブルには、Sync Framework によって各クライアントに生成される ID の列と、そのクライアントのアンカーを含む列があります。同期中、アプリケーションは、新しいアンカー値でこの列を更新します。

    2. 同期中のクライアントに対する最小のアンカー値が選択されるように、同期コマンドを変更します。この値は、クライアント データベースに格納されている値であることも、サーバー データベースに格納されている値であることも考えられます。データベースの復元操作の後は、サーバー データベースの値の方が小さくなります。サーバー テーブルに値を書き込んでから変更がクライアントに適用されるまでにエラーが発生した場合は、クライアント データベースの値の方が小さくなります。同期が予想どおりに行われていれば、値は等しくなります。挿入コマンドは次のように記述できます。

      SELECT CustomerId, CustomerName, SalesPerson, CustomerType
FROM Sales.Customer
WHERE (InsertTimestamp > (SELECT AnchorValue from ServerAnchorTable WHERE ClientId = @sync_client_id)
OR InsertTimestamp > @sync_last_received_anchor) AND InsertTimestamp <= @sync_new_received_anchor
AND InsertId <> @sync_client_id

クライアント データベース

同期メタデータを使用してサーバー データベースを現時点に復元しても、サーバー バックアップが行われた後にクライアントで行われた変更はデータベースから欠落している場合があります。クライアントが適切に応答できるようになるには、サーバー データベースが復元されたことをクライアントに認識させる必要があります。これを行うには、特定のクライアントが最後に同期されてから復元が発生したかどうかを示す、サーバー側の追跡テーブルを使用します。クライアント アプリケーションは、同期セッションのたびに、まずこのテーブルをチェックして、通常どおりに同期できるか、復元されたデータベースと連動するために特殊なコードを実行する必要があるかどうかを判断します。

クライアント アプリケーションは、サーバー データベースが復元されたことを認識した後で、クライアント データベースとサーバー データベースを統合できるようになります。データベースの統合は、以下を含むいくつかの方法で行うことができます。

  • すべてのテーブルを削除してから、サーバーと同期することによって、クライアント データベースを再初期化します。この方法は最も簡単ですが、クライアント側の変更はすべて失われます。

    再初期化は、ピア ツー ピア同期を行う場合に推奨される方法です。ピア データベースの初期化の詳細については、「コラボレーション同期を構成して実行する方法 (SQL Server 以外)」の「サーバー データベースの初期化」を参照してください。

  • クライアント テーブルのコピーを作成した後で、クライアント データベースを再初期化します。これを行うには、アプリケーションで次のような手順を踏みます。

    1. サーバー データベースが復元されたことを確認します。

    2. クライアント データベース内のすべてのテーブルのコピーを作成してから、元のテーブルを削除します。

    3. サーバーと同期して、新しいスキーマとデータをダウンロードします。

    4. 新しいテーブルの行と作成したコピーを比較します。

    5. 2 組のテーブル間の違いを特定し、必要な変更を新しいテーブルに適用します。

    6. 再び同期して、新しいテーブルに適用された変更をアップロードします。

参照

概念

アプリケーションのデザインと配置に関する注意点