读书笔记--高性能MySQL--15备份与恢复
为什么要备份
- 灾难恢复
- 人们改变想法
- 审计
- 测试
定义恢复需求
只有世界上最好的备份系统是没用的，还需要一个强大的恢复系统。规划备份和恢复策略的两个重要需求：恢复点目标和恢复时间目标
恢复点目标(PRO)：灾难发生后，从IT系统宕机导致业务停顿到IT系统恢复至可以支持各部门运作、恢复运营的时间段。
恢复时间目标(RTO)：从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周的备份数据，也可以是上一次交易的实时数据。
在定义PRO和RTO时，考虑以下几个问题
- 在不导致严重后果情况下，可以容忍损失多少数据？
- 恢复需要在多长时间内完成？哪种类型的宕机是可以接受的？哪种影响是应用和用户可以接受的？当那些场景发生时，又改如何持续服务？
- 需要恢复什么？整个服务器、单个数据库、单个表或是特定的事务或语句？
设计MySQL备份方案
名词解释
SAN (Storage Area Network)和NAS (Network-Attached Storage)是两个外部文件存储设备加载到服务器的方法。不同的是访问存储的方式。访问SAN设备时通过块接口，服务器直接看到一块硬盘并且可以像硬盘一样使用， 但是NAS设备通过基于文件的协议来访问，例如NFS或SMB. SAN设备通常通过光纤通道协议(FCP) 或iSCSI连接到服务器,而NAS设备使用标准的网络连接。还有一些设备可以同时通过这两种方式访问，比如NetApp Filer 存储系统。
DRBD（Distributed Replicated Block Device，分布式复制块设备)是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。DRBD是镜像块设备，是按数据位镜像成一样的数据块。
在线备份还是离线备份
在规划备份时，需要考虑的性能因素
- 锁时间：需要持有锁多长时间，例如在备份期间持有的全局FLUSH TABLES WITH READ LOCK？
- 备份时间：复制备份到目的地需要多久？
- 备份负载：在复制备份到目的地时对服务器性能的影响有多少？
- 恢复时间：把备份镜像从存储位置复制到MySQL服务器，重放二进制日志，需要多久？
逻辑备份还是物理备份
逻辑备份
优点
- 可视化好
- 有助于避免数据损坏
- 与存储引擎无关
- 可通过网络备份和恢复
缺点
- 恢复时间长且不可控
- SQL语句巨大，SQL文件巨大
- 不能保证数据百分百还原。可能出现浮点表示问题，软件BUG等
物理备份
优点
- 恢复速度快
- 备份简单，复制粘贴即可完成备份
缺点
- 原始文件通常比相应的逻辑备份要大得多
建议
混合使用，先使用物理复制，以此数据启动MySQL服务器实例并运行mysqlcheck，然后周期性🉐️使用mysqldump执行逻辑备份。
备份什么
- 复制配置：备份与复制相关的文件，例如二进制日志、中继日志、日志索引文件和.info文件。
- 服务器配置
- 选定的操作系统文件
增量备份和差异备份
- 差异备份：对自上次全备份后所有改变的部分而做的备份
- 增量备份：从任意类型的上次备份后所有修改做的备份
存储引擎和一致性
需要考虑的两类一致性：数据一致性和文件一致性
数据一致性
对于InnoDB，直接开始事务，转储相关表，提交事务即可。只要使用RR事务隔离级别，并且没有任何DDL，就一定会有完美的一致性，以及基于时间点的数据快照，且在备份过程中不会阻塞任何后续的工作。
文件一致性
对于InnoDB，确保文件在磁盘上一致比MyISAM更加困难。即使使用FLUSH TABLES WITH READ LOCK，InnoDB依旧在后台运行：插入缓存、日志和写线程继续将变更合并到日志和表空间文件中。可通过以下方法规避
- 等待直到InnoDB的清除线程和插入缓冲合并线程完成。
- 在一个类似LVM的系统中获取数据和日志文件一致的快照，必须让数据和日志文件在快照时相互一致。
- 发送一个STOP信号给MySQL，做备份，然后再发送一个CONT信号来再次唤醒MySQL。适用于需要关闭服务器的场景，不需要再重启服务器后预热。
管理和备份二进制日志
服务器的二进制日志是备份的最重要因素之一。他们对于基于时间点的恢复是必须的，并且通常比数据要小，所以更容易进行频繁的备份。
mysql5.6版本的mysqlbinlog有一个非常方便的特性，可连接到服务器上来实时对二进制日志做镜像，比运行一个mysqld实例要简单和轻便。
安全地清除老的二进制日志
二进制日志保留多久，应考虑设置复制、分析服务器负载、审计和从上次全备按时间点进行恢复等因素。千万不要使用rm删除日志，会导致mysql-bin.index状态文件与磁盘文件不一致，应当使用expire_log_days变量告诉My SQL定期清理日志。
备份数据
生成逻辑备份
逻辑备份包含SQL导出和符分隔文件两种。
文件系统快照
一种非常好的在线备份方法。支持快照的文件系统和设备包括FreeBSD的文件系统、ZFS文件系统、GNU/Linux的逻辑卷管理(LVM)，以及许多的SAN系统和文件存储解决方案。
LVM使用写时复制的技术来创建快照——例如，对整个卷的某个瞬间的逻辑副本。
先决条件和配置
- 所有的InnoDB文件必须是在单个逻辑卷
- 如果需要备份表定义，MySQL数据目录必须在相同的逻辑卷中
- 必须在卷组中有足够的空闲空间来创建快照
用于在线备份的LVM快照
- FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;使用全局读锁将表刷到磁盘上，获取二进制日志位置；
- 获取LVM快照并立即释放该读锁。
- 加载快照并复制文件到备份位置。
规划LVM备份
LVM需要从原始卷中读取大部分数据，只有快照创建后修改过的数据从写时复制空间读取；因此，逻辑顺序读取快照数据也可能导致磁头来回移动。快照实际上会导致原始卷和快照都比正常的读/写性能要差——如果使用过多的写时复制空间，性能可能会差很多，最多可能会慢5倍。
为快照分配足够多的空间
从备份中恢复
恢复物理备份
前置要求
InnoDB的事务日志文件与表空间文件匹配
- 关闭MySQL
- 复制文件到正确位置
- 重启MySQL
- 观察MySQL启动错误日志。
tail -f /var/log/mysql/mysql.err
show table status;
还原逻辑备份
将一份大SQL拆分成可控大小的块来加载，逐个提交事务。
基于时间点的恢复
全备+二进制日志重放
其他恢复技术
延时备库复制
如果在备库执行问题语句之前发现问题，那么基于时间点的恢复就更快更容易了。
- 停止备库，执行START SLAVE UNTIL来重放事件直到执行问题语句。
- 执行SET GLOBAL SQL_SLAVE_SKIP_COUNTER=n，跳过问题语句。
- START SLAVE，备库执行剩余中继日志。
- 检查备库，无误提升为主库。
使用日志服务器进行恢复
举例：粗心的开发人员昨晚误删了表，现在想恢复此误操作；假定需要恢复的服务器叫做server1，在另一台叫做server2的服务器上恢复昨晚的备份。
- 设置server2为日志服务器来接收server1的二进制日志
- 改变server2的配置文件，增加replicate-do-table=${table}
- 重启server2，使用CHANGE MASTER TO来让它成为日志服务器的备库，配置它从昨晚的二进制日志坐标读取。
- 检测server2的SHOW SLAVE STATUS的输出，验证一切正常。
- 在server2上执行START SLAVE UNTIL来重放事件直到问题语句。
- 在server2上执行STOP SLAVE停止复制进程
- 将所需表从server2复制到server1
InnoDB崩溃恢复
InnoDB每次启动时都会检测数据和日志文件是否一致，若不一致则会根据日志文件将事务应用到数据文件，将未提交的变更从数据文件中回滚。
InnoDB损坏的原因
InnoDB非常健壮可靠，并且有许多内建安全检测来防止、检测和修复损坏的数据。但是，InnoDB并不能保护自己避免一切错误。InnoDB依赖于无缓存的I/O调用和fsync()调用，直到数据完全地写入到物理介质上才会返回。很多InnoDB损坏的原因都是与硬件有关的，常见的错误配置包括打开了不包含电池备份单元的RAID卡的回写缓存，或打开了硬盘驱动器本身的回写缓存。
如何恢复损坏的InnoDB数据
- 二级索引损坏：一般可以用OPTIMIZE TABLE来修复损坏的二级索引；也可以用SELEC T INTO OUTFILE，删除和重建表，然后LOAD DATA INFILE的方法。（本质都是构建一个新表重建受影响的索引，来恢复损坏的索引数据）
- 聚簇索引损坏：也许只能使用innodb_force_recovery选项来导出表
- 损坏系统结构：系统结构包括InnoDB事务日志、表空间的撤销日志区域和数据字典。可能需要做这个数据库的导出和还原。
备份和恢复工具
- MySQL Enterprise Backup：MySQL官方备份工具，不需要停止MySQL，也不需要设置锁或中断正常的数据库活动。
- Percona XtraBackup：与MySQL Enterprise Backup在很多方面类型，但是是开源免费的。还可以提供更多高级功能，支持类型流、增量、压缩和多线程备份操作。
- mylvmbackup：一个perl脚本，通过LVM快照帮助MySQL自动备份。此工具首先获取全局读锁，创建快照，释放锁，然后通过tar压缩数据并移除快照。
- Zmanda Recovery Manager(ZRM)：一个备份和恢复管理器，封装了自有的基于标准工具和技术，例如mysqldump、LVM快照和Percona XtraBackup等之上的功能，将许多冗长的备份和恢复工作进行了自动化。
- mysqldumper：用来替代mysqldump，多线程的备份和还原MySQL和Drizzle的工具集。
- mysqldump：与MySQL一起并发的程序，常见的逻辑备份工具。
5110
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
