LVM snapshot: backup based on LVM snapshot

To continue lvm-snapshot： be based on LVM Backup of snapshot The preparatory work for   http://www.linuxidc.com/Linux/2014-05/101308.htm

Attention,Please! The play begins

3. be based on LVM Backup of snapshot

lvm-snapshot： be based on LVM Backup of snapshot

(1) Transaction log and data file must be on the same volume ;

(2) Before creating a snapshot volume , Ask for MySQL The global lock of ; Release the lock after the snapshot is created ;

(3) After the global lock request is complete , Do a log scroll ; Do binary log file and location mark ( Manually );

-------------------------------------- Split line --------------------------------------

MySQL Management is based on LVM Achieve almost hot standby http://www.linuxidc.com/Linux/2014-04/99672.htm

Ubuntu 12.04 KVM And VM Dynamic migration - be based on LVM http://www.linuxidc.com/Linux/2014-04/99894.htm

RHEL5.9 LVM Use http://www.linuxidc.com/Linux/2014-02/97268.htm

Linux Logical volumes in the system (LVM) The implementation of the http://www.linuxidc.com/Linux/2014-01/95004.htm

LVM Expansion and reduction of disk management LV http://www.linuxidc.com/Linux/2013-03/81262.htm

-------------------------------------- Split line --------------------------------------

Backup steps ：

3.1 Request global lock , And scroll through the log

MariaDB [hellodb]> FLUSH TABLES WITH READ LOCK;

MariaDB [hellodb]> FLUSH LOGS;

3.2 View and record binary log files and location marks ( Manually );

MariaDB [hellodb]> SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+

| File            | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000005 |      365 |              |                  |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

Don't quit at this time Mysql, Once you exit , It'll be the lock we manually imposed , Will automatically release

Record the binary log file and location mark to the specified file

# mkdir /backups

# mysql -e 'show master status' >/backups/binlog.pos

3.3 Create snapshot volume (-L, Specify the snapshot volume size ;-n, Specify the snapshot volume name ;-p, Specify the attributes of the snapshot volume )

# lvcreate -L 100M -s -n mydata-snap -p r /dev/myvg/mydata

see lvm Volume usage

[[email protected] ~]# lvs

  LV          VG  Attr      LSize  Pool Origin Data%  Move Log Cpy%Sync Convert

  mydata      myvg owi-aos--  10.00g                                           

 mydata-snap myvg sri-a-s-- 100.00m      mydata  0.01                         

  root        vg0  -wi-ao---  20.00g                                           

 swap        vg0  -wi-ao---  2.00g                                           

 usr        vg0  -wi-ao---  10.00g                                           

 var        vg0  -wi-ao---  20.00g 

3.4 Release global lock

 MariaDB [hellodb]> UNLOCK TABLES;

  notes ： Snapshot creation completed , But you haven't quit before MariaDB The terminal performs unlocking operation

3.5 Mount the snapshot volume and back it up

(1) Mount the snapshot volume read-only to /mnt Catalog

[[email protected] ~]# mount -o ro /dev/myvg/mydata-snap /mnt/

(2) Check whether the snapshot volume is successfully mounted ( That is, check whether there is any data backed up by us under the mount point )

[[email protected] ~]# cd /mnt/

[[email protected] mnt]# ls

binlogs  data

[[email protected] mnt]# cd data/

[[email protected] data]# ls

aria_log.00000001  ibdata1      multi-master.info  test

aria_log_control  ib_logfile0  mysql              www.linuxidc.com.err

hellodb            ib_logfile1  performance_schema  www.linuxidc.com.pid

Careful, you should notice , We have already released the global lock , So other users can write , therefore

Here we simulate , After our full backup , Another user executed the write operation experimental environment , unfortunately , We haven't been importing data here long , On the contrary, it's very "2" Error of ： Accidentally shut down the database service , And deleted the data by mistake /mydata/data/ All the data below

3.6 Import new data , Simulate a user's write operation

MariaDB [mydb]> source /root/mydb.sql;

3.7 Back up the data in the snapshot to the specified location

# cp -a /mnt/data/ /backups/data-$(date +%F)

3.8 After the backup is complete , Delete snapshot volume

# umount /mnt/  Unmount snapshot volume

# lvremove /dev/myvg/mydata-snap  Remove snapshot volume

recovery ： The binary log must be saved well , Otherwise, it is difficult to achieve instant point restore

Simulation database corruption

4. Accidentally stopped the database , And delete all the files in the data directory

[[email protected] ~]# service mysqld stop

Shutting down MySQL...                                    [  OK  ]

[[email protected] ~]# rm -rf /mydata/data/*

Fortunately, the binary log is still there , Otherwise, you can't do instant restore ( Binary log files are important , Always back up )

[[email protected] ~]# ls /mydata/binlogs/

mysql-bin.000001  mysql-bin.000003  mysql-bin.000005  mysql-bin.state

mysql-bin.000002  mysql-bin.000004  mysql-bin.index

After the data in the data directory is deleted by mistake , The data directory is empty

[[email protected] ~]# ls /mydata/data/

Restore all data under the data directory ,-a Keep the attribute information such as the user's primary group unchanged

[[email protected] ~]# cp -a /backups/data-2014-04-12/*  /mydata/data/

[[email protected] ~]# cd /mydata/data/

