Автоматическая синхронизация клиентской истории при откате серверных баз MyChat
В компаниях, где MyChat давно стал привычным инструментом ежедневного общения, системы работают как часы — до тех пор, пока не случается нечто непредвиденное. «Железо умерло», «По ошибке сделали удаление критичных данных», «Нужен перенос сервера на другую площадку» — так коротко описывают администраторы одну из причин, по которой приходится делать откат серверных баз данных: восстановление из архива, тот самый rollback.
По умолчанию MyChat еженедельно создает автоматические резервные копии, по пятницам. Но администратор может вмешаться, запуская резервирование вручную: чаще, в другой день — как ему удобно. И вот здесь начинается та самая проблема.
Откат баз сервера из бекапа — всегда не по плану 🙂
История сообщений в MyChat хранится не только на сервере, но и на клиентах, чтобы не скачивать её каждый раз после соединения с сервером, как в web-версии в браузере. В больших компаниях за годы накопились сотни мегабайт приватных диалогов и конференций: переписка активна, данные свежие. И если backup сервера сделался в пятницу вечером, а восстановление из резервной копии администратор сделал в среду на следующей неделе, то возникает рассинхрон: на клиентах кеш истории новее, чем на сервере (разница в несколько дней).
Система изначально не была готова к такому сценарию. На форуме поддержки люди периодически писали про это. Клиентское приложение «магическим образом» не догадается, что администратор сервера сделал восстановление базы. Ведь восстановление происходит вручную, выборочно, иногда — частично, в зависимости от ситуации. Серверу нечем подтвердить, что что-то изменилось и сказать про это клиентскому приложению. Из архива просто достали файлы, положили на сервер и перезапустили его. Никаких системных маркеров, никакой сигнализации. Сервер не может узнать о том, что были изменения. Клиент, соответственно, тоже ничего не знает про это.
Последствия ощутимы: при отправке сообщений в приватах и конференциях начинается странное: визуальное дублирование сообщений. Пока индексация сообщений «не выровняется» и сервер не примет столько же сообщений, сколько было с пятницы по среду, когда был откат, пользователи рискуют видеть пропуски, дубликаты, рассогласования.
Историю откатили на сервере — а на клиентах остались «свежие» сообщения
Раньше ситуация решалась так: мы советовали остановить клиентское приложение, вручную «прибить» файл локальной истории, а затем запустить приложение. Начнётся синхронизация, и всё будет ок. Но это решение в стиле «программиста в закрытой комнате», как в анекдоте про фрактальное сжатие:
— Как сжать изображение 4K в 1 килобайт? — Закрываем программиста в комнате и не выпускаем, пока он не разработает алгоритм сжатия картинки.
Если в компании хотя бы пару сотен рабочих мест — решение утопичное.
Чтобы переломить ситуацию, наша команда разработки внедрила технологию, которая меняет правила игры. Мы внедрили технологию определения того, что на сервере был сделан rollback баз — полный или частичный. Как только клиент понимает, что произошло восстановление, он очищает локально у себя базы данных истории и кэши, и делает reconnect к серверу. Далее — управляемая синхронизация.
Сначала — «частичная». Это необходимый минимум, чтобы не грузить сервер. Клиент подключается, получает критически важные данные и готов к работе. Полная выгрузка истории запускается только по явному запросу пользователя. Если тот откроет историю и увидит пустое окно, система честно предупредит: «Извини, истории сейчас нет, но я начинаю синхронизацию, подожди. Когда я закончу, откроется полностью окно истории». Благодаря такому подходу не создаётся ненужная нагрузка, кроме того, она будет очень сильно «размазана». Пользователи не бросаются одновременно читать архивы, а история подтягивается частично, по мере открытия приватных диалогов и конференций.
Теперь стало хорошо. Главное — делать ничего не надо 🙂
В идеале пользователи вообще ничего не заметят. Всё будет работать так, как и раньше. Единственное напоминание о произошедшем найдут лишь самые внимательные — в лог сделается запись, что клиент определил, что был rollback и почистил историю и кэши: «[INFO] Detected server databases rollback, removing local database caches…».
Так в MyChat появился «невидимый страж согласованности»: автоматическое распознавание откатов серверных баз и мягкое восстановление клиентской истории. Без лишнего шума и пыли, без перегруза и с сохранением привычного темпа работы — даже если «железо на сервере умерло» и всё пришлось собирать заново.
