У меня две зеркальные машины SQL Server 2016 с настроенным зеркальным отображением.Предполагается, что это схема горячего резервирования.
Размер жесткого диска составляет 1 ТБ, а размер базы данных составляет около 600 ГБ (только одна БД).Это архивированные данные за 90 дней, все, что старше 90 дней, удаляется каждую ночь (автоматически через внешнее приложение, которое в первую очередь использует / заполняет базу данных).Таким образом, 600 ГБ - это максимальный размер БД, он не выходит за рамки обычной очистки.
Проблема в журнале транзакций в случае сбоя одного сервера или приостановки зеркального отображения по какой-либо другой причине.Если я правильно понял принцип, исправный сервер будет хранить журналы транзакций, пока не получит информацию от партнера, что все в порядке.Таким образом, если зеркалирование не удается, жесткий диск будет заполнен в течение нескольких часов.
Есть ли какой-нибудь подходящий метод для предотвращения этого?У меня есть резервные копии журналов каждые 15 минут, и все работает нормально, но если зеркалирование приостанавливается, резервные копии не стоят большого, поскольку журнал будет продолжать расти, несмотря на резервные копии.А ситуация на сайте немного специфична, инженеров нет, только операторы, которые получают доступ к этим данным один или два раза в день, поэтому сразу реагировать невозможно.Чтобы кто-то мог решить проблему, может потребоваться более 24 часов.
Единственное, о чем я могу подумать, это какой-то триггер, который полностью удалит зеркалирование после того, как оно будет приостановлено на некоторое время (или, может быть, еслиприостановлено и место на жестком диске слишком мало).Это предотвратит полный сбой работоспособного сервера, но кто-то снова должен будет зайти на сайт и настроить зеркалирование с нуля.А из-за плохого дизайна с самого начала размер БД превышает половину размера жесткого диска, поэтому я не могу даже создать локальное резервное копирование / восстановление, мне придется делать все через NAS со скоростью 100 Мбит / с, принадлежащее клиенту.И это займет больше времени, чем журнал транзакций, чтобы снова заполнить диск.