You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

2035 lines
45 KiB

MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2 InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly. The code has been simplified, and many memory leaks have been fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 is being used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads have been removed. Some help was provided by Vladislav Vaintroub. Parameters have been cleaned up and aligned with those of MariaDB 10.2. The --dbug option has been added, so that in debug builds, --dbug=d,ib_log can be specified to enable diagnostic messages for processing redo log entries. By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, double buffering can be enabled. The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup. Some messages have been cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, call it the redo log, not transaction log. We disable any undo log processing in --prepare. Because MariaDB 10.2 supports indexed virtual columns, the undo log processing would need to be able to evaluate virtual column expressions. To reduce the amount of code dependencies, we will not process any undo log in prepare. This means that the --export option must be disabled for now. This also means that the following options are redundant and have been removed: xtrabackup --apply-log-only innobackupex --redo-only In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted. (If the --export option is enabled in the future, it must generate redo log when processing undo logs and buffered changes.) In --prepare, we cannot easily know if a partial backup was used, especially when restoring a series of incremental backups. So, we simply warn about any missing files, and ignore the redo log for them. FIXME: Enable the --export option. FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write a test that initiates a backup while an ALGORITHM=INPLACE operation is creating indexes or rebuilding a table. An error should be detected when preparing the backup. FIXME: In --incremental --prepare, xtrabackup_apply_delta() should ensure that if FSP_SIZE is modified, the file size will be adjusted accordingly.
8 years ago
  1. /******************************************************
  2. hot backup tool for InnoDB
  3. (c) 2009-2015 Percona LLC and/or its affiliates
  4. (c) 2017 MariaDB
  5. Originally Created 3/3/2009 Yasufumi Kinoshita
  6. Written by Alexey Kopytov, Aleksandr Kuzminsky, Stewart Smith, Vadim Tkachenko,
  7. Yasufumi Kinoshita, Ignacio Nin and Baron Schwartz.
  8. This program is free software; you can redistribute it and/or modify
  9. it under the terms of the GNU General Public License as published by
  10. the Free Software Foundation; version 2 of the License.
  11. This program is distributed in the hope that it will be useful,
  12. but WITHOUT ANY WARRANTY; without even the implied warranty of
  13. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  14. GNU General Public License for more details.
  15. You should have received a copy of the GNU General Public License
  16. along with this program; if not, write to the Free Software
  17. Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
  18. *******************************************************
  19. This file incorporates work covered by the following copyright and
  20. permission notice:
  21. Copyright (c) 2000, 2011, MySQL AB & Innobase Oy. All Rights Reserved.
  22. This program is free software; you can redistribute it and/or modify it under
  23. the terms of the GNU General Public License as published by the Free Software
  24. Foundation; version 2 of the License.
  25. This program is distributed in the hope that it will be useful, but WITHOUT
  26. ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
  27. FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
  28. You should have received a copy of the GNU General Public License along with
  29. this program; if not, write to the Free Software Foundation, Inc., 59 Temple
  30. Place, Suite 330, Boston, MA 02111-1307 USA
  31. *******************************************************/
  32. #include <my_global.h>
  33. #include <os0file.h>
  34. #include <my_dir.h>
  35. #include <ut0mem.h>
  36. #include <srv0start.h>
  37. #include <fil0fil.h>
  38. #include <trx0sys.h>
  39. #include <set>
  40. #include <string>
  41. #include <mysqld.h>
  42. #include <sstream>
  43. #include "fil_cur.h"
  44. #include "xtrabackup.h"
  45. #include "common.h"
  46. #include "backup_copy.h"
  47. #include "backup_mysql.h"
  48. #include <btr0btr.h>
  49. #include "xb0xb.h"
  50. /* list of files to sync for --rsync mode */
  51. static std::set<std::string> rsync_list;
  52. /* locations of tablespaces read from .isl files */
  53. static std::map<std::string, std::string> tablespace_locations;
  54. /* Whether LOCK BINLOG FOR BACKUP has been issued during backup */
  55. bool binlog_locked;
  56. /************************************************************************
  57. Struct represents file or directory. */
  58. struct datadir_node_t {
  59. ulint dbpath_len;
  60. char *filepath;
  61. ulint filepath_len;
  62. char *filepath_rel;
  63. ulint filepath_rel_len;
  64. bool is_empty_dir;
  65. bool is_file;
  66. };
  67. /************************************************************************
  68. Holds the state needed to enumerate files in MySQL data directory. */
  69. struct datadir_iter_t {
  70. char *datadir_path;
  71. char *dbpath;
  72. ulint dbpath_len;
  73. char *filepath;
  74. ulint filepath_len;
  75. char *filepath_rel;
  76. ulint filepath_rel_len;
  77. pthread_mutex_t mutex;
  78. os_file_dir_t dir;
  79. os_file_dir_t dbdir;
  80. os_file_stat_t dbinfo;
  81. os_file_stat_t fileinfo;
  82. dberr_t err;
  83. bool is_empty_dir;
  84. bool is_file;
  85. bool skip_first_level;
  86. };
  87. /************************************************************************
  88. Represents the context of the thread processing MySQL data directory. */
  89. struct datadir_thread_ctxt_t {
  90. datadir_iter_t *it;
  91. uint n_thread;
  92. uint *count;
  93. pthread_mutex_t count_mutex;
  94. os_thread_id_t id;
  95. bool ret;
  96. };
  97. static bool backup_files_from_datadir(const char *dir_path);
  98. /************************************************************************
  99. Retirn true if character if file separator */
  100. bool
  101. is_path_separator(char c)
  102. {
  103. return(c == FN_LIBCHAR || c == FN_LIBCHAR2);
  104. }
  105. /************************************************************************
  106. Fill the node struct. Memory for node need to be allocated and freed by
  107. the caller. It is caller responsibility to initialize node with
  108. datadir_node_init and cleanup the memory with datadir_node_free.
  109. Node can not be shared between threads. */
  110. static
  111. void
  112. datadir_node_fill(datadir_node_t *node, datadir_iter_t *it)
  113. {
  114. if (node->filepath_len < it->filepath_len) {
  115. free(node->filepath);
  116. node->filepath = (char*)(malloc(it->filepath_len));
  117. node->filepath_len = it->filepath_len;
  118. }
  119. if (node->filepath_rel_len < it->filepath_rel_len) {
  120. free(node->filepath_rel);
  121. node->filepath_rel = (char*)(malloc(it->filepath_rel_len));
  122. node->filepath_rel_len = it->filepath_rel_len;
  123. }
  124. strcpy(node->filepath, it->filepath);
  125. strcpy(node->filepath_rel, it->filepath_rel);
  126. node->is_empty_dir = it->is_empty_dir;
  127. node->is_file = it->is_file;
  128. }
  129. static
  130. void
  131. datadir_node_free(datadir_node_t *node)
  132. {
  133. free(node->filepath);
  134. free(node->filepath_rel);
  135. memset(node, 0, sizeof(datadir_node_t));
  136. }
  137. static
  138. void
  139. datadir_node_init(datadir_node_t *node)
  140. {
  141. memset(node, 0, sizeof(datadir_node_t));
  142. }
  143. /************************************************************************
  144. Create the MySQL data directory iterator. Memory needs to be released
  145. with datadir_iter_free. Position should be advanced with
  146. datadir_iter_next_file. Iterator can be shared between multiple
  147. threads. It is guaranteed that each thread receives unique file from
  148. data directory into its local node struct. */
  149. static
  150. datadir_iter_t *
  151. datadir_iter_new(const char *path, bool skip_first_level = true)
  152. {
  153. datadir_iter_t *it;
  154. it = static_cast<datadir_iter_t *>(malloc(sizeof(datadir_iter_t)));
  155. memset(it, 0, sizeof(datadir_iter_t));
  156. pthread_mutex_init(&it->mutex, NULL);
  157. it->datadir_path = strdup(path);
  158. it->dir = os_file_opendir(it->datadir_path, TRUE);
  159. if (it->dir == NULL) {
  160. goto error;
  161. }
  162. it->err = DB_SUCCESS;
  163. it->dbpath_len = FN_REFLEN;
  164. it->dbpath = static_cast<char*>(malloc(it->dbpath_len));
  165. it->filepath_len = FN_REFLEN;
  166. it->filepath = static_cast<char*>(malloc(it->filepath_len));
  167. it->filepath_rel_len = FN_REFLEN;
  168. it->filepath_rel = static_cast<char*>(malloc(it->filepath_rel_len));
  169. it->skip_first_level = skip_first_level;
  170. return(it);
  171. error:
  172. free(it);
  173. return(NULL);
  174. }
  175. static
  176. bool
  177. datadir_iter_next_database(datadir_iter_t *it)
  178. {
  179. if (it->dbdir != NULL) {
  180. if (os_file_closedir(it->dbdir) != 0) {
  181. msg("Warning: could not"
  182. " close database directory %s\n", it->dbpath);
  183. it->err = DB_ERROR;
  184. }
  185. it->dbdir = NULL;
  186. }
  187. while (os_file_readdir_next_file(it->datadir_path,
  188. it->dir, &it->dbinfo) == 0) {
  189. ulint len;
  190. if ((it->dbinfo.type == OS_FILE_TYPE_FILE
  191. && it->skip_first_level)
  192. || it->dbinfo.type == OS_FILE_TYPE_UNKNOWN) {
  193. continue;
  194. }
  195. /* We found a symlink or a directory; try opening it to see
  196. if a symlink is a directory */
  197. len = strlen(it->datadir_path)
  198. + strlen (it->dbinfo.name) + 2;
  199. if (len > it->dbpath_len) {
  200. it->dbpath_len = len;
  201. free(it->dbpath);
  202. it->dbpath = static_cast<char*>(
  203. malloc(it->dbpath_len));
  204. }
  205. snprintf(it->dbpath, it->dbpath_len, "%s/%s",
  206. it->datadir_path, it->dbinfo.name);
  207. os_normalize_path(it->dbpath);
  208. if (it->dbinfo.type == OS_FILE_TYPE_FILE) {
  209. it->is_file = true;
  210. return(true);
  211. }
  212. if (check_if_skip_database_by_path(it->dbpath)) {
  213. msg("Skipping db: %s\n", it->dbpath);
  214. continue;
  215. }
  216. /* We want wrong directory permissions to be a fatal error for
  217. XtraBackup. */
  218. it->dbdir = os_file_opendir(it->dbpath, TRUE);
  219. if (it->dbdir != NULL) {
  220. it->is_file = false;
  221. return(true);
  222. }
  223. }
  224. return(false);
  225. }
  226. /************************************************************************
  227. Concatenate n parts into single path */
  228. static
  229. void
  230. make_path_n(int n, char **path, ulint *path_len, ...)
  231. {
  232. ulint len_needed = n + 1;
  233. char *p;
  234. int i;
  235. va_list vl;
  236. ut_ad(n > 0);
  237. va_start(vl, path_len);
  238. for (i = 0; i < n; i++) {
  239. p = va_arg(vl, char*);
  240. len_needed += strlen(p);
  241. }
  242. va_end(vl);
  243. if (len_needed < *path_len) {
  244. free(*path);
  245. *path = static_cast<char*>(malloc(len_needed));
  246. }
  247. va_start(vl, path_len);
  248. p = va_arg(vl, char*);
  249. strcpy(*path, p);
  250. for (i = 1; i < n; i++) {
  251. size_t plen;
  252. p = va_arg(vl, char*);
  253. plen = strlen(*path);
  254. if (!is_path_separator((*path)[plen - 1])) {
  255. (*path)[plen] = FN_LIBCHAR;
  256. (*path)[plen + 1] = 0;
  257. }
  258. strcat(*path + plen, p);
  259. }
  260. va_end(vl);
  261. }
  262. static
  263. bool
  264. datadir_iter_next_file(datadir_iter_t *it)
  265. {
  266. if (it->is_file && it->dbpath) {
  267. make_path_n(2, &it->filepath, &it->filepath_len,
  268. it->datadir_path, it->dbinfo.name);
  269. make_path_n(1, &it->filepath_rel, &it->filepath_rel_len,
  270. it->dbinfo.name);
  271. it->is_empty_dir = false;
  272. it->is_file = false;
  273. return(true);
  274. }
  275. if (!it->dbpath || !it->dbdir) {
  276. return(false);
  277. }
  278. while (os_file_readdir_next_file(it->dbpath, it->dbdir,
  279. &it->fileinfo) == 0) {
  280. if (it->fileinfo.type == OS_FILE_TYPE_DIR) {
  281. continue;
  282. }
  283. /* We found a symlink or a file */
  284. make_path_n(3, &it->filepath, &it->filepath_len,
  285. it->datadir_path, it->dbinfo.name,
  286. it->fileinfo.name);
  287. make_path_n(2, &it->filepath_rel, &it->filepath_rel_len,
  288. it->dbinfo.name, it->fileinfo.name);
  289. it->is_empty_dir = false;
  290. return(true);
  291. }
  292. return(false);
  293. }
  294. static
  295. bool
  296. datadir_iter_next(datadir_iter_t *it, datadir_node_t *node)
  297. {
  298. bool ret = true;
  299. pthread_mutex_lock(&it->mutex);
  300. if (datadir_iter_next_file(it)) {
  301. datadir_node_fill(node, it);
  302. goto done;
  303. }
  304. while (datadir_iter_next_database(it)) {
  305. if (datadir_iter_next_file(it)) {
  306. datadir_node_fill(node, it);
  307. goto done;
  308. }
  309. make_path_n(2, &it->filepath, &it->filepath_len,
  310. it->datadir_path, it->dbinfo.name);
  311. make_path_n(1, &it->filepath_rel, &it->filepath_rel_len,
  312. it->dbinfo.name);
  313. it->is_empty_dir = true;
  314. datadir_node_fill(node, it);
  315. goto done;
  316. }
  317. /* nothing found */
  318. ret = false;
  319. done:
  320. pthread_mutex_unlock(&it->mutex);
  321. return(ret);
  322. }
  323. /************************************************************************
  324. Interface to read MySQL data file sequentially. One should open file
  325. with datafile_open to get cursor and close the cursor with
  326. datafile_close. Cursor can not be shared between multiple
  327. threads. */
  328. static
  329. void
  330. datadir_iter_free(datadir_iter_t *it)
  331. {
  332. pthread_mutex_destroy(&it->mutex);
  333. if (it->dbdir) {
  334. os_file_closedir(it->dbdir);
  335. }
  336. if (it->dir) {
  337. os_file_closedir(it->dir);
  338. }
  339. free(it->dbpath);
  340. free(it->filepath);
  341. free(it->filepath_rel);
  342. free(it->datadir_path);
  343. free(it);
  344. }
  345. /************************************************************************
  346. Holds the state needed to copy single data file. */
  347. struct datafile_cur_t {
  348. pfs_os_file_t file;
  349. char rel_path[FN_REFLEN];
  350. char abs_path[FN_REFLEN];
  351. MY_STAT statinfo;
  352. uint thread_n;
  353. byte* orig_buf;
  354. byte* buf;
  355. size_t buf_size;
  356. size_t buf_read;
  357. size_t buf_offset;
  358. };
  359. static
  360. void
  361. datafile_close(datafile_cur_t *cursor)
  362. {
  363. if (cursor->file != OS_FILE_CLOSED) {
  364. os_file_close(cursor->file);
  365. }
  366. free(cursor->buf);
  367. }
  368. static
  369. bool
  370. datafile_open(const char *file, datafile_cur_t *cursor, uint thread_n)
  371. {
  372. bool success;
  373. memset(cursor, 0, sizeof(datafile_cur_t));
  374. strncpy(cursor->abs_path, file, sizeof(cursor->abs_path));
  375. /* Get the relative path for the destination tablespace name, i.e. the
  376. one that can be appended to the backup root directory. Non-system
  377. tablespaces may have absolute paths for remote tablespaces in MySQL
  378. 5.6+. We want to make "local" copies for the backup. */
  379. strncpy(cursor->rel_path,
  380. xb_get_relative_path(cursor->abs_path, FALSE),
  381. sizeof(cursor->rel_path));
  382. cursor->file = os_file_create_simple_no_error_handling(
  383. 0, cursor->abs_path,
  384. OS_FILE_OPEN, OS_FILE_READ_ALLOW_DELETE, true, &success);
  385. if (!success) {
  386. /* The following call prints an error message */
  387. os_file_get_last_error(TRUE);
  388. msg("[%02u] error: cannot open "
  389. "file %s\n",
  390. thread_n, cursor->abs_path);
  391. return(false);
  392. }
  393. if (!my_stat(cursor->abs_path, &cursor->statinfo, 0)) {
  394. msg("[%02u] error: cannot stat %s\n",
  395. thread_n, cursor->abs_path);
  396. datafile_close(cursor);
  397. return(false);
  398. }
  399. posix_fadvise(cursor->file, 0, 0, POSIX_FADV_SEQUENTIAL);
  400. cursor->buf_size = 10 * 1024 * 1024;
  401. cursor->buf = static_cast<byte *>(malloc((ulint)cursor->buf_size));
  402. return(true);
  403. }
  404. static
  405. xb_fil_cur_result_t
  406. datafile_read(datafile_cur_t *cursor)
  407. {
  408. ulint to_read;
  409. xtrabackup_io_throttling();
  410. to_read = (ulint)MY_MIN(cursor->statinfo.st_size - cursor->buf_offset,
  411. cursor->buf_size);
  412. if (to_read == 0) {
  413. return(XB_FIL_CUR_EOF);
  414. }
  415. if (!os_file_read(IORequestRead,
  416. cursor->file, cursor->buf, cursor->buf_offset,
  417. to_read)) {
  418. return(XB_FIL_CUR_ERROR);
  419. }
  420. posix_fadvise(cursor->file, cursor->buf_offset, to_read,
  421. POSIX_FADV_DONTNEED);
  422. cursor->buf_read = to_read;
  423. cursor->buf_offset += to_read;
  424. return(XB_FIL_CUR_SUCCESS);
  425. }
  426. /************************************************************************
  427. Check to see if a file exists.
  428. Takes name of the file to check.
  429. @return true if file exists. */
  430. static
  431. bool
  432. file_exists(const char *filename)
  433. {
  434. MY_STAT stat_arg;
  435. if (!my_stat(filename, &stat_arg, MYF(0))) {
  436. return(false);
  437. }
  438. return(true);
  439. }
  440. /************************************************************************
  441. Trim leading slashes from absolute path so it becomes relative */
  442. static
  443. const char *
  444. trim_dotslash(const char *path)
  445. {
  446. while (*path) {
  447. if (is_path_separator(*path)) {
  448. ++path;
  449. continue;
  450. }
  451. if (*path == '.' && is_path_separator(path[1])) {
  452. path += 2;
  453. continue;
  454. }
  455. break;
  456. }
  457. return(path);
  458. }
  459. /************************************************************************
  460. Check if string ends with given suffix.
  461. @return true if string ends with given suffix. */
  462. bool
  463. ends_with(const char *str, const char *suffix)
  464. {
  465. size_t suffix_len = strlen(suffix);
  466. size_t str_len = strlen(str);
  467. return(str_len >= suffix_len
  468. && strcmp(str + str_len - suffix_len, suffix) == 0);
  469. }
  470. static bool starts_with(const char *str, const char *prefix)
  471. {
  472. return strncmp(str, prefix, strlen(prefix)) == 0;
  473. }
  474. /************************************************************************
  475. Create directories recursively.
  476. @return 0 if directories created successfully. */
  477. static
  478. int
  479. mkdirp(const char *pathname, int Flags, myf MyFlags)
  480. {
  481. char parent[PATH_MAX], *p;
  482. /* make a parent directory path */
  483. strncpy(parent, pathname, sizeof(parent));
  484. parent[sizeof(parent) - 1] = 0;
  485. for (p = parent + strlen(parent);
  486. !is_path_separator(*p) && p != parent; p--);
  487. *p = 0;
  488. /* try to make parent directory */
  489. if (p != parent && mkdirp(parent, Flags, MyFlags) != 0) {
  490. return(-1);
  491. }
  492. /* make this one if parent has been made */
  493. if (my_mkdir(pathname, Flags, MyFlags) == 0) {
  494. return(0);
  495. }
  496. /* if it already exists that is fine */
  497. if (errno == EEXIST) {
  498. return(0);
  499. }
  500. return(-1);
  501. }
  502. /************************************************************************
  503. Return true if first and second arguments are the same path. */
  504. bool
  505. equal_paths(const char *first, const char *second)
  506. {
  507. #ifdef HAVE_REALPATH
  508. char real_first[PATH_MAX];
  509. char real_second[PATH_MAX];
  510. if (realpath(first, real_first) == NULL) {
  511. return false;
  512. }
  513. if (realpath(second, real_second) == NULL) {
  514. return false;
  515. }
  516. return (strcmp(real_first, real_second) == 0);
  517. #else
  518. return strcmp(first, second) == 0;
  519. #endif
  520. }
  521. /************************************************************************
  522. Check if directory exists. Optionally create directory if doesn't
  523. exist.
  524. @return true if directory exists and if it was created successfully. */
  525. bool
  526. directory_exists(const char *dir, bool create)
  527. {
  528. os_file_dir_t os_dir;
  529. MY_STAT stat_arg;
  530. char errbuf[MYSYS_STRERROR_SIZE];
  531. if (my_stat(dir, &stat_arg, MYF(0)) == NULL) {
  532. if (!create) {
  533. return(false);
  534. }
  535. if (mkdirp(dir, 0777, MYF(0)) < 0) {
  536. my_strerror(errbuf, sizeof(errbuf), my_errno);
  537. msg("Can not create directory %s: %s\n", dir, errbuf);
  538. return(false);
  539. }
  540. }
  541. /* could be symlink */
  542. os_dir = os_file_opendir(dir, FALSE);
  543. if (os_dir == NULL) {
  544. my_strerror(errbuf, sizeof(errbuf), my_errno);
  545. msg("Can not open directory %s: %s\n", dir,
  546. errbuf);
  547. return(false);
  548. }
  549. os_file_closedir(os_dir);
  550. return(true);
  551. }
  552. /************************************************************************
  553. Check that directory exists and it is empty. */
  554. static
  555. bool
  556. directory_exists_and_empty(const char *dir, const char *comment)
  557. {
  558. os_file_dir_t os_dir;
  559. dberr_t err;
  560. os_file_stat_t info;
  561. bool empty;
  562. if (!directory_exists(dir, true)) {
  563. return(false);
  564. }
  565. os_dir = os_file_opendir(dir, FALSE);
  566. if (os_dir == NULL) {
  567. msg("%s can not open directory %s\n", comment, dir);
  568. return(false);
  569. }
  570. empty = (fil_file_readdir_next_file(&err, dir, os_dir, &info) != 0);
  571. os_file_closedir(os_dir);
  572. if (!empty) {
  573. msg("%s directory %s is not empty!\n", comment, dir);
  574. }
  575. return(empty);
  576. }
  577. /************************************************************************
  578. Check if file name ends with given set of suffixes.
  579. @return true if it does. */
  580. static
  581. bool
  582. filename_matches(const char *filename, const char **ext_list)
  583. {
  584. const char **ext;
  585. for (ext = ext_list; *ext; ext++) {
  586. if (ends_with(filename, *ext)) {
  587. return(true);
  588. }
  589. }
  590. return(false);
  591. }
  592. /************************************************************************
  593. Copy data file for backup. Also check if it is allowed to copy by
  594. comparing its name to the list of known data file types and checking
  595. if passes the rules for partial backup.
  596. @return true if file backed up or skipped successfully. */
  597. static
  598. bool
  599. datafile_copy_backup(const char *filepath, uint thread_n)
  600. {
  601. const char *ext_list[] = {"frm", "isl", "MYD", "MYI", "MAD", "MAI",
  602. "MRG", "TRG", "TRN", "ARM", "ARZ", "CSM", "CSV", "opt", "par",
  603. NULL};
  604. /* Get the name and the path for the tablespace. node->name always
  605. contains the path (which may be absolute for remote tablespaces in
  606. 5.6+). space->name contains the tablespace name in the form
  607. "./database/table.ibd" (in 5.5-) or "database/table" (in 5.6+). For a
  608. multi-node shared tablespace, space->name contains the name of the first
  609. node, but that's irrelevant, since we only need node_name to match them
  610. against filters, and the shared tablespace is always copied regardless
  611. of the filters value. */
  612. if (check_if_skip_table(filepath)) {
  613. msg_ts("[%02u] Skipping %s.\n", thread_n, filepath);
  614. return(true);
  615. }
  616. if (filename_matches(filepath, ext_list)) {
  617. return copy_file(ds_data, filepath, filepath, thread_n);
  618. }
  619. return(true);
  620. }
  621. /************************************************************************
  622. Same as datafile_copy_backup, but put file name into the list for
  623. rsync command. */
  624. static
  625. bool
  626. datafile_rsync_backup(const char *filepath, bool save_to_list, FILE *f)
  627. {
  628. const char *ext_list[] = {"frm", "isl", "MYD", "MYI", "MAD", "MAI",
  629. "MRG", "TRG", "TRN", "ARM", "ARZ", "CSM", "CSV", "opt", "par",
  630. NULL};
  631. /* Get the name and the path for the tablespace. node->name always
  632. contains the path (which may be absolute for remote tablespaces in
  633. 5.6+). space->name contains the tablespace name in the form
  634. "./database/table.ibd" (in 5.5-) or "database/table" (in 5.6+). For a
  635. multi-node shared tablespace, space->name contains the name of the first
  636. node, but that's irrelevant, since we only need node_name to match them
  637. against filters, and the shared tablespace is always copied regardless
  638. of the filters value. */
  639. if (check_if_skip_table(filepath)) {
  640. return(true);
  641. }
  642. if (filename_matches(filepath, ext_list)) {
  643. fprintf(f, "%s\n", filepath);
  644. if (save_to_list) {
  645. rsync_list.insert(filepath);
  646. }
  647. }
  648. return(true);
  649. }
  650. static
  651. bool
  652. backup_file_vprintf(const char *filename, const char *fmt, va_list ap)
  653. {
  654. ds_file_t *dstfile = NULL;
  655. MY_STAT stat; /* unused for now */
  656. char *buf = 0;
  657. int buf_len;
  658. const char *action;
  659. memset(&stat, 0, sizeof(stat));
  660. buf_len = vasprintf(&buf, fmt, ap);
  661. stat.st_size = buf_len;
  662. stat.st_mtime = my_time(0);
  663. dstfile = ds_open(ds_data, filename, &stat);
  664. if (dstfile == NULL) {
  665. msg("[%02u] error: "
  666. "cannot open the destination stream for %s\n",
  667. 0, filename);
  668. goto error;
  669. }
  670. action = xb_get_copy_action("Writing");
  671. msg_ts("[%02u] %s %s\n", 0, action, filename);
  672. if (buf_len == -1) {
  673. goto error;
  674. }
  675. if (ds_write(dstfile, buf, buf_len)) {
  676. goto error;
  677. }
  678. /* close */
  679. msg_ts("[%02u] ...done\n", 0);
  680. free(buf);
  681. if (ds_close(dstfile)) {
  682. goto error_close;
  683. }
  684. return(true);
  685. error:
  686. free(buf);
  687. if (dstfile != NULL) {
  688. ds_close(dstfile);
  689. }
  690. error_close:
  691. msg("[%02u] Error: backup file failed.\n", 0);
  692. return(false); /*ERROR*/
  693. }
  694. bool
  695. backup_file_printf(const char *filename, const char *fmt, ...)
  696. {
  697. bool result;
  698. va_list ap;
  699. va_start(ap, fmt);
  700. result = backup_file_vprintf(filename, fmt, ap);
  701. va_end(ap);
  702. return(result);
  703. }
  704. static
  705. bool
  706. run_data_threads(datadir_iter_t *it, os_thread_func_t func, uint n)
  707. {
  708. datadir_thread_ctxt_t *data_threads;
  709. uint i, count;
  710. pthread_mutex_t count_mutex;
  711. bool ret;
  712. data_threads = (datadir_thread_ctxt_t*)
  713. malloc(sizeof(datadir_thread_ctxt_t) * n);
  714. pthread_mutex_init(&count_mutex, NULL);
  715. count = n;
  716. for (i = 0; i < n; i++) {
  717. data_threads[i].it = it;
  718. data_threads[i].n_thread = i + 1;
  719. data_threads[i].count = &count;
  720. data_threads[i].count_mutex = count_mutex;
  721. os_thread_create(func, data_threads + i, &data_threads[i].id);
  722. }
  723. /* Wait for threads to exit */
  724. while (1) {
  725. os_thread_sleep(100000);
  726. pthread_mutex_lock(&count_mutex);
  727. if (count == 0) {
  728. pthread_mutex_unlock(&count_mutex);
  729. break;
  730. }
  731. pthread_mutex_unlock(&count_mutex);
  732. }
  733. pthread_mutex_destroy(&count_mutex);
  734. ret = true;
  735. for (i = 0; i < n; i++) {
  736. ret = data_threads[i].ret && ret;
  737. if (!data_threads[i].ret) {
  738. msg("Error: thread %u failed.\n", i);
  739. }
  740. }
  741. free(data_threads);
  742. return(ret);
  743. }
  744. /************************************************************************
  745. Copy file for backup/restore.
  746. @return true in case of success. */
  747. bool
  748. copy_file(ds_ctxt_t *datasink,
  749. const char *src_file_path,
  750. const char *dst_file_path,
  751. uint thread_n)
  752. {
  753. char dst_name[FN_REFLEN];
  754. ds_file_t *dstfile = NULL;
  755. datafile_cur_t cursor;
  756. xb_fil_cur_result_t res;
  757. const char *dst_path =
  758. (xtrabackup_copy_back || xtrabackup_move_back)?
  759. dst_file_path : trim_dotslash(dst_file_path);
  760. if (!datafile_open(src_file_path, &cursor, thread_n)) {
  761. goto error_close;
  762. }
  763. strncpy(dst_name, cursor.rel_path, sizeof(dst_name));
  764. dstfile = ds_open(datasink, dst_path, &cursor.statinfo);
  765. if (dstfile == NULL) {
  766. msg("[%02u] error: "
  767. "cannot open the destination stream for %s\n",
  768. thread_n, dst_name);
  769. goto error;
  770. }
  771. msg_ts("[%02u] %s %s to %s\n",
  772. thread_n, xb_get_copy_action(), src_file_path, dstfile->path);
  773. /* The main copy loop */
  774. while ((res = datafile_read(&cursor)) == XB_FIL_CUR_SUCCESS) {
  775. if (ds_write(dstfile, cursor.buf, cursor.buf_read)) {
  776. goto error;
  777. }
  778. }
  779. if (res == XB_FIL_CUR_ERROR) {
  780. goto error;
  781. }
  782. /* close */
  783. msg_ts("[%02u] ...done\n", thread_n);
  784. datafile_close(&cursor);
  785. if (ds_close(dstfile)) {
  786. goto error_close;
  787. }
  788. return(true);
  789. error:
  790. datafile_close(&cursor);
  791. if (dstfile != NULL) {
  792. ds_close(dstfile);
  793. }
  794. error_close:
  795. msg("[%02u] Error: copy_file() failed.\n", thread_n);
  796. return(false); /*ERROR*/
  797. }
  798. /************************************************************************
  799. Try to move file by renaming it. If source and destination are on
  800. different devices fall back to copy and unlink.
  801. @return true in case of success. */
  802. static
  803. bool
  804. move_file(ds_ctxt_t *datasink,
  805. const char *src_file_path,
  806. const char *dst_file_path,
  807. const char *dst_dir, uint thread_n)
  808. {
  809. char errbuf[MYSYS_STRERROR_SIZE];
  810. char dst_file_path_abs[FN_REFLEN];
  811. char dst_dir_abs[FN_REFLEN];
  812. size_t dirname_length;
  813. snprintf(dst_file_path_abs, sizeof(dst_file_path_abs),
  814. "%s/%s", dst_dir, dst_file_path);
  815. dirname_part(dst_dir_abs, dst_file_path_abs, &dirname_length);
  816. if (!directory_exists(dst_dir_abs, true)) {
  817. return(false);
  818. }
  819. if (file_exists(dst_file_path_abs)) {
  820. msg("Error: Move file %s to %s failed: Destination "
  821. "file exists\n",
  822. src_file_path, dst_file_path_abs);
  823. return(false);
  824. }
  825. msg_ts("[%02u] Moving %s to %s\n",
  826. thread_n, src_file_path, dst_file_path_abs);
  827. if (my_rename(src_file_path, dst_file_path_abs, MYF(0)) != 0) {
  828. if (my_errno == EXDEV) {
  829. bool ret;
  830. ret = copy_file(datasink, src_file_path,
  831. dst_file_path, thread_n);
  832. msg_ts("[%02u] Removing %s\n", thread_n, src_file_path);
  833. if (unlink(src_file_path) != 0) {
  834. my_strerror(errbuf, sizeof(errbuf), errno);
  835. msg("Error: unlink %s failed: %s\n",
  836. src_file_path,
  837. errbuf);
  838. }
  839. return(ret);
  840. }
  841. my_strerror(errbuf, sizeof(errbuf), my_errno);
  842. msg("Can not move file %s to %s: %s\n",
  843. src_file_path, dst_file_path_abs,
  844. errbuf);
  845. return(false);
  846. }
  847. msg_ts("[%02u] ...done\n", thread_n);
  848. return(true);
  849. }
  850. /************************************************************************
  851. Read link from .isl file if any and store it in the global map associated
  852. with given tablespace. */
  853. static
  854. void
  855. read_link_file(const char *ibd_filepath, const char *link_filepath)
  856. {
  857. char *filepath= NULL;
  858. FILE *file = fopen(link_filepath, "r+b");
  859. if (file) {
  860. filepath = static_cast<char*>(malloc(OS_FILE_MAX_PATH));
  861. os_file_read_string(file, filepath, OS_FILE_MAX_PATH);
  862. fclose(file);
  863. if (strlen(filepath)) {
  864. /* Trim whitespace from end of filepath */
  865. ulint lastch = strlen(filepath) - 1;
  866. while (lastch > 4 && filepath[lastch] <= 0x20) {
  867. filepath[lastch--] = 0x00;
  868. }
  869. os_normalize_path(filepath);
  870. }
  871. tablespace_locations[ibd_filepath] = filepath;
  872. }
  873. free(filepath);
  874. }
  875. /************************************************************************
  876. Return the location of given .ibd if it was previously read
  877. from .isl file.
  878. @return NULL or destination .ibd file path. */
  879. static
  880. const char *
  881. tablespace_filepath(const char *ibd_filepath)
  882. {
  883. std::map<std::string, std::string>::iterator it;
  884. it = tablespace_locations.find(ibd_filepath);
  885. if (it != tablespace_locations.end()) {
  886. return it->second.c_str();
  887. }
  888. return NULL;
  889. }
  890. /************************************************************************
  891. Copy or move file depending on current mode.
  892. @return true in case of success. */
  893. static
  894. bool
  895. copy_or_move_file(const char *src_file_path,
  896. const char *dst_file_path,
  897. const char *dst_dir,
  898. uint thread_n)
  899. {
  900. ds_ctxt_t *datasink = ds_data; /* copy to datadir by default */
  901. char filedir[FN_REFLEN];
  902. size_t filedir_len;
  903. bool ret;
  904. /* read the link from .isl file */
  905. if (ends_with(src_file_path, ".isl")) {
  906. char *ibd_filepath;
  907. ibd_filepath = strdup(src_file_path);
  908. strcpy(ibd_filepath + strlen(ibd_filepath) - 3, "ibd");
  909. read_link_file(ibd_filepath, src_file_path);
  910. free(ibd_filepath);
  911. }
  912. /* check if there is .isl file */
  913. if (ends_with(src_file_path, ".ibd")) {
  914. char *link_filepath;
  915. const char *filepath;
  916. link_filepath = strdup(src_file_path);
  917. strcpy(link_filepath + strlen(link_filepath) - 3, "isl");
  918. read_link_file(src_file_path, link_filepath);
  919. filepath = tablespace_filepath(src_file_path);
  920. if (filepath != NULL) {
  921. dirname_part(filedir, filepath, &filedir_len);
  922. dst_file_path = filepath + filedir_len;
  923. dst_dir = filedir;
  924. if (!directory_exists(dst_dir, true)) {
  925. ret = false;
  926. goto cleanup;
  927. }
  928. datasink = ds_create(dst_dir, DS_TYPE_LOCAL);
  929. }
  930. free(link_filepath);
  931. }
  932. ret = (xtrabackup_copy_back ?
  933. copy_file(datasink, src_file_path, dst_file_path, thread_n) :
  934. move_file(datasink, src_file_path, dst_file_path,
  935. dst_dir, thread_n));
  936. cleanup:
  937. if (datasink != ds_data) {
  938. ds_destroy(datasink);
  939. }
  940. return(ret);
  941. }
  942. static
  943. bool
  944. backup_files(const char *from, bool prep_mode)
  945. {
  946. char rsync_tmpfile_name[FN_REFLEN];
  947. FILE *rsync_tmpfile = NULL;
  948. datadir_iter_t *it;
  949. datadir_node_t node;
  950. bool ret = true;
  951. if (prep_mode && !opt_rsync) {
  952. return(true);
  953. }
  954. if (opt_rsync) {
  955. snprintf(rsync_tmpfile_name, sizeof(rsync_tmpfile_name),
  956. "%s/%s%d", opt_mysql_tmpdir,
  957. "xtrabackup_rsyncfiles_pass",
  958. prep_mode ? 1 : 2);
  959. rsync_tmpfile = fopen(rsync_tmpfile_name, "w");
  960. if (rsync_tmpfile == NULL) {
  961. msg("Error: can't create file %s\n",
  962. rsync_tmpfile_name);
  963. return(false);
  964. }
  965. }
  966. msg_ts("Starting %s non-InnoDB tables and files\n",
  967. prep_mode ? "prep copy of" : "to backup");
  968. datadir_node_init(&node);
  969. it = datadir_iter_new(from);
  970. while (datadir_iter_next(it, &node)) {
  971. if (!node.is_empty_dir) {
  972. if (opt_rsync) {
  973. ret = datafile_rsync_backup(node.filepath,
  974. !prep_mode, rsync_tmpfile);
  975. } else {
  976. ret = datafile_copy_backup(node.filepath, 1);
  977. }
  978. if (!ret) {
  979. msg("Failed to copy file %s\n", node.filepath);
  980. goto out;
  981. }
  982. } else if (!prep_mode) {
  983. /* backup fake file into empty directory */
  984. char path[FN_REFLEN];
  985. snprintf(path, sizeof(path),
  986. "%s/db.opt", node.filepath);
  987. if (!(ret = backup_file_printf(
  988. trim_dotslash(path), "%s", ""))) {
  989. msg("Failed to create file %s\n", path);
  990. goto out;
  991. }
  992. }
  993. }
  994. if (opt_rsync) {
  995. std::stringstream cmd;
  996. int err;
  997. if (buffer_pool_filename && file_exists(buffer_pool_filename)) {
  998. fprintf(rsync_tmpfile, "%s\n", buffer_pool_filename);
  999. rsync_list.insert(buffer_pool_filename);
  1000. }
  1001. if (file_exists("ib_lru_dump")) {
  1002. fprintf(rsync_tmpfile, "%s\n", "ib_lru_dump");
  1003. rsync_list.insert("ib_lru_dump");
  1004. }
  1005. fclose(rsync_tmpfile);
  1006. rsync_tmpfile = NULL;
  1007. cmd << "rsync -t . --files-from=" << rsync_tmpfile_name
  1008. << " " << xtrabackup_target_dir;
  1009. msg_ts("Starting rsync as: %s\n", cmd.str().c_str());
  1010. if ((err = system(cmd.str().c_str()) && !prep_mode) != 0) {
  1011. msg_ts("Error: rsync failed with error code %d\n", err);
  1012. ret = false;
  1013. goto out;
  1014. }
  1015. msg_ts("rsync finished successfully.\n");
  1016. if (!prep_mode && !opt_no_lock) {
  1017. char path[FN_REFLEN];
  1018. char dst_path[FN_REFLEN];
  1019. char *newline;
  1020. /* Remove files that have been removed between first and
  1021. second passes. Cannot use "rsync --delete" because it
  1022. does not work with --files-from. */
  1023. snprintf(rsync_tmpfile_name, sizeof(rsync_tmpfile_name),
  1024. "%s/%s", opt_mysql_tmpdir,
  1025. "xtrabackup_rsyncfiles_pass1");
  1026. rsync_tmpfile = fopen(rsync_tmpfile_name, "r");
  1027. if (rsync_tmpfile == NULL) {
  1028. msg("Error: can't open file %s\n",
  1029. rsync_tmpfile_name);
  1030. return(false);
  1031. }
  1032. while (fgets(path, sizeof(path), rsync_tmpfile)) {
  1033. newline = strchr(path, '\n');
  1034. if (newline) {
  1035. *newline = 0;
  1036. }
  1037. if (rsync_list.count(path) < 1) {
  1038. snprintf(dst_path, sizeof(dst_path),
  1039. "%s/%s", xtrabackup_target_dir,
  1040. path);
  1041. msg_ts("Removing %s\n", dst_path);
  1042. unlink(dst_path);
  1043. }
  1044. }
  1045. fclose(rsync_tmpfile);
  1046. rsync_tmpfile = NULL;
  1047. }
  1048. }
  1049. msg_ts("Finished %s non-InnoDB tables and files\n",
  1050. prep_mode ? "a prep copy of" : "backing up");
  1051. out:
  1052. datadir_iter_free(it);
  1053. datadir_node_free(&node);
  1054. if (rsync_tmpfile != NULL) {
  1055. fclose(rsync_tmpfile);
  1056. }
  1057. return(ret);
  1058. }
  1059. /** Start --backup */
  1060. bool backup_start()
  1061. {
  1062. if (!opt_no_lock) {
  1063. if (opt_safe_slave_backup) {
  1064. if (!wait_for_safe_slave(mysql_connection)) {
  1065. return(false);
  1066. }
  1067. }
  1068. if (!backup_files(fil_path_to_mysql_datadir, true)) {
  1069. return(false);
  1070. }
  1071. history_lock_time = time(NULL);
  1072. if (!lock_tables(mysql_connection)) {
  1073. return(false);
  1074. }
  1075. }
  1076. if (!backup_files(fil_path_to_mysql_datadir, false)) {
  1077. return(false);
  1078. }
  1079. if (!backup_files_from_datadir(fil_path_to_mysql_datadir)) {
  1080. return false;
  1081. }
  1082. // There is no need to stop slave thread before coping non-Innodb data when
  1083. // --no-lock option is used because --no-lock option requires that no DDL or
  1084. // DML to non-transaction tables can occur.
  1085. if (opt_no_lock) {
  1086. if (opt_safe_slave_backup) {
  1087. if (!wait_for_safe_slave(mysql_connection)) {
  1088. return(false);
  1089. }
  1090. }
  1091. }
  1092. if (opt_slave_info) {
  1093. lock_binlog_maybe(mysql_connection);
  1094. if (!write_slave_info(mysql_connection)) {
  1095. return(false);
  1096. }
  1097. }
  1098. /* The only reason why Galera/binlog info is written before
  1099. wait_for_ibbackup_log_copy_finish() is that after that call the xtrabackup
  1100. binary will start streamig a temporary copy of REDO log to stdout and
  1101. thus, any streaming from innobackupex would interfere. The only way to
  1102. avoid that is to have a single process, i.e. merge innobackupex and
  1103. xtrabackup. */
  1104. if (opt_galera_info) {
  1105. if (!write_galera_info(mysql_connection)) {
  1106. return(false);
  1107. }
  1108. write_current_binlog_file(mysql_connection);
  1109. }
  1110. if (opt_binlog_info == BINLOG_INFO_ON) {
  1111. lock_binlog_maybe(mysql_connection);
  1112. write_binlog_info(mysql_connection);
  1113. }
  1114. if (have_flush_engine_logs) {
  1115. msg_ts("Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...\n");
  1116. xb_mysql_query(mysql_connection,
  1117. "FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS", false);
  1118. }
  1119. return(true);
  1120. }
  1121. /** Release resources after backup_start() */
  1122. void backup_release()
  1123. {
  1124. /* release all locks */
  1125. if (!opt_no_lock) {
  1126. unlock_all(mysql_connection);
  1127. history_lock_time = 0;
  1128. } else {
  1129. history_lock_time = time(NULL) - history_lock_time;
  1130. }
  1131. if (opt_lock_ddl_per_table) {
  1132. mdl_unlock_all();
  1133. }
  1134. if (opt_safe_slave_backup && sql_thread_started) {
  1135. msg("Starting slave SQL thread\n");
  1136. xb_mysql_query(mysql_connection,
  1137. "START SLAVE SQL_THREAD", false);
  1138. }
  1139. }
  1140. /** Finish after backup_start() and backup_release() */
  1141. bool backup_finish()
  1142. {
  1143. /* Copy buffer pool dump or LRU dump */
  1144. if (!opt_rsync) {
  1145. if (buffer_pool_filename && file_exists(buffer_pool_filename)) {
  1146. const char *dst_name;
  1147. dst_name = trim_dotslash(buffer_pool_filename);
  1148. copy_file(ds_data, buffer_pool_filename, dst_name, 0);
  1149. }
  1150. if (file_exists("ib_lru_dump")) {
  1151. copy_file(ds_data, "ib_lru_dump", "ib_lru_dump", 0);
  1152. }
  1153. }
  1154. msg_ts("Backup created in directory '%s'\n", xtrabackup_target_dir);
  1155. if (mysql_binlog_position != NULL) {
  1156. msg("MySQL binlog position: %s\n", mysql_binlog_position);
  1157. }
  1158. if (mysql_slave_position && opt_slave_info) {
  1159. msg("MySQL slave binlog position: %s\n",
  1160. mysql_slave_position);
  1161. }
  1162. if (!write_backup_config_file()) {
  1163. return(false);
  1164. }
  1165. if (!write_xtrabackup_info(mysql_connection, XTRABACKUP_INFO, opt_history != 0)) {
  1166. return(false);
  1167. }
  1168. return(true);
  1169. }
  1170. bool
  1171. ibx_copy_incremental_over_full()
  1172. {
  1173. const char *ext_list[] = {"frm", "isl", "MYD", "MYI", "MAD", "MAI",
  1174. "MRG", "TRG", "TRN", "ARM", "ARZ", "CSM", "CSV", "opt", "par",
  1175. NULL};
  1176. const char *sup_files[] = {"xtrabackup_binlog_info",
  1177. "xtrabackup_galera_info",
  1178. "xtrabackup_slave_info",
  1179. "xtrabackup_info",
  1180. "ib_lru_dump",
  1181. NULL};
  1182. datadir_iter_t *it = NULL;
  1183. datadir_node_t node;
  1184. bool ret = true;
  1185. char path[FN_REFLEN];
  1186. int i;
  1187. datadir_node_init(&node);
  1188. /* If we were applying an incremental change set, we need to make
  1189. sure non-InnoDB files and xtrabackup_* metainfo files are copied
  1190. to the full backup directory. */
  1191. if (xtrabackup_incremental) {
  1192. ds_data = ds_create(xtrabackup_target_dir, DS_TYPE_LOCAL);
  1193. it = datadir_iter_new(xtrabackup_incremental_dir);
  1194. while (datadir_iter_next(it, &node)) {
  1195. /* copy only non-innodb files */
  1196. if (node.is_empty_dir
  1197. || !filename_matches(node.filepath, ext_list)) {
  1198. continue;
  1199. }
  1200. if (file_exists(node.filepath_rel)) {
  1201. unlink(node.filepath_rel);
  1202. }
  1203. if (!(ret = copy_file(ds_data, node.filepath,
  1204. node.filepath_rel, 1))) {
  1205. msg("Failed to copy file %s\n",
  1206. node.filepath);
  1207. goto cleanup;
  1208. }
  1209. }
  1210. /* copy buffer pool dump */
  1211. if (innobase_buffer_pool_filename) {
  1212. const char *src_name;
  1213. src_name = trim_dotslash(innobase_buffer_pool_filename);
  1214. snprintf(path, sizeof(path), "%s/%s",
  1215. xtrabackup_incremental_dir,
  1216. src_name);
  1217. if (file_exists(path)) {
  1218. copy_file(ds_data, path,
  1219. innobase_buffer_pool_filename, 0);
  1220. }
  1221. }
  1222. /* copy supplementary files */
  1223. for (i = 0; sup_files[i]; i++) {
  1224. snprintf(path, sizeof(path), "%s/%s",
  1225. xtrabackup_incremental_dir,
  1226. sup_files[i]);
  1227. if (file_exists(path))
  1228. {
  1229. if (file_exists(sup_files[i])) {
  1230. unlink(sup_files[i]);
  1231. }
  1232. copy_file(ds_data, path, sup_files[i], 0);
  1233. }
  1234. }
  1235. }
  1236. cleanup:
  1237. if (it != NULL) {
  1238. datadir_iter_free(it);
  1239. }
  1240. if (ds_data != NULL) {
  1241. ds_destroy(ds_data);
  1242. }
  1243. datadir_node_free(&node);
  1244. return(ret);
  1245. }
  1246. bool
  1247. ibx_cleanup_full_backup()
  1248. {
  1249. const char *ext_list[] = {"delta", "meta", "ibd", NULL};
  1250. datadir_iter_t *it = NULL;
  1251. datadir_node_t node;
  1252. bool ret = true;
  1253. datadir_node_init(&node);
  1254. /* If we are applying an incremental change set, we need to make
  1255. sure non-InnoDB files are cleaned up from full backup dir before
  1256. we copy files from incremental dir. */
  1257. it = datadir_iter_new(xtrabackup_target_dir);
  1258. while (datadir_iter_next(it, &node)) {
  1259. if (node.is_empty_dir) {
  1260. #ifdef _WIN32
  1261. DeleteFile(node.filepath);
  1262. #else
  1263. rmdir(node.filepath);
  1264. #endif
  1265. }
  1266. if (xtrabackup_incremental && !node.is_empty_dir
  1267. && !filename_matches(node.filepath, ext_list)) {
  1268. unlink(node.filepath);
  1269. }
  1270. }
  1271. datadir_iter_free(it);
  1272. datadir_node_free(&node);
  1273. return(ret);
  1274. }
  1275. bool
  1276. apply_log_finish()
  1277. {
  1278. if (!ibx_cleanup_full_backup()
  1279. || !ibx_copy_incremental_over_full()) {
  1280. return(false);
  1281. }
  1282. return(true);
  1283. }
  1284. bool
  1285. copy_back()
  1286. {
  1287. bool ret;
  1288. datadir_iter_t *it = NULL;
  1289. datadir_node_t node;
  1290. char *dst_dir;
  1291. memset(&node, 0, sizeof(node));
  1292. if (!opt_force_non_empty_dirs) {
  1293. if (!directory_exists_and_empty(mysql_data_home,
  1294. "Original data")) {
  1295. return(false);
  1296. }
  1297. } else {
  1298. if (!directory_exists(mysql_data_home, true)) {
  1299. return(false);
  1300. }
  1301. }
  1302. if (srv_undo_dir && *srv_undo_dir
  1303. && !directory_exists(srv_undo_dir, true)) {
  1304. return(false);
  1305. }
  1306. if (innobase_data_home_dir && *innobase_data_home_dir
  1307. && !directory_exists(innobase_data_home_dir, true)) {
  1308. return(false);
  1309. }
  1310. if (srv_log_group_home_dir && *srv_log_group_home_dir
  1311. && !directory_exists(srv_log_group_home_dir, true)) {
  1312. return(false);
  1313. }
  1314. /* cd to backup directory */
  1315. if (my_setwd(xtrabackup_target_dir, MYF(MY_WME)))
  1316. {
  1317. msg("cannot my_setwd %s\n", xtrabackup_target_dir);
  1318. return(false);
  1319. }
  1320. /* parse data file path */
  1321. if (!innobase_data_file_path) {
  1322. innobase_data_file_path = (char*) "ibdata1:10M:autoextend";
  1323. }
  1324. srv_sys_space.set_path(".");
  1325. if (!srv_sys_space.parse_params(innobase_data_file_path, true)) {
  1326. msg("syntax error in innodb_data_file_path\n");
  1327. return(false);
  1328. }
  1329. srv_max_n_threads = 1000;
  1330. sync_check_init();
  1331. ut_crc32_init();
  1332. /* copy undo tablespaces */
  1333. dst_dir = (srv_undo_dir && *srv_undo_dir)
  1334. ? srv_undo_dir : mysql_data_home;
  1335. ds_data = ds_create(dst_dir, DS_TYPE_LOCAL);
  1336. for (uint i = 1; i <= TRX_SYS_MAX_UNDO_SPACES; i++) {
  1337. char filename[20];
  1338. sprintf(filename, "undo%03u", i);
  1339. if (!file_exists(filename)) {
  1340. break;
  1341. }
  1342. if (!(ret = copy_or_move_file(filename, filename,
  1343. dst_dir, 1))) {
  1344. goto cleanup;
  1345. }
  1346. }
  1347. ds_destroy(ds_data);
  1348. ds_data = NULL;
  1349. /* copy redo logs */
  1350. dst_dir = (srv_log_group_home_dir && *srv_log_group_home_dir)
  1351. ? srv_log_group_home_dir : mysql_data_home;
  1352. /* --backup generates a single ib_logfile0, which we must copy
  1353. if it exists. */
  1354. ds_data = ds_create(dst_dir, DS_TYPE_LOCAL);
  1355. MY_STAT stat_arg;
  1356. if (!my_stat("ib_logfile0", &stat_arg, MYF(0)) || !stat_arg.st_size) {
  1357. /* After completed --prepare, redo log files are redundant.
  1358. We must delete any redo logs at the destination, so that
  1359. the database will not jump to a different log sequence number
  1360. (LSN). */
  1361. for (uint i = 0; i <= SRV_N_LOG_FILES_MAX + 1; i++) {
  1362. char filename[FN_REFLEN];
  1363. snprintf(filename, sizeof filename, "%s/ib_logfile%u",
  1364. dst_dir, i);
  1365. unlink(filename);
  1366. }
  1367. } else if (!(ret = copy_or_move_file("ib_logfile0", "ib_logfile0",
  1368. dst_dir, 1))) {
  1369. goto cleanup;
  1370. }
  1371. ds_destroy(ds_data);
  1372. /* copy innodb system tablespace(s) */
  1373. dst_dir = (innobase_data_home_dir && *innobase_data_home_dir)
  1374. ? innobase_data_home_dir : mysql_data_home;
  1375. ds_data = ds_create(dst_dir, DS_TYPE_LOCAL);
  1376. for (Tablespace::const_iterator iter(srv_sys_space.begin()),
  1377. end(srv_sys_space.end());
  1378. iter != end;
  1379. ++iter) {
  1380. const char *filename = base_name(iter->name());
  1381. if (!(ret = copy_or_move_file(filename, iter->name(),
  1382. dst_dir, 1))) {
  1383. goto cleanup;
  1384. }
  1385. }
  1386. ds_destroy(ds_data);
  1387. /* copy the rest of tablespaces */
  1388. ds_data = ds_create(mysql_data_home, DS_TYPE_LOCAL);
  1389. it = datadir_iter_new(".", false);
  1390. datadir_node_init(&node);
  1391. while (datadir_iter_next(it, &node)) {
  1392. const char *ext_list[] = {"backup-my.cnf",
  1393. "xtrabackup_binary", "xtrabackup_binlog_info",
  1394. "xtrabackup_checkpoints", ".qp", ".pmap", ".tmp",
  1395. NULL};
  1396. const char *filename;
  1397. char c_tmp;
  1398. int i_tmp;
  1399. bool is_ibdata_file;
  1400. /* create empty directories */
  1401. if (node.is_empty_dir) {
  1402. char path[FN_REFLEN];
  1403. snprintf(path, sizeof(path), "%s/%s",
  1404. mysql_data_home, node.filepath_rel);
  1405. msg_ts("[%02u] Creating directory %s\n", 1, path);
  1406. if (mkdirp(path, 0777, MYF(0)) < 0) {
  1407. char errbuf[MYSYS_STRERROR_SIZE];
  1408. my_strerror(errbuf, sizeof(errbuf), my_errno);
  1409. msg("Can not create directory %s: %s\n",
  1410. path, errbuf);
  1411. ret = false;
  1412. goto cleanup;
  1413. }
  1414. msg_ts("[%02u] ...done.", 1);
  1415. continue;
  1416. }
  1417. filename = base_name(node.filepath);
  1418. /* skip .qp files */
  1419. if (filename_matches(filename, ext_list)) {
  1420. continue;
  1421. }
  1422. /* skip undo tablespaces */
  1423. if (sscanf(filename, "undo%d%c", &i_tmp, &c_tmp) == 1) {
  1424. continue;
  1425. }
  1426. /* skip the redo log (it was already copied) */
  1427. if (!strcmp(filename, "ib_logfile0")) {
  1428. continue;
  1429. }
  1430. /* skip innodb data files */
  1431. is_ibdata_file = false;
  1432. for (Tablespace::const_iterator iter(srv_sys_space.begin()),
  1433. end(srv_sys_space.end()); iter != end; ++iter) {
  1434. const char *ibfile = base_name(iter->name());
  1435. if (strcmp(ibfile, filename) == 0) {
  1436. is_ibdata_file = true;
  1437. break;
  1438. }
  1439. }
  1440. if (is_ibdata_file) {
  1441. continue;
  1442. }
  1443. if (!(ret = copy_or_move_file(node.filepath, node.filepath_rel,
  1444. mysql_data_home, 1))) {
  1445. goto cleanup;
  1446. }
  1447. }
  1448. /* copy buffer pool dump */
  1449. if (innobase_buffer_pool_filename) {
  1450. const char *src_name;
  1451. char path[FN_REFLEN];
  1452. src_name = trim_dotslash(innobase_buffer_pool_filename);
  1453. snprintf(path, sizeof(path), "%s/%s",
  1454. mysql_data_home,
  1455. src_name);
  1456. /* could be already copied with other files
  1457. from data directory */
  1458. if (file_exists(src_name) &&
  1459. !file_exists(innobase_buffer_pool_filename)) {
  1460. copy_or_move_file(src_name,
  1461. innobase_buffer_pool_filename,
  1462. mysql_data_home, 0);
  1463. }
  1464. }
  1465. cleanup:
  1466. if (it != NULL) {
  1467. datadir_iter_free(it);
  1468. }
  1469. datadir_node_free(&node);
  1470. if (ds_data != NULL) {
  1471. ds_destroy(ds_data);
  1472. }
  1473. ds_data = NULL;
  1474. sync_check_close();
  1475. return(ret);
  1476. }
  1477. bool
  1478. decrypt_decompress_file(const char *filepath, uint thread_n)
  1479. {
  1480. std::stringstream cmd, message;
  1481. char *dest_filepath = strdup(filepath);
  1482. bool needs_action = false;
  1483. cmd << IF_WIN("type ","cat ") << filepath;
  1484. if (opt_decompress
  1485. && ends_with(filepath, ".qp")) {
  1486. cmd << " | qpress -dio ";
  1487. dest_filepath[strlen(dest_filepath) - 3] = 0;
  1488. if (needs_action) {
  1489. message << " and ";
  1490. }
  1491. message << "decompressing";
  1492. needs_action = true;
  1493. }
  1494. cmd << " > " << dest_filepath;
  1495. message << " " << filepath;
  1496. free(dest_filepath);
  1497. if (needs_action) {
  1498. msg_ts("[%02u] %s\n", thread_n, message.str().c_str());
  1499. if (system(cmd.str().c_str()) != 0) {
  1500. return(false);
  1501. }
  1502. if (opt_remove_original) {
  1503. msg_ts("[%02u] removing %s\n", thread_n, filepath);
  1504. if (my_delete(filepath, MYF(MY_WME)) != 0) {
  1505. return(false);
  1506. }
  1507. }
  1508. }
  1509. return(true);
  1510. }
  1511. static
  1512. os_thread_ret_t STDCALL
  1513. decrypt_decompress_thread_func(void *arg)
  1514. {
  1515. bool ret = true;
  1516. datadir_node_t node;
  1517. datadir_thread_ctxt_t *ctxt = (datadir_thread_ctxt_t *)(arg);
  1518. datadir_node_init(&node);
  1519. while (datadir_iter_next(ctxt->it, &node)) {
  1520. /* skip empty directories in backup */
  1521. if (node.is_empty_dir) {
  1522. continue;
  1523. }
  1524. if (!ends_with(node.filepath, ".qp")) {
  1525. continue;
  1526. }
  1527. if (!(ret = decrypt_decompress_file(node.filepath,
  1528. ctxt->n_thread))) {
  1529. goto cleanup;
  1530. }
  1531. }
  1532. cleanup:
  1533. datadir_node_free(&node);
  1534. pthread_mutex_lock(&ctxt->count_mutex);
  1535. --(*ctxt->count);
  1536. pthread_mutex_unlock(&ctxt->count_mutex);
  1537. ctxt->ret = ret;
  1538. os_thread_exit();
  1539. OS_THREAD_DUMMY_RETURN;
  1540. }
  1541. bool
  1542. decrypt_decompress()
  1543. {
  1544. bool ret;
  1545. datadir_iter_t *it = NULL;
  1546. srv_max_n_threads = 1000;
  1547. sync_check_init();
  1548. /* cd to backup directory */
  1549. if (my_setwd(xtrabackup_target_dir, MYF(MY_WME)))
  1550. {
  1551. msg("cannot my_setwd %s\n", xtrabackup_target_dir);
  1552. return(false);
  1553. }
  1554. /* copy the rest of tablespaces */
  1555. ds_data = ds_create(".", DS_TYPE_LOCAL);
  1556. it = datadir_iter_new(".", false);
  1557. ut_a(xtrabackup_parallel >= 0);
  1558. ret = run_data_threads(it, decrypt_decompress_thread_func,
  1559. xtrabackup_parallel ? xtrabackup_parallel : 1);
  1560. if (it != NULL) {
  1561. datadir_iter_free(it);
  1562. }
  1563. if (ds_data != NULL) {
  1564. ds_destroy(ds_data);
  1565. }
  1566. ds_data = NULL;
  1567. sync_check_close();
  1568. return(ret);
  1569. }
  1570. /*
  1571. Copy some files from top level datadir.
  1572. Do not copy the Innodb files (ibdata1, redo log files),
  1573. as this is done in a separate step.
  1574. */
  1575. static bool backup_files_from_datadir(const char *dir_path)
  1576. {
  1577. os_file_dir_t dir = os_file_opendir(dir_path, TRUE);
  1578. os_file_stat_t info;
  1579. bool ret = true;
  1580. while (os_file_readdir_next_file(dir_path, dir, &info) == 0) {
  1581. if (info.type != OS_FILE_TYPE_FILE)
  1582. continue;
  1583. const char *pname = strrchr(info.name, IF_WIN('\\', '/'));
  1584. if (!pname)
  1585. pname = info.name;
  1586. /* Copy aria log files, and aws keys for encryption plugins.*/
  1587. const char *prefixes[] = { "aria_log", "aws-kms-key" };
  1588. for (size_t i = 0; i < array_elements(prefixes); i++) {
  1589. if (starts_with(pname, prefixes[i])) {
  1590. ret = copy_file(ds_data, info.name, info.name, 1);
  1591. if (!ret) {
  1592. break;
  1593. }
  1594. }
  1595. }
  1596. }
  1597. os_file_closedir(dir);
  1598. return ret;
  1599. }