We’ve recently received a number of questions on how to implement incremental MySQL backups alongside encryption with Percona XtraBackup. Some users thought it was not initially possible because with the default --encrypt options with XtraBackup, all files will be encrypted, but alas, that is not the case. This is where the option --extra-lsn-dir becomes useful, […]
Percona Server 5.6.11-60.3 has introduced a new feature called Log Archiving for XtraDB. This feature makes copies of the old log files before they are overwritten, thus saving all the redo log for a write workload. When log archiving is enabled, it duplicates all redo log writes in a separate set of files in addition […]
With our newest release of Percona XtraDB Cluster, I would like to highlight a very nice ability to recovery a node and bring it back to the cluster with an incremental transfer after a crash. This feature was available even in previous release, but now I want to give some details. So, MySQL crashes from […]
Sometimes you might hear people talk about full backups, and differential backups versus incremental backups. What is the difference? A full backup is pretty self-explanatory. It makes a copy of all of your MySQL data. A differential backup, on the other hand, simply records the differences since your last full backup. The advantage of taking […]
Are you using InnoDB tables on MySQL version 5.1.22 or newer? If so, you probably have gaps in your auto-increment columns. A simple INSERT IGNORE query creates gaps for every ignored insert, but this is undocumented behaviour. This documentation bug is already submitted. Firstly, we will start with a simple question. Why do we have […]
A lot of people are running MySQL Master-Master replication pairs in Active-Passive mode for purpose of high availabilities using MMM or other solutions. Such solutions generally have one major problem – you have to be very carefully switching writes as if you do not do it atomically (such as some scripts continue to write to […]
A couple of weeks ago I blogged about Sharing an auto_increment value across multiple MySQL tables. In the comments, a few people wrote in to suggest alternative ways of implementing this.Â I just got around to benchmarking those alternatives today across two large EC2 machines:
The title is SEO bait – you can’t do it. We’ve seen a few recurring patterns trying to achieve similar – and I thought I would share with you my favorite two: Option #1: Use a table to insert into, and grab the insert_id:
CREATE TABLE option1 (id int not null primary key auto_increment) engine=innodb;
# each insert does one operations to get the value:
INSERT INTO option1 VALUES (NULL);
Option #2: Use a table with one just row:
CREATE TABLE option2 (id int not null primary key) engine=innodb;
INSERT INTO option2 VALUES (1); # start from 1
# each insert does two operations to get the value:
UPDATE option2 SET id=@id:=id+1;
We’ve written about replication slaves lagging behind masters before, but one of the other side effects of the binary log being serialized, is that it also limits the effectiveness of using it for incremental backup.Â Let me make up some numbers for the purposes of this example: We have 2 Servers in a Master-Slave topology. […]
I am happy to announce next build of our backup tool. This version contains several bugfixes and introduces initial implementation of incremental backup. Incremental backup works in next way. When you do regular backup, at the end of procedure you can see output:
The latest check point (for incremental): '1319:813219999'
>> log scanned up to (1319 813701532)
Transaction log of lsn (1318 3034677302) to (1319 813701532) was copied.
090404 06:03:29 innobackupex: All tables unlocked
090404 06:03:29 innobackupex: Connection to database server closed
innobackupex: Backup created in directory '/mnt/data/tmp'
innobackupex: MySQL binlog position: filename 'db02-bin.001271', position 247627478
090404 06:07:58 innobackupex: innobackup completed OK!
innobackupex: You must use -i (--ignore-zeros) option for extraction of the tar stream.
which gives start point 1319:813219999 for further incremental backup. This point […]