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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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