Репликация MySQL master-slave, горячее резервное копирование на две машины

MySQL

1. Репликация ведущий-ведомый

Принцип репликации master-slave:

База данных MySQL предоставляет механизм резервного копирования master-slave, который заключается в одновременной записи всех данных главной базы данных в резервную базу данных. Реализовать горячее резервное копирование базы данных mysql.

Чтобы выполнить горячее резервное копирование с двумя машинами, вы должны сначала понять требования к версии главного-подчиненного сервера базы данных. Версия mysql для горячего резерва выше 3.2. Существует также основной принцип, согласно которому версия данных подчиненной базы данных может быть выше версии базы данных главного сервера, но не ниже версии базы данных главного сервера.

Конечно, для обеспечения горячего резервного копирования двух машин mysql, в дополнение к функции REPLICATION, которая поставляется с самим mysql, это также может быть достигнуто с помощью программного обеспечения с открытым исходным кодом Heartbeat. Основная операция репликации master-slave состоит в том, чтобы снова выполнить sql, выполняемый с главного сервера, на подчиненной машине.Пока начальное состояние базы данных (структура базы данных, данные, конфигурация) двух машин одинаково, тогда запускаем master-slave репликацию, после чего можно гарантировать, что они всегда будут в одном и том же состоянии. Все это реализовано самим mysql, мы можем его настроить.

Как мы видим из рисунка, то, что нужно сделать главному серверу, очень просто, просто сохранить выполненный оператор sql в двоичном файле binary-log, в то время как подчиненному серверу нужно сделать больше вещей, и он должен использовать два каждый. поток отслеживает и обрабатывает все событие.

Наша репликация master-slave разделена на три этапа:

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

Из-за некоторых характеристик репликации master-slave для обеспечения согласованности данных необходимо соблюдать следующие принципы:

  • На каждого раба приходится только один мастер
  • Каждое подчиненное устройство может иметь только один уникальный идентификатор сервера.
  • У каждого мастера может быть несколько ведомых

1.1. Подготовка окружающей среды:

  • Сервер (главный сервер Master): 192.0.0.131

  • Сервер B (подчиненный сервер): 192.0.0.188

  • Версия Mysql главного и подчиненного серверов — 5.6.

  • Здесь нужно обратить внимание на то, чтобы порт 3306 брандмауэра был открыт

  • Структура таблицы данных и конфигурация двух серверных баз данных должны быть одинаковыми.

1.2 Основные настройки сервера:

Войдите в mysql главного сервера и выполните следующую инструкцию, чтобы создать пользователя и предоставить разрешения:

CREATE USER 'slave'@'%' IDENTIFIED BY '123456';

GRANT ALL PRIVILEGES ON *.* TO slave@"%" IDENTIFIED BY "123456";

Измените файл конфигурации my.cnf

log-bin=mysql-bin
server-id=1

инструкция:

    1. log-bin: включить двоичный журнал, который записывается в файл журнала при фиксации транзакции. Размер по умолчанию — 1G, за которым следует суффикс, например 001 002.
    1. server-id однозначно идентифицирует хост, а мастер и ведомый сервер mysql настраиваются по-разному для каждого экземпляра mysql. По умолчанию это значение равно 0. Если оно равно 0, главный сервер отклоняет любое соединение с подчиненным сервером.

Другая конфигурация (не обязательно):

  • 1. binlog-do-db=db_001 (основная конфигурация базы данных) # Укажите, какие db записываются в журнал binlog mysql, и настройте базу данных для синхронизации, вы можете настроить несколько, если нет такого элемента конфигурации, синхронизировать все.

  • 2. binlog-ignore-db=mysql (основная конфигурация базы данных) # Настройте асинхронные базы данных, вы можете настроить несколько.

  • 3. binlog_format = смешанный #Настроить формат бинлога

  • 4. только для чтения = 0 #Настроить только для чтения 0 означает не только для чтения, 1 означает только для чтения

  • 5. auto-increment-increment = 10 # Используется для установки конфликта идентификаторов столбца автоинкремента в случае двойных мастеров, в основном используется для установки размера шага автоинкремента

  • 6. auto-increment-offset = 1       # Указывает порядковый номер данного сервера, начиная с 1, не более, чем auto-increment-increment

