Spec-Zone.ru › MySQL Enterprise Backup 8.4

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

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

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

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

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

    mysql> STOP REPLICA;
  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 в качестве параметра.

    Примечание

    Хотя последняя позиция бинарного журнала, восстанавливающаяся, также отображается 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
    

    Для получения более подробной информации об использовании mysqlbinlog см. соответствующую документацию.

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

  7. Запустите источник ещё раз.

  8. Возобновите репликацию на репликах:

    mysql> START REPLICA;

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-enterprise-backup-8.4-en/advanced.source.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API