MySQL之备份与恢复(七)

备份与恢复

文件系统快照

规划LVM备份

LVM快照备份也是有开销的。服务器写到原始卷的越多,引发的额外开销也越多。当服务器随机修改许多不同块时,磁头需要需要自写时复制空间来来回回寻址,并且将数据的老版本写到写时复制空间。从快照中读取也有开销,因为LVM需要从原始卷中读取大部分数据。只有快照创建后修改过的数据从写时复制空间读取;因此,逻辑顺序读取快照数据实际上也可能导致磁头来回移动。所以应该为此规划好快照。快照实际上会导致原始卷和快照都比正常的读/写性能要差------如果使用过多的写时复制空间,性能可能会差很多。这会降低MySQL服务器和复制文件进行备份的性能。我们做了基准测试,发现LVM快照的开销要远高于它本应该有的------我们发现性能最多可能会慢5倍,具体取决于负载和文件系统。再规划备份时要记得这一点。

规划中另外一个重要的事情是,为快照分配足够多的空间。我们一般采取下面的方法.

  • 1.记住,LVM只需要复制每个修改块到快照一次。MySQL写一个块到原始卷中时,它会复制这个块到快照中,然后对复制的块在例外表中生成一个标记。后续对这个块的写不会产生任何到快照的复制
  • 2.如果只使用InnoDB,要考虑InnoDB是如何写数据的。InnoDB实际需要对数据写两遍,至少一半的InnoDB的写IO会到双写缓冲区(doublewrite buffer)、日志文件,以及其他磁盘上相对小的区域中。这部分会多次重用相同的磁盘块,因此第一次时对快照有影响,但写过一次以后就不会对快照带来写压力
  • 3.接下来,相对于反复修改同样的数据,需要评估有多少IO需要写入到那些还没有复制到快照写时复制的空间的块中,对评估的结果要保留足够的余量
  • 4.使用vmstat或iostat来手机服务器每秒写多少块的统计信息
  • 5.衡量(或评估)复制备份到其他地方需要多久。换言之,需要在复制起见保持LVM快照打开多长时间。

假设评估出有一半的写会导致往快照的写时复制空间的写操作,并且服务器支持10MB/s的写入。如果需要一个小时(3600s)将快照复制到另外一个服务器上,那么将需要1/2 * 10MB * 3600 即18GB的快照空间。考虑到容错,还要增加一些额外的空间。有时候当快照打开时,很容易计算会有多少数据发生改变。让我们看个例子。BoardReader论坛搜索引擎每隔存储节点有1TB的InnoDB表。但是,我们知道最大的开销时加载心数据。每天新增近10GB的数据,因此50GB的快照空间应该完全足够。然而这样来评估不总是正确的。假设在某个时间点,有一个长时间运行的依次修改每个分片的ALTER TABLE操作,它会修改超过50GB的数据;在这个时间点,就不能做备份的操作。为了避免这样的问题,可以稍后再创建快照,因为创建快照后会导致一个负载的高峰。

备份误区2:"快照就是备份"

一个快照,不论是LVM快照、ZFS快照,还是SAN快照,都不是实际的备份,因为它不包含数据的完整副本。正因为快照是写时复制的,所以它只包含实际数据和快照发生的时间点的数据之间的差异数据。如果一个没有被修改的块在备份副本时被损坏,那就没有该块的正常副本可以用来恢复,并且备份副本时每隔快照看到的都是相同的损坏的块。可以使用快照来"冻结"备份时的数据,但不要把快照当作一个备份

快照的其他用途和替代方案

快照有更多的其他用途,而不仅仅用于备份。例如,之前提到,在一个有潜在危险的动作之前生成一个"检查点"会有帮助。有些系统允许将快照提升为原文件系统,这使得回滚到生成快照的时间点的数据非常简单。文件系统快照不是取得数据瞬间副本的唯一方法。另一个选择是RAID分裂;举个例子,如果有一个三磁盘的软RAID镜像,就可以从该RAID组中移出来一个磁盘单独加载。这样做没有写时复制的代价,并且需要时将此类"快照"提升为主副本的操作也很简单。不错,如果要将磁盘加回到RAID集合,就必须重新进行同步,当然,天下没有免费的午餐。

从备份中恢复

如何恢复数据取决于是怎么备份的。可能需要以下部分或全部步骤。

  • 1.停止MySQL服务器
  • 2.记录服务器的配置和文件权限
  • 3.将数据从备份中移到MySQL数据目录
  • 4.改变配置
  • 5.改变文件权限
  • 6.以限制访问模式重启服务器,等待完成启动
  • 7.载入逻辑备份文件
  • 8.检查和重放二进制日志
  • 9.检测已经还原的数据
  • 10.以完全权限重启服务器

如果有机会使用文件的当前版本,就不要用备份中的文件来代替。例如,如果备份包含二进制日志,并且需要重放这些日志来做基于时间点的恢复,那么不要把当前二进制日志用备份中的老的副本替代。如果有需要,可以将其重命名或移动到其他地方。

