xtrabackup xtrabackup: error: last checkpoint LSN (XXX) is larger than last copied LSN (XXX).

[shengery]

I use xtrabackup my percona server, it's a rather heavy server with over thounds of qps, the backup complete successfully, however the recovery failed. Or the backup process does not complete at all
here is the backup command and recovery command, ( both of them are on the same machine) Version:2.3.3 Linux-Generic
OS: Amazon Linux 4.1.13-19.30.amzn1.x86_64 #1 SMP Fri Dec 11 03:42:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Hareware: AWS EC2 r3.2xlarge
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 62
Model name: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
Stepping: 4
CPU MHz: 2494.084
BogoMIPS: 4988.16
Hypervisor vendor: Xen
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 25600K
NUMA node0 CPU(s): 0-7
Total memory: 61GB
Storage : 160GB SSD of Instance Storage

BACKUP:
innobackupex --user=root --host=127.0.0.1 --password=PASSWD --port=3308 --defaults-file=/data/mysql/3308/data/my.cnf --no-lock --prepare /data/dbbackup
innobackupex --user=root --host=127.0.0.1 --password=PASSWD --port=3308 --defaults-file=/data/mysql/3308/data/my.cnf --no-lock /data/dbbackup

here is the backup command failure output :

151231 13:46:27 Finished backing up non-InnoDB tables and files
151231 13:46:27 [00] Writing xtrabackup_binlog_info
151231 13:46:27 [00] ...done
151231 13:46:27 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '256243027607'
xtrabackup: Stopping log copying thread.
.151231 13:46:27 >> log scanned up to (256228180480)

151231 13:46:27 Backup created in directory '/data/dbbackup/2015-12-31_13-45-10'
MySQL binlog position: filename 'mysql-bin.000166', position '497999141'
151231 13:46:27 [00] Writing backup-my.cnf
151231 13:46:27 [00] ...done
151231 13:46:27 [00] Writing xtrabackup_info
151231 13:46:27 [00] ...done
xtrabackup: Transaction log of lsn (256228180557) to (256228180480) was copied.
xtrabackup: error: last checkpoint LSN (256243027607) is larger than last copied LSN (256228180480).

when the backup completed successfully, I tried to run recovery command :

innobackupex --apply-log /data/dbbackup/2015-12-31_13-45-10

151231 13:55:14 innobackupex: Starting the apply-log operation

IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".

innobackupex version 2.3.3 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 525ca7d)
xtrabackup: cd to /data/dbbackup/2015-12-31_13-45-10
xtrabackup: This target seems to be not prepared yet.
2015-12-31 13:55:14 7f49b5fbd740 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
xtrabackup: Warning: cannot open ./xtrabackup_logfile. will try to find.
  xtrabackup: 'ib_logfile0' seems to be 'xtrabackup_logfile'. will retry.
xtrabackup: xtrabackup_logfile detected: size=235814912, start_lsn=(255720678541)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 235814912
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 235814912
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 255720678541
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 255725921280 (2%)
InnoDB: Doing recovery: scanned up to log sequence number 255731164160 (5%)
InnoDB: Doing recovery: scanned up to log sequence number 255736407040 (7%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 255741649920 (10%)
InnoDB: Doing recovery: scanned up to log sequence number 255746892800 (12%)
InnoDB: Doing recovery: scanned up to log sequence number 255752135680 (15%)
InnoDB: Doing recovery: scanned up to log sequence number 255757378560 (17%)
.
.
.
.

.2 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 255799321600 (37%)
InnoDB: Doing recovery: scanned up to log sequence number 255804564480 (40%)
InnoDB: Doing recovery: scanned up to log sequence number 255809807360 (42%)
InnoDB: Doing recovery: scanned up to log sequence number 255815050240 (45%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 255820293120 (47%)
InnoDB: Doing recovery: scanned up to log sequence number 255825536000 (50%)
InnoDB: Doing recovery: scanned up to log sequence number 255830778880 (52%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 255836021760 (55%)
InnoDB: Doing recovery: scanned up to log sequence number 255841264640 (57%)
InnoDB: Doing recovery: scanned up to log sequence number 255846507520 (60%)
InnoDB: Doing recovery: scanned up to log sequence number 255851553280 (62%)
InnoDB: We scanned the log up to 255851553280. A checkpoint was at 255720678541 and the maximum LSN on a database page was 256051447089. It is possible that the database is now corrupt!
2015-12-31 13:55:21 7f49b5fbd740 InnoDB: Error: page 4 log sequence number 255865085692
InnoDB: is in the future! Current system log sequence number 255851553183.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2015-12-31 13:55:21 7f49b5fbd740 InnoDB: Error: page 5 log sequence number 255922379541
InnoDB: is in the future! Current system log sequence number 255851553183.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2015-12-31 13:55:21 7f49b5fbd740 InnoDB: Error: page 6 log sequence number 255922311331
.
.
.
.
.
.
...skipping...
InnoDB: for more information.
2015-12-31 13:55:22 7f49ac4da700 InnoDB: Error: page 780 log sequence number 255907590246
InnoDB: is in the future! Current system log sequence number 255851553183.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2015-12-31 13:55:22 7f49ac4da700 InnoDB: Error: page 790 log sequence number 255937400281
InnoDB: is in the future! Current system log sequence number 255851553183.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.

InnoDB: Apply batch completed
2015-12-31 13:55:22 7f49b5fbd740 InnoDB: Error: page 5 log sequence number 255922379541
InnoDB: is in the future! Current system log sequence number 255851553183.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
InnoDB: Cleaning up trx with id 1870338525
2015-12-31 13:55:22 7f49b5fbd740 InnoDB: Assertion failure in thread 139954562520896 in file trx0trx.cc line 292
InnoDB: Failing assertion: trx->update_undo == NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:55:22 UTC - xtrabackup got signal 6 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x10000
innobackupex(my_print_stacktrace+0x2e) [0x986b0e]
innobackupex(handle_fatal_signal+0x235) [0x8f0125]
/lib64/libpthread.so.0(+0xf100) [0x7f49b5b9f100]
/lib64/libc.so.6(gsignal+0x37) [0x7f49b41095f7]
/lib64/libc.so.6(abort+0x148) [0x7f49b410ace8]
innobackupex(trx_free_for_background(trx_t*)+0x175) [0x66d5f5]
innobackupex(trx_rollback_or_clean_recovered(unsigned long)+0x2b0) [0xa0d1d0]
innobackupex(innobase_start_or_create_for_mysql()+0xeca) [0x698cba]
innobackupex() [0x5798ae]
innobackupex(main+0xa48) [0x57bec8]
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f49b40f5b15]
innobackupex(__gxx_personality_v0+0x349) [0x56f989]

Please report a bug at https://bugs.launchpad.net/percona-xtrabackup

[Muhammad Irfan (muhammad-irfan)]

Is your backup fails always or it's failed first time with error ? Did you re-tried to backup ? Please, provide server my.cnf file and output of backup directory.
$ ls -lah /data/dbbackup/2015-12-31_13-45-10/

[shengery (shengery)]

Hi Muhammad irfan,

Thank you and sorry for my late reply .

I tried tens of times,most of the time, I got the failed result almost every time.
My database is rather big with almost 50GB of innodb data, there are about 1K tables in the tablespace. and they are queried very frequently.
The backup command I use is :
innobackupex --user=root --host=127.0.0.1 --password=xxxxxxx --port=3308 --defaults-file=/data/mysql/3308/data/my.cnf /data/dbbackup/

and the backup fail information is :
160116 19:01:16 [01] ...done
160116 19:01:16 [01] Copying ./db_user_tj/t_user_tj98.frm to /data/dbbackup//2016-01-16_18-58-40/db_user_tj/t_user_tj98.frm
160116 19:01:16 [01] ...done
160116 19:01:16 [01] Copying ./db_user_tj/t_user_tj99.frm to /data/dbbackup//2016-01-16_18-58-40/db_user_tj/t_user_tj99.frm
160116 19:01:16 [01] ...done
160116 19:01:16 Finished backing up non-InnoDB tables and files
160116 19:01:16 Executing LOCK BINLOG FOR BACKUP...
160116 19:01:16 [00] Writing xtrabackup_binlog_info
160116 19:01:16 [00] ...done
160116 19:01:16 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '446279907114'
xtrabackup: Stopping log copying thread.
.160116 19:01:16 >> log scanned up to (446272306688)

160116 19:01:16 Executing UNLOCK BINLOG
160116 19:01:16 Executing UNLOCK TABLES
160116 19:01:16 All tables unlocked
160116 19:01:16 Backup created in directory '/data/dbbackup//2016-01-16_18-58-40'
MySQL binlog position: filename 'mysql-bin.000292', position '827827898'
160116 19:01:16 [00] Writing backup-my.cnf
160116 19:01:16 [00] ...done
160116 19:01:16 [00] Writing xtrabackup_info
160116 19:01:16 [00] ...done
xtrabackup: Transaction log of lsn (446272307022) to (446272306688) was copied.
xtrabackup: error: last checkpoint LSN (446279907114) is larger than last copied LSN (446272306688).160116 19:01:16 [01] ...done
160116 19:01:16 [01] Copying ./db_user_tj/t_user_tj98.frm to /data/dbbackup//2016-01-16_18-58-40/db_user_tj/t_user_tj98.frm
160116 19:01:16 [01] ...done
160116 19:01:16 [01] Copying ./db_user_tj/t_user_tj99.frm to /data/dbbackup//2016-01-16_18-58-40/db_user_tj/t_user_tj99.frm
160116 19:01:16 [01] ...done
160116 19:01:16 Finished backing up non-InnoDB tables and files
160116 19:01:16 Executing LOCK BINLOG FOR BACKUP...
160116 19:01:16 [00] Writing xtrabackup_binlog_info
160116 19:01:16 [00] ...done
160116 19:01:16 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '446279907114'
xtrabackup: Stopping log copying thread.
.160116 19:01:16 >> log scanned up to (446272306688)

160116 19:01:16 Executing UNLOCK BINLOG
160116 19:01:16 Executing UNLOCK TABLES
160116 19:01:16 All tables unlocked
160116 19:01:16 Backup created in directory '/data/dbbackup//2016-01-16_18-58-40'
MySQL binlog position: filename 'mysql-bin.000292', position '827827898'
160116 19:01:16 [00] Writing backup-my.cnf
160116 19:01:16 [00] ...done
160116 19:01:16 [00] Writing xtrabackup_info
160116 19:01:16 [00] ...done
xtrabackup: Transaction log of lsn (446272307022) to (446272306688) was copied.
xtraba...

[Eugene Klimov (bloodjazman)]

i have same error
with my 430 Gb InnoDB database

i increase innodb_log_file_size

mysql -e "SHOW VARIABLES LIKE '%innodb_log_file%';"
+---------------------------+------------+
| Variable_name | Value |
+---------------------------+------------+
| innodb_log_file_size | 2147483648 |
| innodb_log_files_in_group | 4 |
+---------------------------+------------+

RUN
 innobackupex --defaults-file=/etc/mysql/debian.cnf --compress --slave-info --throttle=100 --no-timestamp /var/backups/mysql

but see something strang in log file
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ why ?
xtrabackup: innodb_log_file_size = 2147483648

160119 14:03:44 Executing UNLOCK BINLOG
160119 14:03:44 Executing UNLOCK TABLES
160119 14:03:44 All tables unlocked
160119 14:03:44 Backup created in directory '/var/backups/oa'
MySQL binlog position: filename 'mysql-bin.000009', position '1062'
MySQL slave binlog position: master host 'db103', filename 'mysql-bin.112033', position '56130523
160119 14:03:44 [00] Compressing backup-my.cnf
160119 14:03:44 [00] ...done
160119 14:03:44 [00] Compressing xtrabackup_info
160119 14:03:44 [00] ...done
xtrabackup: Transaction log of lsn (16716117490664) to (16717598021120) was copied.
xtrabackup: error: last checkpoint LSN (16717966287892) is larger than last copied LSN (16717598021120).

[shengery (shengery)]

Well, It's really an important issue, which may cause the innobackup tool disfunction.
Please try to fix it.

[Sveta Smirnova (svetasmirnova)]

Please try to increase innodb_log_file_size. Looks like hey are rewritten faster than backup competes.

[Sergei Glushchenko (sergei.glushchenko)]

I am looking to "Transaction log of lsn (256228180557) to (256228180480) was copied." and by doing simple math I conclude that xtrabackup_logfile very small, nearly zero.

Then on prepare I see that it is actually 235814912 ~ 224M, which is not that big, but is definitely not zero. And --prepare does actually some work replay the log.

It looks confusing to me.

What is your server version and what is your redo log file size and count? Also what is the value of innodb_flush_log_at_trx_commit setting? Would be great if you could paste the whole my.cnf.

[Sergei Glushchenko (sergei.glushchenko)]

To Eugene Klimov, please check that /etc/mysql/debian.cnf contains correct redo log settings. Since xtrabackup was able to find only two of four log files, it is not able to copy redo log properly.

[shengery (shengery)]

The server version is Percona server 5.6.25-73.1 . and the whole my.cnf is below:
[client]
port = 3308
socket = /tmp/mysql.sock

[mysqld]
port = 3308
server-id = 2
socket = /tmp/mysql.sock
tmpdir = /tmp/
sql_mode=TRADITIONAL
skip-name-resolve
skip-symbolic-links
skip-external-locking
back_log = 500
max_connections = 3000
max_connect_errors = 10000
open_files_limit = 10240

max_allowed_packet = 64M
thread_stack = 256K
thread_cache_size = 20
thread_concurrency = 8
query_cache_size = 256M
query_cache_limit = 2M
query_cache_min_res_unit = 2K

character-set-server = utf8
tmp_table_size = 512M
max_heap_table_size = 512M
log-bin = mysql-bin
log-warnings = 1
log_output = FILE
slow_query_log = 1
long-query-time = 2

binlog_format=mixed
max_binlog_size = 1G
expire_logs_days = 2
binlog_cache_size = 2M
replicate-wild-ignore-table = mysql.%
replicate-wild-ignore-table = test.%
key_buffer_size = 256M
sort_buffer_size = 2M
read_buffer_size = 2M
join_buffer_size = 8M
read_rnd_buffer_size = 8M
bulk_insert_buffer_size = 64M

transaction_isolation = READ-COMMIT
innodb_file_per_table
innodb_buffer_pool_size = 30G
innodb_data_file_path = ibdata1:512M:autoextend
innodb_file_io_threads = 4
innodb_thread_concurrency = 8
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 8M
innodb_log_file_size = 500M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 50
innodb_flush_method = O_DSYNC
[mysqldump]
quick
max_allowed_packet = 64M
[mysql]
disable-auto-rehash
default-character-set = utf8
connect-timeout = 3

The error information I gave was from different time, however , both they were failed

[Sergei Glushchenko (sergei.glushchenko)]

Hi shengery,

This command doesn't look good:

innobackupex --user=root --host=127.0.0.1 --password=PASSWD --port=3308 --defaults-file=/data/mysql/3308/data/my.cnf --no-lock /data/dbbackup

Please try to move "--defaults-file=/data/mysql/3308/data/my.cnf" to be first argument. xtrabackup should refuse to start if --defaults-file is not the first argument. If innobackupex doesn't exit with error, please file bug report about it.

Please also paste the beginning of the backup log, we will see which settings were picked up by xtrabackup. Have they changed moving --dfeaults-file to the beginning?

[Sergei Glushchenko (sergei.glushchenko)]

err, I mean, have the xtrabackup output changed after changing the options order?

I am looking for lines like:

xtrabackup: innodb_log_files_in_group = N
xtrabackup: innodb_log_file_size = NNNNNNNN

[shengery (shengery)]

Hi Sergei ,

I tried the command you gave above, which told me to move the "--defaults-file=/data/mysql/3308/data/my.cnf" to the first argument, it did succeed this time, however the database load is not so heavy this time, I will try it later when server load is more heavier.
thank you

[Sergei Glushchenko (sergei.glushchenko)]

Lets mark it as "Incomplete" since changing cmd args order seems to resolve the issue. I filed bug 1543029 for innobackupex didn't failed with error with the wrong --defaults-file position.

[snowave (shawn001)]

hi ，all

we have this problem also， but we start innobackup with defaults-file in the first postion：

160216 01:18:13 innobackupex: Starting ibbackup with command: xtrabackup --defaults-file="/data1/mysql3301/my3301.cnf.bakuse" --defaults-group="mysqld" --backup --su
spend-at-end --target-dir=/nfsbackup/day/mysql3301/20160216/mysql3301 --datadir="/data3/mysql3301/" --innodb_log_file_size="1363148800" --innodb_data_file_path="ib
data1:10M:autoextend" --tmpdir=/dev/shm --throttle=800 --extra-lsndir='/dev/shm' --parallel=1

prints：

xtrabackup: error: last checkpoint LSN (846389848171) is larger than last copied LSN (846334725632).
160216 03:50:17 innobackupex: All tables unlocked
.....
.....
160216 03:50:17 innobackupex: xtrabackup failed! (exit code 1) The backup may not be complete.

[Sergei Glushchenko (sergei.glushchenko)]

Please compare the output of xtrabackup:

xtrabackup: innodb_log_files_in_group = N
xtrabackup: innodb_log_file_size = NNNNNNNN

when you taking a backup with your actual settings. Do they match?

[Sergei Glushchenko (sergei.glushchenko)]

I also see that you are providing innodb_log_file_size and innodb_data_file_path directly via command line. Is it because something wrong with the cnf file "/data1/mysql3301/my3301.cnf.bakuse" ?

[snowave (shawn001)]

yes, it works ,thanks

[Launchpad Janitor (janitor)]

[Expired for Percona XtraBackup because there has been no activity for 60 days.]

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-1358