1. Введение
MySQL поставляется со своей собственной схемой репликации, которая дает следующие преимущества:
резервное копирование данных.
Балансировка нагрузки.
распределенные данные.
Введение концепции:
Master (мастер): реплицируемая база данных.
Ведомый: база данных, которая реплицирует данные хоста.
Шаги копирования:
(1) Мастер записывает детали изменений и сохраняет их в двоичном журнале.
(2) Ведущее устройство отправляет подчиненному сообщение синхронизации.
(3) После того, как ведомое устройство получает сообщение, оно копирует двоичный журнал ведущего в локальный журнал ретрансляции.
(4) Ведомое устройство воспроизводит сообщения в журнале реле, тем самым изменяя данные в базе данных.
Вот классическая картинка, иллюстрирующая процесс:
2. Реализуйте репликацию
Существуют следующие шаги для достижения репликации:
1. Установите двоичный журнал и идентификатор сервера основной библиотеки MySQL.
Файлы конфигурации MySQL обычно хранятся в /etc/my.cnf.
# 在[mysqld]下面添加配置选项
[mysqld]
server-id=1
log-bin=mysql-bin.logserver-id — уникальный идентификатор в базе данных всего кластера базы данных, должен быть уникальным.
Перезапустите MySQL.
注：如果MySQL配置文件中已经配置过此文件，则可以跳过此步。
2. Создайте новую учетную запись для копирования
Создайте учетную запись в базе данных master для копирования данных базы данных master из базы данных и предоставьте разрешение на копирование.
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO user_name@'host' IDENTIFIED BY 'password';3. Установите идентификатор сервера основной базы данных MySQL.
Как и в случае с настройкой второго шага, следует отметить два момента:
- Если подчиненной библиотеке не требуется быть основной библиотекой для других подчиненных библиотек, нет необходимости настраивать двоичный журнал.
- Во многих случаях нет необходимости копировать все базы данных основной базы данных (особенно информационную базу данных конфигурации mysql). Таким образом, вы можете настроить replicate_do_db для указания реплицируемой базы данных.
4. Инициализировать данные основной библиотеки из библиотеки
Если объем данных невелик, вы можете использовать инструмент mysqldump для экспорта данных основной базы данных, а затем импортировать их в подчиненную базу данных.
mysqldump --single-transaction --triggers --master-data databasename > data.sqlЕсли объем данных велик, для экспорта базы данных следует использовать Xtrabackup, который здесь не рассматривается.
Некоторые студенты могут спросить, почему бы не использовать бинарный журнал напрямую для инициализации?
- Если наша основная библиотека работает в течение длительного времени, использование подчиненной библиотеки для копирования данных по двоичному журналу нецелесообразно, так как непосредственное использование двоичного журнала для инициализации подчиненной библиотеки потребует времени и производительности.
- В большинстве случаев пункт конфигурации бинарного журнала основной библиотеки не включается, поэтому бинарный журнал предыдущих операций отсутствует.
5. Включите репликацию
Выполните следующую команду из библиотеки
mysql> CHANGE MASTER TO MASTER_HOST='host',
-> MASTER_USER='user',
-> MASTER_PASSWORD='password',
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=0;Обратите внимание на последние две команды: MASTER_LOG_FILE и MASTER_LOG_POS, которые указывают, какой бинарный файл читать из библиотеки, и где начинается смещение, эти два параметра можно найти в импортированном нами SQL.
включить репликацию
start slave;В это время репликация завершена, и результат можно запросить в подчиненной базе данных, обновив данные в главной базе данных или добавив новые данные.
Состояние потока репликации также можно запросить в основной базе данных.
3. Формат реплицированного журнала
Существует три формата журналов для репликации MySQL.Существуют следующие три типа в зависимости от того, как база данных master хранит данные:
| Метод копирования | Функции | преимущество | недостаток |
|---|---|---|---|
| row | Репликация формата на основе строк записывает информацию о данных для каждой строки, которую необходимо изменить. Если SQL изменяет 2w строк данных, будет записан формат журнала 2w строк. | Гарантируется строгая согласованность данных, а поскольку результат выполнения записывается, восстановление из библиотеки будет происходить быстрее. | Количество записей в журнале велико, и передача между ведущим и ведомым занимает больше времени. |
| statement | Репликация формата журнала на основе сегментов, то есть записи измененных записей SQL, а не записи измененных строк. | Логирование минимальное. | Для некоторых функций с неопределенными результатами вывода могут возникнуть проблемы при однократном выполнении на ведомой библиотеке, например uuid.Когда ведомая библиотека восстанавливает данные основной базы данных по логу, ей нужно один раз выполнить SQL, а время является относительно медленным. |
| mixed | Смешивание двух вышеупомянутых форматов журнала записывает журнал, а когда использовать какой метод журнала, определяется самой MySQL. | Преимущества и недостатки двух вышеуказанных форматов журналов можно сбалансировать. |
До MySQL 5.7 формат оператора использовался по умолчанию.
Способ настройки можно задать в конфигурационном файле (предпочтительно):
binlog_format=ROWИли временно установите глобальную переменную (действительно текущее соединение mysql):
查看日志格式
mysql > show variables like 'binlog_format';
设置日志格式
mysql > set binlog_format='row';Поскольку два главных-ведомых сервера обычно размещаются в одном и том же компьютерном зале, скорость синхронизации между ними будет выше.Для обеспечения строгой согласованности следует предпочесть запись формата журнала строки (строка), чтобы гарантировать, что скорость передачи может быть выбрана. Смешанный.
Формат линейного журнала имеет следующие три метода записи:
| Метод записи | Функции |
|---|---|
| minimal | Записывать только данные измененного столбца |
| full | Запишите данные всех столбцов измененной строки |
| noblob | Характеристики такие же, как и выше, за исключением того, что если столбцы типа blob и text не изменены, данные этих столбцов не будут записываться (т. е. большие столбцы данных). |
Mysql по умолчанию полный, лучше поменять на минимальный.
binlog_row_image=minimal4. Задержка репликации master-slave
Так как главная библиотека и подчиненная библиотека не находятся на одном хосте, между синхронизацией данных возникает неизбежная задержка.Решение состоит в том, чтобы добавить кеш и дождаться скачка бизнес-уровня.Если вам нужно уменьшить проблему задержки с На уровне базы данных вы можете начать с трех основных шагов во время репликации (основная библиотека создает журналы, журналы передачи ведущий-ведомый, а подчиненная библиотека восстанавливает содержимое журналов):
1. Скорость, с которой основная библиотека пишет в лог
Управляйте размером транзакций основной базы данных и разделяйте большие транзакции на несколько небольших транзакций.
Например, если вы вставляете данные 20 Вт, измените их, чтобы вставить 5000 строк несколько раз (вы можете использовать идею разбиения на страницы)
2. Время передачи двоичных журналов между ведущим и ведомым. Ведущий и ведомый должны находиться в одном и том же компьютерном зале или регионе, насколько это возможно.
Формат лога изменен на СМЕШАННЫЙ, а формат лога в строке настроек не минимален.Подробности см. в описании формата лога выше.
3. Сократить время восстановления логов из библиотеки
После MySQL 5.7 вы можете использовать метод логических часов для выделения многопоточности SQL.
Установите логические часы: slave_parallel_type='logical_clock';
Установить количество потоков репликации: slave_parallel_workers=4;
5. На что обратить внимание
- Лучше всего переключить пользователя MySQL, чтобы перезапустить MySQL, иначе после запуска файла возникнут проблемы с правами доступа.
- После настройки среды MySQL установите в конфигурации опцию log-bin, чтобы при необходимости репликации базы данных из библиотеки в будущем не было необходимости перезапускать базу данных и прерывать работу.
- Соответствующий порт mysql брандмауэра основной библиотеки должен быть открыт.
- Благодаря тому, что ведомая библиотека синхронизирует ведущую библиотеку, она отслеживает информацию, отправляемую ведущей библиотекой, а не опрашивает ее, поэтому в случае сбоя связи после повторного подключения, если ведущая библиотека не выполняет изменения данных, ведомая библиотека не будет синхронизировать данные, поэтому данные можно синхронизировать, вставив пустые транзакции.