Ошибка replication lag в мониторинге или расхождение данных между основным сервером и копией — типичный признак того, что реплика работает, но отстаёт от мастера. Чтобы понять, почему это происходит и нормально ли это, нужно разобраться в самом механизме: реплика — это копия базы данных, которая автоматически получает изменения с основного сервера и применяет их у себя.
Репликация используется повсеместно: от небольших сайтов на MySQL до распределённых систем вроде PostgreSQL, MongoDB или Redis. Она решает три задачи: отказоустойчивость (если основной сервер упал, копия подхватит работу), распределение нагрузки (запросы на чтение идут на реплики) и географическую близость данных к пользователям. Ниже разберём, как именно устроен этот процесс изнутри.
Основной принцип: поток изменений от мастера к реплике
В классической схеме есть мастер (primary, source) — сервер, который принимает все операции записи, и одна или несколько реплик (slave, standby, secondary), которые эти изменения копируют. Ключевая идея: реплика не получает данные «целиком» при каждом изменении — она получает поток событий, описывающих, что именно изменилось.
В большинстве реляционных СУБД этот поток строится на основе журнала изменений. В MySQL это binlog (binary log), в PostgreSQL — WAL (Write-Ahead Log). Каждая транзакция сначала фиксируется в журнале, а реплика читает этот журнал и последовательно применяет записанные операции к своей копии данных. Пока журнал читается быстрее, чем пишется, реплика находится в актуальном состоянии.
Упрощённо цикл выглядит так: клиент выполняет INSERT или UPDATE на мастере → изменение попадает в журнал → реплика забирает запись из журнала по сети → применяет её локально → подтверждает позицию в журнале. Позиция важна: именно по ней реплика знает, с какого места продолжать после перезапуска или разрыва соединения.
💡Реплика не копирует данные заново — она непрерывно применяет поток изменений из журнала мастера (binlog или WAL), отслеживая свою позицию в нём.