MySQl的备份和恢复(笔记1)

备份的目的:

1.灾难恢复:

2.审计:

3.测试:如:版本升级

提示:备份后需要测试备份的数据是否能做恢复

备份类型:

备份类型：

        根据备份时，数据库服务器是否在线：
            冷备：cold backup,备份的时候,在线业务需要下线,最安全的备份方式
            温备：warm backup,全局施加共享锁,所有业务只能读,不能写,服务器没有完全离线,
            热备：hot backup:备份的时候,业务不用下线,只有基于事务的存储引擎才能完成

        根据备份的数据集：
            完全备份：full backup,备份整个库
            部分备份: partial backup,备份某张表,或某张表东西部分数据

        根据备份时的接口（直接备份数据文件还是通过mysql服务器导出数据）：
            物理备份：直接复制数据文件或打包归档,跨平台能力差,不过InnoDB的库比较容易跨平台,如果使用表空间来保存数据,有些未被占用的表空间也会占储存空间,使用于大数据量,备份超过1G或者很大,不要用逻辑备份,麻烦,物理备份与存储引擎关联较大；physical backup
            逻辑备份：把数据抽取出来保存为文本文件,能使用编辑器管理,导入简单,能基于网络恢复,于存储引擎无关,导入到其他数据库的时候完全可以换一种存储引擎,并且可以避免数据损坏.恢复速度慢,占据空间大,无法保证浮点数的精度,还原回数据后需要重建索引,对一个大型数据库来说,重建索引是相当消耗资源的,mysqldump工具进行逻辑备份.

        根据备份时是备份整个数据还是仅备份变化的数据：
            完全备份：full backup,备份整个库
            增量备份：incremental backup,完全备份后后一次的备份至前一次的位置
            差异备份：differential backup,从完全备份后的再备份

备份策略：
        选择备份方式
        选择备份时间:一般凌晨2-3点,
        考虑到恢复成本
            恢复时长
        备份成本：
            锁时间
            备份时长
            备份负载

 

备份对象：
        数据文件
        MySQL的配置文件
        代码：存储过程，存储函数，触发器
        OS相关的配置文件，如crontab配置计划及相关的脚本

        跟复制相关的配置；
        二进制日志文件

 

备份工具：
        mysqldump：逻辑备份工具,原生的,MySQl自带的
            InnoDB热备、MyISAM温备、Aria温备
            因为是逻辑备份,所以备份和恢复过程较慢,他是单线程工具,所以只能启动一个cpu一个线程来工作
        mysqldumper: 多线程的mysqldump,很难实现差异或增量备份；

        lvm-snapshot:
            接近于热备的工具：因为要先请求全局锁，而后创建快照，并在创建快照完成后释放全局锁；
            使用cp、tar等工具进行物理备份;备份和恢复速度较快；很难实现增量备份，并且请求全局需要等待一段时间，在繁忙的服务器上尤其如此；

            在使用lvm-snapshot备份的时候,首先要请求全局锁,FLUSH TABLES WITH READ LOCK;这时,在备份MyISAM储存引擎的库的时候没问题,但是在备份InnoDB的时候就有问题了,当FLUSH TABLES的时候,有些事务可能并没有存到数据文件中,而是存到了事务日志中,所以备份InnoDB的库时,不仅要备份源数据,还得备份事务日志,并且,如果你备份完成的后释放锁的那一刻,事务日志马上同步到数据中了,那后续的操作就记录不了了,所以使用lvm-snashot备份InnoDB恢复是要借助二进制日志一起恢复.并且事务日志和数据文件必须放在同一个卷上.

        SELECT clause INTO OUTFILE '/path/to/somefile'
        LOAD DATA INFILE '/path/from/somefile'
            部分备份工具， 不会备份关系定义,不会备份表格式，仅备份表中的数据；是逻辑备份工具，在速度上略快于mysqldump,因为他只备份数据本身

        Innobase: 商业备份工具, innobackup
            InnoDB热备，增量备份；
            MyISAM温备，不支持增量；
            物理备份，速度快；

         Xtrabackup: 由Percona提供的开源备份工具
            InnoDB热备，增量备份；
            MyISAM温备，不支持增量；
            物理备份，速度快；

        mysqlhotcopy: 几乎冷备,mysql自带的

    mysqldump: 备份数据量较小的数据
        mysqldump [options] [db_name [tbl_name ...]]

        备份单个库：mysqldump [options] db_name
            恢复时：如果目标库不存在，需要事先手动创建

        --all-databases: 备份所有库

        --databases db1 db2 ...: 备份指定的多个库

    注意：备份前要加锁

        --lock-all-tables：请求锁定所有表之后再备份，对MyISAM、InnoDB、Aria做温备

        --single-transaction: 能够对InnoDB存储引擎实现热备；

备份代码：
            --events: 备份事件调度器代码
            --routines: 备份存储过程和存储函数
            --triggers：备份触发器

