13 ноября с 14:25 до 14:40 (мск) наблюдалась недоступность сервиса api.mindbox.ru для 10% клиентов.

Корневая причина недоступности — отказ части клиентских баз данных при изменении в кластере серверов.

Влияние на клиента

В время инцидента на пострадавших проектах завершались с ошибкой синхронные вызовы, скапливалась очередь выполнения асинхронных запросов.

Как выявляли и устраняли инцидент

14:37 — сработал алерт на проблему с репликацией данных между основной и резервной репликами баз данных

14:39 — начали поступать жалобы на недоступность административных панелей

14:40 — команда дежурных инженеров приступила к починке, однако работоспособность баз данных уже была восстановлена автоматически

Отчёт

Для хранения баз данных клиентов мы используем кластеры серверов, организованных по технологии WSFC. Это оптимальный вариант для повышения надёжности системы через обеспечение автоматического переключения и синхронизации между серверами и ресурсами в случае неполадок. Для каждого клиента предусмотрена собственная группа доступности, состоящая из основной (primary) и резервной (secondary) репликами.

Нам известно, что любые изменения в кластерах приводят к автоматическому переключению работы на резервные реплики. При этом в базах с долгими активными транзакциями, происходящими например во время расчетов по сложным фильтрам время переключения может составлять до 5 минут. Тем не менее, изменения являются необходимыми для корректной работы системы и полностью исключить их мы не можем. 

Мы связываем возникающие проблемы с обновлением версии SQL Server до 2019 и ищем пути решения, но детальный разбор и починка серьёзно осложнены отсутствием подробной документации по WSFC, являющейся проприетарной технологией компании Microsoft, прекратившей поддержку на территории РФ.

Что улучшили

• Включили функцию Accelerated Database Recovery для снижения времени недоступности БД при аварийных переключениях
• Перенесли базу данных микросервисов в отдельный WSFC кластер. Это первый из двух шагов, позволяющий реагировать на нарушение SLA и SLO превентивно

Что улучшим

• Добавим внешний мониторинг доступности микросервиса, ответственного за клиентский SLA и SLO. Это второй шаг для превентивной реакции на нарушение SLA – 1 квартал 24 

• Обновим версию MS SQL Server в текущем контуре. Новая версия содержит багфиксы в области непрерывной доступности – 1 квартал 24 

• Переделаем схему развертывания клиентских баз данных в ЦОД, изолировав стойки и доведя количество инстанцирований на каждой до 300. Это позволит снизить время возможной недоступности – 1 полугодие 24

• Начнём перенос баз клиентов с MS SQL Server на PostgreSQL для окончательного решения проблемы – 1 полугодие 24