内需拜候分化DB数据时

稍微场景下,供给隔绝不一致的DB,相互DB之间不可能相互访谈,但实在的作业场景又供给从A
DB访谈B DB的场所,那时如何是好?笔者感到有如下常规的三种方案:

1.双方提供RESET
API,必要走访不相同DB数据时,可以透过API来得到钦命数量;

这种方案优点是隔开分离性、定制性强,统意气风发出入口,只可以通过点名的API访谈钦定的数额;缺点与亮点是周旋的,也正是定制性太强,导致每一遍业务产生改换,要求拜望分裂数额的时候,须要双方改动API的入参或返参,减弱了支付功能;何况不或许选用表JOIN,那样在少数意况下也会导致查询数据成效变低。最近主流的方案都以提出利用API方案

2.利用DB的联合本领(如:SQL
SEPAJEROVE中华V的订阅复制、MYSQL的主从复制脚本等)来兑现差异DB的多少同步分享

这种方案优点是足以在同一个DB访谈到另贰个DB中所需表的多少,能够直接JOIN,把本来的跨DB访谈形成了同一个DB的事体;劣势是信任DB的一路技艺,并且两台DB服务器的互联网必需互通,未有完全的隔开,且再三同步过来的表不一致敬直接更换,或需修改还是须求跨DB修改或使用方案1的API来进展更改。

3.通进程序代码达成四个DB的数额同步(增、删、改、查),如:能够定期轮询源DB的A表,然后拿走更换的笔录(平时是:增、删、改的记录),再通进程序代码把源DB的A表的转移记录批量更新(要是新增加、则是插入,若是修改,则是翻新,若是删除,则是去除)到指标DB的A表中。

这种方案的优点是:能够依附真实意况灵活定制风流罗曼蒂克块的表数据,不局限于某一张表或某三个DB,能够确定保障不相同DB间同步表的数额意气风发致性,让本来跨DB操作表形成了同三个DB的事情,并且能够增、删、改、查,功用不受限;劣势是随俗浮沉太强,程序代码实现可信赖的跨DB的实时同步逻辑的落实复杂度较高,对于开采人士的渴求较高,假设写的大器晚成块儿逻辑无法确认保障实时、可相信、高可用,那对于事情来说是磨难性的。

上述三种方案,第1、2方案基本都以定制化的平时方案,笔者(梦在路上,)后天要享受的是第3种方案:跨DB增量(增、改)同步两张表的多少,注意是增量同步,个中删除那些本人从不表明,原因是黄金年代旦DB表中著录是概略删除(即:真实的DELETE),那就不能轻巧的通进度序代码获取到删除的笔录,除非在DB中步向DELETE触发器记录删除记录的主键到有的时候表或开启改换追踪(CHANGE_TRACKING)或DB日志剖析,故本文讲的是不给表、DB扩展额外担任的处境实时增量同步,至于删的联手这么些自身感到最棒是逻辑标志删除(过期最终清理【真实删除】),而毫无物理删除。

至于程序代码完毕跨DB同步表数据方案,以前已有总结过,详见:https://www.cnblogs.com/zuowj/p/6264711.html 
—》4.采纳BCP(sqlbulkcopy)来兑现多个不等数据库之间展开数据差别传输(即:数据同步)

 在此以前的稿子同步首假若根据TranFlag标志字段
或触发器来促成联机,这种方法必需对表数据的增、删、改逻辑都有供付与专门的学问,也即是增、改必须改造TranFlag=0,删必需记录表删除临进表中,那样技术贯彻同台逻辑,而明日是在这里个合伙基础上(BCP),不给表、DB增添额外肩负的景况实时增量同步,对数据源的插入、退换未有供给。

