首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >雪花故障转移-复制机制

问雪花故障转移-复制机制
EN

Stack Overflow用户
提问于 2019-11-18 19:53:01
回答 1查看 165关注 0票数 0

我一直在深入研究关于如何在雪花中管理故障转移/复制用例的文档。这里 --基本上,故障转移策略是基于数据库在同一组织位于不同区域的两个不同帐户之间的复制特性。

从复制的角度来看,我可以配置这两个DB,并在每10分钟刷新一次主DB的任务中设置复制,并以这种方式尽量保持次要DB的更新。不过,在发生意外事件时,我的二级数据库一旦被提升为主数据库,将有基于上次完成的更新的数据版本,这意味着我可能会部分丢失在中断之前执行的整个新数据/转换。这让我思考:

  • 有什么方法可以将丢失的数据尽可能地减少到雪花中的故障转移设计中,而不只是将复制任务安排在1分钟?
  • 在已经解决了中断并需要将主DB带回的场景中,如何管理无法复制到辅助DB但与我可以生成的新数据合并的部分数据,而我是在二级DB中作为产品运行的?

非常感谢

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2019-11-19 00:03:00

( a)为了减少数据丢失,如您所指出的,一种策略是频繁地安排复制操作。另一种是有能力在故障转移后重放最近的ETL作业。为此,您需要确保源数据可用,并且在灾难发生后可以恢复ETL进程。ETL可以以幂等的方式重放。

( b)不支持合并变更/解决冲突。雪花的数据库复制遵循单一主模型。刷新辅助数据库时,会用主数据库的当前状态覆盖它。建议通过重播(a)中建议的ETL来恢复主故障转移后丢失的数据。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/58921944

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档