Что позволяет реализовать репликация master slave в mysql

Репликация MySQL¶

MySQL имеет встроенную репликацию, которая может послужить основой для нагруженных распределенных приложений.

Основная проблема, решаемая при репликации – синхронизация данных между серверами. Возможны различные топологии: один мастер (master) – много слэйвов (slave), много мастеров и т.д. Реплицировать можно весь сервер целиком, одну базу, одну таблицу. MySQL поддерживает на данный момент один тип репликаций: логическую репликацию (statement) . Построчная репликация (row-based) появится начиная с версии 5.1. Обе репликации имеют асинхронный характер, т.е. нет никаких гарантий, что процесс может длиться строго фиксированный промежуток времени. Репликация не работает вниз, т.е. база версии 5.0 не может быть реплицирована на версию 4.0. Основным условием репликации является включение бинарного логирования на мастере.

Что достигается с помощью репликации?

• Распределение данных: данные можно копировать по разным дата-центрам.
• Распределение нагрузки: запросы можно разносить между разными серверами с помощью простого базового round-robin DNS или используя Linux Virtual Server (LVS).
• Бэкапы: репликация упрощает архивацию.
• Устойчивость: наличие слэйвов позволяет уменьшить риск отказов системы.

Как работает репликация MySQL¶

Процесс репликации состоит из трех основных фаз:

• происходит добавление записи в бинарный лог на мастере;
• добавленные записи копируются из лога мастера слэйв-сервером в свой лог;
• слэйв реплицирует свой лог в свою базу данных.

Во время этого процесса на мастере и на слэйве два отдельных треда устанавливают между собой коннект и передают репликационные данные.

Как конфигурировать master/slave¶

Для настройки репликации необходимо:

• на каждом сервере настроить репликационный аккаунт;
• сконфигурировать мастер и слэйв;
• настроить на слэйве коннект и репликацию.

На мастере и на слэйве нужно выполнить команду:

mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* -> TO repl@'192.168.0.%' IDENTIFIED BY 'p4ssword';

На мастере нужно сделать изменения в конфиге my.cnf:

log_bin = mysql-bin server_id = 10

Перезапускаем мастера и выполняем команду SHOW MASTER STATUS:

mysql> SHOW MASTER STATUS; +------------------+----------+ | File | Position | +------------------+----------+ | mysql-bin.000001 | 98 | .

На слэйве делаем аналогичные настройки в конфиге:

log_bin = mysql-bin server_id = 2 relay_log = mysql-relay-bin log_slave_updates = 1 read_only = 1

Здесь relay_log – промежуточный репликационный лог. log_slave_updates включает обмен данными между промежуточным и основным логами.

Запуск slave¶

Для запуска процесса репликации на слэйве нужно запустить команду:

mysql> CHANGE MASTER TO MASTER_HOST='server1', -> MASTER_USER='repl', -> MASTER_PASSWORD='p4ssword', -> MASTER_LOG_FILE='mysql-bin.000001', -> MASTER_LOG_POS=0;

После этого нужно сделать проверку:

mysql> SHOW SLAVE STATUS\G ********************* 1. row ******************* Slave_IO_State: Master_Host: server1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 4 Relay_Log_File: mysql-relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: mysql-bin.000001

Теперь запускаем репликацию:

mysql> START SLAVE;

mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: server1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 164 Relay_Log_File: mysql-relay-bin.000001 Relay_Log_Pos: 164 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes

Запущен реплицирующий тред, который ждет сообщений от мастера. Если на мастере произойдут изменения, мы это увидим, запустив повторно команду SHOW SLAVE STATUS.

На мастере и на слэйве можно запустить команду, которая покажет информацию о тредах:

mysql> SHOW PROCESSLIST\G

Для мастера рекомендуется в конфиге поставить параметр:

sync_binlog=1

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

В качестве основного движка базы данных рекомендуется InnoDB. Что касается MyISAM, то он может вести себя некорректно при остановках на слэйве. Для InnoDB рекомендуются следующие конфигурационные настройки мастера:

innodb_flush_logs_at_trx_commit=1 # синхронизация всех коммитов на диск innodb_support_xa=1 # начиная с версии MySQL 5.0 innodb_safe_binlog # только для версии MySQL 4.1

Для слэйва рекомендуется установить следующие конфигурационные параметры: первая опция предотвращает автоматический рестарт слэйва после остановки, вторая не дает возможности обычным пользователям делать изменения на слэйве:

skip_slave_start read_only

Различия в репликации¶

