Я создал следующую структуру:
Это работает должным образом, когда дело доходит до подключения к базе данных и ручного переключения при отказе с помощью SSMS (T-SQL). (Пришлось решить проблему с локальными логинами SQL Server, имеющими разные идентификаторы безопасности, поскольку приложение использовало аутентификацию SQL Server, но оно работает). Теперь я попытался имитировать сбой SQL Server, остановив сервер - BAM, AAG полностью не удалось. Расследование с Get-ClusterLog показал, что WSFC сказал: «Отсутствие отказа для группы XXX, failoverCount 3, failoverThresholdSetting 1, lastFailover 1601/01 / 01-00: 00: 00.000». Хорошо, я сказал, давайте подождем 6 часов (таймаут по умолчанию для ресурса WSFC для очистки счетчика отработки отказа), попробовал еще раз - счетчик отказов BAM увеличился до 4. Затем я попытался снизить период отработки отказа до 1 часа и порог до 5 - снова ничего и счетчик отработки отказа снова превысил пороговое значение. Я пошел в Google и обнаружил некоторую информацию о том, что этот таймаут можно уменьшить до нуля, эффективно мгновенно сбросив счетчик отработки отказа - НИ В КОЕМ СЛУЧАЕ, он все равно растет всякий раз, когда я пытался имитировать отработку отказа. Однако, когда я просто перезапускаю теперь основной узел кластера вместе с сервером SQL, AAG должным образом перемещается на оставшийся узел, и реплика локальной базы данных становится основной.
Итак, что делать и как заставить SQL Server 2012 AAG переключиться на другой узел в случае отказа SQL Server, а узел остается в рабочем состоянии?
В качестве примечания, почему последнее время переключения при отказе показывает нули? Может быть, дело в этом или в части симптомов, которая показывает, куда смотреть?