Грязное чтение в SQL Server AlwaysOn

У меня есть пара баз данных SQL Server 2014, настроенная как синхронная группа доступности AlwaysOn.

Оба сервера установлены в Synchronous commit режим доступности с тайм-аутом сеанса 50 секунд. Вторичный устанавливается как Read-intent only читаемый вторичный.

Если я пишу в первичный, а затем сразу же читаю из вторичного (через ApplicationIntent=ReadOnly), я последовательно читаю грязные данные (то есть состояние до записи). Если я жду примерно секунду между записью и чтением, я получаю правильные данные.

Это ожидаемое поведение? Если да, могу ли я что-нибудь сделать, чтобы убедиться, что показания со вторичного сервера актуальны?

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


sql sql-server acid alwayson
person Paul    schedule 19.09.2016    source источник
comment
Вероятно, лучше для dba.stackexchange.com   -  person Liam    schedule 19.09.2016
comment
Это не грязное чтение, это просто задержка. Прочтите здесь: блоги . msdn.microsoft.com/sqlserverstorageengine/2011/12/22/   -  person dean    schedule 19.09.2016
comment
См. dba.stackexchange.com/questions/84420/. Вкратце: да, это ожидается, и если вы не можете терпеть любую задержку, читайте с основного. Вы могли бы придумать свой собственный механизм для обеспечения актуальности ваших чтений (таблица временных меток с триггером и т.п.), но в большинстве случаев это было бы больше проблем, чем того стоит. Ни в коем случае не смешивайте слепо реплики в одной рабочей нагрузке в ожидании их синхронизации.   -  person Jeroen Mostert    schedule 19.09.2016
comment
Это ожидаемое поведение в режиме доступности синхронной фиксации. Насколько я знаю, есть единственный способ уменьшить задержку, если вы перейдете в режим асинхронной фиксации. Но есть риск потери данных. В режиме асинхронной фиксации первичная реплика фиксирует транзакции, не дожидаясь подтверждения того, что вторичная реплика асинхронной фиксации укрепила журнал. Режим асинхронной фиксации минимизирует задержку транзакций в вторичных базах данных, но позволяет им отставать от первичных баз данных, что делает возможной некоторую потерю данных.   -  person Shiwangini    schedule 24.12.2018

Ответы (1)


arrow_upward
3
arrow_downward

Невозможно получить грязное чтение, если вы не используете подсказку без блокировки.

Когда вы включаете вторичные серверы только для чтения в AlwaysOn .. Внутренне SQL использует версию строки для хранения предыдущей версии строки.

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

вы видите задержку данных ..

Этот whitePaper посвящен этому сценарию. Ниже приведена соответствующая часть, которая помогает в понимании больше об этом ..

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

Задержка данных существует, даже если вы настроили вторичную реплику на синхронный режим. Хотя верно то, что синхронная реплика помогает гарантировать отсутствие потери данных в идеальных условиях (то есть RPO = 0), укрепляя записи журнала транзакций перед отправкой ACK на первичный, это не гарантирует, что поток REDO на вторичной реплике действительно применил связанные записи журнала к страницам базы данных.

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

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

person TheGameiswar    schedule 19.09.2016