mysql lvm管理_MySQL管理之基于LVM实现几乎热备

快照大小规划思路

·在备份过程的这段时间，可能数据的变化量远远大于它，这是必然的

·假设我们备份时间需要2个小时，在2个小时之内数据变化量在50MB左右，那则给它200MB即可，如果在备份过程中数据量变化超出快照卷的量会导致快照卷崩溃，那么对于快照备份没有任何意义了

·指定大小必须确保快照卷和原卷要在同一个卷组内

·确保卷组有足够的空间可用

备份数据

[root@test ~]#lvcreate -L 100M -n mydata-snap -p r -s /dev/myvg/mydata

Logical volume "mydata-snap"created

在此瞬间完成之后，我们就可以进行释放表锁了

MySQL> unlocktables;

Query OK, 0 rowsaffected (0.00 sec)

备份数据或使用tar/zip 打包

[root@test mydata]#cp -fra data/ /backup/2014-04-02/

注意事项：

一旦将数据恢复到数据目录下去启动数据的时候，那些在事物日志中的某些事物尚未提交或已经提交但尚未同步到磁盘中，那这时innodb存储引擎必须对其做一次从崩溃状态中恢复，会将在事物日志中尚未提交的时候回滚，将未同步至磁盘中的事物则进行同步操作

因为我们锁定所有表之后并不意味着事物日志中的所有数据都同步在磁盘中去了，所以一旦做了快照而有可能导致事物日志中出现以上两种问题，如果我们要对这部分做数据恢复的话，那么一定是会复制这些未同步的数据或未提交的事物，就算后续快照完之后都提交后也不行，类似于mysql服务器崩溃过一次，因此要从崩溃中恢复到正常以后才能恢复数据的，所以在cp或tar进行备份的时候要有一个恢复的过程

有时候我们是以root用户进行复制的，这就意味着我们备份的数据或打包数据后的文件属组是root而不再是mysql用户了

如果某个事物已经提交了，而且已经写入到事物日志里，但尚未同步到磁盘上，那么这时做了快照的话，如果二进制日志文件已经记录下来，如果没有记录事件提交，而等备份恢复以后可能会丢失事物，因此避免这种情况，我们备份的时候要调整几个属性信息：

sync_binlog=1;任何事物提交立刻将事件同步到二进制日志文件，以避免事物丢失

启动mysql并实现几乎热备

首先必须确认事物日志必须跟数据在同一个lv

连接数据库

施加全局锁，将所有表的请求数据全部刷新至硬盘上，完后对其加全局锁

mysql> flushtables with read lock;

Query OK, 0 rowsaffected (0.00 sec)

过程可能会有很长时间，因为它会处理完请求并等待数据同步至磁盘，加锁之后一定不要退出，如果退出锁会被释放

记下二进制日志位置，对于后面恢复至关重要

[root@testmydata]# mysql -uroot -e 'show master status\G;' >/tmp/snapback_`date +%F`.txt

[root@test mydata]#cat /tmp/snapback_`date +%F`.txt

***************************1. row ***************************

File:mysql-bin.000004

Position: 107

Binlog_Do_DB:

Binlog_Ignore_DB:

创建快照卷

[root@test mydata]#lvcreate -L 100M -s -p r -n mydata_snap /dev/myvg/mydata

Logical volume "mydata_snap"created

查看快照卷

[root@test mydata]#ll /dev/myvg/

total 0

lrwxrwxrwx. 1 rootroot 7 Apr 3 00:22 mydata -> ../dm-0

lrwxrwxrwx. 1 rootroot 7 Apr 3 00:22 mydata_snap -> ../dm-4

创建完成，一创建完成我们就可以释放表锁

mysql> unlocktables;

Query OK, 0 rowsaffected (0.00 sec)

备份数据

可以手动去备份，如果需要的话可以将二进制日志也一起备份，或者二进制日志另外备份也可以

[root@test data]#mkdir -p /backup/snapback_$(date +%F)

[root@test data]#cp -fra * /backup/snapback_2014-04-03/

因为都是二进制文件所以压缩的意义不是非常大

