MySQL: снятие данных для реплики

MySQL: снятие данных для реплики

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

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

В качестве примера пара команд:

mysqldump -u имя_пользователя -pоченьсложныйпароль имя_базы -r имя_файла.sql

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

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

mysqldump --single-transaction -u имя_пользователя -pоченьсложныйпароль имя_базы -r имя_файла.sql

— данная команда не блокирует таблицы на время снятия дампа базы.

Для создания реплики нам нобходимы данные мастера — позиция в бин-логе и имя бинлога:

--master-data

— этот параметр добавит информацию о мастере в дамп.

Но процесс снятия дамп очень долгий. Есть способ выполнить задачу побыстрее. Разрабатываемые командой Percona инструменты позволяют выполнить операцию в разы быстрее с помощью утилиты innobackupex, входящей в пакет percona-xtrabackup, который есть в репозитариях Percona. Эта утилита также не блокирует таблицы.

Два замечания по этой чудесной утилите:

1. эта утилита работает только с innodb-движком. Сможет ли она снять дамп с myisam? Я думаю нет, для этого лучше использовать утилиту xtrabackup, как более универсальную.

2. рекомендуется использовать эту базу либо для создания полной копии всех баз на сервере, либо для создания копии базы и переноса ее на тот сервер, где более движок innodb  не используется (позже поймете почему, если, конечно, я сам все правильно понял).

Что ж… Приступим! Создадим папку для бэкапов:

sam@centos1:~:28/10/14-08:55$ sudo mkdir /var/log/mysql/tmp

И запускаем нашу утилиту:

sam@centos1:~:28/10/14-09:16$ sudo innobackupex --user <user> --password <password> --defaults-file=/etc/my.cnf --databases="database" --no-timestamp /var/log/mysql/tmp/new 
...
2014-10-28 09:17:10 b77a66d0  InnoDB: Operating system error number 24 in a file operation.
InnoDB: Error number 24 means 'Too many open files'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
InnoDB: Error: could not open single-table tablespace file ./youstar/ServiceDeleted.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
innobackupex: Error: The xtrabackup child process has died at /usr/bin/innobackupex line 2681.

Опа… Ошибка. Не беда:

sam@centos1:~:28/10/14-09:17$ ulimit -n 4096

Пробуем снова (вывод весь показывать не буду, большой очень):

innobackupex: Backup created in directory '/var/log/mysql/tmp/new'
innobackupex: MySQL binlog position: filename 'mysql-bin.000058', position 331, GTID of the last change ''
141028 09:16:13  innobackupex: Connection to database server closed
141028 09:16:13  innobackupex: completed OK!

Готово! Теперь надо применить логи:

sam@centos1:~:28/10/14-09:20$ sudo innobackupex --user <user> --password <password> --defaults-file=/etc/my.cnf --apply-log /var/log/mysql/tmp/new

И копия нашей базы готова. По сути, это «холодный» бэкап базы. Посмотрим, что у нас в папке:

sam@centos1:~:28/10/14-09:20$ ls -l /var/log/mysql/tmp/new
итого 594028
-rw-r--r-- 1 root root       358 Окт 28 09:15 backup-my.cnf
-rw-r----- 1 root root  69206016 Окт 28 09:20 ibdata1
-rw-r--r-- 1 root root 268435456 Окт 28 09:20 ib_logfile0
-rw-r--r-- 1 root root 268435456 Окт 28 09:20 ib_logfile1
-rw-r--r-- 1 root root        23 Окт 28 09:16 xtrabackup_binlog_info
-rw-r--r-- 1 root root        26 Окт 28 09:20 xtrabackup_binlog_pos_innodb
-rw-r----- 1 root root        95 Окт 28 09:20 xtrabackup_checkpoints
-rw-r--r-- 1 root root       692 Окт 28 09:16 xtrabackup_info
-rw-r----- 1 root root   2097152 Окт 28 09:20 xtrabackup_logfile
drwx--S--- 2 root root     90112 Окт 28 09:16 database

Интересная информация лежит в файлах:

sam@centos1:~:28/10/14-09:19$ less /var/log/mysql/tmp/new/xtrabackup_info
sam@centos1:~:28/10/14-09:19$ less /var/log/mysql/tmp/new/xtrabackup_binlog_info

Как видно, тут даже есть копия конфига.

Теперь это необходимо скопировать на будущую реплику — tar… rsync… снова tar)

Настройку базы как реплики я опущу. Вы можете настроить ее на основе конфига мастера или на свое усмотрение.

Базу останавливаем.

Как вы заметили, я снял дамп только одной базы. Больше и не надо, больше баз в innodb  у меня нет. Поэтому я могу спокойно скопировать базу с ее innodb лог-файлами на реплику. В случае, если у меня есть другие базы на этом движке — такой финт ушами уже не прокатит.

Удаляю лог-файлы innodb (ib_logfile0, ib_logfile1, ibdata1) на реплике и копирую данные из архива. Проверяю права, если все верно, то запускаю.

Создаем пользователя и запускаем репликацию (к примеру):

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'db_repl'@'192.168.1%' IDENTIFIED BY "12345"; - на мастере
CHANGE MASTER TO MASTER_HOST = '192.168.1.4', MASTER_USER = 'db_repl', MASTER_PASSWORD = "12345", MASTER_CONNECT_RETRY = 5000, MASTER_LOG_FILE = "mysql-bin.000058", MASTER_LOG_POS = 331; - на слейве

Данные для реплики (позиция и имя бинлог файла) я беру из:

/var/log/mysql/tmp/new/xtrabackup_info

Проверяем статус реплики и убеждаемся, что реплика работает.