Запись ушла в лидера, а чтение — на асинхронную реплику, которая ещё не догнала. Это нормальное поведение асинхронной репликации; приложение должно давать нужные гарантии само.
А ещё Мониторить отставание и выводить из балансировки сильно отставшие реплики
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
При асинхронной репликации лидер подтверждает запись, не дожидаясь реплик. Обычно реплики отстают на миллисекунды, но под нагрузкой, при долгих транзакциях, тяжёлых миграциях или сетевых проблемах — на секунды и минуты. Тогда возможны аномалии:
Решения для «вижу своё» (read-your-writes):
Монотонное чтение — закрепить пользователя за одной репликой (хеш user_id), чтобы последовательные чтения не шли назад во времени.
Причинная согласованность — писать связанные данные в один шард или передавать «версию» прочитанного, чтобы зависимые данные читались не старше неё.
В интерфейсе иногда достаточно оптимистичного обновления: показать сохранённое сразу из ответа на запись, не перечитывая.
Эксплуатация:
sottopg_stat_replication, replay_lag; Seconds_Behind_Master) и алерт;def get_profile(user_id, session):
# недавно писал — читаем с лидера, иначе с реплики
if session.get("wrote_at", 0) > time.time() - 5:
return primary.fetch_profile(user_id)
return replica_for(user_id).fetch_profile(user_id) # одна реплика на пользователя — монотонноsotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.