ждать репликации транзакций в ADO.NET или TSQL

Question

Мое веб-приложение использует ADO.NET против SQL Server 2008. Операции записи в базу данных выполняются для основной базы данных (издателя), но чтения сбалансированы по нагрузке для основной и дополнительной базы данных (подписчика). Мы используем встроенную в SQL Server репликацию транзакций, чтобы поддерживать вторичность в актуальном состоянии. В большинстве случаев задержка в несколько секунд не является проблемой.

Однако у меня есть случай, когда я хотел бы заблокировать, пока транзакция не будет зафиксирована на дополнительном сайте. Блокировка на несколько секунд - это нормально, но возврат устаревшей страницы пользователю - нет. Есть ли способ в ADO.NET или TSQL указать, что я хочу дождаться завершения репликации? Или я могу от издателя проверить состояние репликации транзакции, не подключаясь к вторичному серверу вручную.

[править] 99,9% времени, данные в подписчике "достаточно свежо". Но есть одна операция, которая делает его недействительным. Я не могу читать от издателя каждый раз, когда он может стать недействительным. Если я не могу решить эту проблему при репликации транзакций, можете ли вы предложить альтернативную архитектуру?

Answer 1

Нет такого решения для SQL Server, но вот как я работал с ним в других средах.

Используйте три отдельные строки подключения в своем приложении и выберите правильную в зависимости от потребностей вашего запроса:

• Realtime - указывает прямо на один главный сервер. Все записи идут в эту строку подключения, и только самые важные для чтения операции идут сюда.
• Near-Realtime - указывает на пул абонентов с балансировкой нагрузки. Здесь нет записей, только чтение. Используется для подавляющего большинства операций чтения OLTP.
• Отложенная отчетность. В вашей среде прямо сейчас она будет указывать на тот же пул подписчиков с балансировкой нагрузки, но в будущем вы можете использовать такую ​​технологию, как доставка журналов, чтобы иметь пул серверов с отставанием на 8-24 часа. Они очень хорошо масштабируются, но данные далеко позади. Он отлично подходит для отчетов, поиска, долгосрочной истории и других потребностей, не связанных с реальным временем.

Если вы спроектировали свое приложение так, чтобы использовать эти 3 строки подключения с самого начала, масштабирование будет намного проще, особенно в том случае, если вы испытываете это.

Answer 2

Вы описываете ситуацию синхронного зеркалирования. Репликация по определению не может поддержать ваше требование. Репликация должна дождаться подтверждения транзакции, прежде чем читать ее из журнала и передавать ее распространителю, а оттуда - подписчику, что означает, что репликация по определению имеет возможность для синхронизации данных .

Если вам требуется операция по чтению достоверной копии данных, то вы должны принять это решение на клиенте и убедиться, что в этом случае вы читаете от издателя.

Хотя вы можете, по сути, проверять, была ли определенная транзакция распределена подписчику или нет, вы не должны основывать на ней свой дизайн. Репликация транзакций не обеспечивает гарантированную задержку, поэтому вы не можете полагаться на режим работы «идеальный день».