数据无价,MySQL做为一个数据库系统,其备份天然也是很是重要且有必要去作。备份的理由千千万,预防故障,安全需求,回滚,审计,删了又改的需求等等,备份的重要性不言而喻。除了备份自己,如何使用备份来恢复服务也是一项重点内容,不能用来恢复的备份没有意义。本文主要会针对备份和恢复这两方面作一些简单的介绍。mysql
本文为《高性能MySQL》备份相关章节的读书笔记。
正如简介所说,备份人尽皆知,也很容易引发人的重视。根据需求写按期脚本,或者使用其余方式都是比较常见的。可是恢复就没有那么引人注目了。好比说,也许会每周/天天按期进行自动备份。可是多久会进行一次备份的恢复测试?备份的内容是否完成?是否可用于恢复?若是出现故障,恢复的流程是否易操做?
备份只是数据源,如何使用数据源,完全恢复系统这个过程。也很是重要。备份与恢复,都是MySQL运维中须要掌握的内容。sql
备份的意义在于恢复。若是不能恢复,那就不叫备份(好比RAID阵列不是备份,若是DROP DATABASE,RAID阵列不能恢复)
[还原] 和 [恢复] 的区别:数据库
也就是说,恢复是要恢复到异常出前,采起的全部操做(好比修改参数,重启服务等)。不只仅只是还原备份。
恢复计划在设计的时候,须要考虑一些因素,从而根据不一样的需求进行更好的规划。能够根据RPO(恢复点目标)和RTO(恢复时间目标)这两个需求来协助制定合适的恢复策略。安全
也许还需考虑:须要恢复什么?(整个服务器,单个库,单个表,仍是事务)
其次,恢复计划须要按期进行测试,抽出数据测试备份确实有效、实际进行一次完整的备份恢复,熟悉整个恢复流程,确保真正发生问题时,能够有条不紊的完成恢复。服务器
最简单的策略就是只备份数据和表定义。可是恢复数据库须要更多内容,若是能备份的越充足,那么恢复起来也就更容易。(主要仍是根据需求)运维
好比能够根据实际状况,考虑备份以下内容:
一、Binlog和InnoDB事务日志。
二、主/从库配置文件。
三、数据库操做系统配置(cron、脚本、内核参数)性能
或者说,根据须要进行备分内容的扩展。若是对于数据库恢复、甚至重建有很高需求(好比要求更快恢复),那么备份更多的内容也必不可少。若是须要有从0恢复数据库的能力,那须要作更多工做。
备份种类 | 逻辑备份 | 物理备份 |
---|---|---|
简介 | 利用mysqldump等命令实现备份 | 直接复制数据库文件 |
优势 | 能够文本编辑,恢复简单,使用mysqldump备份灵活。 | 足够直观,备份和恢复过程,本质上就是文件的移动。恢复速度更快。MySQL服务器几乎不须要执行操做。 |
缺点 | 备份和恢复都须要MySQL服务参与、且占用CPU资源。有可能很慢 | InnoDB的原始文件一般比逻辑备份大得多。 |
物理备份和逻辑备份的一点抉择:学习
物理备份简单高效,逻辑备份尽可能也要作。【二者都要有,看具体需求和资源分配】
其次:除非通过测试,不然不能假设备份可用。好比使用mysqlcheck -A
测试数据库。
Binlog也是备份中的重要一环,由于基于时间点的恢复须要用到它。并且Binlog通常很小,频繁的备份也较容易实现。若是有某个时间点的数据备份,加上自那之后的全部Binlog,就能够回滚全部变更。测试
4.3.一、备份Binlog的一些策略大数据
FLUSH LOGS
建立新的Binlog(这样就只须要备份最新的Binlog了) --log_slave_updata
的只读备库。
须要注意的是,expire_log_days是经过
日志文件的修改时间来判断的,而不是内容。(若是一直只有一个Binlog文件,可能就不会清理)。因此必定要使用
FLUSH LOGS
按期刷新Binlog。
4.3.二、老Binlog的清理
最好使用expire_log_days来进行自动的清理,保留必定天数。若是须要用cron清理。那么不要使用 find+rm配置的cron清理日志。0 3 * * * /usr/bin/mysql /var/log/mysql -mtime +N -name "mysql-bin.[0-9]"* | xargs rm
使用以下cron代替:0 3 * * * /usr/bin/mysql -e "PURGE MASTER LOGS BEFORE CURRENT_DATE - INTERVAL N DAY"
4.3.三、Binlog备份的几点注意事项
增量备份:自任意类型备份后,改动的全部内容的备份。
差别备份:特指自上次全备份以后,改动的全部内容的备份。
也就是说,差别备份基于全备份。而增量备份基于任意备份(好比某一个指定的差别备份。
下面举一个例子:周日进行一次全备份,周一针对周日的全备份作一次差别备份。周二开始就能够有两种选择:一、基于周日的全备份作备份(差别)。二、基于周一的差别备份作备份(增量)
差别备份可选项:
虽然这样作差别备份能够提升恢复速度。可是全备份仍是颇有必要的。( 全备份能够频率低,可是必须有)。
在从库中备份,有时候是一个可选项,不会干扰到主库,避免给主库增长更多的负载。其次,当计划从从库备份的时候,要保存更多信息,好比从库相对于主库的位置(偏移)等。
首先 从库不等于备份,从库和主库数据不匹配是很常见的。其次、从从库备份确实能够减轻主库备份时的负载,可是不够好。稳定起见,仍是建议进行主库备份、全备份。
4.6.一、在线备份与离线备份
离线备份是最简单最安全的。也是一致性最好的。问题就是,大部分数据库不能接受停机备份。因此基本仍是用在线备份,或者说不停机备份
能够考虑在业务低峰期进行在线备份,即便负载增大也不会有太大影响。
4.6.二、数据一致性
数据一致性:对于多个表之间数据的一致性要求。(好比两个逻辑相关的操做分在了两个事务内,而备份在两个事务之间执行,就会致使数据不一致)
InnoDB能够在转储一组相关表的时候,开始一个事务,这样能够很大程度上保证数据的一致性。
可是也要注意,若是事务设置的不合理,好比一组相关表的修改分在了两个事务内,这仍然会致使数据不一致。( 一组表的相关操做须要确保在一个事务内)
4.6.三、按期进行备份恢复测试,确认整个恢复过程须要的资源
能恢复的备份才有价值,不是有备份就能够
本文讲解了一些备份的基本知识和概念,包括一些基本概念、恢复的重要性、备份和恢复的简单策略。还说起到了备分内容的选择、差别/增量备份、Binlog备份等。后续还须要继续学习,了解备份和恢复的具体操做方法和实践。