У нас есть SQL Server 2008, настроенный с основным, зеркальным и контролирующим сервером, зеркало синхронизировано и настроено на автоматическое переключение при отказе. Недавно мы столкнулись с ситуацией, когда у нас закончилось место на основном сервере, что привело к повреждению приложения, использующего базу данных, но не вызвавшего аварийного переключения, даже несмотря на то, что на каждый запрос, выполняемый приложением, отвечал с ошибкой:
The transaction log for database 'XXXX' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
Я пытаюсь понять, почему не произошло переключения при отказе. Это потому, что зеркало / свидетель по-прежнему считает, что сервер работает, поскольку он отвечает на эхо-запросы и запросы (все с ошибкой)? Или это что-то, что мы неправильно настроили? Нужно ли нам добавлять код нашего прикладного уровня, чтобы обнаруживать подобные ошибки базы данных и инициировать аварийное переключение?
Параллельно мы улучшаем наш мониторинг, чтобы попытаться избежать проблем с дисковым пространством, но мы все равно хотели бы повысить надежность автоматического переключения при отказе.
В этом сценарии ваша база данных не была «отключена», просто был заполнен журнал из-за проблем с пространством или распределением. Отработка отказа произойдет только в том случае, если первичная база данных / экземпляр перейдет в автономный режим, а затем свидетель и зеркало могут решить, что зеркало должно быть новым первичным.
Вы можете периодически запускать сценарий (или использовать SQL Alert), который проверяет это условие, которое затем инициирует аварийное переключение, но это может быть немного сложно.
Вы неправильно сконфигурировали - но не на SQL Server.
Ошибки: * Использование расширяемых файлов без наблюдения за уровнем ОС (доступным дисковым пространством) * Очевидно, что отсутствуют процессы управления операциями, когда диск начинает переходить на определенный критический уровень. * Затем интересно, почему что-то не получается.
В основном: подсистема discc в базе данных НИКОГДА не бывает полной - ошибка была не «полный диск», а «некомпетентный администратор».
Можно спорить о том, отказал ли SQL Sever, но, учитывая, что это проблема, которая полностью связана с работой серверов - извините, я не ожидаю, что SQ LServer справится с этим.
Между прочим, производственные базы данных никогда не должны расширять файлы;) Размер их должен быть правильным, изменять размер возможно, но никогда не расширять их автоматически.