Резервное копирование и настройка репликации MySQL с помощью LVM

Содержание

Введение

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

Из более-менее распространённых файловых систем, имеющих поддержку мгновенных снимков можно назвать:

• UFS2 во FreeBSD,
• BtrFS в Linux,
• ZFS в Solaris, FreeBSD, NetBSD и, с некоторыми оговорками, в Linux.

Кроме этого, даже если файловая система сама по себе не позволяет создавать снимки, снимки файловой системы иногда можно создавать средствами операционной системы. Например, в Windows можно создать снимок любой файловой системы средствами драйвера VolSnap.sys. В Linux похожим средством может стать модуль blksnap, который пока ещё не принят в официальные исходные тексты ядра.

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

• Подсистема Device-mapper позволяет добавить к одному блочному устройству, на котором находится отслеживаемая файловая система, добавить второе блочное устройство, на котором будут сохраняться изменённые блоки, нужные мгновенному снимку. Из этих двух блочных устройств создаются ещё два блочных устройства: одно используется для монтирования отслеживаемой файловой системы, а второе используется для доступа к мгновенному снимку.
• Подсистема Logical Volume Manager, или сокращённо - LVM, позволяет объединить несколько блочных устройств в одну группу, а группу поделить на логические блочные устройства произвольного размера. В каждом из логических блочных устройств можно разместить файловую систему, а если в группе осталось свободное место, то можно создавать мгновенный снимок любого логического тома, принадлежащего этой группе. Кстати говоря, поддержка LVM также присутствует и в NetBSD.

В этой статье пойдёт речь о создании полной резервной копии баз данных MySQL, находящихся на файловой системе, расположенной на логическом томе LVM в Linux.

Создание резервной копии

Создание и монитрование мгновенного снимка

Если в базе данных используются только таблицы формата InnoDB, то для создания простой резервной копии средствами LVM достаточно просто создать снимок логического тома с файловой системой, в которой расположены файлы баз данных MySQL:

# lvcreate -L 10G -s vg0/storage -n storage-snapshot

Где:

• vg0 - группа томов, содержащая логический том с интересущей нас файловой системой, в которой находятся файлы баз данных MySQL,
• storage - имя логического тома с файловой системой, в которой находятся файлы баз данных MySQL,
• storage-snapshot - мгновенный снимок, в котором будут сохраняться исходные версии изменённых блоков,
• 10G - максимальный объём изменений логического тома, сохраняемых в снимке. Если указанный объём будет исчерпан, то снимок перейдёт в неисправное состояние и попытки его чтения будут завершаться ошибкой. В файле конфигурации /etc/lvm/lvm.conf можно настроить автоматическое увеличение размеров снимков вплоть до исчерпания всего свободного места в группе томов.

Полученный в результате снимок можно смонтировать, например, в каталог /mnt/:

# mount /dev/vg0/storage-snapshot /mnt/

Этот снимок можно скопировать в локальный каталог или на удалённый компьютер с помощью rsync, его можно заархивировать или целиком передать по сети.

Локальная резервная копия с помощью rsync

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

# rsync -axv --delete-before /mnt/mysql/ /backup/db/

Здесь:

• /mnt/mysql/ - путь к каталогу с файлами баз данных MySQL, который находится на смонтированном мгновенном снимке,
• /backup/db/ - путь к каталогу с резервной копией файлов баз данных.

Локальная резервная копия в архиве

В качестве альтернативы, можно создать архивный файл с файлами баз данных MySQL:

# tar -cSjf /backup/db.tbz -C /mnt/mysql/ db

Где:

• /mnt/mysql/ - путь к каталогу с файлами баз данных MySQL, который находится на смонтированном мгновенном снимке,
• /backup/db.tbz - имя архивного файла с резервной копией файлов баз данных MySQL,
• db - имя каталога внутри архивного файла, в который будет помещено содержимое каталога /mnt/mysql/.

Резервная копия на удалённом сервере с помощью rsync

Чтобы скопировать файлы баз данных MySQL в каталог на удалённом компьютере, можно прибегнуть к более сложной команде:

# rsync -axv --delete-before -e 'ssh -i ~/.ssh/id_rsa' /mnt/mysql/ backup@server.domain.tld:/backup/db/

Где:

• /mnt/mysql/ - путь к каталогу с файлами баз данных MySQL, который находится на смонтированном мгновенном снимке,
• server.domain.tld - удалённый сервер, на который нужно скопировать резервную копию файлов баз данных. Если в указанном каталоге уже есть резервная копия, сделанная ранее, то она будет обновлена,
• backup - пользователь на удалённом сервере, имеющий доступ к этому серверу по SSH,
• ~/.ssh/id_rsa - путь к приватному ключу, который можно использовать для входа на удалённый сервер по SSH.

Резервная копия на удалённом сервере в виде архива

Для отправки архива на удалённый сервер, не прибегая к настройке SSH, можно привлечь утилиты pigz и socat. Установить их в систему можно, например, следующим образом:

# apt-get install pigz socat

Применение утилиты pigz позволяет сжать архив, при необходимости - в несколько потоков, для передачи по сети меньшего объёма данных. Утилита sockat при этом занимается передачей архива в сеть и его приёмом из сети.

На принимающем сервере запустим такую команду:

# socat -u TCP-LISTEN:4444,reuseaddr stdio > /backup/db.tbz

Здесь:

• 4444 - номер TCP-порта, на который socat примет одно входящее подключение,
• /backup/db.tbz - имя файла, в который будет записан принятый по сети архив с резервной копией файлов баз данных MySQL.

Затем на исходном сервере можно запустить формирование архива и его отправку в сеть на принимающий сервер:

# tar -cSjf - -C /mnt/mysql/ db | pigz -k -1 -p4 - | socat -u stdio TCP:192.168.169.2:4444

Где:

• /mnt/mysql/ - путь к каталогу с файлами баз данных MySQL, который находится на смонтированном мгновенном снимке,
• db - имя каталога внутри архивного файла, в который будет помещено содержимое каталога /mnt/mysql/.
• -1 - минимальная степень сжатия архива для наибольшей скорости сжатия. При необходимости использовать максимальное сжатие можно указать опцию -11,
• -p4 - сжатие в 4 потока. Будьте осторожны: не стоит отнимать ядра процессоров у MySQL, т.к. это может отразиться на скорости работы MySQL. Оцените, сколько процессорных ядер свободно, и укажите в этой опции их количество, а лучше - меньшее количество, чтобы оставался запас для MySQL,
• 192.168.169.2 - IP-адрес принимающего сервера,
• 4444 - номер TCP-порта удалённого сервера, на котором socat ожидает поступления входящих подключений.

Резервная копия на удалённом сервере

Для отправки резервной копии файлов баз данных MySQL на удалённый сервер, не прибегая к настройке SSH, можно привлечь те же самые утилиты tar, pigz и socat. Установить их в систему можно, например, следующим образом:

# apt-get install pigz socat

На принимающем сервере запустим такую команду:

# cd /backup/ && socat -u TCP-LISTEN:4444,reuseaddr stdio | pigz -dc -p4 - | tar xf -

Где:

• 4444 - номер TCP-порта, на который socat примет одно входящее подключение,
• /backup/ - каталог, в который будет помещены файлы баз данных MySQL, принятые по сети. Имя подкаталога в данном случае будет определяться передающей стороной.

Затем на исходном сервере можно запустить формирование архива и его отправку в сеть на принимающий сервер:

# tar -cSjf - -C /mnt/mysql/ db | pigz -k -1 -p4 - | socat -u stdio TCP:192.168.169.2:4444

Тут:

• /mnt/mysql/ - путь к каталогу с файлами баз данных MySQL, который находится на смонтированном мгновенном снимке,
• db - имя подкаталога на удалённом сервере, в который будут помещены файлы баз данных MySQL,
• -1 - минимальная степень сжатия архива для наибольшей скорости сжатия. Увеличивать степень сжатия в данном случае не имеет особого смысла, т.к. это не позволит сэкономить место на диске, но приведёт к замедлению передачи данных по сети из-за более длительного сжатия,
• -p4 - сжатие в 4 потока. Будьте осторожны: не стоит отнимать ядра процессоров у MySQL, т.к. это может отразиться на скорости работы MySQL. Оцените, сколько процессорных ядер свободно, и укажите в этой опции их количество, а лучше - меньшее количество, чтобы оставался запас для MySQL,
• 192.168.169.2 - IP-адрес принимающего сервера,
• 4444 - номер TCP-порта удалённого сервера, на котором socat ожидает поступления входящих подключений.

Размонтирование и удаление мгновенного снимка

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

# umount /mnt
# lvremove vg0/storage-snapshot
Do you really want to remove active logical volume storage-snapshot? [y/n]: y
  Logical volume "storage-snapshot" successfully removed

Настройка реплики из резервной копии источника

Настройка источника репликации

Чтобы настраиваемая реплика могла забирать журналы репликации с источника, на источнике нужно включить запись журналов репликации. Для этого в секцию [mysqld] файла конфигурации /etc/mysql/my.cnf нужно вписать следующие настройки:

server_id = 1
log_bin = bin-log
binlog_format = ROW
binlog_do_db = db
expire_logs_days = 3

Где:

• server_id - идентификатор сервера,
• log_bin - префикс имён файлов журналов репликации, к которому через точку будут добавляться порядковые номера частей,
• binlog_format - формат журнала: STATEMENT - в журнал пишутся SQL-запросы, ROW - в журнал пишутся изменения строк, MIXED - смешанный режим, в котором предпочтение отдаётся SQL-запросам, если они не содержат функций RANDOM(), NOW() и т.п.,
• binlog_do_db - база данных, изменения которой нужно записывать в журнал репликации. В случае нескольких баз данных опция указывается несколько раз,
• expire_logs_days - указывает, сколько суток хранить журналы репликации. Файлы старше будут автоматически удаляться. В MySQL версии 8.0 вместо этой опции нужно использовать опцию binlog_expire_logs_seconds, которая принимает значение срока хранения журналов в секундах.

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

# systemctl restart mysql

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

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

GRANT REPLICATION SLAVE ON *.* TO repl@host IDENTIFIED BY 'password';

Где:

• repl - имя пользователя, который будет использоваться репликой для подключения к источнику,
• password - пароль пользователя, который будет использоваться репликой для подключения к источнику,
• host - IP-адрес реплики, с которого реплика будет подключаться к источнику.

В случае с MySQL версии 8.0 команды немного отличаются:

CREATE USER repl@host IDENTIFIED WITH mysql_native_password BY 'password';
GRANT REPLICATION SLAVE ON *.* TO repl@host;

И применяем изменения:

FLUSH PRIVILEGES;

Подготовка копии

Для настройки консистентной реплики из резервной копии свервера-источника нужно выполнить следующие запросы в клиенте MySQL:

mysql> FLUSH LOCAL TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.10 sec)

mysql> SHOW MASTER STATUS;
+----------------+----------+--------------+------------------+
| File           | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------+----------+--------------+------------------+
| bin-log.001038 | 96682764 | db           |                  |
+----------------+----------+--------------+------------------+
1 row in set (0.02 sec)

Не закрывая клиента MySQL выполняем в соседнем окне команду создания мгновенного снимка логического тома, на котором находятся файлы баз данных MySQL:

# lvcreate -L 10G -s vg0/storage -n storage-snapshot

Возвращаемся к консольному клиенту MySQL и снимаем блокировки с таблиц (или можно просто выйти из клиента):

mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)

Запрос FLUSH LOCAL TABLES WITH READ LOCK предписывает MySQL дождаться завершения всех выполняемых транзакций, записать в файлы таблиц все зафиксированные транзакциями изменения, закрыть таблицы и открыть их в режиме только для чтения. После выполнения этого запроса все вновь начатые транзакции смогут прочитать данные, но не смогут ничего менять, поэтому все описанные выше операции лучше выполнять как можно быстрее. Для того, чтобы выполнить их разом, можно воспользоваться командой такого вида:

# mysql mysql -BN <<END
FLUSH LOCAL TABLES WITH READ LOCK;
SHOW MASTER STATUS;
system lvcreate -L 10G -s vg0/storage -n storage-snapshot
UNLOCK TABLES;
END

Мгновенный снимок можно скопировать на реплику с помощью rsync или с использованием команд socat, как это было описано выше.

У скопированных файлов нужно не забыть поменять владельца на пользователя mysql и группу доступа на группу mysql:

# chown mysql:mysql /var/lib/mysql

Также стоит отобрать права доступа у посторонних пользователей, не входящих в группу mysql:

# chmod o= -R /var/lib/mysql

Из каталога с данными на реплике можно удалить файлы журналов репликации, путь к которым на источнике можно найти в глобальной переменной log_bin_basename, а также файл auto.cnf, в котором содержится UUID сервера:

# rm /var/lib/mysql/bin-log.*
# rm /var/lib/mysql/auto.cnf

При совпадении UUID у источника и реплики репликация не запустится с сообщением об ошибке следующего вида:

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

Настройка реплики

Процесс репликации состоит из двух отделённых друг от друга задач:

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

Для настройки репликации на реплике в секцию [mysqld] файла конфигурации /etc/mysql/my.cnf нужно вписать следующие настройки:

server_id = 2
relay_log = relay-log
relay_log_space_limit = 10G
replicate_do_db = db
slave_transaction_retries = 20

Где:

• server_id - идентификатор сервера, должен отличаться от идентификатора источника и других реплик,
• relay_log - префикс имён файлов журналов репликации подчинённого сервера, к которому через точку будут добавляться порядковые номера частей,
• relay_log_space_limit - ограничение на объём журналов репликации, полученных с сервера-источника,
• replicate_do_db - реплицируемая база данных. При необходимости можно указать опцию несколько раз,
• slave_transaction_retries - количество попыток повторить выполнение транзакции из журнала репликации при ошибках блокировки и т.п. По умолчанию 10. В MySQL версии 8.0 эта опция называется replica_transaction_retries.

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

# systemctl start mysql

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

CHANGE MASTER TO MASTER_HOST = '192.168.1.1',
                 MASTER_USER = 'repl',
                 MASTER_PASSWORD = 'password',
                 MASTER_LOG_FILE = 'bin-log.001038',
                 MASTER_LOG_POS = 96682764;

Здесь:

• MASTER_HOST - IP-адрес или доменное имя источника репликации, из мгновенного снимка которого мы настраиваем реплику. Узнать IP-адрес можно, например, с помощью команды ip addr show,
• MASTER_USER - имя пользователя, который будет использоваться репликой для подключения к источнику. Это тот пользователь, которого мы настраивали в разделе Настройка источника репликации,
• MASTER_PASSWORD - пароль пользователя, который будет использоваться репликой для подключения к источнику. Это тот пользователь, которого мы настраивали в разделе Настройка источника репликации,
• MASTER_LOG_FILE - имя файла журнала на источнике, с которого нужно начать репликацию. Имя файла можно взять из поля File, выведенное командой SHOW MASTER STATUS в разделе Подготовка копии,
• MASTER_LOG_POS - позиция в файле журнала на источнике, с которой нужно начать репликацию. Позицию можно взять из поля Position, выведенное командой SHOW MASTER STATUS в разделе Подготовка копии.

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

START SLAVE;

За процессом репликации можно наблюдать при помощи команды следующего вида:

# watch "mysql -Be 'SHOW SLAVE STATUS\G' | fgrep Seconds_Behind_Master"

Она выводит количество секунд, на которое реплика отстаёт от источника. Когда отставание станет нулевым, можно считать реплику полностью синхронизированной с источником. Если же вместо числа выводится значение NULL, то процесс синхронизации по каким-то причинам не активен. Стоит посмотреть на полный вывод запроса SHOW SLAVE STATUS\G, чтобы установить причину.

Восстановление реплики из резервной копии источника

Бывает, что настроенная репилка теряет синхронизацию с источником.

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

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

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

Во всех других случаях, если журнал репликации успешно копируется с источника, но не применяется, придётся восстановить реплику из копии источника. Перед тем, как приступить к восстановлению, нужно сохранить права доступа, имеющиеся на реплике, с помощью утилиты pt-show-grants и сохранить настройки подключения к источнику. Сохраним права доступа в файле grants.sql:

# pt-show-grants > grants.sql

IP-адрес или доменное имя источника, имя и пароль пользователя для копирования журналов репликации с источника и порт источника можно найти в файле master.info, например вот так:

# awk 'NR>3 && NR<8 { print $0; }' /var/lib/mysql/master.info
192.168.1.1
repl
password
3306

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

После этого можно восстановить сохранённые права доступа:

# mysql mysql -BNe "SELECT CONCAT('DROP USER \`', user, '\`@\`', host, '\`;') FROM user WHERE user NOT IN ('root', 'mysql.session', 'mysql.sys');" | mysql mysql
# mysql mysql -BNe "SOURCE grants.sql"
# mysqladmin flush-privileges

Настроим и запустим репликацию, как было описано в разделе Настройка реплики, подставив адрес источника, имя пользователя и пароль, взятые из файла master.info:

CHANGE MASTER TO MASTER_HOST = '192.168.1.1',
                 MASTER_USER = 'repl',
                 MASTER_PASSWORD = 'password',
                 MASTER_LOG_FILE = 'bin-log.001038',
                 MASTER_LOG_POS = 96682764;
START SLAVE;

За процессом репликации можно наблюдать при помощи команды следующего вида:

# watch "mysql -Be 'SHOW SLAVE STATUS\G' | fgrep Seconds_Behind_Master"

Она выводит количество секунд, на которое реплика отстаёт от источника. Когда отставание станет нулевым, можно считать реплику полностью синхронизированной с источником.

Скрипт периодического резервного копирования

Для автоматизации резервного копирования с помощью мгновенных снимков я написал скрипт lvbackup.sh, функционально аналогичный скрипту xtrabackup2.sh, описанному в статье Периодическое резервное копирование MySQL с помощью xtrabackup в разделе Скрипт резервного копирования. В отличие от того скрипта, пригодного для резервного копирования баз данных с таблицами InnoDB, этот скрипт пригоден для резервного копирования баз данных с таблицами любого формата, в том числе таблиц TokuDB.

Настроить скрипт можно с помощью файла конфигурации /etc/lvbackup.conf, пример которого приведён ниже:

VGNAME=vg0
LVNAME=srv
LVSNAP=srv-snapshot
SNAP_PATH=/mnt/
SRC=mysql

BACKUP_PATH=/backup/

FOLLOW=master

RUSER=archive
RSERVER=server.domain
RPATH=/backups/db.tgz
RKEY=/etc/mysql/archive.key

DAYS=0

Где:

• VGNAME - группа томов, на которой находятся файлы баз данных MySQL,
• LVNAME - логический том, на котором находятся файлы баз данных MySQL,
• LVSNAP - имя логического тома с мгновенным снимком, который будет создан во время работы скрипта,
• SNAP_PATH - каталог, в который нужно смонтировать мгновенный снимок для копирования,
• SRC - относительный путь к каталогу с файлами баз данных на смонтированном мгновенном снимке. Если файлы баз данных находятся прямо в корне раздела, то в качестве имени можно указать точку - обозначение текущего каталога,
• BACKUP_PATH - каталог для резервных копий. В этом каталоге будет создан подкаталог db, содержащий внутри себя резервную копию файлов баз данных,
• FOLLOW - чью позицию из журнала репликации нужно сохранить в файл xtrabackup_binlog_info: master - файл будет содержать позицию из журнала репликации сервера, являющегося для текущего источником, me - файл будет содержать позицию из журнала репликации, который пишет текущий сервер,
• RUSER - имя пользователя на удалённом сервере,
• RSERVER - доменное имя или IP-адрес удалённого сервера, на который нужно скопировать архив с резервной копией,
• RPATH - путь к файлу архива на удалённом сервере,
• RKEY - путь к приватному ключу пользователя на удалённом сервере для подключения по SSH,
• DAYS - сколько архивов с резервной копией необходимо сохранять локально.

Для работы скрипту нужны права пользователя root. Пароль для подключения к базе данных можно поместить в файл /root/.my.cnf в следующем виде, указав реальный пароль справа от знака "равно":

[client]
password = password

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

# chown root:root /root/.my.cnf
# chmod u=rw,go= /root/.my.cnf

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

# crontab -e

И добавить в список задач время запуска скрипта и путь к скрипту, в данном случае скрипт /usr/local/bin/lvbackup.sh будет запускаться ежесуточно ровно в 6 часов утра:

0       6       *       *       *       /usr/local/bin/lvbackup.sh

Скрипты для настройки реплики

Для частичной автоматизации действий, описанных в разделе Подготовка копии я подготовил скрипты lvrecv.sh и lvsend.sh. Скрипты используют утилиты tar, pigz и socat. Первая обычно установлена в системе по умолчанию, а последние две нужно установить, например, так:

# apt-get install pigz socat

Скрипт lvrecv.sh предназначен для запуска на настраиваемой реплике и запускается первым. Перед запуском скрипта стоит заглянуть в него и отредактировать его настройки, вынесенные в переменные в начале скрипа:

DIR=/srv/mysql.new
PORT=4444

Где:

• DIR - каталог, в который будет записана копия файлов баз данных, принятая по сети,
• PORT - TCP-порт, на котором скрипт будет ожидать поступления входящего подключения со стороны источника.

Скрипт lvsend.sh предназначен для запуска на источнике, копия которого будет использована для настройки реплики, и запускается вторым. Перед запуском скрипта нужно отредактировать его настройки, вынесенные в переменные в начале скрипта:

VGNAME=vg0
LVNAME=srv
LVSNAP=srv-snapshot
SNAP_PATH=/mnt/
SRC=mysql

DST_IP=192.168.1.1
DST_PORT=4444

Здесь:

• VGNAME - группа томов, на которой находятся файлы баз данных MySQL,
• LVNAME - логический том, на котором находятся файлы баз данных MySQL,
• LVSNAP - имя логического тома с мгновенным снимком, который будет создан во время работы скрипта,
• SNAP_PATH - каталог, в который нужно смонтировать мгновенный снимок для копирования,
• SRC - относительный путь к каталогу с файлами баз данных на смонтированном мгновенном снимке. Если файлы баз данных находятся прямо в корне раздела, то в качестве имени можно указать точку - обозначение текущего каталога,
• DST_IP - IP-адрес или доменное имя настраиваемой реплики, в сторону которой будет отправлена копия мгновенного снимка файлов баз данных MySQL,
• DST_PORT - TCP-порт, на котором настраиваемая реплика ожидает поступления входящего подключения и через который она будет принимать копию файлов баз данных MySQL.

Скрипт lvsend.sh выведет имя файла журнала репликации исходного сервера и позицию внутри этого файла, с которых реплика должна будет продолжить репликацию. Нужно дождаться завершения обоих скриптов.

Из принятой резервной копии на настраиваемой реплике нужно вручную удалить файлы журналов, которые вёл источник - на реплике они не нужны. Далее можно действовать в соответствии с уже описанными инструкциями, используя в качестве точки для начала репликации информацию, выведенную скриптом lvsend.sh.

Использованные материалы

• Сравнение файловых систем
• Stephen R Lang. Setting up MySQL Master Slave Replication with LVM snapshots
• Peter Zaitsev. Using LVM for MySQL Backup and Replication Setup

Дополнительные материалы

• snapshot UFS2 во FreeBSD
• FreeBSD Documantation Portal / The Z File System (ZFS) / Managing Snapshots
• blksnap - block devices snapshots module
• Device-mapper snapshot support
• Device-mapper / Snapshot
• Understanding LVM snapshots (create, merge, remove, extend) / Automatically extend the snapshot volume