4

私のWebアプリはSQLServer2008に対してADO.NETを使用しています。データベースの書き込みはプライマリ（パブリッシャー）データベースに対して行われますが、読み取りはプライマリ（サブスクライバー）データベース間で負荷分散されます。SQL Serverの組み込みのトランザクションレプリケーションを使用して、セカンダリを最新の状態に保ちます。ほとんどの場合、数秒の遅延は問題になりません。

ただし、セカンダリサイトでトランザクションがコミットされるまでブロックしたい場合があります。数秒間ブロックしても問題ありませんが、古いページをユーザーに返すことはできません。ADO.NETまたはTSQLで、レプリケーションが完了するのを待つように指定する方法はありますか？または、発行元から、セカンダリサーバーに手動で接続せずに、トランザクションのレプリケーションステータスを確認できますか。

[編集]99.9％の確率で、サブスクライバーのデータは「十分に新鮮」です。しかし、それを無効にする操作が1つあります。それが無効になるという偶然の機会に、私は毎回出版社から読むことができません。トランザクションレプリケーションでこの問題を解決できない場合は、別のアーキテクチャを提案できますか？

4

2 に答える 2

2

SQL Serverにはそのようなソリューションはありませんが、他の環境でこれを回避する方法は次のとおりです。

アプリケーションで3つの個別の接続文字列を使用し、クエリのニーズに基づいて適切な接続文字列を選択します。

  • リアルタイム-1つのマスターサーバーを直接指します。すべての書き込みはこの接続文字列に送られ、最もミッションクリティカルな読み取りのみがここに送られます。
  • ほぼリアルタイム-負荷分散されたサブスクライバーのプールをポイントします。ここには書き込みはなく、読み取りのみが行われます。大多数のOLTP読み取りに使用されます。
  • レポートの遅延-現在の環境では、同じ負荷分散されたサブスクライバーのプールを指しますが、将来的には、ログ配布などのテクノロジーを使用して、サーバーのプールを8〜24時間遅らせることができます。これらは非常にうまくスケールアウトしますが、データははるかに遅れています。レポート、検索、長期履歴、およびその他の非リアルタイムのニーズに最適です。

これらの3つの接続文字列を最初から使用するようにアプリを設計すると、特に経験している場合は、スケーリングがはるかに簡単になります。

于 2010-01-23T14:37:31.843 に答える
0

あなたは同期ミラーリングの状況を説明しています。レプリケーションは、定義上、要件をサポートできません。レプリケーションは、トランザクションがコミットするのを待ってから、ログから読み取り、ディストリビューターに配信し、そこからサブスクライバーに配信する必要があります。つまり、レプリケーションには、定義上、データが同期していない可能性があります。

データの信頼できるコピーを読み取る操作が必要な場合は、クライアントでその決定を行い、その場合は発行者から確実に読み取る必要があります。

理論的には、特定のトランザクションがサブスクライバーに配布されたかどうかを検証できますが、それに基づいて設計を行うべきではありません。トランザクションレプリケーションは、設計上、遅延を保証しないため、「完璧な日」の操作モードに依存することはできません。

于 2010-01-15T00:41:18.210 に答える