Check whether the primary and subordinate groups of the data in the data directory are mysql, If it is not , Just modify it by yourself

[[email protected] data]# ll 

total 110636

-rw-rw---- 1 mysql mysql    16384 Apr 12 22:33 aria_log.00000001

-rw-rw---- 1 mysql mysql      52 Apr 12 22:33 aria_log_control

drwx------ 2 mysql mysql    4096 Apr 12 22:38 hellodb

-rw-rw---- 1 mysql mysql 12582912 Apr 12 22:34 ibdata1

-rw-rw---- 1 mysql mysql 50331648 Apr 12 22:34 ib_logfile0

-rw-rw---- 1 mysql mysql 50331648 Apr 12 22:32 ib_logfile1

-rw-rw---- 1 mysql mysql        0 Apr 12 22:34 multi-master.info

drwx------ 2 mysql mysql    4096 Apr 12 22:33 mysql

drwx------ 2 mysql mysql    4096 Apr 12 22:33 performance_schema

drwx------ 2 mysql mysql    4096 Apr 12 22:25 test

-rw-r----- 1 mysql root      3660 Apr 12 22:34 www.linuxidc.com.err

-rw-rw---- 1 mysql mysql        5 Apr 12 22:34 www.linuxidc.com.pid

Confirm that the data directory permissions are correct , You can start it mysql 了

[[email protected] data]# service mysqld start

Check whether the data files have been recovered under the data directory

[[email protected] data]# ls

aria_log.00000001  ibdata1      multi-master.info  test

aria_log_control  ib_logfile0  mysql              www.linuxidc.com.err

hellodb            ib_logfile1  performance_schema  www.linuxidc.com.pid

Check whether the data files have been recovered in the data

MariaDB [(none)]> show databases;

+--------------------+

| Database          |

+--------------------+

| hellodb            |

| information_schema |

| mysql              |

| performance_schema |

| test              |

+--------------------+

5 rows in set (0.01 sec)

here , The full backup has been successfully restored , But we simulate what the user writes mydb.sql file , Generated mydb database , And the data table has not been recovered

Because the write operation occurred after our full backup , Therefore, the database and its data are not included in our full backup , So we can only use binary log files at this time . The binary log file at our last full backup is mysql-bin.000005, After we do a full backup and restore , It's restarted sql service ,

And so it was mysql-bin.000006 Binary log file .

View binary log files

[[email protected] data]# ls /mydata/binlogs/

mysql-bin.000001  mysql-bin.000003  mysql-bin.000005  mysql-bin.index

mysql-bin.000002  mysql-bin.000004  mysql-bin.000006

Check the binary log saved before our full backup mysql-bin.000005 Information about

[[email protected] data]# cat /backups/binlog.pos

FilePositionBinlog_Do_DBBinlog_Ignore_DB

mysql-bin.000005365

View binary log files mysql-bin.000005 Specific content of

# mysqlbinlog --start-position=365 /mydata/binlogs/mysql-bin.000005

# at 365

#140412 22:55:48 server id 1  end_log_pos 403GTID 0-1-2176

/*!100001 SET @@session.gtid_domain_id=0*//*!*/;

/*!100001 SET @@session.server_id=1*//*!*/;

/*!100001 SET @@session.gtid_seq_no=2176*//*!*/;

...... Omit some unimportant information

# at 4857

#140412 22:55:51 server id 1  end_log_pos 4895GTID 0-1-2200

/*!100001 SET @@session.gtid_seq_no=2200*//*!*/;

# at 4895

#140412 22:55:51 server id 1  end_log_pos 5009Querythread_id=4exec_time=0error_code=0

SET TIMESTAMP=1397314551/*!*/;

DROP TABLE IF EXISTS `t5` /* generated by server */

/*!*/;

# at 5009

#140412 22:55:51 server id 1  end_log_pos 5047GTID 0-1-2201

/*!100001 SET @@session.gtid_seq_no=2201*//*!*/;

# at 5047

#140412 22:55:51 server id 1  end_log_pos 5245Querythread_id=4exec_time=0error_code=0

SET TIMESTAMP=1397314551/*!*/;

CREATE TABLE `t5` (

  `ID` int(10) unsigned NOT NULL DEFAULT '0',

  `Name` char(30) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1

/*!*/;

# at 5245

#140412 22:55:51 server id 1  end_log_pos 5283GTID 0-1-2202

Realize the recovery of incremental backup with the help of binary log file

Now we need to import these binary log information into mysql The server

Law 1：

# mysqlbinlog --start-position=365 /mydata/binlogs/mysql-bin.000005 >/tmp/incr.sql

# mysql </tmp/incr.sql or mysql> source /tmp/incr.sql

Law 2：

# mysqlbinlog --start-position=365 /mydata/binlogs/mysql-bin.000005 | mysql

View in the database mydb Whether the database has been restored

MariaDB [(none)]> show databases;

+--------------------+

| Database          |

+--------------------+

| hellodb            |

| information_schema |

| mydb              |

| mysql              |

| performance_schema |

| test              |

+--------------------+

6 rows in set (0.01 sec)

We can see mydb The database has been successfully restored .

notes ： After database disaster recovery , The first thing we need to do is to make a full backup of the current database , For a rainy day , Be prepared against want

mylvbackup: perl Script , Fast based on lvm Backup mysql