Comments on: Just how useful are binary logs for incremental backups? http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Robert Hodges http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/comment-page-1/#comment-614439 Robert Hodges Wed, 22 Jul 2009 21:47:03 +0000 http://www.mysqlperformanceblog.com/?p=843#comment-614439 Hi Morgan, Have you tried Tungsten Replicator? It has built-in time-delay replication. Also, it now has built-in backup/restore support (checked in; will be in an official build shortly). I'm going to look at putting in support for invoking XtraBackup as it seems pretty good, especially the incremental capacity. Finally, as Peter mentioned, running replication anywhere near full capacity is asking for trouble. One thing we are planning for later in the year in Tungsten is to split events into different "channels" for replication in parallel. Parallel replication seems to be particularly helpful when you have events that are truly slow, such as DDL, or for replication of data that are already sharded. Hi Morgan,

Have you tried Tungsten Replicator? It has built-in time-delay replication. Also, it now has built-in backup/restore support (checked in; will be in an official build shortly). I’m going to look at putting in support for invoking XtraBackup as it seems pretty good, especially the incremental capacity.

Finally, as Peter mentioned, running replication anywhere near full capacity is asking for trouble. One thing we are planning for later in the year in Tungsten is to split events into different “channels” for replication in parallel. Parallel replication seems to be particularly helpful when you have events that are truly slow, such as DDL, or for replication of data that are already sharded.

]]> By: Justin Swanhart http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/comment-page-1/#comment-614402 Justin Swanhart Wed, 22 Jul 2009 19:41:21 +0000 http://www.mysqlperformanceblog.com/?p=843#comment-614402 I'm curious why the implementation notes in that workload preclude UPDATE. UPDATE can be logically decomposed into DELETE followed by INSERT. This doesn't inhibit transaction serialization. I’m curious why the implementation notes in that workload preclude UPDATE. UPDATE can be logically decomposed into DELETE followed by INSERT. This doesn’t inhibit transaction serialization.

]]> By: Shlomi Noach http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/comment-page-1/#comment-614397 Shlomi Noach Wed, 22 Jul 2009 19:22:04 +0000 http://www.mysqlperformanceblog.com/?p=843#comment-614397 Just to mention that Xtrabackup incremental backups do not backup MyISAM/ARCHIVE tables (yet), and so provide incremental backup only fo InnoDB tables. Just to mention that Xtrabackup incremental backups do not backup MyISAM/ARCHIVE tables (yet), and so provide incremental backup only fo InnoDB tables.

]]> By: Morgan Tocker http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/comment-page-1/#comment-614362 Morgan Tocker Wed, 22 Jul 2009 13:31:41 +0000 http://www.mysqlperformanceblog.com/?p=843#comment-614362 @Peter - Yes, I chose a pretty harsh set of number for the purpose of illustration - but there are a lot of people in this category. If we follow your advice, and repeat the math with 50% slave load (peak), 30% slave load (off peak), it doesn't look as bad: To replay logs: (12 * 0.50) + (12 * 0.30) = 9h36m For slave to come online: (each day has 24hr-9h36m = 14h24m “free” capacity, will be online in less than a day). @Daniellek - I think your solution is a good one. Always have a slave with no load up to date and ready to clone from. You still need to remember that it doesn't count as a backup. There's a range of problems (i.e. accidental/malicious delete) that you need to build a strategy for and cope with. @Peter – Yes, I chose a pretty harsh set of number for the purpose of illustration – but there are a lot of people in this category. If we follow your advice, and repeat the math with 50% slave load (peak), 30% slave load (off peak), it doesn’t look as bad:

To replay logs: (12 * 0.50) + (12 * 0.30) = 9h36m
For slave to come online: (each day has 24hr-9h36m = 14h24m “free” capacity, will be online in less than a day).

@Daniellek – I think your solution is a good one. Always have a slave with no load up to date and ready to clone from. You still need to remember that it doesn’t count as a backup. There’s a range of problems (i.e. accidental/malicious delete) that you need to build a strategy for and cope with.

]]> By: Daniellek http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/comment-page-1/#comment-614357 Daniellek Wed, 22 Jul 2009 08:51:34 +0000 http://www.mysqlperformanceblog.com/?p=843#comment-614357 Hardcore (but working) solution: Setup: Master+2 slaves (one slave is "production", and the other is "backup") mysql-backup stop tar czvf .... mysql-backup start Hardcore (but working) solution:
Setup: Master+2 slaves (one slave is “production”, and the other is “backup”)

mysql-backup stop
tar czvf ….
mysql-backup start

]]> By: peter http://www.mysqlperformanceblog.com/2009/07/21/just-how-useful-are-binary-logs-for-incremental-backups/comment-page-1/#comment-614355 peter Wed, 22 Jul 2009 05:02:47 +0000 http://www.mysqlperformanceblog.com/?p=843#comment-614355 Morgan, I would mention if you're running your slave at 90% capacity during peak load you're looking for trouble big deal. I would highly recommend slave thread busy no more than 30-50% - this makes sure you have at least some time to take an action as load or data size growths. With 90% you can wake up one morning and see things never catch up :) Morgan,

I would mention if you’re running your slave at 90% capacity during peak load you’re looking for trouble big deal.

I would highly recommend slave thread busy no more than 30-50% – this makes sure you have at least some time to take an action as load or data size growths. With 90% you can wake up one morning and see things never catch up :)

]]>