读高性能MySQL(第4版)笔记15_备份与恢复(下)
1.读高性能MySQL(第4版)笔记01_MySQL架构(上)2.读高性能MySQL(第4版)笔记02_MySQL架构(下)3.读高性能MySQL(第4版)笔记03_监控4.读高性能MySQL(第4版)笔记04_操作系统和硬件优化5.读高性能MySQL(第4版)笔记05_优化服务器设置6.读高性能MySQL(第4版)笔记06_优化数据类型(上)7.读高性能MySQL(第4版)笔记07_优化数据类型(下)8.读高性能MySQL(第4版)笔记08_创建高性能索引(上)9.读高性能MySQL(第4版)笔记09_创建高性能索引(下)10.读高性能MySQL(第4版)笔记10_查询性能优化(上)11.读高性能MySQL(第4版)笔记11_查询性能优化(中)12.读高性能MySQL(第4版)笔记12_查询性能优化(下)13.读高性能MySQL(第4版)笔记13_备份与恢复(上)14.读高性能MySQL(第4版)笔记14_备份与恢复(中)
15.读高性能MySQL(第4版)笔记15_备份与恢复(下)
16.读高性能MySQL(第4版)笔记16_复制(上)17.读高性能MySQL(第4版)笔记17_复制(下)18.读高性能MySQL(第4版)笔记18_扩展MySQL19.读高性能MySQL(第4版)笔记19_云端和合规性20.读高性能MySQL(第4版)笔记20_Performance Schema和其他21.读高性能MySQL(第4版)笔记21_读后总结与感想兼导读1. 二进制日志
1.1. 服务器的二进制日志是需要备份的最重要元素之一
1.2. 对于基于时间点的恢复是必需的,并且通常比数据要小,所以更容易被进行频繁的备份
1.3. 如果有某个时间点的数据备份和所有从那时以后的二进制日志,就可以重放从上次全备份以来的二进制日志并“向前回滚”所有的变更
1.4. 如果你不能承受丢失超过30分钟数据的代价,至少要每30分钟就备份一次
1.5. 需要制定日志的过期策略以防止磁盘被二进制日志写满
1.6. 日志增长的大小取决于工作负载和日志格式(基于行的日志会产生更大的日志记录)
1.7. 保留日志对于设置复制、分析服务器负载、审计和从上次全备份中按时间点进行恢复,都很有帮助
1.8. 使用binlog_expire_logs_seconds变量来通知MySQL定期清理日志,而不应该手动地去删除这些文件
1.9. MySQL服务器通过查看修改时间而不是内容来决定要清除哪些文件
2. 工具
2.1. MySQL Enterprise Backup
2.1.1. MySQL官方的备份工具
2.2. Percona XtraBackup
2.2.1. 开源并且免费的
2.2.2. 支持类似流、增量、压缩和多线程(并行)备份操作
2.2.3. 降低在高负载系统上进行备份的影响
2.2.4. 当使用Percona XtraBackup进行备份时,它会记录日志序列号(LSN),并使用该序列号对备份文件执行崩溃恢复
2.3. mydumper
2.3.1. 一个多线程(并发)的MySQL备份和恢复工具集
2.4. mysqldump
3. 备份数据
3.1. 应该最大化地利用网络、磁盘和CPU的能力以尽可能快地完成备份
3.2. 主要的问题
3.2.1. 将库表结构和数据存储在一起
3.2.2. 巨大的SQL语句
3.2.2.1. 服务器解析和执行SQL语句的工作量非常大,所以加载数据时会非常慢
3.2.3. 单个巨大的文件
3.2.4. 逻辑备份的成本很高
3.2.4.1. 在生产环境使用逻辑备份可能很难满足要求
3.2.4.2. 如果使用逻辑备份,强烈建议考虑使用mydumper,以避免单线程备份的一些问题,并实际测试使用该工具备份对数据库的影响
3.3. 文件系统快照
3.3.1. 一种非常好的在线备份方法
3.3.2. FreeBSD的文件系统、ZFS文件系统、GNU/Linux的逻辑卷管理(LVM)
3.3.3. 创建快照是减少必须持有锁的时间的一个简单方法;释放锁后,必须将文件复制到备份中
3.3.4. 使用文件系统快照,有些时候甚至无须任何锁定,就可以创建InnoDB的备份快照
3.3.5. 文件系统快照不是取得数据瞬间副本的唯一方法
3.3.5.1. 另外一个选择是RAID分裂
3.3.6. 快照不仅仅用于备份,还有很多其他用途
4. 恢复数据
4.1. 步骤
4.1.1. 停止MySQL服务器
4.1.2. 记录服务器的配置和文件权限
4.1.3. 将数据从备份中移到MySQL数据目录
4.1.4. 改变配置
4.1.5. 改变文件权限
4.1.6. 以限制访问模式重启服务器,等待其完成启动
4.1.7. 载入逻辑备份文件
4.1.8. 检查和重放二进制日志
4.1.9. 检测已经还原的数据
4.1.10. ⑩以完全权限重启服务器
4.2. 恢复逻辑备份
4.2.1. 如果恢复的是逻辑备份而不是裸文件备份,则与使用操作系统将文件简单地复制到适当位置的方式不同,需要使用MySQL服务器本身来将数据加载到表中
4.2.2. 一个值得倡导的规则是,恢复过程越难越复杂,也就越需要逻辑备份的保护
4.2.3. 应付某些无法使用裸文件备份的场景,准备好逻辑备份总是值得推荐的
4.3. 从快照中恢复
4.3.1. 恢复裸文件备份往往非常直接
4.3.2. 如果使用InnoDB的file-per-table特性(innodb_file_per_table),InnoDB会将每个表的数据和索引存储于一个.ibd文件中
4.3.3. 最大的限制是,只能在当初备份的服务器上还原单个表
合集:
读高性能MySQL(第4版)
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库