Big xtrabackup_log file cause long GLOBAL-READ-LOCK time on streaming backup.
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 ?
Matt,
This has also been reported as bug #1055989 and will be fixed in XB 2.0.5 (to be released this week).