c2oo / xtrabackup-manager

Automatically exported from code.google.com/p/xtrabackup-manager
0 stars 0 forks source link

'--safe-slave-backup' is always present in the innobackupex command and causes the process to scan the logs indefinitely #69

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I noticed that the parameters '--safe-slave-backup' and '--slave-info' are 
hard-coded into the innobackupex command regardless of the DB server's 
replication role. Refer to genericBackupTaker.class.php lines 165, 432, and 
433. 

Unfortunately, when the DB server is not a slave (either a master or not part 
of replication), the presence of these parameters causes the backup process to 
scan the logs indefinitely. I see a continuous output of lines like this:
>> log scanned up to (4434910400347)
>> log scanned up to (4434910400347)
>> log scanned up to (4434910400347)
>> log scanned up to (4434910400347)
>> log scanned up to (4434910400347)
>> log scanned up to (4434910429344)
>> log scanned up to (4434910448052)
>> log scanned up to (4434910448052)
>> log scanned up to (4434910459829)
>> log scanned up to (4434910460409)
>> log scanned up to (4434910460409)
>> log scanned up to (4434910460409)
>> log scanned up to (4434910460409)
>> log scanned up to (4434910460409)
>> log scanned up to (4434910460409)
>> log scanned up to (4434910488715)
>> log scanned up to (4434910490949)
>> log scanned up to (4434910490949)
>> log scanned up to (4434910498963)
>> log scanned up to (4434910510374)
>> log scanned up to (4434910510374)
>> log scanned up to (4434910510374)
>> log scanned up to (4434910510374)
>> log scanned up to (4434910510374)
>> log scanned up to (4434910510374)
>> log scanned up to (4434910530027)
>> log scanned up to (4434910539853)
>> log scanned up to (4434910539853)
>> log scanned up to (4434910548097)
>> log scanned up to (4434910548685)
>> log scanned up to (4434910548685)
>> log scanned up to (4434910548685)
>> log scanned up to (4434910548685)
>> log scanned up to (4434910548685)
>> log scanned up to (4434910548685)
>> log scanned up to (4434910569351)
>> log scanned up to (4434910571711)
>> log scanned up to (4434910571711)
>> log scanned up to (4434910580018)
>> log scanned up to (4434910580598)
>> log scanned up to (4434910580598)
>> log scanned up to (4434910580598)
>> log scanned up to (4434910580598)

NOTE: I only see these lines when I copy the command being issued by XBM and 
execute it manually (but without the --stream).

Example:
innobackupex /path/to/backup/dir --user=user1 --password=password1 --slave-info 
--safe-slave-backup

When the backup execution is indirect (i.e. triggered by XBM), the "log scanned 
up to (xxxxxxxxxxxxxxx)" messages are not printed. Rather, the last line that I 
see is:

"2013-07-18 00:03:01 +0800 [INFO] : [ Running FULL xtrabackup snapshot of 
/path/to/data/dir via ssh: mysql@hostname ... ]"

In one of my tests, I waited for several hours to see if the backup process 
would finish. Eventually, I decided to just kill it. And when I repeated the 
backup without the '--safe-slave-backup' parameter, it finished within 20 
minutes.

Note that '--slave-info' doesn't do any harm on its own regardless of the 
server's replication role. But just like '--safe-slave-backup', I think it 
should not be part of the command unless the server is identified as a slave. 

You can probably consider one of these:
1. Add a parameter in "xbm host add" which would allow the user to specify 
whether the server is a slave or not (allowed values: Y,N; default: N)
2. Automatically detect the replication role by checking the output of SHOW 
SLAVE STATUS. I'm not sure if this is the best indicator of replication role 
but I would assume that there is at least a way to determine it based from one 
of the server's status information.

Original issue reported on code.google.com by p.carde...@marktheglobe.com on 19 Jul 2013 at 3:35

GoogleCodeExporter commented 8 years ago
Try upgrading xtrabackup (xtrabackup 2.1.3 had a bug causing exactly this when 
the server is not a slave; bug is fixed in xtrabackup 2.1.4).

Original comment by arnaud.lb on 31 Aug 2013 at 2:26