перезапустить базу данных

systemctl restart mysqld.service

1.3, из настроек сервера:

настроить my.cnf

server-id=2
replicate-do-db=test
skip-slave-start=true

Примечание. Если вы используете виртуальную машину, а подчиненная машина клонирована с главного хоста, вам необходимо выполнить этот шаг.

Войдите в каталог нашей базы данных mysql:

#这是默认的地址，根据自己配置的datadir即可
cd /var/lib/mysql

vim auto.cnf

Измените UUID внутри на другой.

перезапустить базу данных

systemctl restart mysqld.service

1.4, настройте подчиненный сервер для распознавания главного

Получить информацию о бинлоге

Сначала заходим на главный (главный) сервер для получения информации binlog, и вводим в командный интерфейс mysql:

show master status;

Здесь показано имя файла binlog, используемого нашим текущим главным сервером, где position — это смещение в файле. Нам нужно использовать эту информацию для последующей настройки подчиненного устройства. Этот файл отличается после каждого изменения состояния сервера.

Перейдите к самому важному шагу.После входа в рабочий интерфейс mysql подчиненного сервера введите следующую команду:

stop slave;          //先停步slave服务线程，这个是很重要的，如果不这样做会造成以下操作不成功，第一次设计主从的话忽略。

change master to 
master_host='192.0.0.131',
master_user='slave',
master_password='123456',
master_log_file='mysql-bin.000002', 
master_log_pos=1472;

Здесь user и password — это имя пользователя и пароль, которые мы создали на главном сервере на первом этапе, а затем MASTER_LOG_FILE — это файл binlog, используемый мастером, который мы проверили на предыдущем шаге (этот файл отличается после каждого изменения статуса главного сервера), MASTER_LOG_POS Это смещение binlog, которое используется для синхронного сканирования. master_log_file соответствует файлу, а master_log_pos соответствует положению. Mysql 5.x и более поздние версии больше не поддерживают указание основных параметров, связанных с сервером, в файле конфигурации.

Неважно, выдается ли предупреждение после выполнения, исключений нет.

Запустите подчиненный поток с сервера

start slave;

Просмотр (подчиненного) статуса

show slave status\G;

Если вы видите два «да» на рисунке, это означает, что наш подчиненный сервер полностью запущен.

Теперь мы можем внести изменения в базу данных главного сервера, чтобы проверить, синхронизирована ли она с базой данных подчиненного сервера для подтверждения доступности.

1.5, проверка ведущий-ведомый

Поскольку данные в базе данных прежние, теперь мы создадим новую тестовую библиотеку и создадим новую таблицу user_test в тестовой библиотеке.

Здесь следует отметить, что обе базы данных должны быть выполнены

#创建新库
CREATE DATABASE test;

#指定编码
CREATE DATABASE IF NOT EXISTS my_db default charset utf8 COLLATE utf8_general_ci;

#创建新表
create table user_test( id int comment'ID',name VARCHAR(20) comment'名称', create_time timestamp DEFAULT now() comment'创建时间' );

Условия подготовки выполнены, вступайте в тест

Основной запрос библиотеки:

Запрос из библиотеки:

Теперь вручную вставляем кусок данных в основную библиотеку

use test;

insert INTO user_test value(1,"张三",NOW());

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

В результате очевидно, что данные были синхронизированы, что указывает на то, что конфигурация нашей репликации master-slave в порядке.

2. Горячее резервное копирование на две машины

Для достижения горячего резервного копирования с двумя машинами принцип фактически состоит в том, чтобы сделать две машины главными и подчиненными.