我们对数据库进行简单写操作：

mysql> createtable testtb (id int,name char(20));

Query OK, 0 rowsaffected (0.47 sec)

mysql> insertinto testtb values (1,'xiaohong'),(2,'xiaoming');

Query OK, 2 rowsaffected (0.15 sec)

Records: 2 Duplicates: 0 Warnings: 0

mysql> usemydb2;

Database changed

mysql> createtable tb1 (id int);

Query OK, 0 rowsaffected (0.07 sec)

mysql> insertinto tb1 values (1);

Query OK, 1 rowaffected (0.05 sec)

进行增量备份

之前备份过二进制日志

[root@test /]# cat/tmp/snapback_`date +%F`.txt

***************************1. row ***************************

File: mysql-bin.000004

Position: 107

Binlog_Do_DB:

Binlog_Ignore_DB:

从位置107开始，因此我们记住这个位置去读取mysql二进制文件并将其备份

[root@test /]# mysqlbinlog--start-position=107 /mydata/data/mysql-bin.000004 >/backup/snapback_incrementa/incrementa_$(date +%F).sql

让其数据库崩溃

删除数据库目录中的所有文件

[root@test mysql]#/etc/init.d/mysqld stop

[root@test data]#rm -fr *

[root@test data]#pwd

/mydata/data

现在数据库中空空如也

恢复快照

[root@test data]#cp -fra /backup/snapback_2014-04-03/* ./

[root@test data]#ll

total 30296

-rw-rw----. 1 mysqlmysql 18874368 Apr 2 23:54 ibdata1

-rw-rw----. 1 mysqlmysql 5242880 Apr 2 23:54 ib_logfile0

-rw-rw----. 1 mysqlmysql 5242880 Apr 2 23:19 ib_logfile1

drwx------. 2 mysqlmysql 4096 Apr 2 23:21 mydb

drwx------. 2 mysqlroot 4096 Apr 2 23:21 mysql

-rw-rw----. 1 mysqlmysql 27668 Apr 2 23:17 mysql-bin.000001

-rw-rw----. 1 mysqlmysql 1061358 Apr 2 23:17 mysql-bin.000002

-rw-rw----. 1 mysqlmysql 532317 Apr 2 23:54 mysql-bin.000003

-rw-rw----. 1 mysqlmysql 107 Apr 2 23:54 mysql-bin.000004

-rw-rw----. 1 mysqlmysql 76 Apr 2 23:54 mysql-bin.index

drwx------. 2 mysqlmysql 4096 Apr 2 23:17 performance_schema

drwx------. 2 mysqlroot 4096 Apr 2 23:16 test

-rw-r-----. 1 mysqlroot 3418 Apr 2 23:54 test.err

-rw-rw----. 1 mysqlmysql 5 Apr 2 23:54 test.pid

drwx------. 2 mysqlmysql 4096 Apr 2 23:21 wpdb

我们看到部分权限的属组还是root用户的，所以还需将其权限改为mysql

[root@test data]#chown -R mysql.mysql ./*

尝试启动mysql

[root@test data]# /etc/init.d/mysqldrestart

mysql> showtables;

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

| Tables_in_wpdb |

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

| students |

| tb3 |

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

2 rows in set (0.00sec)

之前我们创建的testtb表是不存在的，所以这时我们还需要使用增量备份

mysql> source/backup/snapback_incrementa/incrementa_2014-04-03.sql

mysql> showtables;

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

| Tables_in_wpdb |

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

| students |

| tb3 |

| testtb |

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

3 rows in set (0.00sec)

mysql> select *from testtb;

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

| id | name |

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

| 1 | xiaohong |

| 2 | xiaoming |

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

2 rows in set (0.00sec)

数据已经恢复，最后将binlog功能开启

mysql> setsql_log_bin=1;

Query OK, 0 rowsaffected (0.00 sec)

恢复完成

不管是否有备份需求的时候我们一定要备份、记住二进制日志的事件的位置否则后续恢复将无法正常进行，哪怕是滚动后的日志也要将其记录。