重庆哪里有做网站的公司,武夷山市网站建设,免费ppt模板下载有哪些,wordpress 微信接口优质博文#xff1a;IT-BLOG-CN 一、为什么要备份
【1】容灾恢复#xff1a;硬件故障、不经意的 Bug 导致数据损坏#xff0c;或者服务器及其数据由于某些原因不可获取或无法使用等#xff08;例如#xff1a;机房大楼烧毁#xff0c;恶意的黑客攻击或 Mysql 的 Bug 等IT-BLOG-CN 一、为什么要备份
【1】容灾恢复硬件故障、不经意的 Bug 导致数据损坏或者服务器及其数据由于某些原因不可获取或无法使用等例如机房大楼烧毁恶意的黑客攻击或 Mysql 的 Bug 等。 【2】人们改变想法很多人经常会在删除某些数据后又想恢复这些数据。 【3】审计有时需要知道数据或 Schema 在过去的某个时间点的状态和数据或发现了应用的一个 Bug想知道在此之前发生了什么等等。 【4】测试定期使用生产数据来更新测试服务器备份是为了恢复这样也可以验证备份的数据是否完整是否能够正常还原等。如果备份的方案非常简单只需要将备份文件还原到测试服务器上即可。 规划备份和恢复策略时有两个重要的需求恢复点目标RPO定义了可以容忍丢失多少数据恢复时间目标RTO定义了需要等待多久将数据恢复。 二、在线备份还是离线备份
如果可以关闭 MySQL 做备份是最简单安全的也是获取一致性最好的方法而且损坏和不一致的风险最小。根本不用关心 InnoDB 缓冲池中的脏页或其他缓存。也不需要担心数据在尝试备份的过程中被修改并且因服务器不对应用提供访问因此会更快的完成备份。
但在高负载和高数据量下关闭和重启 MySQL 可能要花很长一段时间即使最小化停顿时间服务器停机的代价也会很昂贵。因此需要在线备份。即便如此由于一致性的需要对服务器进行在线备份仍然会有明显的服务中断。MyISAM 在线备份的一个最大问题是使用 FLUSH TABLES WITH READ LOCK关闭所有打开的表并使用全局读锁锁定所有数据库的所有表不会刷新脏块 操作这会导致 MySQL 关闭并锁住所有的表将 MyISAM 的数据文件刷新到磁盘上并且刷新查询缓存。该操作需要非常长的时间具体需要多久不可预估。因为如果一个会话中使用表锁LOCK TABLES tbl_name lock_type语句对某表加了表锁在该表锁未释放前那么另外一个会话如果执行 FLUSH TABLES WITH READ LOCK 也会被堵塞。除非锁被释放否则不能在服务器上更改任何数据。 FLUSH TABLES WITH READ LOCK 不像关闭服务器代价那么高因为大部分缓存仍然在内存中并且服务器一直是“预热”状态但是它也有非常大的破坏性。避免使用 FLUSH TABLES WITH READ LOCK 的最好办法是只使用 InnoDB 表。
【在规划备份时有一些与性能相关的因素需要考虑】 ■ 锁时间需要持有锁多长时间例如在备份期间持有的全局 FLUSH TABLES WITH READ LOCK ■ 备份时间复制备份到目的地需要多久。 ■ 备份负载在复制备份到目的地时对服务器性能的影响是多少 ■ 恢复时间把备份镜像从存储位置复制到 MySQL 服务器重放二进制日志等需要多久 最大的权衡是备份时间与备份负载。可以牺牲其一以增强另外一个。例如可以降低服务器性能来提高备份的优先级。 三、逻辑备份还是物理备份
逻辑备份也叫“导出”和直接复制原始文件的物理备份。逻辑备份将数据包含在一种 MySQL 能够解析的格式中要么是 SQL要么是以某个符号分隔的文本。原始文件是指存在硬盘上的文件。
【1】逻辑备份优点如下 ■ 逻辑备份可以用编辑器或像 grep 和 sed 之类的命令查看和操作的普通文件。当需要恢复数据或只想查看数据但不恢复时这都非常有帮组。 ■ 恢复非常简单。可以通过管道把他们输入到 mysql或者使用 mysqlimport。 ■ 通过网络来备份和恢复相当于在与 MySQL 主机不同的另外一台机器上操作。 ■ 可以在类似 Amazon RDS关系型数据库服务 这种不能访问底层文件系统的系统中使用。 ■ 非常灵活因为 mysqldump大部分人都喜欢的工具可以接受许多选项例如可以用 WHERE 子句来限制需要备份的数据。 ■ 与存储引擎无关。因为是从 MySQL 服务器中提取数据而生成所以消除了底层数据存储的不同。因此可以从 InnoDB 表中备份然后只需要极小的工作量就可以还原到 MYISAM 表中。而原始数据却不能这么做。 ■ 有助于避免数据损坏。如果磁盘驱动器有故障需要复制原始文件时将得到一个错误或部分损坏的备份。如果 MySQL 在内存中的数据还没有损坏可以得到一个可以信赖的逻辑备份。
【逻辑备份的缺点如下】 ■ 必须由数据库服务器完成生成逻辑备份工作因此要使用更多的 CPU 周期。 ■ 无法保证导出后再还原出来的一定时同样的数据。浮点表示问题、软件 Bug 等都会导致问题尽管非常少见。 ■ 从逻辑备份中还原需要 MySQL 加载和解释语句转化为存储格式并重建索引所有这一切都会很慢。 最大的缺点是从 MySQL 中导出数据和通过 SQL 语句将其加载回去的开销。如果使用逻辑备份测试恢复需要的时间将非常重要。Percona Server 中包含的 mysqldump 在使用 InnoDB 表时能起到帮组作用因为它会对输出格式化以便在重新加载时利用 InnoDB 的快速建索引的优点。我们测试显示这样做可以减少 2/3 甚至更多的还原时间。索引越多好处越明显。 【2】物理备份优点如下 ■ 基于文件的物理备份只需要将需要的文件复制目标地址即可完成备份。不需要其他额外的工作来生成原始文件。 ■ 物理备份的恢复可能更简单取决于存储引擎。对于 MyISAM 只需要简单的复制文件到目的地即可。对于 InnoDB 则需要停止数据库服务可能还要采取其他一些步骤。 ■ InnoDB 和 MyISAM 的物理备份非常容易跨平台、操作系统和 MySQL 版本。 ■ 从物理备份中恢复会更快因为不需要执行任何 SQL 和构建索引。如果有很大的 InnoDB 表无法完全缓存再内存中则物理备份的恢复要快非常多只是要快一个数量级。事实上逻辑备份最可怕的地方就是不确定的还原时间。
【物理备份的缺点如下】 ■ InnoDB 的原始文件通常比相应的逻辑备份要大的多。InnoDB 的表空间往往包含很多未使用的空间。还有很多空间被用来做存储以外的用途插入缓冲回滚段等。 ■ 物理备份不总是可以跨平台、操作系统及 MySQL 版本。文件名大小写敏感和浮点格式是可能会遇到的麻烦。很可能因浮点格式不同而不能移动文件到另一个系统。
物理备份简单高效但也容易出错。尽管如此对于长期保留的备份还是很适合的。但尽量不要完全依赖物理备份。至少每隔一段时间还是需要做一次逻辑备份。建议混合使用物理和逻辑两种方式来做备份先使用物理复制以此数据启动 MySQL 服务器实例并运行 mysqlcheck。然后周期性地使用 mysqldump 执行逻辑备份。这样做可以获得两种方法的优点不会使生产服务器在导出时过度负担。如果能够利用文件系统的快照也可以生成一个快照将该快照复制到另一个服务器上并释放然后测试原始文件再执行逻辑备份。
备份文件一定要经过数据恢复测试特别是物理备份。不要自认为数据备份是正常的这样容易酿成大错。对 InnoDB 来说这意味着需要启动一个 MySQL 实例执行 InnoDB 恢复操作然后执行 CHECK TABLES。也可以跳过这一操作仅对文件运行 innochecksum是一个用于校验 innodb 表空间文件完整性的工具是一个官方自带的工具但不建议这样做。
四、增量备份和差异备份
当数据量很庞大时一个常见的策略是做定期的增量或差异备份。差异备份是对自上次全量备份后所有改变的部分而做的备份而增量备份则是从任意类型的上次备份后所有修改做的备份。 ::: tip 例如周日做一个全备份在周一对周日以来所有的改变做一个差异备份。在周二就有两个选择备份自周日以来所有的改变差异或只备份自从周一备份后所有的改变增量 ::: 两者都是部分备份能够减少服务器开销不一定例如Percona XtraBackup 和 MySQL Enterprise Backup仍会扫描服务器上的所有数据块因而并不会节约太多时间的开销、备份时间以及备份空间。 ■ 使用 Percona XtraBackup 和 MySQL Enterprise Backup 等软件中的增量备份特性。 ■ 备份二进制日志。可以在每次备份后使用 FLUSH LOGS 来开始一个新的二进制日志这样就只需要备份新的二进制日志。 ■ 不要备份没有改变的表。MyISAM 引擎会记录每个表最后修改时间。可以通过查看磁盘上的文件或运行 SHOW TABLE STATUS 来看这个时间。如果使用 InnoDB 可以利用触发器记录修改时间到一个表中。 ■ 不要备份没有改变的行。如果一个表只是做插入可以增加一列时间戳然后只备份自上次备份后插入的行。 ■ 备份所有数据然后发送到一个有去重特性的目的地例如 ZFS 文件管理程序。
增量备份的缺点 增加恢复复杂性额外的风险以及更长的恢复时间。如果可以全备考虑到简便性尽量经常做全备。建议至少一周一次周内通过增量的方式进行备份。
五、备份什么
最简单的策略是只备份数据和定义表但这是一个最低的要求。在生产环境中恢复数据库一般需要更多的工作例如 【1】非显著数据 不要忘记那些容易被忽略的数据例如二进制日志和 InnoDB 事务日志等。 【2】代码 MySQL 服务器可以存储许多代码例如触发器和存储过程。如果备份了 MySQL数据库大部分这类代码也就备份了但此时如果还原单个业务数据库会比较麻烦。 【3】复制配置 如果恢复一个设计复制关系的服务器应该备份所有与复制相关的文件二进制日志、中继日志、日志索引文件和.info 文件。至少应该包含 SHOW MASTER STATUS 和 SHOW SLAVE STATUS 的输出。执行 FLUSH LOGS 也非常有好处可以让 MySQL 从一个新的二进制日志开始。从日志文件的开头做基于故障时间点的恢复要比从中间更容易。 【4】服务器配置 如果需要从灾难中恢复这时需要在新数据中心构建服务器如果此时备份中包含服务器配置会免去很多工作。 【5】选定的操作系统文件 对于服务器配置来说备份中对生产服务器至关重要的任务外部配置都十分重要。在 UNIX 服务器上这可能包括 cron 任务实现 linux 定时任务、用户和组的配置、管理脚本以及 sudo是 linux 系统管理指令是允许系统管理员让普通用户执行一些或者全部的 root 命令的一个工具 规则。
六、存储引擎和一致性 MySQL 对存储引擎的选择会导致备份明显更复杂。如何对给定的存储引擎后得到一致的备份。实际上有两类一致性需要考虑数据一致性和文件一致性。 【1】数据一致性 当备份时应该考虑是否需要数据在指定时间点一致。例如淘宝中的发货单和付款之间的一致性。付款时如果不考虑其发货单或反过来都会导致麻烦。 如果做在线备份可能需要所有相关表的一致性备份。InnoDB 的多版本控制功能可以帮助我们。开始一个事务转储存储一组相关的表然后提交事务。再要在服务器上使用 REPEATABLE READ 事务隔离级别并且没有任何 DDL就一定会有完美的一致性以及基于时间点的快照数据且在备份过程中不会阻塞任何后续工作。如果不是事务型存储引擎则只能在备份时用LOCK TABLES 来锁住所有要一起备份的表备份完后在释放锁。 也可以用 mysqldump 来获得 InnoDB 表的一致性逻辑备份采用 --single-transaction 选项。但可能会导致一个很长的事务在某些负载下会导致开销大到不可接受。
【2】文件一致性 所有备份的文件相互之间应该一致包括每个文件的内部一致性也非常重要。如果是在不同的时间复制相关文件他们彼此可能也不一致。MyISAM 的 .MYD 和 .MYI 文件就是个栗子。InnoDB 检测到不一致或损坏会记录错误日志直到让服务器崩溃。 对于非事务型存储引擎 MyISAM需要锁表并刷新表。这意味着要么用 LOCK TABLES 和 FLUSH TABLES 结合的方法以使服务器将内存中的变更刷新到磁盘上要么使用 FLUSH TABLES WITH READ LOCK。一但刷新完成就可以安全地复制 MyISAM 的原始文件。 对于事务型存储引擎 InnoDB确保文件的一致性比较困难。即使使用 FLUSH TABLES WITH READ LOCKInnoDB 依旧在后台运行插入缓存、日志和写线程继续将变更合并到日志和表空间文件中。这些线程设计上是异步的这也是InnoDB 取得更高并发性的原因与 LOCK TABLES 无关。因此不仅需要确保每个文件内部是一致的还需要同时复制同一个时间点的日志和表空间。如果在备份时有其他线程在修改文件或备份表空间与日志文件时间点不同会在恢复后再次因系统损坏而告终。可以通过如下几个方法规避这个问题 ■ 等待直到 InnoDB 清除线程和插入缓冲合并线程完成。可以观察 SHOW INNODB STATUS 的输出当没有脏缓存或挂起的写时就可以复制文件。尽管如此这种方法可能需要很长一段时间因为 InnoDB 的后台线程涉及太多的干扰而不太安全。不推荐使用。 ■ 在一个类似 LVMLogical Volume Manager逻辑卷管理的系统中获取数据和日志文件的快照必须让数据和日志文件在快照中是相互一致单独取它们的快照是没有意义的。 ■ 方式一个 STOP 信号给 MySQL做备份然后在发送一个 CONT 信号来再次唤醒 MySQL。看起来像是一个很少推荐方式但如果另一种方法是在备份过程中需要关闭服务器则这种方法值得考虑。至少这种技术不需要重启服务器后预热。 在复制数据到其他地方后就可以释放锁以使 MySQL 服务器再次正常运行。同时也可以从备库中备份这样的好处是可以不干扰主库避免在主库上增加额外的负载。
