Replication basics

Репликация MySQL копирует изменения с primary на replicas через binary log (binlog). По умолчанию применение асинхронное — чтение с replica может быть устаревшим.

					-- На replica: сигналы lag
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source (или Seconds_Behind_Master в старых версиях)

-- Осторожно с read/write split
-- Пишем на primary; читаем с replica только если stale допустим
				

Типовые топологии: один primary и read replicas; ручной failover; managed HA в cloud. GTID упрощает позиционирование при failover. Row-based binlog снижает неоднозначность vs statement-based для недетерминированного SQL.

На интервью: replication lag; почему read-your-writes на replica может не сработать; роль binlog; риски failover (split brain, отставание promoted replica).

Типовые ошибки: критичные чтения с replica без мониторинга lag; ожидание синхронной репликации по умолчанию; failover без проверки gap; длинные транзакции раздувают binlog.

Компромисс — масштаб чтения и доступность против eventual consistency и сложности эксплуатации при failover.

Чеклист:

• Мониторьте lag и рост binlog.
• На replica — только чтения, терпящие stale.
• Failover с учётом GTID.
• Тестируйте promote/failover и переподключение приложения.