RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 		 Visa 
4274 3200 2453 6495 

Глава 8. MySQL Enterprise Backup и репликация

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

8.1. Подготовка новой точной копии

MySQL Enterprise Backup позволяет вам настраивать сервер точной копии (называемый далее точной копией), поддерживая исходный сервер (называемый далее источником) и восстанавливая резервную копию на новой машине, не имея необходимости останавливать источник.

Для серверов, не использующих GTID :

  1. Сделайте полное резервное копирование источника, затем используйте, например, copy-back-and-apply-log, чтобы восстановить резервную копию и файлы журнала к правильным каталогам на новой точной копии и подготовить данные.

    Не используйте опцию --no-locking, поддерживая сервер, или вы не будете способны получить надлежащее двоичное положение регистрации в Шаге 4 ниже для инициализации точной копии.

  2. Отредактируйте файл my.cnf новой точной копии и поместите skip-slave-start и event_scheduler=off (если источник использует Event Scheduler) в секцию [mysqld].

  3. Начните новую точную копию mysqld. Вы видите следующее в выводе сервера:

    InnoDB: Last MySQL binlog file position 0 128760007,
        file name ./hundin-bin.000006

    В то время как показано сообщение Last MySQL binlog file position , это НЕ обязательно последнее положение двоичной регистрации на поддержанном сервере, поскольку InnoDB не хранит информацию о положении регистрации ни для каких операций DDL или любых изменений не-InnoDB таблиц Не используйте это положение двоичной регистрации, чтобы инициализировать точную копию. Следующий шаг объясняет, как найти правильное положение двоичной регистрации.

  4. Ищите файл datadir/meta/backup_variables.txt, где datadir это каталог данных новой точной копии. Изучите файл, чтобы восстановить последнее положение двоичной регистрации и соответствующий номер файла журнала, сохраненные внутри:

    binlog_position=hundin-bin.000006:128760128

  5. Используйте SQL-запрос CHANGE MASTER TO и информацию, которую вы получили на последнем шаге, чтобы инициализировать точную копию правильно:

    CHANGE MASTER TO
       MASTER_LOG_FILE='hundin-bin.000006',
       MASTER_LOG_POS=128760128;

  6. Установите статусы любых событий, которые были скопированы от источника до SLAVESIDE_DISABLED. Например:

    mysql> UPDATE mysql.event SET status = 'SLAVESIDE_DISABLED';

  7. Удалите строки skip-slave-start и event_scheduler=off из файла my.cnf, которые вы туда добавили на Шаге 2. Можно также убрать skip-slave-start, но тогда необходимо будет всегда использовать запрос START SLAVE, чтобы начать репликацию каждый раз, когда вы перезапускаете сервер точной копии.

  8. Перезапустите сервер точной копии.

Для серверов, использующих GTID (см. Setting Up Replication Using GTIDs о том, как позволить серверам использовать GTID):

  1. Возьмите полное резервное копирование источника и затем используйте, например, команду copy-back-and-apply-log, чтобы восстановить резервную копию и файлы журнала к правильным каталогам на новой GTID-точной копии и подготовить данные.

  2. Отредактируйте файл my.cnf новой точной копии и поместите skip-slave-start и event_scheduler=off (если источник использует Event Scheduler) в секцию [mysqld].

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

  4. Соединитесь с сервером точной копии клиентом mysql. Затем выполните следующий запрос, чтобы перезагрузить двоичную регистрацию:

    mysql> RESET MASTER;

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

    mysql> SET sql_log_bin=0;

  5. Когда сервер, использующий функцию GTID, поддерживается, mysqlbackup генерирует файл backup_gtid_executed.sql, который может быть найден в восстановленном каталоге данных нового сервера точной копии. Файл содержит SQL-оператор, который устанавливает параметр конфигурации GTID_PURGED на точной копии:

    # On a new replica, issue the following command if GTIDs are enabled:
SET @@GLOBAL.GTID_PURGED='f65db8e2-0e1a-11e5-a980-080027755380:1-3';

    Это также содержит прокомментированный запрос CHANGE MASTER TO для инициализации точной копии:

    # Use the following command if you want to use the GTID handshake protocol:
# CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

    Раскомментируйте команду и добавьте любую необходимую связь и параметры аутентификации к ней (например, MASTER_HOST, MASTER_USER, MASTER_PASSWORD и MASTER_PORT):

    # Use the following command if you want to use the GTID handshake protocol:
CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_USER='muser',
       MASTER_PASSWORD='mpass', MASTER_PORT=18675, MASTER_AUTO_POSITION = 1;

    Выполните файл клиентом mysql:

    mysql> source /path-to-backup_gtid_executed.sql/backup_gtid_executed.sql

  6. Установите статусы любых событий, которые были скопированы от источника до SLAVESIDE_DISABLED. Например:

    mysql> UPDATE mysql.event SET status = 'SLAVESIDE_DISABLED';

  7. Удалите добавленные ранее строки skip-slave-start и event_scheduler=off из файла my.cnf. Можно также добавить skip-slave-start, но тогда необходимо будет всегда использовать START SLAVE, чтобы начать репликацию каждый раз, когда вы перезапускаете сервер точной копии.

  8. Перезапустите сервер точной копии.

Для получения дополнительной информации о GTID см. GTID feature.

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

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

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

Временные таблицы на основанной на запросе репликации (SBR). MySQL Enterprise Backup не включает временные таблицы в резервной копии. В результате для сервера точной копии в основанной на запросе репликации (SBR) или смешанной установке повторения (см. Replication Formats) любые временные таблицы все еще открытые в конце процесса резервного копирования, будет отсутствовать в восстановленном сервере точной копии, делая состояние репликации непоследовательным, и любые последующие копируемые запросы, которые обращаются к временным таблицам, потерпит неудачу. Чтобы избежать проблемы, после фазы горячего резервного копирования, в которой mysqlbackup копирует все таблицы InnoDB, он создает цикл, в котором происходит следующее:

  1. mysqlbackup ждет, пока все временные таблицы не были закрыты SQL-потоком репликации. mysqlbackup говорит, если это так, проверяя, если переменная Slave_open_temp_tables = 0.

  2. После Slave_open_temp_tables=0 mysqlbackup останавливает SQL-поток репликации, чтобы предотвратить изменения таблиц на точной копии.

  3. Чтобы избежать неожиданного последствия в виде состояния состязания, после остановки потока SQL репликации, mysqlbackup еще раз проверит, что Slave_open_temp_tables=0:

    • Если это так, mysqlbackup выходит из цикла и заканчивает резервную копию, устанавливая блокировку чтения на все не-InnoDB таблицы и копирует их.

    • Если это не так, новые временные таблицы были составлены и открыты на точной копии. mysqlbackup тогда перезапускает поток SQL репликации, таким образом обновления могут быть сделаны на серверах точной копии. mysqlbackup тогда возвращается к шагу 1 цикла.

Помимо выходного условия, описанного в шаге (3) выше (действительно нет никаких открытых временных таблиц и mysqlbackup готово закончить резервную копию), mysqlbackup имеет тайм-аут в цикле, чтобы не ждать слишком долго все временные таблицы, которые будут закрыты. Продолжительность ожидания mysqlbackup определяется опцией --safe-slave-backup-timeout.

Кроме того, mysqlbackup также осуществляет начальную проверку в начале резервной копии, чтобы увидеть, если условие Slave_open_temp_tables=0 станет верным в течение --safe-slave-backup-timeout. См. описание для --safe-slave-backup-timeout.

Заметьте, что вышеописанная проблема с временными таблицами не существует для установки построчной репликации (RBR), для которой временные таблицы не копируются на точную копию вообще. Пользователь, который уверен, что SBR не происходит для точной копии, может установить --safe-slave-backup-timeout=0, что будет препятствовать mysqlbackup запускать проверочный цикл.

См. ограничение, которое применяется, поддерживая точную копию.

8.3. Восстановление исходной базы данных

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

  1. Закройте исходную базу данных и затем используйте, например, copy-back-and-apply-log, чтобы восстановить резервную копию и подготовить данные.

  2. Отредактируйте файл my.cnf источника и закомментруйте log-bin, чтобы точные копии не получали дважды двоичную регистрацию.

  3. Репликация в точных копиях должна быть остановлена временно в то время, как вы перекачиваете двоичную регистрацию к источнику. На точных копиях сделайте:

    mysql> STOP SLAVE;

  4. Запустите mysqld источника на восстановленной резервной копии:

    $ mysqld
InnoDB: Doing recovery: scanned up to log sequence number 0 64300044
InnoDB: Last MySQL binlog file position 0 5585832, file name
        ./omnibook-bin.000002

    InnoDB печатает файл двоичного журнала (./omnibook-bin.000002 в этом примере) и положение (5585832 в этом примере), в которых система запустилась.

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

    Также необходимо поставлять стартовую позицию в двоичной регистрации, с которой должна начаться передача событий. Выведите эту информацию из файла meta/backup_variables.txt в резервной копии, которую восстановили в шаге 1 выше (обратитесь к backup_variables.txt во временном резервном каталоге, указанном с --backup-dir во время восстановления, подкаталог meta): найдите запись binlog_position=value в meta/backup_variables.txt и передайте value в mysqlbinlog опцией --start-position.

    В то время как последнее восстановленное двоичное положение регистрации также показано InnoDB после восстановления (см. шаг 4 выше), оно не является надежным числом для выведения положения начала для mysqlbinlog, поскольку могли быть события DDL и изменения не-InnoDB, которые произошли после времени, отраженного показанным положением.

    Например, если есть еще два двоичных файла журнала, omnibook-bin.000003 и omnibook-bin.000004 после omnibook-bin.000002 и восстановление в шаге 4 выше закончилось на позиции 5585834 согласно файлу backup_variables.txt, перекачайте двоичную регистрацию:

    $ mysqlbinlog --start-position=5585834 /mysqldatadir/omnibook-bin.000002 \
              /mysqldatadir/omnibook-bin.000003 \
              /mysqldatadir/omnibook-bin.000004 | mysql

    См. Point-in-Time (Incremental) Recovery для большего количества инструкций относительно использования mysqlbinlog.

  6. Исходная база данных теперь восстановлена. Закройте источник и отредактируйте файл my.cnf, чтобы раскомментировать log-bin.

  7. Запустите источник снова.

  8. Запустите репликацию в точных копиях снова:

    mysql> START SLAVE;

8.4. Работа с зашифрованными журналами

MySQL Enterprise Backup 8.0.14 и позже понимает зашифрованные журналы, которые обработаны похожим способом, как зашифрованные таблицы InnoDB (см. главу 6).

Когда выполняется резервирование зашифрованного журнала, опция --encrypt-password требуется в следующих целях:

  • Если сервер использует плагин keyring_encrypted_file, пользователь должен использовать выбор --encrypt-password , чтобы предоставить mysqlbackup пароль шифрования файла брелка, который был установлен на сервере опцией keyring_encrypted_file_password. mysqlbackup тогда копирует с сервера зашифрованный файл данных брелка, который содержит главный ключ репликации используемый, чтобы зашифровать все пароли для отдельных файлов журнала, в каталог meta в резервной копии.

  • Если сервер использует плагин брелка кроме keyring_encrypted_file, mysqlbackup получает доступ к брелоку, чтобы получить главный ключ репликации и использует его, чтобы расшифровать пароли отдельных файлов журнала. Главный ключ репликации тогда помещается в файл данных брелка, который зашифрован с паролем пользователя, поставляемым через --encrypt-password и сохранен в каталоге meta в резервной копии с именем keyring_kef.

Когда восстановливается зашифрованный журнал, тот же самый пароль, используемый для поддержки базы данных, должен поставляться --encrypt-password, когда mysqlbackup выполняет следующие действия:

    • MySQL Enterprise Server: mysqlbackup вернул зашифрованный файл данных брелка к своему надлежащему местоположению на сервере. Восстановленный сервер должен быть запущен с плагином keyring_encrypted_file и опциями keyring_encrypted_file_data и keyring_encrypted_file_password (которая должна поставлять серверу тот же самый пароль, который использован с --encrypt-password при восстановлении).

    • MySQL Community Server: плагин keyring_file это единственный плагин брелка, поддержанный MySQL Community Server, поэтому mysqlbackup использует пароль, поставляемый опцией --encrypt-password, чтобы расшифровать файл данных брелка и затем вернуть его к надлежащему местоположению на сервере для плагина keyring_file.

Для возрастающих резервных копий. Для ряда возрастающих резервных копий, если плагин брелка кроме than keyring_encrypted_file используется на сервере, пользователи могут предоставить другое значение --encrypt-password для любого полного резервного копирования или инкрементного резервного копирования в резервной последовательности. Однако, пароль, используемый, чтобы сделать определенное полное резервное копирование или инкрементное резервное копирование, должен быть обеспечен, чтобы восстановить эту резервную копию. Начиная сервер после восстановления ряда возрастающих резервных копий, пароль, используемый для того, чтобы восстанавливать последнее инкрементное резервное копирование, должен поставляться серверу (за исключением MySQL Community Server, который запустится с плагином keyring_file и не требует опции keyring_encrypted_file_password).

Поиск

  

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru