Comments 4
Регулярная сверка данных в локальных индексах с БД
Подскажите, что за сверки. Я так понял данные в индексе могут в каких-то случаях разъезжаться с БД. Как это обнаруживать и устранять?
Да, иногда в случае резкой нештатной остановки сервиса или бага в коде часть изменений могут потеряться и не доехать до индекса.
Для этого раз в день в наименее загруженное время можно запускать фоновую задачу, которая выгрузит на диск 2 списка пар [ID клиента, timestamp последнего изменения] из базы и поискового индекса. Дальше упорядочит их и сравнит между собой. Если есть расхождения, то по проблемным IDникам клиентов нужно заново загрузить полное состояние из БД и обновить им индекс. Выгружать данные на диск нужно, чтобы не держать их в памяти и не словить ошибку OutOfMemory. Задача в зависимости от объема может работать от нескольких минут до пары часов.
спасибо за быстрый ответ, интересное решение.
Получается, что технически полдня (смотря сколько до операции) может неверно работать поиск по "кривым записям" и прочие процессы, если есть рассинхрон? Не думали над тем, есть ли более надежные вариант решения такой задачи, или этого достаточно, и рисков нет?
Ну тут все же речь шла о нештатной ситуации. Поддержка после жесткого падения прибегает и сразу запускает задачу сверки, чтобы проверить и устранить рассинхрон максимально быстро.
А периодический запуск по ночам - это больше для контроля что нет каких-то багов в логике синхронизации.
Нужно понимать, что записи в индексе всегда будут немного отставать из-за асинхронной природы обновления. Поэтому если нужна гарантия максимально свежих данных, то можно проверить временную метку перед тем как возвращать данные из индекса, и если она старее метки из БД, то взять данные целиком из БД. Запрос метки последнего обновления из БД очень легкий и сильно базу не нагружает.
Как перейти на многонодовую архитектуру без боли. Или почти без боли