MySQL, включая версию 5.0, поддерживает только логическую (statement-based) репликацию. Когда слэйв реплицирует данные, фактически он выполняет тот же самый SQL-запрос, который выполнял мастер. У этого метода есть свои преимущества – он прост в реализации, размер лога при этом компактен. Но есть и недостатки: время выполнения запросов на мастере и на слэйве может сильно различаться. Некоторые выражения не реплицируются корректно, например функция CURRENT_USER(). Есть также проблемы с триггерами и хранимыми процедурами.

В версии 5.1 появится поддержка построчной (row-based) репликации. Преимущество этого варианта в том, что каждое выражение может быть реплицировано корректно и эффективно. При этом может возрасти размер лога, который уже нельзя будет инспектировать с помощью утилиты mysqlbinlog.

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

mysql> INSERT INTO global_table(col1, col2, sum_col3) -> SELECT col1, col2, sum(col3) -> FROM my_table -> GROUP BY col1, col2;

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

Зато, с другой стороны, если взять выражение:

mysql> UPDATE enormous_table SET col1 = 0;

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

В версии 5.1 будет динамическое переключение между логической и построчной репликациями. По умолчанию будет применяться логическая репликация, это можно настраивать с помощью параметра binlog_format.

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

В MySQL для репликации есть несколько правил, независимо от их топологии: мастер может иметь несколько слэйвов; у каждого слэйва может быть только один мастер, т.е. multimaster не поддерживается.

Существует несколько топологических вариантов.

• Мастер и несколько слэйвов.
• Мастер-мастер в режиме active-active.
• Мастер-мастер в режиме active-passive.
• Мастер-мастер и несколько слэйвов.
• Кольцо.
• Дерево или пирамида.

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

Тут можно реализовать следующие идеи:

• каждый слэйв исполняет свою роль – например, выборочное индексирование;
• использовать слэйв для аварийного восстановления;
• использовать слэйв для бэкапа или разработки.

Мастер-мастер в режиме active-active: этот вариант известен как двунаправленная репликация. Каждый из двух серверов выступает одновременно в качестве мастера и в качестве слэйва. В этом варианте есть проблема с разрешением конфликтов, когда, например, два запроса начинают одновременно менять одну и ту же строку или когда происходит одновременная автоинкрементная вставка в таблицу на оба сервера. В версии 5.0 появились специальные параметры конфига: auto_increment_increment, auto_increment_offset, которые генерируют неконфликтные инсерты. Вообще говоря, в этой схеме можно придумать логику апдейтов, которая разрушает синхронизацию между серверами или создает между ними конфликты.

Мастер-мастер и несколько слэйвов: здесь можно назначить один или более слэйвов на каждый мастер. Эта схема уменьшает трафик между мастером и слэйвом.

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

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

Настройка репликации master-slave в MySQL

Репликация — механизм синхронизации содержимого нескольких копий объекта. Под этим процессом понимается копирование данных из одного источника на множество других и наоборот.

• master — главный сервер, данные которого необходимо дублировать;
• replica — починенный сервер, хранящий копию данных главного

Для настройки репликации в MySQL необходимо выполнить ниже описанную последовательность действий, но это не догма и параметры могут изменяться в зависимости от обстоятельств.

На главном сервере отредактируем файл файл my.cnf, в секцию mysqld добавить строки:

server-id = [master server id] log-bin = mysql-bin log-bin-index = mysql-bin.index log-error = mysql-bin.err relay-log = relay-bin relay-log-info-file = relay-bin.info relay-log-index = relay-bin.index expire_logs_days=7 binlog-do-db = [dbname]

• [master server id] — уникальный идентификатор сервера MySQL, число в диапазоне 2 (0-31)
• [dbname] — имя базы, информация о которой будет писаться в бинарный журнал, если баз несколько, то для каждой необходима отдельная строка с параметром binlog_do_db

На подчиненном отредактируем файл файл my.cnf, в секцию mysqld добавить строки:

server-id = [slave server id] master-host = master master-user = replication master-password = password master-port = 3306 relay-log = relay-bin relay-log-info-file = relay-log.info relay-log-index = relay-log.index replicate-do-db = [dbname]

На главном сервере добавим пользователя replication с правами на репликацию данных:

GRAANT REPLICATION SLAVE ON *.* TO 'replication'@'replica' IDENTIFIED BY 'password'

Заблокируем реплицируемые базы на главном сервере от изменения данных, программно или с помощью функционала MySQL:

mysql@master> FLUSH TABLES WITH READ LOCK; mysql@master> SET GLOBAL read_only = ON;

Для разблокировки используется команда:

