Пока после отказа основной БД идёт переключение на резервную, запись невозможна, а последние данные, которые не успели реплицироваться, могут пропасть.
Почему Из-за отказа основной БД резервная повышается до основной → Следствие Во время переключения запись невозможна от нескольких секунд до нескольких минут, при асинхронной репликации возможна потеря нереплицированных данных → На экране Ненадолго не проходят все сохранения, роллбэк предметов и опыта
Основной ответственный Команда инфраструктуры · Инфраструктура БД · Совместно Команда разработки · Разработка сервера
Команда разработки: задачи
Делать сохранения, которые можно безопасно повторить, настроить быстрый сброс оборванных соединений и переподключение по новому адресу (пул соединений, кэш DNS), проверять переподключение на учениях по переключению.
Команда инфраструктуры: задачи
Использовать синхронную или полусинхронную репликацию (ценой роста задержки записи), проводить учения по переключению, отслеживать время переключения и отставание репликации.
Цифры для ориентира
Автоматическое переключение управляемой БД обычно занимает от десятков секунд до 2 минут. При асинхронной репликации можно потерять последние сохранения за время, равное отставанию репликации (от менее чем 1 секунды до нескольких секунд).
На графике
Массовый обрыв соединений · число соединений с БД, число ошибок записи
Где смотреть
Поставить на один график записи о переключении на стороне БД (в RDS события RDS-EVENT-0013 начало переключения и RDS-EVENT-0049 окончание, в самостоятельно управляемой БД лог повышения реплики) и число соединений с БД и ошибок соединения на игровых серверах. При асинхронной репликации смотреть и отставание репликации перед отказом (ReplicaLag в RDS, replay_lag в pg_stat_replication в PostgreSQL)
Подтверждает
Сбои сохранения сосредоточены в одном отрезке, и он совпадает с интервалом между началом и концом переключения. Потерянный отрезок прогресса примерно равен отставанию репликации перед отказом. Игровой сервер, у которого ошибки продолжаются и после переключения, всё ещё использует соединения со старым адресом
Опровергает
Обрывы соединений в моменты, когда записей о переключении нет, указывают на сеть или перегрузку БД
Failing over a Multi-AZ DB instance for Amazon RDSAWS Переключение Multi-AZ обычно занимает 60–120 секунд, после него нужно заново установить соединения, TTL кэша DNS в JVM рекомендуется не больше 60 секунд
High availability for Amazon AuroraAWS Во время сбоя чтение и запись не проходят, восстановление обычно в пределах 60 секунд (часто в пределах 30)
Semisynchronous ReplicationMySQL При асинхронной репликации после отказа основной БД закоммиченных транзакций может не оказаться на реплике. Полусинхронная репликация сокращает этот риск, дожидаясь подтверждения получения от одной реплики, но задержка растёт
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL Передача журнала асинхронная, поэтому при отказе основного сервера ещё не отправленные транзакции теряются, отставание потоковой репликации обычно меньше 1 секунды