在恢复过程中,保证MySQL除了恢复进程外不接受其他访问,这一点往往比较重要。我们喜欢以--skip-networking和--socket=/tmp/mysql_recover.sock选项来启动MySQL.以确保它对于已经存在的应用不可访问,直到我们检测完并重新提供服务。这对于按块加载的逻辑备份的恢复来说尤其重要

恢复物理备份

恢复物理备份往往非常直接------换言之,没有太多的选项。这可能是好事,也可能是坏事,具体取决于恢复的需求。一般过程是简单地复制文件到正确位置。是否需要关闭MySQL取决于存储引擎。MyISAM的文件一般相互独立,即使服务器正在运行,简单地复制每个表的.frm .MYI和.MYD文件也可以正常操作。一旦有任何对此表的查询,或者其他会导致服务器访问此表的操作(例如,执行SHOW TABLES),MySQL都会立刻找到这些表。如果在复制这些文件时表是打开的,可能会有麻烦,因为此操作要么删除或重命名该表,要么使用LOCK TABLES和FLUSH TABLES来关闭它。InnoDB的情况有所不同。如果用传统的InnoDB的步骤来还原,即所有表都存储在单个表空间,就必须关闭MySQL,复制或移动文件到正确位置上,然后重启。同样也需要InnoDB的事务日志文件与表空间文件匹配。如果文件不匹配------例如,替换了表空间文件但没有替换事务日志文件------InnoDB将会拒绝启动。这也是将日志和数据文件一起备份非常关键的一个原因。入股哦使用InnoDB file-per-table特性(innodb_file_per_table),InnoDB会将每隔表的数据和索引存储于一个.ibd文件中,这就像MyISAM的.MYI和.MYD文件合在一起。可以在服务器运行时通过复制这些文件来备份和还原单个表,但这并不像MyISAM中那样简单。这些文件并不完全独立于InnoDB。每个.ibd文件都有一些内部的信息,保存着它与主(共享)表空间之前的关系。在还原这样的文件时,需要让InnoDB先"导入"这个文件。这个过程有许多的西安至,如果有需要可以阅读MySQL手册 中关于每个表使用独立表空间中的部分。最大的限制是只能在当初备份的服务器上还原单个表。用这种配置来备份和还原多个表不是不可能,但可能比想象得要更棘手。

所有这些复杂度意味着还原物理备份会非常乏味,并且容易出错。一个好的值得倡导的规则是,恢复过程越难越复杂,也就需要逻辑备份的保护。为了防止一些无法意料的情况或者某些无法使用物理备份的场景,准备好逻辑备份总是值得推荐的。

还原物理备份后启动MySQL

在启动正在恢复的MySQL服务器之前,还有些步骤要做,首先,最重要且最容易忘记的事情,是在启动MySQL服务器之前检查服务器的配置,确保恢复的文件有正确的归属和权限。这些属性必须完全正确,否则MySQL可能无法启动。这些属性因系统的不同而不同,因此要仔细检查是否和之前做的记录温和。一般都需要mysql用户和组拥有这些文件和目录,并且只有这个用户和组拥有可读/写权限。建议观察MySQL启动时的错误日志。在UNIX类系统上,可以如下观察文件。

bash 复制代码
tail -f /var/log/mysql/mysql.err

注意错误日志的准确位置会有所不同。一旦开始监测文件,就额可以启动MySQL服务器并监测错误。如果一切进展顺利,MySQL启动后就有一个恢复好的数据库服务器了。观察错误日志对于新的MySQL版本更为重要。老版本在InnoDB有错时不会启动,但新版本不管怎样都会启动,而只是让InnoDB失效。即使服务器看起来启动没有任何问题,也应该对每隔数据库运行SHOW TABLE STATUS来再次检测错误日志

相关推荐
路有瑶台2 分钟前
MySQL数据库学习(持续更新ing)
数据库·学习·mysql
y25085 分钟前
《Object类》
java·开发语言
曙曙学编程6 分钟前
初级数据结构——树
android·java·数据结构
BestandW1shEs12 分钟前
彻底理解消息队列的作用及如何选择
java·kafka·rabbitmq·rocketmq
爱吃烤鸡翅的酸菜鱼14 分钟前
Java算法OJ(8)随机选择算法
java·数据结构·算法·排序算法
数字扫地僧17 分钟前
WebLogic 版本升级的注意事项与流程
数据库
码蜂窝编程官方18 分钟前
【含开题报告+文档+PPT+源码】基于SpringBoot+Vue的虎鲸旅游攻略网的设计与实现
java·vue.js·spring boot·后端·spring·旅游
软件技术员25 分钟前
Let‘s Encrypt SSL证书:acmessl.cn申请免费3个月证书
服务器·网络协议·ssl
lwprain27 分钟前
常用docker应用部署,wordpress、mysql、tomcat、nginx、redis
mysql·docker·tomcat
Viktor_Ye34 分钟前
高效集成易快报与金蝶应付单的方案
java·前端·数据库