目录一、为什么需要增量备份二、增量备份是怎么工作的2.1 全量备份时记录的“起点”2.2 增量备份从“上一结束点”到“当前”2.3 恢复时“全量 到所选增量为止”的组合恢复三、如何通过 Web 界面使用增量备份3.1 创建增量备份衔接全量3.2 恢复“全量 增量”四、使用增量备份的注意事项五、与全量备份分享的衔接小结《 MySQL备份工具分享一 可视化备份与还原》《 MySQL备份工具分享二 增量备份》《 MySQL备份工具分享三 定时全量备份》《 MySQL备份工具分享四 定时增量备份》在上一篇分享中我们介绍了这款 MySQL 数据库备份工具的全量备份能力智能大表拆分、结构与数据分离、表过滤、Web 可视化界面等。本篇在此基础上专门介绍本次新增的增量备份功能如何在全量备份之后形成连续的增量链如何恢复“全量 若干增量”到指定时间点的数据状态以及使用时的注意事项。一、为什么需要增量备份全量备份适合作为基线快照但在数据量较大或备份频率较高时每次都做全量会带来时间长大库全量备份耗时明显占空间多次全量会占用大量磁盘恢复粒度粗只能恢复到某次全量完成的时间点无法精确到“全量之后的某个时刻”。增量备份则是在某次全量之后只记录“从上一备份结束到当前”的数据变更基于 MySQL binlog从而缩短单次备份时间只抓取变更片段节省存储增量文件通常远小于全量提高恢复灵活性可以选“全量 到某个增量为止”得到更接近目标时间点的数据。本工具在保留原有全量能力的前提下新增了基于 binlog 的增量备份与组合恢复与全量形成一条清晰的备份链。二、增量备份是怎么工作的2.1 全量备份时记录的“起点”本工具的全量备份是按表进行的每张表在自己的mysqldump --single-transaction一致性快照中完成备份。因此每张表完成快照的时刻可能略有不同。为了后续增量能正确衔接全量备份会在每张表备份前记录当时 MySQL 的 binlog 位点文件名 位置并写入该次全量备份目录下的meta/tables-binlog.json。这样我们就有了“这次全量备份对应的 binlog 起点”的精确信息为后续增量提供了基准。2.2 增量备份从“上一结束点”到“当前”第一次增量从该全量备份的meta/tables-binlog.json中选取最新的位点作为起点调用mysqlbinlog从该起点拉取到当前生成一份changes.sql并记录本次的起止位点到meta/binlog_from.json、meta/binlog_to.json。后续增量从该全量下已有增量的最后一个的meta/binlog_to.json读取结束位点作为本次增量的起点再拉取到当前形成连续链全量 → 增量1 → 增量2 → 增量3 → …每次增量都会在对应全量备份目录下创建子目录例如全量备份目录/incremental/数据库名_inc_YYYYMMDD_HHMMSS/其内包含changes.sql本段 binlog 解析出的 SQL 变更已按数据库过滤meta/binlog_from.json起始位点与时间meta/binlog_to.json结束位点与时间。增量备份的表过滤条件仅备份哪些表、排除哪些表与所属全量备份完全一致由全量目录下的meta/backup-options.json决定不可在增量时修改以保证与全量数据范围一致。change.sql文件信息2.3 恢复时“全量 到所选增量为止”的组合恢复当用户选择某次全量 某个增量节点进行恢复时工具会先使用该全量备份执行一次全量恢复与仅全量恢复的逻辑一致再在该全量目录下按时间顺序找到**从第一个增量到用户所选增量含**的所有增量目录依次执行每个增量目录中的changes.sql将期间的 DML 变更回放进去。这样最终得到的数据状态 全量完成时的数据 直到所选增量结束时的所有变更实现“恢复到该增量对应时间点”的效果。由于 MySQL binlog 的语义限制当前版本的增量恢复仅支持将数据还原到与备份时相同的数据库名例如备份的是mall恢复目标也必须是mall。在 Web 界面中若填写的目标数据库名与增量所属库名不一致会禁用“执行还原”按钮并给出提示避免误用。三、如何通过 Web 界面使用增量备份3.1 创建增量备份衔接全量先完成至少一次全量备份参见上一篇分享的“创建全量备份”步骤。在“新建备份”区域将备份类型切换为“增量备份”。在“本次增量对应的全量备份目录”下拉框中选择要基于哪次全量做增量列表来自“备份列表”中的全量备份。确认数据库主机、端口、用户名、密码、数据库名与全量一致增量会沿用全量的表过滤条件界面会展示为只读。点击“执行备份”。若是该全量下的第一次增量起点自动取该全量的meta/tables-binlog.json中的最新位点。若该全量下已有增量起点自动取最后一个增量的结束位点无需手动填 binlog 文件与位置。在“备份列表”中对应全量备份那一行点击“查看增量”可看到该全量下的所有增量记录及起止时间、位点信息。3.2 恢复“全量 增量”在“数据还原”区域选择全量备份目录必选。如需要恢复到“全量 某次增量”的状态在“选择增量备份目录可选”中选择目标增量节点不选则仅恢复全量。目标数据库名必须与备份时的数据库名一致例如都为mall否则“执行还原”按钮会置灰并提示。填写目标主机、端口、用户名、密码后可先“测试连接”再点击“执行还原”。工具会先执行全量恢复再按顺序回放从第一个到所选增量含的所有changes.sql全程日志写入该全量目录下的restore.log便于排查。四、使用增量备份的注意事项MySQL 需开启 binlog增量依赖 MySQL 的 binlog且推荐使用 ROW 格式。备份账号需具备读取 binlog 的权限如REPLICATION SLAVE或等价权限。binlog 保留时间要覆盖需求若 binlog 已被清理或过期对应时间段的增量将无法再生成或回放。请根据备份策略合理设置binlog_expire_logs_seconds或等效参数。增量与全量一一对应每条增量链必须从某一次全量开始且表过滤条件与全量一致。删除全量备份时其下的增量目录会一并失效需在界面上或文档中注意说明。增量恢复仅支持“同名库”当前实现下增量还原只能还原到与备份时相同的数据库名以保证 binlog 回放语义正确。若需还原到其他库名可先还原到同名库再通过库级迁移或复制到目标库。全量 增量的恢复顺序恢复时务必使用本工具提供的“全量 至某增量”的组合恢复流程不要手动乱序执行changes.sql否则可能导致数据不一致。五、与全量备份分享的衔接小结上一篇介绍了全量备份大表拆分、结构/数据分离、表过滤、Web 操作、日志与清理等。本篇在此基础上说明了增量备份全量如何记录 binlog 起点增量如何从“上一结束点”连续生成如何在 Web 上创建增量、查看增量列表以及如何执行“全量 到某增量为止”的组合恢复使用时的前置条件与注意点。两者结合后可以形成“定期全量 高频增量”的备份策略全量作为基线增量节省时间和空间恢复时按需选择“全量”或“全量 若干增量”在保证数据安全的前提下提高备份与恢复的效率和灵活性。
MySQL 备份工具分享（二）：增量备份功能
目录一、为什么需要增量备份二、增量备份是怎么工作的2.1 全量备份时记录的“起点”2.2 增量备份从“上一结束点”到“当前”2.3 恢复时“全量 到所选增量为止”的组合恢复三、如何通过 Web 界面使用增量备份3.1 创建增量备份衔接全量3.2 恢复“全量 增量”四、使用增量备份的注意事项五、与全量备份分享的衔接小结《 MySQL备份工具分享一 可视化备份与还原》《 MySQL备份工具分享二 增量备份》《 MySQL备份工具分享三 定时全量备份》《 MySQL备份工具分享四 定时增量备份》在上一篇分享中我们介绍了这款 MySQL 数据库备份工具的全量备份能力智能大表拆分、结构与数据分离、表过滤、Web 可视化界面等。本篇在此基础上专门介绍本次新增的增量备份功能如何在全量备份之后形成连续的增量链如何恢复“全量 若干增量”到指定时间点的数据状态以及使用时的注意事项。一、为什么需要增量备份全量备份适合作为基线快照但在数据量较大或备份频率较高时每次都做全量会带来时间长大库全量备份耗时明显占空间多次全量会占用大量磁盘恢复粒度粗只能恢复到某次全量完成的时间点无法精确到“全量之后的某个时刻”。增量备份则是在某次全量之后只记录“从上一备份结束到当前”的数据变更基于 MySQL binlog从而缩短单次备份时间只抓取变更片段节省存储增量文件通常远小于全量提高恢复灵活性可以选“全量 到某个增量为止”得到更接近目标时间点的数据。本工具在保留原有全量能力的前提下新增了基于 binlog 的增量备份与组合恢复与全量形成一条清晰的备份链。二、增量备份是怎么工作的2.1 全量备份时记录的“起点”本工具的全量备份是按表进行的每张表在自己的mysqldump --single-transaction一致性快照中完成备份。因此每张表完成快照的时刻可能略有不同。为了后续增量能正确衔接全量备份会在每张表备份前记录当时 MySQL 的 binlog 位点文件名 位置并写入该次全量备份目录下的meta/tables-binlog.json。这样我们就有了“这次全量备份对应的 binlog 起点”的精确信息为后续增量提供了基准。2.2 增量备份从“上一结束点”到“当前”第一次增量从该全量备份的meta/tables-binlog.json中选取最新的位点作为起点调用mysqlbinlog从该起点拉取到当前生成一份changes.sql并记录本次的起止位点到meta/binlog_from.json、meta/binlog_to.json。后续增量从该全量下已有增量的最后一个的meta/binlog_to.json读取结束位点作为本次增量的起点再拉取到当前形成连续链全量 → 增量1 → 增量2 → 增量3 → …每次增量都会在对应全量备份目录下创建子目录例如全量备份目录/incremental/数据库名_inc_YYYYMMDD_HHMMSS/其内包含changes.sql本段 binlog 解析出的 SQL 变更已按数据库过滤meta/binlog_from.json起始位点与时间meta/binlog_to.json结束位点与时间。增量备份的表过滤条件仅备份哪些表、排除哪些表与所属全量备份完全一致由全量目录下的meta/backup-options.json决定不可在增量时修改以保证与全量数据范围一致。change.sql文件信息2.3 恢复时“全量 到所选增量为止”的组合恢复当用户选择某次全量 某个增量节点进行恢复时工具会先使用该全量备份执行一次全量恢复与仅全量恢复的逻辑一致再在该全量目录下按时间顺序找到**从第一个增量到用户所选增量含**的所有增量目录依次执行每个增量目录中的changes.sql将期间的 DML 变更回放进去。这样最终得到的数据状态 全量完成时的数据 直到所选增量结束时的所有变更实现“恢复到该增量对应时间点”的效果。由于 MySQL binlog 的语义限制当前版本的增量恢复仅支持将数据还原到与备份时相同的数据库名例如备份的是mall恢复目标也必须是mall。在 Web 界面中若填写的目标数据库名与增量所属库名不一致会禁用“执行还原”按钮并给出提示避免误用。三、如何通过 Web 界面使用增量备份3.1 创建增量备份衔接全量先完成至少一次全量备份参见上一篇分享的“创建全量备份”步骤。在“新建备份”区域将备份类型切换为“增量备份”。在“本次增量对应的全量备份目录”下拉框中选择要基于哪次全量做增量列表来自“备份列表”中的全量备份。确认数据库主机、端口、用户名、密码、数据库名与全量一致增量会沿用全量的表过滤条件界面会展示为只读。点击“执行备份”。若是该全量下的第一次增量起点自动取该全量的meta/tables-binlog.json中的最新位点。若该全量下已有增量起点自动取最后一个增量的结束位点无需手动填 binlog 文件与位置。在“备份列表”中对应全量备份那一行点击“查看增量”可看到该全量下的所有增量记录及起止时间、位点信息。3.2 恢复“全量 增量”在“数据还原”区域选择全量备份目录必选。如需要恢复到“全量 某次增量”的状态在“选择增量备份目录可选”中选择目标增量节点不选则仅恢复全量。目标数据库名必须与备份时的数据库名一致例如都为mall否则“执行还原”按钮会置灰并提示。填写目标主机、端口、用户名、密码后可先“测试连接”再点击“执行还原”。工具会先执行全量恢复再按顺序回放从第一个到所选增量含的所有changes.sql全程日志写入该全量目录下的restore.log便于排查。四、使用增量备份的注意事项MySQL 需开启 binlog增量依赖 MySQL 的 binlog且推荐使用 ROW 格式。备份账号需具备读取 binlog 的权限如REPLICATION SLAVE或等价权限。binlog 保留时间要覆盖需求若 binlog 已被清理或过期对应时间段的增量将无法再生成或回放。请根据备份策略合理设置binlog_expire_logs_seconds或等效参数。增量与全量一一对应每条增量链必须从某一次全量开始且表过滤条件与全量一致。删除全量备份时其下的增量目录会一并失效需在界面上或文档中注意说明。增量恢复仅支持“同名库”当前实现下增量还原只能还原到与备份时相同的数据库名以保证 binlog 回放语义正确。若需还原到其他库名可先还原到同名库再通过库级迁移或复制到目标库。全量 增量的恢复顺序恢复时务必使用本工具提供的“全量 至某增量”的组合恢复流程不要手动乱序执行changes.sql否则可能导致数据不一致。五、与全量备份分享的衔接小结上一篇介绍了全量备份大表拆分、结构/数据分离、表过滤、Web 操作、日志与清理等。本篇在此基础上说明了增量备份全量如何记录 binlog 起点增量如何从“上一结束点”连续生成如何在 Web 上创建增量、查看增量列表以及如何执行“全量 到某增量为止”的组合恢复使用时的前置条件与注意点。两者结合后可以形成“定期全量 高频增量”的备份策略全量作为基线增量节省时间和空间恢复时按需选择“全量”或“全量 若干增量”在保证数据安全的前提下提高备份与恢复的效率和灵活性。
