Spec-Zone.ru › MySQL Enterprise Backup 4.1

7.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 с соответствующим параметром.

    Примечание

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

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

Spec-Zone.ru

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