mysql@master> SET GLOBAL read_only = OFF;

Сделаем резервные копии всех баз данных на главном сервере (или тех которые нам необходимы):

root@master# tar -czf mysqldir.tar.gz /var/lib/mysql/[dbname]

или средствами утилиты mysqldump:

root@master# mysqldump -u root -p --lock-all-tables [dbname] > dbdump.sql

Остановим оба сервера (в отдельных случаях можно обойтись и без этого):

root@master# mysqlamdin -u root -p shutdown root@replica# mysqlamdin -u root -p shutdown

Восстановим реплицируемые базы данных на подчиненном сервере с помощью копирования директории. Перед началом репликации базы данных должны быть одинаковы:

root@replica# cd /var/lib/mysql root@replica# tar -xzf mysqldir.tar.gz

или функционала mysql, тогда mysql на подчиненном сервере не было необходимости останавливать:

root@replica# mysql -u root -p [dbname] < dbdump.sql

Запустим mysql на главном сервере (а затем - на подчиненном, если это необходимо):

root@master# /etc/init.d/mysql start root@replica# /etc/init.d/mysql start

Проверим работы главного и подчиненного серверов:

mysql@replica> start slave; mysql@replica> SHOW SLAVE STATUS\G mysql@master> SHOW MASTER STATUS\G

На подчиненном сервере проверить логи в файле master.info, там должны содержаться запросы на изменение данных в базе. Так этот файл бинарный необходимо сначала преобразовать его в текстовый формат:

root@replica# mysqlbinlog master.info > master_info.sql

При возникновении ошибок, можно использовать команды:

mysql@replica> stop slave; mysql@replica> RESET SLAVE; mysql@master> RESET MASTER;

и повторить все действия начиная с блокировки баз данных.

Для горячего добавления серверов репликации можно использовать синтаксис:

mysql@replica> SHOW SLAVE STATUS\G mysql@master> SHOW MASTER STATUS\G mysql@replica-2> CHANGE MASTER TO MASTER_HOST = "master", MASTER_USER ="replication ", MASTER_PASSWORD = "password ", MASTER_LOG_FILE ="mysql-bin.000004 ", MASTER_LOG_POS = 155; mysql@replica-2> START SLAVE;

Информация из статусов покажет позицию и имя текущего файла лога.

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

Список использованных источников

1. Habrahabr.ru - Основы репликации в MySQL (http://habrahabr.ru/blogs/mysql/56702/)
2. Википедия (http://ru.wikipedia.org/wiki/Репликация_(вычислительная_техника))

При полном или частичном использовании любых материалов с сайта вы обязаны явным образом указывать ссылку на handyhost.ru в качестве источника.

Купить услугу выделенного сервера можно на нашем сайте.

Все способы

© 2009–2024 «HANDYHOST.RU» 8-800-505-68-01

• Услуги
• Хостинг сайтов
• Домены
• Конструктор сайтов
• Linux VPS / Windows VPS
• Выделенные серверы
• SSL сертификаты

• Клиентам
• Контакты
• О компании
• Акции
• Оборудование
• Партнерская программа

• Поддержка
• Способы оплаты
• Регламент
• Документы
• Справка

Репликация master slave MySQL

Репликация master slave позволяет обеспечить системе надежность и гарантирует ее работоспособность при выходе из строя основного сервера БД.

Репликация базы данных это прием, применяемый в архитектуре информационных систем, результатом применения которого является распределение нагрузки при работе с одной базой данных на несколько серверов. В MySQL репликация Master-Slave используется чаще, но применяется и второй тип репликации — Master-Master.

Репликация Master-Slave предполагает дублирование данных на подчиненный сервер MySQL, производится подобное дублирование с целью обеспечения надежности. В случае выхода из строя Master сервера его функции переключаются на Slave.

Настройка MASTER SLAVE репликации в Debian

Будем использовать два сервера с адресами:

• Master сервер 192.168.0.1
• Slave сервер 192.168.0.2

Для демонстрации используются VDS объединенные в локальную сеть.
Чтобы всегда наверняка знать на каком сервере мы выполняем ту или иную команду отредактируем файлы /etc/hosts на обоих серверах

192.168.0.1 master

192.168.0.2 slave

Заменим существующие значения в /etc/hostname на master и slave соответственно, чтобы изменения вступили в силу сервера перезагрузим.

1. Производим настройки на мастер сервере.

root@master:/#

Редактируем основной конфигурационный файл сервера баз данных

Выбираем ID сервера — число можно указать любое, по умолчанию стоит 1 — строку достаточно раскомментировать

Задаем путь к бинарному логу — также указано по умолчанию, раскомментируем

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

Перезапускаем Mysql чтобы конфигурационный файл считался и изменения вступили в силу:

2. Задаем пользователю необходимые права

Заходим в консоль сервера баз данных:

Даем пользователю на подчиненном сервере необходимые права:

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY '123';

Блокируем все таблицы в БД

Проверяем статус Master-сервера:

3. Создаем дамп базы данных на сервере

Создаем дамп базы данных:

mysqldump -u root -p db1 > db1.sql

Разблокируем таблицы в консоли mysql:

4. Переносим дамп базы на Slave-сервер

Дальнейшие действия производим на Slave-сервере

root@slave:/#

5. Созданием базу данных

6. Вносим изменения в my.cnf

Назначаем ID инкрементируя значение установленное на Master сервере

Задаем путь к relay логу

и путь bin логу на Master сервере

7. Задаем подключение к Master серверу

CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='slave_user', MASTER_PASSWORD='123', MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 327;

Запускаем репликацию на подчиненном сервере:

Проверить работу репликации на Slave можно запросом:

*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.1
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 555
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 row in set (0.00 sec)

Поскольку каких-либо ошибок не возникло можно сделать вывод о том, что репликация настроена корректно. Настройка завершена.

Распределение запросов на чтение и запись по разными серверам, включенным в процесс репликации

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

При работе приложения с БД самыми частыми операциями являются операции SELECT — запросы на считывание данных, модификация данных — запросы DELETE, INSERT, UPDATE, ALTER статистически происходит гораздо реже.

Чтобы в случае выхода из строя одного из серверов не произошло потери данных операции на изменение информации в таблицах всегда обрабатываются Master-сервером. Затем изменения реплицируются на Slave. Считывание же можно производить с сервера играющего роль Slave.
За счет этого можно получить выигрыш в производительности вместе с надежностью.

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

Направление запросов определенного типа к тому или иному серверу баз данных реализуется на уровне приложения.

Если выполнять разделение SELECT запросов и всех остальных на программном уровне отправляя их на нужный сервер — при выходе из строя одного из них приложение, которое обслуживает инфраструктура, окажется неработоспособно. Чтобы это работало нужно предусматривать более сложную схему и резервировать каждый из серверов.

Репликация применяется для отказоустойчивости, не для масштабирования

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

Полностью их избежать позволяет использование более современного решения Galera Cluster. Оно отличается простой настройкой, надежностью и отсутствием необходимости вручную копировать SQL дампы баз данных.

Как настроить MySQL Master/Slave репликацию?

В сегодняшней статье я вам буду рассказывать о такой вещи в Mysql как репликация на основе положения двоичного файла журнала. Этот вариант считается самым простим в исполнении, но не менее аффективным. Сам процесс репликации в Mysql позволяет копировать данные с одного сервера базы данных на другой, такие сервера принято называть master slave. Репликация по умолчанию асинхронна.

Версию базы данных я буду использовать: 8.0.29

Сервера я буду использовать для демонстрации:

192.168.2.229 mysql1.local - MASTER
192.168.2.230 mysql2.local - SLAVE

Настройки 192.168.2.229 mysql1.local и 192.168.2.230 mysql2.local будут абсолютно одинаковые так как у вас будут случаи когда вам нужно будет переключать репликацию в обратную сторону, и чтобы потом ничего не перенастраивать то мы сразу все сделать одинаковым.

1. Настройка master сервера.
2. Создания учетной записи на master сервере.
3. Настройка slave сервера.
4. Резервная копия master сервера.
5. Поиск позиции двоичного журнала на master сервере.
6. Подключаем slave сервер к master серверу.
7. Запуск репликации.
8. Проверка репликации.
9. Итоги.

1. Настройка master сервера.

Будем начинать с настройки конфигурационного файла базы данных. По умолчанию он находится по пути /etc/my.cnf.

1.1. Первый делом нам нужно настроить server_id. server_id это идентификатор сервера и он используется для идентификации сервера в топологии репликации и он обязательно должен быть положительным целым числом от 1 до 32.

[mysqld]
server_id = 10

1.2. Настройка ведение двоичного журнала (binary log).

Ведения двоичного журнала на сервере master является обязательным действием потому что сервер slave будет подключаться на сервер master и читать эти двоичные журналы. Ведение двоичного журнала по умолчанию включено. Но по умолчанию все двоичные журналы будут создаваться и хранится в директории там где лежат все файлы базы данных. Нам это не подходит и мы сами укажем место хранения двоичных журналов.

[mysqld]
log_bin = /app/mysql/binary_log/mysql-bin.log
log_bin_index = /app/mysql/binary_log/binlog.index

1.3. Настройка согласованности репликации.

За согласованность репликации отвечает переменная innodb_flush_log_at_trx_commit и sync_binlog. Всегда ставьте значения этих переменных в значения 1. Данная переменная может иметь значения 0, 1, 2. Если вы укажите 0 или 2, то есть риск потерять транзакции.

[mysqld]
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

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

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

[mysqld]
log_replica_updates = ON

1.5. Настройка ведения журнала ретрансляции.

За ведения журнала ретрансляции отвечают переменные relay_log и relay_log_index. Эти переменные относятся к серверу slave, и они по умолчанию включены, но они будут создаваться в директории где у вас лежат все файлы базы данных, и нам это не подходит. Мы создадим свои директории.

[mysqld]
relay_log = /app/mysql/relay_log/mysql-relay.log
relay_log_index = /app/mysql/relay_log/mysql-relay.index

1.6. Результат.

В итоги у вас в конфигурационном файле должно быть как у меня. Это сервер master 192.168.2.229 mysql1.local

[mysqld]
server_id = 10
log_bin = /app/mysql/binary_log/mysql-bin.log
log_bin_index = /app/mysql/binary_log/binlog.index
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
log_replica_updates = ON
relay_log = /app/mysql/relay_log/mysql-relay.log
relay_log_index = /app/mysql/relay_log/mysql-relay.index

2. Создания учетной записи на master сервере.

Каждый slave сервер будет подключаться к master серверу с использованием имени пользователя и пароля, поэтому на master сервере должна быть учетная запись пользователя, которую slave сервер будет использовать для подключения.

2.1. Создаем учетную запись на master серверу.

mysql> CREATE USER 'replication'@'%' IDENTIFIED BY 'kjs&#&d89h3G';

2.2. Назначаем этому пользователю необходимые права.

mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%';

3. Настройка slave сервера.

В конфигурационный файл slave сервера мы должны добавить все что мы добавляли на master сервер, но за исключением server_id. server_id должен быть уникальный на каждом сервере в той топологии репликации где он участвует. Ну и добавим параметр read_only чтобы не было возможности делать операции вставки, редактирования и удаления данных, а только их чтения.

[mysqld]
server_id = 11
log_bin = /app/mysql/binary_log/mysql-bin.log
log_bin_index = /app/mysql/binary_log/binlog.index
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
log_replica_updates = ON
relay_log = /app/mysql/relay_log/mysql-relay.log
relay_log_index = /app/mysql/relay_log/mysql-relay.index
read_only = ON

На master сервере server_id у нас 10, а slave сервер будет 11.

4. Резервная копия master сервера.

4.1. Настала очередь сделать резервную копию базы данных master сервера и перенести эту копию на slave сервер. Сделать резервную копию есть множество вариантов, но мы будем использовать самый простой, утилита mysqldump.

$. mysqldump -u root -p --all-databases --source-data > /app/backup/backup.db

4.2. После того как мы сделали резервную копию базы данных, нам нужно её перенести на slave сервер.

$. scp /app/backup/backup.db root@192.168.2.230:/app/backup/

4.3. На slave сервере теперь нам нужно эту резервную копию импортировать.

5. Поиск позиции двоичного журнала на master сервере.

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

mysql> SHOW MASTER STATUS;

В этом результате нам важно записать значения File и Position.

6. Подключаем slave сервер к master серверу.

Теперь после всего что мы сделали выше нам осталось указать slave серверу как подключатся к master серверу.

mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.2.229', SOURCE_USER='replication', SOURCE_PASSWORD='kjs&#&d89h3G', SOURCE_LOG_FILE='mysql-bin.000004', SOURCE_LOG_POS=871;

Успех! Осталось запустить репликацию.

7. Запуск репликации.

За включения и остановку репликации в базе данных существуют команды START REPLICA и STOP REPLICA. Нам же нужно выполнить START REPLICA.

mysql> START REPLICA;

8. Проверка репликации.

После запуска репликации нам нужно проверить правильно ли все работает. Для проверки на slave сервере воспользуемся командой:

mysql> SHOW REPLICA STATUS\G;

Самые важные параметры которые показывают что репликация проходит успешно это:

Replica_IO_Running: Yes
Replica_SQL_Running: Yes

9. Итоги.

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

Постепенно в следующих статьях мы будем разбирать более сложные реализации репликации включая такое понятия как GTID и так далее.