Открыть сервис
Главная → Блог → MySQL Replication

MySQL Replication

MySQL Replication — это механизм асинхронной или полусинхронной синхронизации данных между несколькими серверами баз данных MySQL, при котором изменения, выполненные на одном сервере (источнике, или мастере), автоматически копируются на один или несколько серверов-реплик (слейвов). Репликация используется для масштабирования нагрузки на чтение, обеспечения отказоустойчивости, создания резервных копий в реальном времени и географического распределения данных.

История

Репликация в MySQL появилась в ранних версиях в виде асинхронного механизма, основанного на бинарном логе (binary log). Первоначально она была реализована как односторонняя репликация «мастер-слейв» (master-slave). В версии MySQL 3.23.15 (1999 год) была введена поддержка репликации, но она была нестабильной. Начиная с MySQL 4.0 (2003 год), репликация стала более надёжной и получила поддержку различных форматов журналирования.

В MySQL 5.1 (2008 год) была добавлена поддержка полусинхронной репликации, а также появился механизм репликации на основе строк (row-based replication). В MySQL 5.5 (2010 год) была улучшена производительность и стабильность. В MySQL 5.6 (2013 год) появилась глобальная идентификация транзакций (GTID), что упростило управление репликацией. В MySQL 5.7 (2015 год) была добавлена многопоточная репликация, ускоряющая обработку изменений на слейвах.

В версии MySQL 8.0 (2018 год) была представлена групповая репликация (Group Replication), основанная на протоколе Paxos, которая обеспечивает автоматическое управление кластером и согласованность данных. Также была добавлена поддержка репликации с несколькими источниками (multi-source replication).

Принцип работы

Репликация в MySQL основана на журналировании изменений. Основные компоненты:

  • Мастер (источник): сервер, на котором выполняются операции записи (INSERT, UPDATE, DELETE). Он записывает все изменения в бинарный лог (binary log) в виде событий.
  • Слейв (реплика): сервер, который получает и применяет изменения от мастера. Он подключается к мастеру, читает бинарный лог и записывает его в свой релейный лог (relay log), а затем применяет события к своей локальной базе данных.
  • Бинарный лог (binlog): последовательность событий, описывающих изменения данных на мастере. Каждое событие соответствует одной транзакции или изменению строки.
  • Релейный лог (relay log): копия бинарного лога мастера, хранящаяся на слейве. Слейв читает события из релейного лога и применяет их.
  • Поток ввода/вывода (I/O thread): на слейве этот поток подключается к мастеру, читает события из бинарного лога мастера и записывает их в релейный лог.
  • Поток SQL (SQL thread): на слейве этот поток читает события из релейного лога и применяет их к локальной базе данных.

Процесс репликации:

  1. Мастер записывает изменения в бинарный лог.
  2. I/O thread на слейве подключается к мастеру и запрашивает новые события.
  3. Мастер отправляет события слейву.
  4. I/O thread записывает полученные события в релейный лог.
  5. SQL thread читает события из релейного лога и выполняет их на слейве.

Типы репликации

Асинхронная репликация

По умолчанию MySQL использует асинхронную репликацию. Мастер не ждёт подтверждения от слейва о том, что изменения были применены. Мастер завершает транзакцию сразу после записи в свой бинарный лог. Это обеспечивает максимальную производительность мастера, но может привести к потере данных при сбое мастера, если слейв ещё не получил изменения.

Полусинхронная репликация

В полусинхронной репликации мастер ждёт подтверждения от хотя бы одного слейва о том, что событие было записано в его релейный лог (но не обязательно применено). Транзакция на мастере завершается только после получения такого подтверждения. Это повышает надёжность, но снижает производительность мастера. Полусинхронная репликация реализована через плагин rpl_semi_sync_master и rpl_semi_sync_slave.

Синхронная репликация (Групповая репликация)

Групповая репликация (Group Replication) — это синхронный механизм, при котором все серверы в группе должны подтвердить применение транзакции, прежде чем она будет зафиксирована. Она использует протокол консенсуса Paxos для обеспечения согласованности данных. Групповая репликация поддерживает автоматическое управление кластером, обнаружение сбоев и автоматическое переключение (failover). Она доступна в MySQL 8.0 и более поздних версиях.

Репликация с несколькими источниками (Multi-source replication)

Эта функция позволяет слейву получать изменения от нескольких мастеров одновременно. Каждый мастер имеет свой собственный канал репликации. Это полезно для объединения данных из разных источников или для создания централизованного хранилища данных.

