summaryrefslogtreecommitdiff
path: root/extra/mariabackup/innobackupex.cc
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.2 into 10.3Marko Mäkelä2021-04-131-7/+0
|\
| * MDEV-25356: SST scripts should use the new mariabackup interfacebb-10.2-MDEV-25356Julius Goryavsky2021-04-111-7/+0
| | | | | | | | | | | | | | | | | | | | | | SST scripts for Galera should use the new mariabackup interface instead of the innobackupex interface, which is currently only supported for compatibility reasons. This commit converts the SST script for mariabackup to use the new interface. It does not need separate tests, as any problems will be seen as failures when running multiple tests for the mariabackup-based SST.
* | Merge 10.2 into 10.3Marko Mäkelä2021-04-091-1/+20
|\ \ | |/
| * MDEV-25321: mariabackup failed if password is passed via environment variablebb-10.2-MDEV-25321Julius Goryavsky2021-04-011-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | The mariabackup interface currently supports passing a password through an explicit command line variable, but does not support passing a password through the MYSQL_PWD environment variable. At the same time, the Galera SST script for mariabackup uses the environment variable to pass the password, which leads (in some cases) to an unsuccessful launch of mariabackup and to the inability to start the cluster. This patch fixes this issue. It does not need a separate test, as the problem is visible in general testing on buildbot.
| * MDEV-24197: Add "innodb_force_recovery" for "mariabackup --prepare"Srinidhi Kaushik2021-04-011-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the prepare phase of restoring backups, "mariabackup" does not seem to allow (or recognize) the option "innodb_force_recovery" for the embedded InnoDB server instance that it starts. If page corruption observed during page recovery, the prepare step fails. While this is indeed the correct behavior ideally, allowing this option to be set in case of emergencies might be useful when the current backup is the only copy available. Some error messages during "--prepare" suggest to set "innodb_force_recovery" to 1: [ERROR] InnoDB: Set innodb_force_recovery=1 to ignore corruption. For backwards compatibility, "mariabackup --innobackupex --apply-log" should also have this option. Signed-off-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com>
* | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-01-241-4/+5
|\ \ | |/
| * Merge branch '10.1' into 10.2Oleksandr Byelkin2020-01-241-4/+5
| |\
| | * MDEV-17601: MariaDB Galera does not expect 'mbstream' as streamfmtJulius Goryavsky2020-01-211-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting "streamfmt=mbstream" in the "[sst]" section causes SST to fail because the format automatically switches to 'tar' by default (insead of mbstream). To fix this, we need to add mbstream to the list of valid values for the format, making it synonymous with xbstream. This must be done both in the SST script and when parsing the options of the corresponding utilities.
* | | Lintian complains on spelling errorFaustin Lammler2019-12-021-1/+1
|/ / | | | | | | | | The lintian check complains on spelling error: https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/95739
* | Merge 10.1 into 10.2Marko Mäkelä2019-05-131-3/+3
|\ \ | |/
| * Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-111-1/+1
| |
| * Update FSF addressVicențiu Ciorbaru2019-05-111-2/+2
| |
* | MDEV-18212 mariabackup: Make output format uniform whenever possibleVladislav Vaintroub2019-01-151-1/+1
| |
* | MDEV-14267: correct FSF addressDaniel Black2018-10-301-2/+2
| |
* | Merge branch '10.1' into 10.2Vicențiu Ciorbaru2018-04-101-1/+1
|\ \ | |/
| * MDEV-15825 Mariabackup help mentions Percona and PXC but not MariaDBVladislav Vaintroub2018-04-091-1/+1
| |
* | Mariabackup: Remove unused parameters and fix some memory leaksMarko Mäkelä2017-07-061-3/+0
| | | | | | | | | | | | Use GET_STR instead of GET_STR_ALLOC, so that the memory will cannot be leaked. For some reason, calling my_cleanup_options() on xb_server_options or xb_client_options would not work.
* | MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2Marko Mäkelä2017-07-051-18/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Mariabackup: Remove support for .xbcrypt filesMarko Mäkelä2017-06-191-98/+7
|
* Mariabackup: Remove the options --compact --rebuild-indexes --rebuild-threadsMarko Mäkelä2017-06-191-10/+1
|
* MDEV-12832 : remove libarchive support from mariabackup,Vladislav Vaintroub2017-05-211-3/+1
| | | | | | | | | | | due to different packaging issues. Also, Percona thinks that tar support has many limitations and should be removed as well( see discussion in https://bugs.launchpad.net/percona-xtrabackup/+bug/1681721) there is an alternative streaming format xbstream that is supported and does not have these limitations.
* MDEV-9566 Port Percona Xtrabackup to MariaDB as mariabackupVladislav Vaintroub2017-04-271-24/+3
| | | | | | - Modify backup code to work with MariaDB's 10.1 xtradb - Remove crypt encryption, version_check.pl, "compact backup" - Add encryption plugin
* MDEV-9566 Add Percona Xtrabackup 2.3.7Vladislav Vaintroub2017-04-271-0/+1153