高性能MySQL之【第十五章 备份与恢复】学习记录
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了高性能MySQL之【第十五章 备份与恢复】学习记录,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含11690字,纯文字阅读大概需要17分钟。
内容图文
我们不打算包括的话题: 安全(访问备份,恢复数据的权限,文件是否需要加密) 备份存储在哪里,包括他们应该离源数据多远,以及如何将数据从源头移动到目的地 保留策略、审计、法律要求,以及相应的条款 存储解决方案和介质,压缩,以及增量备份 存储的格式 对备份的监控和报告 存储层内置备份功能,或者其他专用设备,例如预制式文件服务器 还原意味着从备份文件中获取数据,可以加载这些文件到MySQL里,也可以将这些文件放置到MySQL期望的路径中。恢复一般意味着当某些异常发生后对一个系统或者其部分的拯救,包括从备份中还原数据,以及使服务器完恢复功能的所有必要操作,例如重启MySQL、改变配置和预热服务器的缓存等。 存储引擎的奔溃恢复要求数据和日志文件一致。要确保数据文件中只包含已经提交的事务所做的修改,恢复操作会将日志中还没有应用到数据文件的食物重新执行。
为什么要备份 灾难恢复:硬件故障、一个不经意的Bug导致数据损坏,或者服务器及其数据由于某些原因不可获取或无法使用等。 人们改变想法:删除某些数据和又想要恢复这些数据 审计: 数据快照,过去某个时间点的数据状态 测试:取数据到测试环境做测试使用
定义恢复需求 不仅仅要有备份系统,还要有一个强大的恢复系统。 规划恢复策略时,有两个重要的需求可以帮助思考:恢复点目标(PRO)和恢复时间目标(RTO)。他们定义了可以容忍丢失多少数据,以及需要等待多久将数据恢复。 在定义RPO和RTO是,先尝试回答下面几类问题:
- 在不导致严重后果的情况下,可以容忍丢失多少数据?需要故障恢复,还是可以接受自从上次日常备份后所有的工作全部丢失?是否有法律法规的要求?
- 恢复需要在多长时间内完成?哪种类型的宕机是可以接受的?哪些影响(例如,部分服务不可用)是应用和用户可以接受的?当那些场景发生时,又该如何持续服务?
- 需要恢复什么?常见的需求是恢复整个服务器,单个数据库,单个表,或仅仅是特定的事务或语句
设计MySQL备份方案 细节之前的建议:
- 在生产实践中,大数据库来说,物理备份是必须的:逻辑备份太慢并且受资源限制,逻辑备份中恢复需要很长时间。基于快照的备份,例如Perconna XtraBackup和MySQL Enterprise Backup是最好的选择。
- 保留多个备份集
- 定期从逻辑备份(或者物理备份)中抽取数据进行恢复测试
- 保存二进制日志以用于基于故障时间点的恢复。expire_logs_days应该设置的足够长.至少大于全量备份的间隔时间。
- 完不借助备份工具本身来监控备份和备份的过程。需要另外验证备份是否正常。
- 通过演练整个恢复过程来测试备份和恢复。测算恢复所需要的资源(CPU、磁盘空间、实际时间,以及网络带宽等)
- 对安全性要仔细考虑。
在线备份还是离线备份 规划备份是,有一些与性能相关的因素需要考虑:
- 锁时间:需要持有锁多长时间,例如备份期间持有的全局FLUSH TABLES WITH READ LOCK?
- 备份时间: 复制备份到目的地需要多久
- 备份负载:在复制备份到目的地时对服务器性能的影响有多少
- 恢复时间:把备份镜像从存储位置复制到MySQL服务器,重放二进制日志需要多久?
逻辑备份还是物理备份 逻辑备份(也叫"导出")和直接复制原始文件的物理备份。 逻辑备份有如下的优点:
- 逻辑备份可以使用编辑器或grep和sed之类的命令查看和操作的普通文件。
- 恢复非常简单。直接导入。
- 可以通过网络来备份和恢复
- 可以在类似Amazon RDS这样不能访问底层文件系统中使用
- 非常灵活,因为mysqldump大部分人喜欢的工具.
- 与存储引擎无关
- 有助于避免数据损坏,物理备份可能磁盘损坏
- 必须由数据库服务器完成生成逻辑备份的工作,因此要使用更多的cpu周期
- 逻辑备份在某些场景下笔数据库文件本身更大
- 无法保证到处后再还原出俩的一定是同样的数据
- 从逻辑备份中还原需要MySQL加载和解释语句,转化为存储格式,并重建索引,所有这一切会很慢
- 基于文件的物理备份,只需要将需要的文件复制到其他地方即可完成备份。不需要其他额外的工作来生成原始文件
- 恢复更简单,取决于存储引擎。对于MyISAM复制到目的地即可。InnoDB需要停止数据库服务采取其他的步骤
- InnoDB和MyISAM的物理备份非常容易跨平台、操作系统和MySQL版本
- 从屋里备份中恢复会更快,因为不需要执行任何SQL或构建索引
- InnoDB的原始文件通常比相应的逻辑备份要大的多。InnoDB的表空间包含很多未使用的空间。还有很多空间被用来做存储数据意外的用途(插入缓冲、回滚段等)
- 物理备份不总是可以跨平台、操作系统以及MySQL版本。文件名大小写敏感和浮点格式是可能会遇到的麻烦。很可能因浮点格式不同而不能移动文件到另一个系统
备份什么 恢复的需求决定需要备份什么,最简单的测率是指备份数据和表定义 下面是MySQL备份需要考虑的几点:
- 非显著数据: 容易被忽略的数据,例如二进制日志和InnoDB事务日志
- 代码 : 触发器和存储过程
- 复制配置: 有复制关系的。二进制日志、中继日志、日志索引文件和info文件
- 服务器配置: 配置文件
- 选定的操作系统文件管理脚本等
- 使用Percona XtraBackup和MySQL Enterprise Backup中的增量备份特性
- 备份二进制日志。
- 不要备份没有改变的表。
- 不要备份没有改变的行
- 某些数据根本不需要备份
- 备份所有的数据,然后发送到一个有去重特性的目的地。
存储引擎和一致性 数据一致性:只要服务器上使用REPEATABLE READ事务隔离级别,并且没有任何DDL,就一定会有完美的一致性,以及基于时间点的数据快照,且在备份过程中不会阻塞任何后续的工作。 文件一致性:如果是MyISAM,可能是锁住并刷新表。 复制:从悲苦中备份最大的好处是可以不干扰主库,避免在主库上增加额外的负载。
管理和备份二进制日志 服务器的二进制日志是备份的最重要因素之一。 MySQL 5.6版本的mysqlbinlog有一个非常方便的特性,可以连接到服务器上来实时对二进制日志做镜像。 二进制日志格式: 使用mysqlbinlog工具查看二进制日志的内容。时间的日志和时间、原服务器的服务器ID,end_log_pos,下一个时间的偏移字节值、时间类型,元服务器上执行时间的线程ID,对于审计和执行CONNECTION_ID()函数很重要。 exec_time,在原服务器上时间产生的错误代码。 如果使用的是MySQL5.1中基于行的日志,事件将不再是SQL。而是可读性较差的由语句对表所做变更的”镜像“。 安全清理二进制日志:expire_log_days 变量来告诉MySQL定期清理日志。这个变量是MySQL 4.1才引入。之前都是rm mysql-bin.[0-9]*直接删除 在新版本中不要这样做,用rm删除日志会导致mysql-bin.index转台文件与磁盘上的文件不一致,有些语句,例如show master logs可能会受到影响而悄然失败,手动修改mysql-bin.index文件也不会修复这个问题 应该iyong雷利下面的cron命令: /usr/bin/mysql -e "PURGE MASTER LOGS BEFORE CURRENT_DATA - INTERVAL N DAY" expire_logs_days 设置在服务器启动或MySQL切换二进制日志时生效,因此,如果二进制日志从没有增长和切换,服务器不会清楚老条目。此设置是通过产看日志的修改时间而不是内容来决定哪个文件需要被清除的。
备份数据 逻辑备份: SQL导出和符号分隔文件 SQL导出:mysqldump不是生成sql逻辑备份的唯一工具。例如,也可以用mydumper或phpmyadmin工具来创建。 SQL逻辑备份缺点:
- schema和数据存储在一起
- 巨大的SQL语句
- 单个巨大的文件
- 逻辑备份的成本很高
- 只能备份到运行MySQL服务器的机器上的文件中
- 运行MySQL的系统用户必须有文件目录的写权限,因为是由MySQL服务器来执行文件的写入,而不是运行SQL命令的用户。
- 出于安全原因,不能覆盖已经存在的文件,不管文件权限如何
从备份中恢复 如何恢复数据取决于是怎么备份的。可能需要一下部分或全部步骤:
- 停止MySQL服务器
- 记录服务器的配置和文件权限
- 将数据从备份中移到MySQL数据目录
- 改变配置
- 改变文件权限
- 以限制访问模式重启服务器,等待完成启动
- 载入逻辑备份文件
- 检查和重放二进制日志
- 检测已经还原的数据
- 以完全权限重启服务器
InnoDB崩溃恢复 根据日志文件将事务应用到数据文件,将未提交的变更从数据文件中回滚 InnoDB损坏的原因:硬件有关的(例如电力问题或内存损坏而导致损坏页的写入)。错误配置的硬件是更多的问题之源。 常见的错误配置包括打开了不包含电池备份单元的RAID卡的回写缓存,或打开iale硬盘驱动器本身的诙谐缓存。 严重的损坏会使InnoDB或MySQL奔溃,而不是那么严重的损坏则可能只是由于日志文件未真正同步到磁盘而丢掉了某些事务。
如何恢复损坏的InnoDB数据 InnoDB损坏有三种主要类型:
- 二级索引损坏: 一般可以用optimize table 来修复损坏的二级索引;也可以使用select into outfile,删除和重建表,然后 LOAD DATA INFILE的方法。这些都是通过构建一个新表受影响的索引,来修复损坏的索引数据。
- 聚簇索引损坏:也许只能使用 innodb_force_recovery选项导出表.笔者就曾遇到过不止一次,都是因为意外断电导致,或者存储挂掉。
- 损坏系统结构:包括InnoDB事务日志、表空间的撤销日志(undo log)区域和数据字典。这种损坏可能需要整个数据库的导出和还原,因为InnoDB内部绝大部分的工作都可能受到影响。
备份和恢复工具
- MySQL Enterprise Backup : 之前叫做InnoDB Hot Backup 或ibbackup。备份不需要停止MySQL,也不需要设置锁或中断正常的数据库活动。支持类似压缩备份、增量备份和到其他服务器的流备份特性。官方的备份工具
- Percona XtraBackup: 开源并且免费,支持类似流、增量、压缩和多线程(并行)备份操作。工作方式是在后台线程不断追踪InnoDB日志文件尾部,然后复制InnoDB数据文件。这是个轻量级的侵入过程,依靠特别的检测机制确保复制的数据是一致的。 还有XtraBack Manager项目:http://code.google.com/p/xtrabackup-manager
- mylvmbackup: http://lenz.homelinux.org/mylvmbackup 是一个perl脚本,通过LVM快照帮助MySQL自动备份。此工具首先获全局读锁,创建快照,释放锁。然后通过tar压缩数据并移除快照。它通过备份时的时间戳命名压缩包。
- Zmanda Recovery Manager: http://www.zmanda.com。配置、备份、验证、恢复、报告和调度,分免费和商业两种版本。
- mydumper: mysqldump的替代品。多线程备份和还原: http://www.mydumper.org
- mysqldump: 与mysql一起发行的程序。最常见。
总结: 每个人都知道需要备份,但并不是每个人都意识到需要的是可恢复的备份。我们需要明确并记录恢复点目标和恢复时间目标,并且在选择备份系统时将其作为参考。 ----内容摘自《高性能MySQL 第三版》
高性能MySQL之【第十五章 备份与恢复】学习记录
标签:www 灾难恢复 文件系统 优点 在线 不能启动 一致性 逻辑备份 无法
本文系统来源:http://www.cnblogs.com/topicjie/p/7354418.html
内容总结
以上是互联网集市为您收集整理的高性能MySQL之【第十五章 备份与恢复】学习记录全部内容,希望文章能够帮你解决高性能MySQL之【第十五章 备份与恢复】学习记录所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。