Форматы бинарного лога

MySQL поддерживает три формата журналирования событий:

  • Statement-based (SBR): в бинарный лог записываются SQL-запросы (INSERT, UPDATE, DELETE). Слейв выполняет те же самые запросы. Этот формат может быть недетерминированным (например, при использовании NOW() или RAND()).
  • Row-based (RBR): в бинарный лог записываются изменения отдельных строк (какие строки были изменены и на какие значения). Этот формат детерминирован и безопасен, но может генерировать большие объёмы данных.
  • Mixed (MBR): MySQL автоматически выбирает между SBR и RBR в зависимости от типа запроса. По умолчанию используется SBR, но для недетерминированных запросов переключается на RBR.

Топологии репликации

Мастер-слейв (Master-Slave)

Один мастер и один или несколько слейвов. Все изменения выполняются на мастере, а слейвы используются для чтения. Это самая распространённая топология.

Мастер-мастер (Master-Master)

Два мастера, каждый из которых может принимать записи. Изменения реплицируются между ними. Эта топология требует осторожного управления конфликтами (например, с помощью автоинкремента с разными шагами). Она может использоваться для отказоустойчивости, но не рекомендуется для критически важных систем без дополнительных механизмов разрешения конфликтов.

Звезда (Star)

Один мастер и несколько слейвов, которые могут быть подключены к мастеру напрямую или через другие слейвы (каскадная репликация).

Кольцо (Ring)

Несколько мастеров, соединённых в кольцо. Каждый мастер реплицирует изменения на следующего. Эта топология сложна в управлении и подвержена конфликтам.

Древовидная (Tree)

Мастер реплицируется на несколько слейвов, которые, в свою очередь, могут быть мастерами для других слейвов. Используется для распределения нагрузки на чтение.

Применение

  • Масштабирование нагрузки на чтение: слейвы обслуживают запросы SELECT, разгружая мастер.
  • Отказоустойчивость: при сбое мастера можно переключить один из слейвов на роль мастера (failover).
  • Резервное копирование: слейв можно использовать для создания резервных копий без остановки мастера.
  • Географическое распределение: данные копируются в разные дата-центры для снижения задержек.
  • Аналитика и отчёты: слейвы могут использоваться для выполнения тяжёлых аналитических запросов, не влияющих на производительность основного сервера.
  • Тестирование и разработка: слейвы могут использоваться для тестирования новых версий MySQL или приложений на реальных данных.

Настройка и управление

Настройка репликации включает следующие шаги:

  1. Включение бинарного лога на мастере (log_bin = ON).
  2. Создание пользователя для репликации на мастере (CREATE USER ... REPLICATION SLAVE).
  3. Снятие дампа базы данных с мастера и восстановление его на слейве.
  4. Настройка слейва (CHANGE MASTER TO ...).
  5. Запуск репликации (START SLAVE).

Для мониторинга используются команды SHOW MASTER STATUS, SHOW SLAVE STATUS. Для управления репликацией — STOP SLAVE, RESET SLAVE, CHANGE MASTER.

Проблемы и ограничения

  • Задержка репликации (lag): слейв может отставать от мастера, особенно при высокой нагрузке.
  • Потеря данных: при асинхронной репликации возможна потеря данных при сбое мастера.
  • Конфликты: в топологиях с несколькими мастерами возможны конфликты при одновременной записи одних и тех же данных.
  • Сложность управления: кластеры с несколькими мастерами и каскадной репликацией требуют тщательного администрирования.
  • Размер бинарного лога: бинарный лог может занимать много места на диске.
  • Не все операторы детерминированы: при использовании SBR некоторые функции (например, UUID(), RAND()) могут давать разные результаты на мастере и слейве.

Альтернативы

  • Групповая репликация (Group Replication): встроенный механизм синхронной репликации.
  • MySQL Cluster (NDB Cluster): распределённая база данных с автоматическим шардированием и репликацией.
  • Galera Cluster: стороннее решение, обеспечивающее синхронную репликацию с поддержкой нескольких мастеров.
  • ProxySQL и другие балансировщики: используются для маршрутизации запросов между мастером и слейвами.

Источники

  • Официальная документация MySQL по репликации (MySQL 8.0 Reference Manual, Chapter 17: Replication).
  • Книга «High Performance MySQL» (Baron Schwartz, Peter Zaitsev, Vadim Tkachenko).
  • Статьи и руководства на сайте dev.mysql.com.
  • Материалы конференций Percona Live и MySQL Conference.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы