En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

  • Méthode de réplication MySQL dite "de snapshot"

    Cette méthode est celle utilisée par Percona :

    1) Connect to MySQL and run FLUSH TABLES WITH READ LOCK
    Note – this command may take a while to complete if you have long running queries. The catch here is FLUSH TABLES WITH READ LOCK actually waits for all statements to complete, even selects. So be careful if you have any long running queries. If you’re using only Innodb tables and do not need to synchronize binary log position with backup you can skip this step.

    2) While holding connection open run: lvcreate -L16G -s -n dbbackup /dev/Main/Data – This will create snapshot nameddbbackup for Logical Volume Main/Data . You should specify enough of undo space to hold modifications during backup process – I’ve specified 16GB in this case. If your undo size is not large enough snapshot will get invalidated and backup will be aborted.

    Sometimes you might run into the errors on this step, The most common one I’ve resently seen is: snapshot: Required device-mapper target(s) not detected in your kernel – This means snapshot module is not loaded in your kernel by default and you need to load it, which is done by running modprobe dm-snapshot

    3) Now you have created logical volume and can unlock the tables, but before that you should probably record binary log position which is done by running SHOW MASTER STATUS – This is binary log position you’ll need to point your MySQL Slaves created from this snapshot.

    4) Snapshot created, now you want to let MySQL Server to continue, which is done by running UNLOCK TABLES or simply closing connection.

    5) Mount backup Filesystem: mount /dev/Main/dbbackup /mnt/backup

    6) Copy data to backup. Normally you can skip slow query logs and error log while taking backup. You also can skip most of binary logs – however if some of your slaves are far behind you might want to keep some of last binary logs just in case, or you can assume in case of recovery from the backup you will need to restore slaves as well and skip binary logs in your backup process.

    7) Unmount filesystem umount /mnt/backup

    8) Remove snapshot: lvremove -f /dev/Main/dbbackup

    If you want to create slave based on such snapshot you need to perform couple of more simple steps

    9) Extract/Copy database to the slave database directory.

    10) Start MySQL Server. Wait for it to perform recovery.

    11) Use CHANGE MASTER TO to point slave to saved binary log position:


    12) Run SLAVE START to restart replication.

    With slightly modified process you can clone slaves from the slaves without stopping them – you just need to use SHOW SLAVE STATUS instead of SHOW MASTER STATUS to find out appropriate binary log position. Be careful however – cloning slave from the slave also clones inconsistences in data which slave could have accomulated – especially if you useslave_skip_errors or sql_slave_skip_counter. Cloning master you’re starting from consistent copy.



  • Faurisson

    Robert Faurisson