代码如下:(以下同步适用于SQL SEEnclaveVE奥迪Q3 差异DB的表增量同步)

            try
            {
                SqlConnection obConnSrc = new SqlConnection(connLMSStr);
                SqlConnection obConnDest = new SqlConnection(mconnCCSStr);

                string lastTamp = ClsDatabase.gGetFieldValue(obConnSrc, "update TS_SyncUptime set UPTime=GETDATE() OUTPUT (deleted.LastUPstamp) as oldtamp FROM TS_CCSUptime WHERE TableName=N'tableNameA'", "oldtamp");


                string selectSql = @"SELECT id,aaa,bbb,ccc,ddd,eee,fff  
                                  FROM tableNameA WHERE 其它同步过滤查询条件 AND CONVERT(bigint,sys_tamp)>{0}";

                selectSql = string.Format(selectSql, lastTamp);

                master.TransferBulkCopy(selectSql, obConnSrc,
                                "tableNameA", obConnDest,
                                 (stable) =>
                                 {
                                     var colMaps = new Dictionary<string, string>();
                                     foreach (DataColumn col in stable.Columns)
                                     {
                                         colMaps.Add(col.ColumnName, col.ColumnName);
                                     }
                                     return colMaps;
                                 },
                                 (tempTableName, stable, destConn, srcConn) =>
                                 {
                                     StringBuilder saveSqlBuilder = new StringBuilder("begin tran" + Environment.NewLine);

                                     string IUSql = master.BuildInsertOrUpdateToDestTableSql("tableNameA", tempTableName, new[] { "id" }, stable.ExtendedProperties[master.MapDestColNames_String], 2);
                                     saveSqlBuilder.Append(IUSql);

                                     saveSqlBuilder.AppendLine("commit");

                                     ClsDatabase.gExecCommand(destConn, saveSqlBuilder.ToString());


                                     ClsDatabase.gExecCommand(srcConn, "update TS_SyncUptime set UPTime=GETDATE(),LastUPstamp=CONVERT(bigint,sys_tamp) FROM TS_SyncUptime WHERE TableName=N'tableNameA'");

                                     return false;
                                 });


            }
            catch (Exception ex)
            {
                writeLog(ex);//记错误日志
            }

 上述联合代码逻辑很简短,能够参照他事他说加以考察在此以前的稿子,这里最重借使验证多少个首要点:

1.TS_SyncUptime表用于记录与治本同步职分的新闻,紧要含有如下多少个字段:

 图片 1

TableName:要一同的表名,UPTime每三遍联合的触发时间点(可改换),sys_tamp行改造时间戳(不可改动),LastUPstamp行最终有效变量时间戳(能够革新)

2.具体关键同步逻辑如下:

2.1先更新TS_SyncUptime表,以便触发sys_tamp行改造时间戳爆发改动(相当于记录同步触发时间点),在退换的同一时候抽出LastUPstamp行最终有效改观时间戳(也就是上次共同的接触时间点)

2.2施用LastUPstamp作为过滤条件,查询>源DB的源表中时间戳字段,那样就足以查询出自上一次联合触发点到当下时刻待同步的笔录(增、改)

2.3利作BCP实行同步(详见以前作品证实)

2.4保障联合成功后,再一次更新TS_SyncUptime表,并把sys_tamp行更换时间戳(当前接触时间点)更新到LastUPstamp行最终有效变量时间戳(记住这一次触发时间点)

如上手续就可以实现可相信的朝气蓬勃道,有人大概有疑点,那样就能够达成可信赖同步啊?作者那边解释一下:

3.1联手触发时记录当前接触时间点,并收获上一遍的接触时间点(这里的上二次接触时间点是指上一回先导筹算一齐的笔录时间点,确定保证从上一遍查询到一日千里块到位之间的命宫点都不外乎内部,防止漏数据)

3.2万一起步的任豆蔻梢头环节退步(只要最后未有风姿洒脱块成功),那么再一次同台触发时均取到的是同 八个时间点(LastUPstamp),并且即便重复履行同步逻辑,也不会现身重复(因为存在则更新不设有则插入原则),保险幂等,那样就保证了共同的可信赖性

3.3自然倘诺有个别时间点的数量或有些DB有标题,导致直接同不不成事,大概会冒出一贯联手不过去的动静,这种情景能够增添预先警示+人工干预,这一个是概率的事情。

好了,假诺大家有哪些好的视角或提出招待下方留言批评,谢谢!

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*
*
Website