您的位置:首页 > 数据库 > MySQL

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

2014-04-13 22:45 204 查看
备份的目的:
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
[/code]
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,模拟所有数据丢失






把备份的数据复制回去






总结:逻辑卷备份也很难实现差异或增量备份,所以也需结合二进制日志恢复数据
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: