数据魔术师:如何在ClkLog中恢复丢失数据并实现数据更新

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
简介: ​在数字化的世界里,数据就是企业的血液,是推动业务发展的关键动力。想象一下,你正在运行你的业务,依赖ClkLog为你提供的数据,突然,由于网络波动或其他原因,定时脚本未能执行,页面上的数据缺失了。或者你刚刚优化了你的算法,但你需要重新计算以前的数据以便与新的算法保持一致。这种情况下,数据的完整性和稳定性就显得尤为重要,它们不仅影响业务的正常运行,而且直接关系到业务决策的准确性和及时性。

​在数字化的世界里,数据就是企业的血液,是推动业务发展的关键动力。想象一下,你正在运行你的业务,依赖ClkLog为你提供的数据,突然,由于网络波动或其他原因,定时脚本未能执行,页面上的数据缺失了。或者你刚刚优化了你的算法,但你需要重新计算以前的数据以便与新的算法保持一致。这种情况下,数据的完整性和稳定性就显得尤为重要,它们不仅影响业务的正常运行,而且直接关系到业务决策的准确性和及时性。

针对这类问题,我们在ClkLog中提供了强大的解决方案。

场景一:由于网络等其他原因导致定时脚本未执行产生的数据缺失
以visituri_summary_bydate表的数据缺失为示例,进行补录指定日期数据,

首先进入脚本(.sh文件)存放目录,编辑脚本文件

1.补充指定脚本指定日期的数据

bash visituri_summary_bydate.sh 1 2023-12-25

说明:该命令会补录2023.12.25日visituri_summary_bydate.sh脚本所产生的数据

2.补充指定脚本指定日期以来的数据

首先修改脚本中的起始时间

image.png
然后执行脚本:bash visituri_summary_bydate.sh 0

说明:该命令会补录脚本标注日期以来visituri_summary_bydate.sh脚本所产生的数据,此日期可以根据需求修改。

场景二:算法升级需要重新计算旧的数据
你可以按照以下步骤操作:

1.找到需要修改算法的脚本,visituri_summary_bydate.sh为示例
2.修改脚本中数据产生的规则保存
image.png
3.然后使用上述补录数据方式重新计算产生数据

​----

结束语.png

相关文章
|
存储 前端开发 数据库
状态持久化:在应用中保留数据和用户体验的关键
在现代应用程序开发中,状态持久化是一个至关重要的概念。它使应用程序能够在不同会话之间保留数据,确保用户在退出应用程序后再次打开时能够恢复到之前的状态。本博客将深入研究状态持久化的核心概念、方法和最佳实践,以提高用户体验并确保数据的安全性。
155 0
|
存储 设计模式 分布式计算
全量、增量、流水、拉链、快照、代理键、缓慢变化维...
全量、增量、流水、拉链、快照、代理键、缓慢变化维...
|
算法 Oracle 关系型数据库
【续】全量、增量、流水、拉链、快照、代理键、缓慢变化维
【续】全量、增量、流水、拉链、快照、代理键、缓慢变化维
|
3月前
|
存储 安全 数据挖掘
服务器数据恢复—异常断电导致EVA存储中RAID信息丢失的数据恢复案例
意外断电导致raid硬件损坏或者riad管理信息丢失等raid模块损坏而导致数据丢失的情况非常普遍。正常情况下,磁盘阵列一旦创建完成就不会再对管理模块中的信息进行更改,但是raid管理模块中的信息属于可修改信息,一次或多次的意外断电可能会导致这部分信息被篡改或丢失。断电次数过多甚至会导致raid卡上的元器损坏。
|
安全 关系型数据库 MySQL
为什么延迟复制适用于备库数据的紧急恢复?底层原理是什么?
为什么延迟复制适用于备库数据的紧急恢复?底层原理是什么?
118 0
|
存储 Kubernetes 测试技术
应用存储和持久化数据卷:存储快照与拓扑调查(一)|学习笔记
快速学习应用存储和持久化数据卷:存储快照与拓扑调查(一)
142 0
应用存储和持久化数据卷:存储快照与拓扑调查(一)|学习笔记
|
存储 Kubernetes 调度
应用存储和持久化数据卷:存储快照与拓扑调查(二)|学习笔记
快速学习应用存储和持久化数据卷:存储快照与拓扑调查(二)
应用存储和持久化数据卷:存储快照与拓扑调查(二)|学习笔记
|
存储 运维 算法
CPU静默数据错误:存储系统数据不丢不错的设计思考
对于数据存储系统来说,保障数据不丢不错是底线,也是数据存储系统最难的部分。据统计,丢失数据中心10天的企业,93%会在1年内破产。那么如果想要做到数据不丢不错,我们可以采取怎样的措施呢?
CPU静默数据错误:存储系统数据不丢不错的设计思考
|
存储 SQL Oracle
回到过去,找回遗失的珍宝 - TiDB 的历史读功能
数据作为业务的核心,关系着整个业务的生死,所以对于数据库来说,数据的安全性是放在首位的,从宏观角度来看,安全性不仅仅在于的数据库本身足够稳定不会主动的丢失数据,有的时候更是对业务本身甚至人为失误造成损失是否有足够且便捷的应对方案,例如在游戏行业中经常遇到的反作弊(作弊玩家回档)问题,对于金融业务的审计需求等等,如果在数据库层面上提供相关机制,会让业务开发的工作量和复杂度减少很多。 传统的方案会定期备份数据,几天一次,甚至一天一次,把数据全量备份。当意外发生的时候,可以用来还原。但是用备份数据还原,代价还是非常大的,所有备份时间点后的数据都会丢失,你绝对不希望走到这一步。另外全量备份带来的存储
323 0
|
SQL 关系型数据库 MySQL