备份时滚动日志：
            --flush-logs: 备份前、请求到锁之后滚动二进制日志；恢复的时候需要备份的日志加上备份后那一刻后的二进制日志,所以需要日志滚动.

复制时的同步位置标记：如果没有使用--flush-logs,备份的时候记录二进制日志文件名和事件位置
            --master-data=[0|1|2]
                0: 不记录
                1：记录为CHANGE MASTER语句
                2：记录为注释的CHANGE MASTER语句

示例:备份单个库

1.所有库

2.备份hellodb库

3.删除原有库,尝试导入

可以看到,这个的恢复需要依赖库,如果目标库不存在,需手动创建库

4.创建新库并导入

这里是因为笔者是在本地数据库,如果是远程,需使用命令

  1: mysql -uroot -hlocalhost -p hdb < /tmp/hdb.sql

示例2:备份所有数据库,只要指定了-databases,恢复时不需要目标库存在

  1:  mysqldump --all-databases > /tmp/all.sql

有一个警告信息,我也不知道是什么,等查清后在说...

看来是需要备份事件调度器

示例3.备份指定的库,只要指定了-databases,恢复时不需要目标库存在

演示了半天,但是千万不要向上面的方式操作,因为你在备份的时候别人在执行写操作怎么办?所以备份时一定要先加锁

示例4:施加锁然后才备份,自动施加读锁,但是也不有理想,因为锁着的时候别人无法写数据,对MyISAM,InnoDB,Aria做温备

示例5:--single-transaction: 能够对InnoDB存储引擎实现热备,使用了--single-transaction就不要使用--lock-all-tables,--single-transaction会启动一个大事务基于MVCC对库实现快照,来备份

示例6:手动请求全局锁

先把缓存中的数据同步到磁盘中,然后施加读锁

滚动日志并查看日志

这里是备份的时候的日志的事件位置,以后恢复二进制日志的时候就从mysql-bin.000024 107以后的开始恢复

备份数据:

释放锁

总结:1.同步缓存数据到磁盘并施加全局读锁;2.滚动日志;3.备份数据;4.解锁;

示例7:自动施加全局锁,请同示例6做比较

图1位置:施加全局锁;图2位置:滚动日志.没有同步缓存到磁盘?????

示例8:如果所有库的存储引擎都是InnoDB的

示例9:备份及恢复

查看表的存储引擎

  1: SHOW TABLE STATUS FROM hellodb \G

2.备份

只能做局域全局锁的温备,因为是MyISAM的存储引擎

3.查看备份文件

  1: vim /tmp/hdb.1.sql

这就是--master-data=2生成的注释信息,以后如果需要做即时点恢复,就恢复从这以后的二进制日志

4.在hellodb中建立一张表,然后模拟删除整个库

  1: use hellodb
  2: CREATE TABLE ldf
  3: CREATE TABLE ldf(Name CHAR(30));

  4: DROP DATABASE hellodb;

5.首先恢复的时候确保你的数据库是离线的,导出二进制日志

  1:  mysqlbinlog --start-position=107 mysql-bin.000028  查看二进制日志

  

导出 at 629之前的二进制日志

  1: mysqlbinlog --start-position=107 --stop-position=629 mysql-bin.000028 > /tmp/hdb.inc.sql

6.准备还原,还原的时候的修改信息无需记录在二进制日志中,所以,先关闭二进制日志

7.首先导入完全备份,因为上图设置的关闭二进制日志的会话变量,所以需要不能使用 mysql< /tmp/hdb.1.sql的方式恢复,这样恢复会修改二进制日志,只能使用source的方式

从以上两图看来,事件位置并没有发生改变

8.查看恢复是否成功,并导入二进制日志

  1: source /tmp/hdb.inc.sql

新创建的表也恢复了

9.开启二进制日志

总结:基于mysqldump的备份,只能基于完全备份+二进制日志文件.建议:每周日做一次完全备份,周一至周六做二进制日志备份,恢复的时候只需完全备份+各二进制日志,在备份二进制日志的时候,使用mysqladmin flush-logs滚动一次二进制日志,然后把之前的都备份了.

lvm_snapshot:基于LVM快照的备份

shot：基于LVM快照的备份
        1、事务日志跟数据文件必须在同一个卷上；
        2、创建快照卷之前，要请求MySQL的全局锁；在快照创建完成之后释放锁；
        3、请求全局锁完成之后，做一次日志滚动；做二进制日志文件及位置标记(手动进行)；

示例:

首先确保自己的数据目录是逻辑卷

施加全局锁,不要退出mysql,否则锁会释放的

图1位置:写入缓冲区数据并施加全局读锁;图2位置:滚动日志;图3位置:查看二进制事件位置,这个得自己记住

也可以自行保存该事件位置

创建快照

释放锁:

挂载快照卷

备份所有数据

卸载快照卷

  1:  umount /mnt

关闭mysql,模拟所有数据丢失

把备份的数据复制回去

总结:逻辑卷备份也很难实现差异或增量备份,所以也需结合二进制日志恢复数据