Если запись идёт в основную БД, а чтение с реплики, то при отставании реплики только что записанные данные не видны.
Почему Из-за потока записей в основную БД реплика отстаёт на несколько секунд → Следствие Если читать только что сохранённые данные с реплики, их там ещё нет → На экране Только что купленный предмет не виден, на торговой площадке старые цены, баги с двойной выдачей
Основной ответственный Команда инфраструктуры · Инфраструктура БД · Совместно Команда разработки · Разработка сервера
Команда разработки: задачи
Только что записанные данные читать из основной БД, проверку факта выдачи и саму выдачу делать в основной БД одной транзакцией (дубли отсекать уникальным ключом или условным UPDATE).
Команда инфраструктуры: задачи
Настроить алерт на отставание репликации, делать реплики не слабее основной БД, включить параллельную репликацию, массовые удаления выполнять мелкими порциями, контролировать долгие агрегирующие запросы на репликах.
На графике
Растёт вслед за онлайном и нагрузкой · отставание репликации (с)
Где смотреть
В MySQL смотреть на реплике Seconds_Behind_Source в SHOW REPLICA STATUS (в версиях до 8.0.22 SHOW SLAVE STATUS). В PostgreSQL смотреть write_lag, flush_lag и replay_lag в pg_stat_replication на основном сервере, в RDS смотреть ReplicaLag
Подтверждает
В моменты жалоб «не видно» отставание составляет несколько секунд и больше, а когда оно рассасывается, всё отображается нормально. Отставание растёт во время потока записей, массовых удалений или долгих агрегирующих запросов на реплике
Опровергает
Если отставание около 0, а данных всё равно не видно, дело в кэше или синхронизации на игровом сервере
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Подробнее
Отставание бывает и без большого потока записей. Одно массовое удаление, которое на основной БД заняло 10 минут, повторно выполняется на реплике и на столько же её задерживает, а долгие агрегирующие запросы на реплике тоже мешают ей догонять.
Источники
SHOW REPLICA STATUS StatementMySQL Seconds_Behind_Source: сколько прошло с момента, когда событие, которое реплика применяет сейчас, было записано на основной БД (отставание репликации)
Replica Server Options and VariablesMySQL replica_parallel_workers: несколько потоков применяют транзакции параллельно (по умолчанию 4, при 0 один поток применяет их по порядку)
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL Потоковая репликация по умолчанию асинхронная, поэтому между коммитом и появлением данных на реплике есть задержка (если реплика успевает, обычно меньше 1 секунды)
The Cumulative Statistics System (PostgreSQL Documentation)PostgreSQL write_lag, flush_lag и replay_lag в pg_stat_replication: время от записи WAL на основном сервере до подтверждения от реплики, что она записала его, сбросила на диск и применила