Безопасно ли включать отложенную стойкость на подписчике репликации транзакций?

Question

В среде репликации транзакций с издателем SQL Сервер, который часто получает вставки и обновления от приложения и подписчика SQL Сервер с заданиями репликации по запросу, безопасно ли включать отложенную стойкость на подписчике?

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

Пока есть Всегда есть риск при включении отложенной устойчивости, есть ли дополнительный риск при включении этого для подписчика репликации? Если он не поддерживается или есть дополнительные риски, есть ли способ уменьшить время ожидания WRITELOG на подписчике? Подписчик - это сервер отчетов, и его ожидание номер один всегда - WRITELOG из-за частых вставок и обновлений, происходящих на издателе из приложения (45,3 часа ожидания WRITELOG при 345,1 часа безотказной работы).

Answer 1

Прежде всего, кого это волнует? Ожидания WRITELOG выполняются агентом распространения, а не пользователями.

Во-вторых, учли ли вы нормальную оптимизацию производительности для репликации, ie Повышение производительности репликации транзакций , в частности Потоки подписки ?

Параметр –SubscriptionStreams может значительно повысить производительность агрегированной репликации. Это позволяет нескольким соединениям с подписчиком применять пакеты изменений параллельно, сохраняя при этом многие характеристики транзакций, присутствующие при использовании одного потока. Если одно из соединений не может быть выполнено или зафиксировано, все соединения прервут текущий пакет, и агент будет использовать один поток для повторения неудачных пакетов. До завершения этой фазы повтора могут возникнуть временные несоответствия транзакций на подписчике. После успешной фиксации неудачных пакетов подписчик возвращается в состояние согласованности транзакций.

Параллельная запись подписчику повысит пропускную способность репликации , а должно уменьшить совокупное WRITELOG ожидает, пока параллельные транзакции могут перемещаться по каждому IO файла журнала.

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