Репликация MySQL master-slave является основой для создания MySQL с высокой доступностью.Репликация предназначена для синхронизации данных одного сервера с другими серверами.Одна основная база данных может быть синхронизирована с несколькими резервными базами данных, а резервная база данных также может мастер другого сервера.библиотека. Между основной базой данных и резервной базой данных может быть множество различных комбинаций.
репликация master-slave
1) Основная библиотека записывает бинарный лог.Каждый раз перед отправкой транзакции для завершения обновления базы данных сначала записывается бинарный лог.После записи бинарного лога основная библиотека сообщит механизму хранилища, что транзакцию можно отправить.
2) Резервная библиотека копирует бинарный журнал основной библиотеки в локальный журнал ретрансляции.Во-первых, резервная библиотека сначала запускает рабочий процесс, называемый рабочим потоком ввода-вывода, который отвечает за установление обычного клиентского соединения с основной библиотекой. . Если процесс догонит основную библиотеку, он перейдет в спящий режим, пока в основной библиотеке не появится новое событие, чтобы его уведомить, он будет разбужен, а полученное событие будет записано в журнал ретрансляции.
3) SQL-поток резервной базы данных выполняет последний шаг.Поток считывает события из журнала реле и выполняет их в резервной базе данных.Когда поток SQL догоняет поток ввода-вывода, журнал реле обычно записывается в систему. кеш, поэтому ретранслятор Накладные расходы на ведение журнала низкие. Поток SQL также может решить, следует ли писать в свой собственный двоичный журнал на основе параметров конфигурации.
полусинхронная репликация
Как решить проблему потери данных, вызванную простоем основной базы данных MySQL?
Используйте полусинхронную репликацию. Прежде чем основная библиотека зафиксирует, двоичный журнал должен быть синхронизирован с подчиненной библиотекой.Главная библиотека может установить время истечения срока действия синхронизированного двоичного журнала.После того, как двоичный журнал будет скопирован в подчиненную библиотеку, подчиненная библиотека сама воспроизведет журнал ретрансляции. . Однако это также увеличивает задержку клиента. Кроме того, для этого требуется установка подключаемого модуля MySQL.
Плагин полусинхронизации MySQL: semisync_xx.so
Для получения подробной информации о том, как работать, обратитесь к моему предыдущему блогу:Подробное объяснение репликации MySQL
Метод копирования
На основе GTID и журналов
- Журнал: традиционный способ, способ по умолчанию. Зависит от бинарного лога, согласно смещению лога. Транзакции постоянно фиксируются, и смещение двоичного журнала постоянно меняется. Ведомая библиотека должна сообщить главной библиотеке, куда она скопировала смещение.
- GTID: глобальный идентификатор транзакции, GTID в кластере уникален, GTID= source_id:transcation_id, source_id находится на этой машине, и ведомое устройство инкрементально реплицирует GTID, который еще не был синхронизирован.
| репликация на основе журнала | на основе GTID |
|---|---|
| хорошая совместимость | Не совместим со старыми версиями |
| Поддержка архитектуры MMM и MHA | Поддерживает только архитектуру MHA |
| Трудности с поиском новых точек синхронизации при готовности к переключению | На основе репликации идентификаторов транзакций очень удобно находить незавершенные идентификаторы транзакций. |
| Удобно пропускать операцию копирования | Операцию можно пропустить, только поместив пустую транзакцию, что немного сложнее |
Рекомендуется сначала использовать метод GTID, который обеспечивает более безопасное переключение при сбое.
Задержка репликации master-slave
Причина задержки?
- Если главный узел выполняет большую транзакцию (обновляет десятки миллионов строк операторов, короче говоря, выполняет длинную транзакцию), это окажет большее влияние на задержку между ведущим и подчиненным.
- Задержка сети, большие журналы и слишком много ведомых устройств.
- Многопоточная запись на ведущем узле, только однопоточное восстановление со ведомого узла
Способ обработки:
- Крупные транзакции: крупная транзакция на более мелкие транзакции, пакетное обновление данных.
- Уменьшите количество слейвов, не более 5, и уменьшите размер одной транзакции.
- После MySQL 5.7 можно использовать многопоточную репликацию с использованием архитектуры репликации MGR.