Единственный экземпляр SQL Server становится общей точкой отказа для нескольких систем.
Термин и практика
SQL Server
Платформа баз данных и устойчивость критичных систем. Microsoft SQL Server хранит данные 1С и других прикладных систем. Его отказоустойчивость определяется не одной настройкой, а связкой архитектуры, резервирования, контроля производительности и регулярно проверяемого восстановления.
Практический фокус
Какие проблемы встречаются
Даже при внедрённой системе могут сохраняться ручные операции, расхождения данных и неясная ответственность.
Резервные копии создаются, но восстановление на контрольном контуре не проверяется.
Always On или кластер настроены технически, однако переключение не связано с допустимым временем простоя и потерей данных.
Рост журнала транзакций, блокировки, тяжёлые запросы и нехватку ресурсов замечают после замедления 1С.
После аварии непонятно, кто принимает решение о переключении, как проверяется целостность и когда система возвращается в штатный режим.
Как мы
подходим к решению
Сначала смотрим на фактическую работу, затем выбираем изменение в процессе, данных, интерфейсе или интеграции.
Шаг 1
Определяем требования бизнеса к допустимому простою и потере данных для каждой критичной базы.
Шаг 2
Проверяем экземпляры SQL Server, хранилище, сеть, кворум, версии, лицензирование и зависимости прикладных систем.
Шаг 3
Выбираем подходящую схему: резервные копии, log shipping, Always On Availability Groups, отказоустойчивый кластер или их обоснованное сочетание.
Шаг 4
Настраиваем наблюдаемость: доступность реплик, задержку синхронизации, задания резервного копирования, место, блокировки, ожидания и ресурсы.
Шаг 5
Проводим учебное восстановление и переключение, фиксируем ответственных, порядок проверки данных и безопасный возврат к штатной работе.
Кейсы
по теме
Все кейсы →ПРАКТИЧЕСКИЙ РАЗБОР
Подготовка ИТ ландшафта к росту: разбор причины
Риски масштабирования проявлялись только при изменении объёмов.
Результат: Развитие стало учитывать будущую нагрузку, а не только текущую потребность.ПРАКТИЧЕСКИЙ РАЗБОРПодготовка ИТ ландшафта к росту: решение и контроль
Риски масштабирования проявлялись только при изменении объёмов.
Результат: Развитие стало учитывать будущую нагрузку, а не только текущую потребность.ПРАКТИЧЕСКИЙ РАЗБОРПеренос сервисов в устойчивую инфраструктуру: разбор причины
Отказ компонента мог привести к простою важного участка.
Результат: Инфраструктурные риски для критичных сервисов стали ниже.ПРАКТИЧЕСКИЙ РАЗБОРПеренос сервисов в устойчивую инфраструктуру: решение и контроль
Отказ компонента мог привести к простою важного участка.
Результат: Инфраструктурные риски для критичных сервисов стали ниже.Статьи
по теме
Все статьи →Обсудим, как эта технология используется в вашей компании и какие задачи требуют решения.
Обсудить проблемный участок ↗