Или используйте два вышеуказанных сервера, конкретные шаги не будут написаны, просто вставьте файлы конфигурации двух серверов my.cnf

Конфигурация сервера А:

log-bin=mysql-bin
server-id=1

# 双机热备需要添加
log-slave-updates
sync_binlog = 1
auto_increment_offset = 1
auto_increment_increment = 2

Конфигурация сервера Б

log-bin=mysql-bin
server-id=2

# 双机热备需要添加
log-slave-updates
sync_binlog = 1
auto_increment_offset = 1
auto_increment_increment = 2

начать тестирование------------------------------------------------ ---->

Сервер A удаляет один и видит данные сервера B

Сервер B добавляет один, удаляет один и проверяет данные сервера A.

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

  • Идентификатор сервера: значение идентификатора однозначно идентифицирует главный и подчиненный серверы в кластере репликации, поэтому они должны быть разными. Master_id должен быть положительным целым числом от 1 до 232-1, а slave_id должен быть положительным целым числом от 2 до 232-1.

  • Log-bin: Указывает, что binlog включен, и эта опция может быть записана в журнал relay-log подчиненного устройства через ввод-вывод, что также является предварительным условием для репликации.

  • Binlog-do-db: указывает базу данных, которая должна записывать двоичные журналы. Если есть несколько данных, их можно разделить запятой или использовать несколько опций binlog-do-dg.

  • Binlog-ignore-db: указывает базу данных, которой не нужно записывать двоичные журналы, если существует несколько баз данных, которые можно разделить запятыми, или использовать несколько параметров binglog-ignore-db.

  • Replicate-do-db (настроено из базы данных): указывает базу данных, которую необходимо синхронизировать, если есть несколько данных, их можно разделить запятыми или использовать несколько параметров replicate-do-db.

  • Replicate-ignore-db (настроено из базы данных): указывает базу данных, которую не нужно синхронизировать, если имеется несколько баз данных, их можно разделить запятыми или использовать несколько параметров репликации-ignore-db.

  • Master-connect-retry: master-connect-retry=n указывает, что соединение между подчиненным сервером и главным сервером не удалось, затем подождите n секунд (с) перед переходом в режим управления (настройка по умолчанию — 60 с). Если на подчиненном сервере существует файл mater.info, он будет игнорировать эти параметры.

  • Log-slave-updates: Настройте, записывается ли операция обновления подчиненной библиотеки в двоичный файл.Если эта подчиненная библиотека должна быть главной библиотекой других подчиненных библиотек, то этот параметр необходимо установить так, чтобы подчиненная библиотека подчиненная библиотека может выполнять синхронизацию журналов.

  • skip-slave-start Слейв не запустится автоматически после перезапуска слейв сервера, его нужно запускать вручную во избежание ошибок.

3. Часто задаваемые вопросы

Двоичный файл журнала mysql заполнен на дисках, служба недоступна, и ошибка выглядит следующим образом.

Disk is full writing './mysql-bin.000032' (Errcode: 15753600 - No space left on device). Waiting for someone to free space...

3.1. Файлы журнала могут быть автоматически удалены с помощью следующих настроек.

vim /etc/my.cnf  //修改expire_logs_days,x是自动删除的天数，一般将x设置为短点，如10
expire_logs_days = x  //二进制日志自动删除的天数。默认值为0,表示“没有自动删除”

Этот метод требует перезапуска mysql

Конечно, вы также можете открыть master-slave mysql без перезапуска mysql и установить expire_logs_days прямо в mysql.

show binary logs;
show variables like '%log%';
set global expire_logs_days = 10;

3.2. Вручную очистить файл binlog

Первый вход в MySQL

PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);   //删除10天前的MySQL binlog日志,附录2有关于PURGE MASTER LOGS手动删除用法及示例
show master logs;

Вы также можете сбросить мастер и удалить все файлы binlog:

reset master;  //附录3有清除binlog时，对从mysql的影响说明
Категории