Я как раз собираюсь настроить зеркало SQL, но есть одна вещь, которую мне еще не удалось решить. Если я зеркалирую DBA (основной) на DBB (зеркало), а DBA переходит в автономный режим, он автоматически переключается на DBB. Но тогда, насколько я понимаю, любые обновления, которые происходят в DBB, не будут отображаться в DBA ... поэтому, когда DBA вернется в сеть и снова станет активным, все обновления во время простоя будут потеряны? Это правильно или я что-то упустил?
Спасибо! Павел
Что вы упустили, так это то, что программисты MS не являются полными идиотами. Когда администратор базы данных возвращается к работе, он знает, что он устарел, и не будет отвечать, пока не получит данные из B. A не имеет «настоящего» приоритета, особенно с доступным принципалом. B будет там и будет знать, что у него более новая авторизация.
Если A продолжит отвечать и данные на B будут потеряны, эта функция станет совершенно бесполезной.
Есть определенные ситуации, когда что-то случится с основным сервером, и он не сможет выполнить синхронизацию без восстановления сеансов зеркалирования. Но если вы находитесь в режиме высокой безопасности и настроили сервер-свидетель, администратор базы данных может столкнуться с DBB.
Подробнее об этом рассказывается в онлайн-книгах в разделе «Переключение ролей». «Как работает автоматический переход на другой ресурс»
Если основной сервер все еще работает, он изменяет состояние основной базы данных на DISCONNECTED и отключает всех клиентов от основной базы данных.
Следящий и зеркальный серверы регистрируют, что основной сервер недоступен.
Если какой-либо журнал ожидает в очереди повтора, зеркальный сервер завершает повтор транзакций для зеркальной базы данных.
Бывшая зеркальная база данных перемещается в оперативный режим в качестве новой основной базы данных, и восстановление очищает все незафиксированные транзакции, откатывая их как можно быстрее. Блокировки изолируют эти транзакции.
Когда бывший основной сервер снова присоединяется к сеансу, он понимает, что его партнер по отработке отказа теперь владеет основной ролью. Бывший основной сервер берет на себя роль зеркала, делая его базу данных зеркальной базой данных. Новый зеркальный сервер синхронизирует новую зеркальную базу данных с основной базой данных как можно быстрее. Как только новый зеркальный сервер повторно синхронизирует базы данных, восстановление после отказа снова станет возможным, но в обратном направлении.
Таким образом, в вашей ситуации, если / когда администратор базы данных вернется в режим онлайн, он в конечном итоге должен столкнуться с DBB, но сколько времени это займет, зависит от того, насколько быстро работает система, недавняя рабочая нагрузка и количество журналов в очереди повторения.