Репликация данных MySQL в режиме master-slave
Репликация (дублирование) данных в MySQL — простой механизм, который позволяет держать в нескольких местах одинаковые, актуальные таблицы, причем работа данного механизма не влияет на производительность MySQL-сервера. Особенно полезной возможностью является то, что MySQL-серверы могут находится в различных локациях — например, в разных странах.
Остановимся несколько подробнее на схеме. Представим, что у нас есть выделенный сервер или SSD VDS, где расположен наш основной (master) MySQL-сервер. Мы хотим реализовать схему с 1-2 дополнительными вторичным (slave) MySQL-серверами для следующих решения задач:
- Повысить доступность данных — даже если с master-сервером что-либо произойдет, будет доступна актуальная копия данных, без каких-либо потерь.
- Не нагружать master-сервер «тяжелыми» операциями — например, со slave можно делать резервные дампы таблиц без снижения производительности основного сервера
- С помощью дополнительных инструментов (mysql-proxy, например) можно использовать slave-серверы для чтения данных, а запись делать на master. Другими словами, можно легко создать мощный масштабируемый и распределенный кластер
О конфигурациях — обычно нет необходимости slave делать настолько же производительными, как и master. Мы успешно используем схемы, когда в качестве master используются выделенные серверы или производительные VDS, в slave — VDS среднего уровня.
Во избежание возможной, но крайне маловероятной несовместимости, мы рекомендуем использовать одну и ту же версию MySQL-сервера на всех узлах.
Приступим. Сразу заметим, что расположения файлов указаны для Centos 6, на других ОС могут быть незначительные изменения. Для начала на master укажем идентификатор сервера и включим журналирование, это делается в секции mysqld в /etc/my.cnf:
|
1 2 3 4 5 |
server-id=1 binlog-format = mixed log-bin=mysql-bin innodb_flush_log_at_trx_commit=1 sync_binlog=1 |
После этого перезапускаем mysql-сервер:
|
1 |
service mysqld restart |
Создаем пользователя, с помощью которого первый slave будет авторизоваться на master-сервере:
|
1 2 3 |
CREATE USER slave101@2.2.2.2; GRANT REPLICATION SLAVE ON *.* TO slave101@2.2.2.2 IDENTIFIED BY 'passw0rd'; FLUSH PRIVILEGES; |
Не используйте указанный выше SQL-запрос без изменений: смените 2.2.2.2 на IP-адрес slave-сервера, вместо passw0rd стоит использовать более стойкий пароль, а имя пользователя slave101 тоже можно сменить на другое.
Теперь сделаем полный дамп всех наших баз данных:
|
1 |
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -A > ~/master.sql |
Просмотрите начало получившегося файла — нужно отметить значения, указанные в переменных MASTER_LOG_FILE и MASTER_LOG_POS. Например, это можно сделать с помощью команды:
|
1 |
head -n80 ~/master.sql |grep MASTER_LOG |
Теперь любым удобным способом (scp, ftp, rsync) перенесем дамп на slave-сервер. Пока наш дамп копируется, на slave-сервере необходимо внести изменения в my.cnf:
|
1 2 3 4 5 6 |
server-id = 101 binlog-format = mixed log_bin = mysql-bin relay-log = mysql-relay-bin log-slave-updates = 1 read-only = 1 |
Перезапустим mysql-сервер на slave, затем загрузим копию данных из нашего дампа:
|
1 |
mysql -u root -p < ~/master.sql |
Запустим репликацию данных. В консоли mysql на slave выполним запрос:
|
1 2 |
CHANGE MASTER TO MASTER_HOST='1.1.1.1',MASTER_USER='slave101',MASTER_PASSWORD='passw0rd', MASTER_LOG_FILE='XXX', MASTER_LOG_POS=YYY; START SLAVE; |
В приведенном выше запросе 1.1.1.1 смените на IP-адрес master-сервера, пароль нужно указать тот, который выбрали ранее при создании пользователе на master-сервере. XXX и YYY нужно, соответственно, сменить на имя журнального файла (обычно имя имеет вид mysql-bin.000123) и на позицию в файле.
На этом настройка закончена. Статус синхронизации можно посмотреть с помощью SQL-команды:
|
1 |
SHOW SLAVE STATUS \G |
Обратите на значение переменной Last_Error — в нормальном режиме она должна быть пустой, а при активной работе master-сервера переменная Read_Master_Log_Pos должна увеличиваться.
В заключение заметим, что репликация данных не заменяет необходимости создания резервных копий. Почему? Представим ситуацию, что вследствие ошибки или сбоя будет удалена или изменена какая-то таблица. Практически мгновенно изменения будут отражены на slave-серверах и восстановить данные будет невозможно. Не забывайте делать резервные копии, причем дамп можно делать с любого slave, не снижая производительности master-сервера.
p.s. При подготовке заметки использовалась отличная запись Setting up MySQL replication without the downtime, автор Bryan Kennedy.