A couple of ideas...
If you're using InnoDB for your tables (and if you're not then consider migrating) then
you could use MySQL Enterprise Backup for non-blocking backups...
If you're able to split your data between multiple schemas/databases then see if the 5.6
Multi-Threaded Slave feature helps replication catch up faster (note that this is part of
MySQL 5.6 which is *not* GA yet)...
> -----Original Message-----
> From: Simon [mailto:greminn@stripped]
> Sent: 18 January 2012 19:02
> To: replication@stripped
> Subject: Slow Slave Replication Catchup
> We are using MySQL5.1 (5.1.49-3) on debian squeeze and have it setup in a
> Master/Slave relationship. The master is a VM on our primary XenServer and
> the slave is a VM on our secondary XenServer. The VMs are not using SWAP.
> The VMs have the following resources:
> Master: 4 x VCPUs, 10GB of Memory, 8GB System Disk, 100GB Data Disk (for
> mysql, disk on iSCSI NAS)
> Slave: 1 x VCPUs, 6GB of Memory, 8GB System Disk, 100GB Data Disk (for
> mysql, disk on local server storage)
> Each night at 12:30am we run a mysqldump backup from the slave using the
> following process. This process takes about 45 mins to complete.
> 1). Stop Slave
> 2). Mysqldump each database (/usr/bin/mysqldump -u ********* -
> p'*********' -h SLAVE_HOST --routines --databases $db | /bin/gzip -9 >
> 3). Start Slave
> The problem we have is that the slave is taking ages to catch up. Im pretty
> sure that at that time in the morning the transactions are minimal... For
> example, i had to stop last nights backup as the slave had not caught up, and
> has still not caught up nearly 24 hours later. I weird thing is it seems like it has
> been taking longer and longer to catch over the last month or so...
> Any ideas?
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe: http://lists.mysql.com/replication