Репликация передаёт изменения от источника (master) к одной или нескольким репликам. Источник записывает каждое зафиксированное изменение в свой бинарный лог (binlog); поток I/O каждой реплики копирует этот лог, а поток SQL/применитель воспроизводит его, так что реплики сходятся к тем же данным.
записи
app ---------> --- binlog ---> <-- чтения
| <-- чтения
+---------- binlog ---> <-- чтения
ROW (логирует фактические образы строк, безопасный вариант по умолчанию), STATEMENT или MIXED.Направляйте записи на источник и распределяйте SELECT по репликам. Приложения с интенсивным чтением (большинство веб-приложений) масштабируют чтение почти линейно, добавляя реплики, тогда как единственный источник по-прежнему обрабатывает все записи.
-- На реплике смотрите, насколько она отстаёт:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- отставание репликации
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
Поскольку асинхронные реплики отстают от источника, пользователь, который пишет, а затем сразу читает с реплики, может не увидеть собственного изменения (нарушение "read-your-writes"). Направляйте чувствительные к задержке или только что записанные чтения на источник или используйте полусинхронную репликацию.
Репликация — это стандартный первый шаг для масштабирования чтения и получения горячего резерва для отказоустойчивости/бэкапов. Её определяющее ограничение — отставание и единственное узкое место записи — формирует реальные архитектуры: оно объясняет, почему вы иногда читаете устаревшие данные и почему масштабирование записи в итоге требует шардинга, а не просто большего числа реплик.
Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать