我们有一个具有本地数据库的Windows应用程序。我们的客户很少要求他们所有位置的集中报告。我们提出的解决方案是在客户端总部通过静态IP建立一个中央数据库,并使用WCF服务同步所有数据。
由于中央服务器可能无法始终可用,我需要一个简单的解决方案,从每个脱机数据库中了解所有与中央数据库不同步的记录。这样后端的定时服务会将所有剩余数据复制到中央数据库。
一个选项在所有表中都有一个布尔列,如IsSynched,表示它是否同步。但是这需要在所有引用的过程和代码中进行大量的代码更改。
任何替代解决方案?
答案 0 :(得分:2)
我建议布尔IsSynced在同步方面非常弱。如果办公室离线的时间更长,那么你肯定很难掌握一切。
如果添加列VersionNumber,您将知道,VersionNumber低于实际VersionNumber的每一行都需要更新。
更复杂的方法可能是将LastUpdated TimeStamp列添加到每个表中,这可能会节省一些流量,因为VersionNumber可能会增加并且可能包含行更新,但可能不会!而LastUpdated来自我看到的是特定于行的,创建了获取(=更新)的机会仅比最新记录更新的(=行)在您的(=中央)整个数据库。事实上,这可能就像花花公子一样。
答案 1 :(得分:0)
听起来你需要实现'多主'或'多源'复制。多主复制是一个非常棘手的实现自己的主张。
我是按照以下方式完成的: 您将需要在每个表上执行触发器(插入,删除,更新),以跟踪对每个行所做的所有更改到“更改跟踪”表(您必须确保触发器保留在任何数据库/表更新中)。更改表将需要全局唯一的密钥(通常是唯一的“站点代码”和每行的唯一ID的组合),更改类型,UTC更改日期/时间,表名称,行ID和每行CRUD的复制状态(即发送日期)。您将更改跟踪表与WCF服务一起使用,以将客户端与服务器表同步。您还需要确保它们在启动复制系统之前包含相同的数据(可能通过在开始时将站点db上载到中央数据库中)。
如果您可以将交换机切换到另一个数据库,则最新版本的MariaDB免费提供开箱即用的此功能(https://mariadb.com/kb/en/multi-source-replication/)。这种在数据库级别的功能将使这项任务变得相当容易。
或者,根据您的预算和DBMS,可能有一些现成的复制产品可以帮助您?
答案 2 :(得分:0)
需要考虑的一些事项:
我最近继承的解决方案通过以下方式处理:
SELECT * FROM central.table WHERE last_update > @lastLocalUpdate;
之类的内容。任何结果都会在本地数据库中插入/更新。SELECT * FROM local.table WHERE is_sent = 0;
。在中央DB中插入/更新任何结果,然后将is_sent设置为1. 它有点健谈,但它最终有效。就我而言,本地设备经常失去连接性,因此这种粒度可行。
我的愿望清单上的重点是完全彻底检查这个机制并实现一个消息队列。
编辑:如果您坚持不想对现有代码库进行任何更改,则可以在SQL级别实现last_updated / is_sent更新并进行同步。服务作为一个完全独立的项目。 <隐形更新'不会成为最干净的解决方案,但嘿 - 挑选你的战斗。