Big xtrabackup_log file cause long GLOBAL-READ-LOCK time on streaming backup.

Bug #1099730 reported by Matt
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
New
Undecided
Unassigned

Bug Description

I saw the Xtrabackup pdf manual edited by Vadim Tkachenko and Alexey Kypytov.
PDF manual say innobackupex copy xtrabackup_log to remote host (with xbstream) after UNLOCK TABLES in backup procedure.
But, on my server Xtrabackup 2.0.1's behavior is a little bit different.

innobackupex procedure.
  -> 1. start xtrabackup_log
  -> 2. copy .ibd, ibdata1
  -> 3. FLUSH TABLES WITH READ LOCK
  -> 4. copy .FRM .MYD .MYI misc files
  -> 5. Get binary log position
  -> 6. UNLOCK TABLES
  -> 7. stop and copy xtrabackup_log

Also in innobackupex perl code, Xtrabackup send xtrabackup_log file first and after that run UNLOCK TABLES on xtreaming mode.
But RemoteHost mode, xtrabackup act like pdf manual.

I'm wondering why xtrabakcup do not run UNLOCK TABLES before copy xtrabackup_log file.
500GB database backup will take about 5 hours, and this will generate huge xtrabackup_log file.
So, Replication delay time is getting high during Xtrabackup copy big xtrabackup_log file.
And at that time, mysql server think there's no user query and mysql server flush dirty page aggresively (of couse server's load is getting high).
(Unfortunately, we can not use RemoteHost backup mode instead of streaming mode, scp or ssh use file contents encryption. and it's really slow.)

What do you think about this ?

Revision history for this message
Alexey Kopytov (akopytov) wrote :

Matt,

This has also been reported as bug #1055989 and will be fixed in XB 2.0.5 (to be released this week).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.