校园云网站建设,房产备案信息查询系统官网,建设一个小说网站,wordpress程序员主题本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作)#xff0c;由 李兆龙 确认#xff0c;转载请注明版权。 文章目录 引言解决方案FAST FINE-GRAINED PITRLog FilterInter-Record Dependency ResolutionL…本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作)由 李兆龙 确认转载请注明版权。 文章目录 引言解决方案FAST FINE-GRAINED PITRLog FilterInter-Record Dependency ResolutionLog Merger FAST IMPORT OF REMOTE TABLES 总结 引言
由组内大佬爽哥推荐的论文sigmod2024的《TimeCloth: Fast Point-in-Time Database Recovery in The Cloud》阐述了一种在恢复表所在实例中基于PITR Point-in-Time的快速恢复方案。 先不讨论论文内容但从这个功能来看存在哪些问题和哪些优化点。
PITR一般我们也称之为流水备份其基本思路非常清晰
定期对数据库做全量冷备并记录冷备的最后一个LSN。一周三份两周五份一个月七份等冷备策略值得一提的是冷备是对每个分片去做的所以全局来看不能做到备份到某个时间点保存数据的WAL写删修改元数据操作每条WAL记录LSN和混合时间时钟冷备和流水备份上传对象存储恢复时指定实例先导入恢复时间前的一个冷备然后再恢复冷备中每个分片最后一个LSN到指定时间的LSN
事实上这个过程有这么几个优化点
恢复的表不是用户的表用户要通过Join从新恢复的表去修正原始表其实我认为有办法做到用户无感知直接恢复源表数据针对表级别数据恢复用户误操作单分片中可能存在不同Collection的数据Collection级别的恢复会扫描无用的数据可以在流水备份文件中添加摘要信息扫描的时候可以规避掉部分不需要的数据针对于实例级别的数据恢复灰色错误导致数据损坏。之前遇到一例在写入存储引擎前内存跳变导致写坏一个字节存储引擎的CRC已经算错了最后是用户发现的错误这种错误不做全局CRC是无法避免的两副本硬盘损坏目前的导入过程是分片并发的但是每个分片内部是重放全量的WAL这个过程显然基于不同的数据模型有更快的恢复方案比如合并部分修改结果只保留最终结果并行导入单分片中没有依赖关系的数据项单分片也可以做到并发
好了回到论文的内容。
计算机工程领域提出问题其实在很多情况下比其解决的过程更为重要我们来看看本篇文章抽象出来的问题是什么。
论文提到 1w 个数据库实例中就有大约 700 次由用户发起的恢复。在这种由用户触发的恢复中客户有两个基本需求
希望将受影响的表回滚到某个历史时间点的一致状态保持原始数据库实例正常运行以满足写入查询
在这个过程中观察到客户经常对恢复的表进行频繁读取如 SELECT 和 JOIN以纠正原始表数据。在服务受到严重影响或纠正过程耗时过长的情况下客户会优先考虑服务可用性完全切换到已恢复的表 RENAME。因此论文确定了云中高效用户触发恢复的两个理想目标
Recovered data in situ恢复后的后续用户操作通常涉及对恢复表的频繁读写。如果恢复的表位于当前实例之外的其他地方则所有表访问都会因跨实例或跨节点通信而产生额外开销。因此恢复表应位于同一数据库实例下以实现良好的查询性能。Lower recovery time objective (RTO)在恢复期间原始表和数据库实例都是实时的因为可能会有新的事务到达。因此较高的 RTO 可能会导致用户执行的恢复后数据校正任务量增加从而提高操作复杂性。所以较低的 RTO 可以大大减少和简化恢复后的用户工作量。
所以可以看到论文其实就是要在恢复表所在实例比传统方案更快速的恢复数据。
解决方案 TimeCloth的解决方案分为两个方面
在恢复实例外快速细粒度恢复数据基于lazy loading的快速导入
FAST FINE-GRAINED PITR
Log Filter 使用 Dictionary 将表名和数据库字典化为较短的字符日志索引中的每个 entry 对应于原始事务日志中的一条日志。包含四项
数据库名对应字典值表名对应字典值日志中的位置时间戳
在恢复过程中基于摘要可以快速识别相关日志记录。当然一般整个WAL文件还是要从对象存储拉下来的一般这是一个对象。
Inter-Record Dependency Resolution
介绍了一种检测依赖关系的轻量级算法可以识别出不同主键之间的依赖关系判断哪些数据可以并行恢复。
总体思路不难有兴趣的可以看看原文。
Log Merger
对于每一批不冲突的日志事件可以通过合并主键相同的日志事件来进一步加快日志重放速度。原因是恢复方案只关注最终状态因此只要不违反记录间的依赖关系我们就可以安全地跳过中间状态合并对同一行的操作。
基本规则如下图所示
FAST IMPORT OF REMOTE TABLES 基本思路认为物理导入速度太慢在完全导入实例前用户无法使用恢复表所以使用 Lazy Loading。
步骤如下
在一台远程主机上基于上一节提到的快速恢复方案恢复一个数据库实例待恢复实例中创建一个 New Table file此时用户可以认为恢复任务完成但是实际数据还是在远程创建一个临时表使用FUSE文件系统接口对上层数据库保持透明拦截用户对于 New Table file的读取先从本地检索是否存在如果不存在则读取远程实例并实时填充临时表后台预取远程实例的页面一旦复制了全部的页面则用临时表替换New Table file远程读取表交换对用户来说的都是透明的
总结
在不同的数据模型下PITR拥有不同的目标在这个基础上有不同的预期从而诞生不同的解决方案
话说回来都是锦上添花不过这也是软实力的体现要是团队都快养不起了自然都是扑杀在前线业务的功能和性能上只有运营稳定营收稳定且愿意投入才能有这样的收获。
不过基于hook的方式真的是很多小创新的高发地域以下提到的东西我都至少见过一篇论文或者一篇专利23333
用户函数的hook文件系统的hook用户态系统调用的hookebpf的函数级别hook…
