xtrabackup --backup hangs on "log scanned up to"

Asked by Daniel Kaelin

I am currently testing your mysql backup solution as an alternative to mysqldumps and my initial tests are getting hung up on the "log scanned up to" portion.

I have included the command line text below. I found one other user who was experiencing the same issue but he did not get a specific answer to the problem. He was also using the utility on Windows while my installation is being ran on CentOS 6.

What would be the cause of such an issue?

Here is the link to the user that had the similar problem: https://bugs.launchpad.net/percona-xtrabackup/+bug/767757/comments/1

[root@localhost MySQLBackup]# xtrabackup --backup --datadir=/var/lib/mysql --target-dir=/Volumes/Thecus2/MySQLBackup/test3
xtrabackup version 1.6.3 for Percona Server 5.1.55 pc-linux-gnu (i686) (revision id: 292)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
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 = 2
xtrabackup: innodb_log_file_size = 5242880
>> log scanned up to (19323982766)
[01] Copying ./ibdata1
     to /Volumes/Thecus2/MySQLBackup/test3/ibdata1
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)
>> log scanned up to (19323982766)

I appreciate any feedback.

Question information

English Edit question
Percona XtraBackup moved to https://jira.percona.com/projects/PXB Edit question
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Alexey Kopytov (akopytov) said :


I think you misinterpreted the output. From the log you have provided, xtrabackup is busy copying ibdata1 (it will print "... done" when finished). It may take a while, depending on your data size, hardware and parallel activity from other applications.

Log scanning should be active during the entire backup process. The fact the LSN is not changing just means there are no writes to the database being backed up.

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) said :

Can you help with this problem?

Provide an answer of your own, or ask Daniel Kaelin for more information if necessary.

To post a message you must log in.