快照复制发布者架构更改

发布于 2024-10-03 19:10:19 字数 472 浏览 1 评论 0原文

目前在我的项目中我有两个数据库,我们称它们为“Live”和“Reporting”。

我需要按照您的预期使用我的“实时”数据库,所有更改都在发生时存储等。我需要我的“报告”数据库全天保持静态(非易失性),除非进行复制。

目前,我的复制设置为每天凌晨 3 点工作,并复制所有表,这需要:

  • 每次“实时”模式更改(例如额外的表?)时进行大量手动工作以重新创建快照复制,必须在许多架构更改之前删除它(可能删除表,甚至备份/恢复数据库)。
  • 或者,我必须编写一个脚本来在每次更新/更改数据库后显式地重新创建发布者和订阅者。

由于我在发布到新服务器时的时间限制(以及手动步骤可能会引入错误的可能性......),我觉得必须有一种更简洁的方法来重新创建或以其他方式维护复制。理想情况下,我想要整个数据库(减去一些明确突出显示的表......)。目前来看,感觉还蛮‘乱’的。

有没有人遇到过类似的问题,或者有没有人有什么建议?

At present in my project I have two database, lets call them 'Live' and 'Reporting'.

I need my 'Live' database to be used as you would expect, all changes stored etc as they happen. I need my 'Reporting' database to remain static (non-volatile) all day, except when replication takes place.

At present, I have replication setup to work at 3am each day, and to copy over all tables, which requires either:

  • Lots of manual work each time the 'Live' schema changes (extra table for example?) to recreate my snapshot replication, which must be deleted prior to many of the schema changes (perhaps a table is removed, or even that the db is backed up/restored).
  • Or, that I have to write a sript to explicitly recreate the publisher and subscriber after each update/change to the database.

Due to my time constraints when releasing to the new server (and the likelihood that errors can be introduced with manual steps..) I feel like there must be a neater way to recreate or otherwise maintain the replication. Ideally, I want the entire database (minus a few explicitly highlighted tables...). At present, it just feels quite 'messy'.

Has anyone had a similar problem, or does anyone have any suggestions?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梦开始←不甜 2024-10-10 19:10:19

我使用 T4 模板解决了这个问题。

I solved this using T4 templates.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文