Closed tilt86 closed 8 years ago
Hi @tilt86,
First, sorry for the late answer. If you look at the --out-file (default: /var/log/mysql/xtrabackup.out), you should see a more precise error. Can you have a look?
What does your mysql log say? For me, browsing that log, basically solved my issue.
Hi,
I don't have anymore the server where I used t, but if I reuse it again, I will check another time.
2015-11-23 18:06 GMT+01:00 bertalanimre notifications@github.com:
What does your mysql log say? For me, browsing that log, basically solved my issue.
— Reply to this email directly or view it on GitHub https://github.com/deviantony/xtrabackup-scripts/issues/29#issuecomment-158997592 .
--
LP
I may have a clue why incremental restoraion failes, cause i got a problem with it as well.
There is this function
def restore_incremental_backups(self, incremental_archive):
try:
repository, archive_name = filesystem_utils.split_path(
incremental_archive)
incremental_target = int(archive_name.split('_')[1])
for step in range(1, incremental_target + 1):
in restoration_tools.py
And i believe there is bug here.
Incremental backups are indexed from 0 so i do not know why you create a range from 1.
When i changed it to for step in range(0, incremental_target + 1):
it started working correctly.
I actually just tested an incremental backup it using the pyxtrabackup-inc
binary and it creates the following file structure (tested in a Docker container):
> docker run --rm -it -v "${PWD}:/src" pyxtrabackup zsh
root on 7bee038cf695 in /
$ workon python3
(python3) root on 7bee038cf695 in /
$ pip install --editable /src/
Obtaining file:///src
Requirement already satisfied (use --upgrade to upgrade): docopt in /root/.python_envs/python3/lib/python3.4/site-packages (from pyxtrabackup==3.1.4)
Requirement already satisfied (use --upgrade to upgrade): requests in /root/.python_envs/python3/lib/python3.4/site-packages (from pyxtrabackup==3.1.4)
Installing collected packages: pyxtrabackup
Running setup.py develop for pyxtrabackup
Successfully installed pyxtrabackup
(python3) root on 7bee038cf695 in /
$ service mysql start
* Starting MySQL database server mysqld [ OK ]
* Checking for tables which need an upgrade, are corrupt or were
not closed cleanly.
(python3) root on 7bee038cf695 in /
$ mkdir /tmp/backup_repository
(python3) root on 7bee038cf695 in /
$ pyxtrabackup-inc /tmp/backup_repository --user=root
INFO:xtrabackup.backup_tools:Backup time: 0:00:02.037952 - Duration: 2
INFO:xtrabackup.backup_tools:Backup archiving time: 0:00:00.180842 - Duration: 0
INFO:xtrabackup.backup_tools:Archive copy time: 0:00:00.000215 - Duration: 0
(python3) root on 7bee038cf695 in /
$ pyxtrabackup-inc --incremental /tmp/backup_repository --user=root
INFO:xtrabackup.backup_tools:Incremental backup time: 0:00:02.078538 - Duration: 2
INFO:xtrabackup.backup_tools:Backup archiving time: 0:00:00.039583 - Duration: 0
INFO:xtrabackup.backup_tools:Archive copy time: 0:00:00.000242 - Duration: 0
(python3) root on 7bee038cf695 in /
$ pyxtrabackup-inc --incremental /tmp/backup_repository --user=root
INFO:xtrabackup.backup_tools:Incremental backup time: 0:00:02.103087 - Duration: 2
INFO:xtrabackup.backup_tools:Backup archiving time: 0:00:00.040284 - Duration: 0
INFO:xtrabackup.backup_tools:Archive copy time: 0:00:00.000223 - Duration: 0
(python3) root on 7bee038cf695 in /
$ ll /tmp/backup_repository
total 4.0K
drwxr-xr-x 3 root root 4.0K Mar 23 06:23 20160323
(python3) root on 7bee038cf695 in /
$ ll /tmp/backup_repository/20160323
total 4.0K
drwxr-xr-x 2 root root 4.0K Mar 23 06:24 INC
(python3) root on 7bee038cf695 in /
$ ll /tmp/backup_repository/20160323/INC
total 612K
-rw-r--r-- 1 root root 226K Mar 23 06:23 base_backup_20160323_0623.tar.gz
-rw-r--r-- 1 root root 189K Mar 23 06:24 inc_0_backup_20160323_0624.tar.gz
-rw-r--r-- 1 root root 189K Mar 23 06:24 inc_1_backup_20160323_0624.tar.gz
A restoration test shows that an incremental backup restoration step is missing indeed:
(python3) root on 7bee038cf695 in /
$ pyxtrabackup-restore --base-archive /tmp/backup_repository/20160323/INC/base_backup_20160323_0623.tar.gz --incremental-archive /tmp/backup_repository/20160323/INC/inc_1_backup_20160323_0624.tar.gz --user root
INFO:xtrabackup.restoration_tools:Base backup restoration time: 0:00:00.654160 - Duration: 0
INFO:xtrabackup.restoration_tools:Incremental step #1 restoration time: 0:00:01.115791 - Duration: 1
INFO:xtrabackup.restoration_tools:Backup final preparation time: 0:00:04.189706 - Duration: 4
I'm investigating on this.
Hello,
I'm trying this nice wrapper, but I'm facing an issue when I want to restore an incremental backup, if the number of the incremental backup is > 0.
Here is the folder containing backups: (I've put inside binlog because it's where I have more space on this server)
root@server:/var/lib/mysql/binlog/backup# ls STOR/20150909/INC/ -lth
Then, if I want to restore up to inc_0, I have no error, but I'm not sure it applied inc_0 ??
root@server:/var/lib/mysql/binlog/backup# pyxtrabackup-restore --base-archive=/var/lib/mysql/binlog/backup/STOR/20150909/INC/base_backup_20150909_1527.tar.gz --incremental-archive=/var/lib/mysql/binlog/backup/STOR/20150909/INC/inc_0_backup_20150909_1547.tar.gz --user=root --password=XXXX --data-dir=/var/lib/mysql/data/db
I can test if the data are consistent however.
But If I want to restore up to inc_0, which I want to to, I got errors...
root@server:/var/lib/mysql/binlog/backup# pyxtrabackup-restore --base-archive=/var/lib/mysql/binlog/backup/STOR/20150909/INC/base_backup_20150909_1527.tar.gz --incremental-archive=/var/lib/mysql/binlog/backup/STOR/20150909/INC/inc_1_backup_20150909_1547.tar.gz --user=root --password=XXXX --data-dir=/var/lib/mysql/data/db
Did I do something wrong? I tried with both python 2.7 and 3.4.
Thanks, Luc