MariaDB инструмент резервного копирования Mariabackup не удалось с ошибкой - PullRequest
0 голосов
/ 01 мая 2018

Мы недавно обновили MariaDB 5.5 до 10.2 и переключились с innobackupex на Mariadbackup (форк xtrabackup). Попытка сделать полную резервную копию всегда терпит неудачу.

Я запускаю резервное копирование с:

sudo mariabackup --backup --target-dir /mnt/database_backups/test --user backups --password REDACTED

Вывод команды выглядит следующим образом:

180501 11:53:30 Connecting to MySQL server host: localhost, user: backups, password: set, port: 3306, socket: /var/run/mysqld/mysqld.sock
Using server version 10.2.14-MariaDB-10.2.14+maria~trusty-log
mariabackup based on MariaDB server 10.2.14-MariaDB debian-linux-gnu (x86_64)
mariabackup: uses posix_fadvise().
mariabackup: cd to /var/lib/mysql/
mariabackup: open files limit requested 0, set to 1024
mariabackup: using the following InnoDB configuration:
mariabackup:   innodb_data_home_dir = .
mariabackup:   innodb_data_file_path = ibdata1:12M:autoextend
mariabackup:   innodb_log_group_home_dir = ./
mariabackup: using O_DIRECT
2018-05-01 11:53:30 140057835345792 [Note] InnoDB: Number of pools: 1
mariabackup: Generating a list of tablespaces
2018-05-01 11:53:30 140057835345792 [Warning] InnoDB: Allocated tablespace ID 2997 for warehouse/warehouses, old maximum was 0
180501 11:53:34 >> log scanned up to (2154583932391)
180501 11:53:34 [01] Copying ./ibdata1 to /mnt/database_backups/test/ibdata1
180501 11:53:35 >> log scanned up to (2154583953963)
180501 11:53:35 [01]        ...done
180501 11:53:35 [01] Copying ./warehouse/warehouses.ibd to /mnt/database_backups/test/warehouse/warehouses.ibd
180501 11:53:35 [01]        ...done

-- MORE Copying... ...done lines

180501 12:09:59 [01] Copying ./vioadmin/amazon__product_blacklist.ibd to /mnt/database_backups/test/vioadmin/amazon__product_blacklist.ibd
180501 12:09:59 [01]        ...done
180501 12:09:59 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
180501 12:09:59 Executing FLUSH TABLES WITH READ LOCK...
180501 12:09:59 Starting to backup non-InnoDB tables and files
180501 12:09:59 [01] Copying ./warehouse/warehouse_actions_archive.frm to /mnt/database_backups/test/warehouse/warehouse_actions_archive.frm
180501 12:09:59 [01]        ...done

-- MORE Copying... ...done lines

180501 12:10:01 Finished backing up non-InnoDB tables and files
180501 12:10:01 [01] Copying aria_log_control to /mnt/database_backups/test/aria_log_control
180501 12:10:01 [01]        ...done
180501 12:10:01 [01] Copying aria_log.00000001 to /mnt/database_backups/test/aria_log.00000001
180501 12:10:01 [01]        ...done
180501 12:10:01 [00] Writing xtrabackup_binlog_info
180501 12:10:01 [00]        ...done
180501 12:10:01 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
mariabackup: The latest check point (for incremental): '2154617240383'
mariabackup: Stopping log copying thread.

2018-05-01 12:10:01 140057835345792 [Note] InnoDB: Read redo log up to LSN=2154583953920
180501 12:10:01 >> log scanned up to (2154583953920)
180501 12:10:01 Executing UNLOCK TABLES
180501 12:10:01 All tables unlocked
180501 12:10:01 [00] Copying ib_buffer_pool to /mnt/database_backups/test/ib_buffer_pool
180501 12:10:01 [00]        ...done
180501 12:10:01 Backup created in directory '/mnt/database_backups/test/'
MySQL binlog position: filename 'mariadb-bin.005485', position '28883329', GTID of the last change '0-1-241386'
180501 12:10:01 [00] Writing backup-my.cnf
180501 12:10:01 [00]        ...done
180501 12:10:01 [00] Writing xtrabackup_info
180501 12:10:01 [00]        ...done
mariabackup: Redo log (from LSN 2154583538384 to 2154583953920) was copied.
mariabackup: error: failed to copy enough redo log (LSN=2154583953920; checkpoint LSN=2154617240383).

Может кто-нибудь пролить свет на проблему? Наш каталог данных составляет приблизительно 94 ГБ, поэтому база данных довольно велика, и, как вы можете видеть, продолжительность составила около 17 минут. Это похоже на то, что мы делали раньше с innobackupex.

Как видно из журнала выше, в процессе резервного копирования есть строки, начинающиеся с Executing FLUSH NO_WRITE_TO_BINLOG TABLES. Я не уверен, что все в порядке или проблема, но они кажутся немного странными, когда они разбросаны по сотням Copying строк. Таблицы, перечисленные ниже, на самом деле представляют собой все InnoDB, несмотря на то, что в нем указано Starting to backup non-InnoDB tables and files.

Спасибо за вашу помощь.

1 Ответ

0 голосов
/ 02 мая 2018

Я создал Mariabackup 10.2. Код разбора журнала повторов несколько отличается от Percona xtrabackup и Mariabackup 10.1.

Можете ли вы поделиться полным журналом, чтобы мы могли выяснить, почему именно он выходит из строя? Нам было бы наиболее удобно, если бы вы подали новую ошибку MDEV по адресу https://jira.mariadb.org/, поделились там подробностями и разместили здесь ссылку на проблему.

У меня есть две гипотезы. Либо Copy_online журнала повторного выполнения останавливается слишком рано из-за ошибки, либо существует много фоновых действий InnoDB, которые приводят к записи журнала повторного выполнения после того, как FLUSH TABLES WITH READ LOCK было выполнено ближе к концу резервного копирования.

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

Редактировать: Кто-то еще подал https://jira.mariadb.org/browse/MDEV-16367 для этой проблемы. Если у вас есть дополнительная информация, пожалуйста, отправьте ее туда.

...