none
异地数据库同步 RRS feed

  • 问题

  • 正在做一个数据中心的项目,想集中将位于不同城市(通过专线连接)的服务器上的数据库集中同步(延时同步)到数据中心,首先考虑了使用SQL 的复制服务进行测试,但是数据库中有一些表是没有主键的,这些表不被SQL 复制服务所支持(ERP的数据库,增加主键是不被允许的),

    各位有什么其他比较好的方案吗?

    谢谢


    Microsoft

    2012年10月9日 14:27

全部回复

  • Try ssis if don't require real time data sync.
    2012年10月9日 15:30
  • 如果表不大的话,可以考虑快照

    否则只能自己实现了,可以考虑使用更改数据跟踪或者Trigger来捕获数据变化

    2012年10月10日 0:58
  • Snapshot Replication应该不需要主键的,但是快照复制将数据以特定时刻的瞬时状态分发,而不监视对数据的更新。发生同步时,将生成完整的快照并将其发送到订阅服务器(全部数据,不只是更改的数据)。

    如果延迟时间允许的话可以考虑用SSIS同步表数据。

    2012年10月10日 1:27
  • 数据文件很大,每个数据库都有几十G,而且每天都数据变动比较多,因此通过快照或者SSIS,触发器等方式实现是不可能的任务,

    更改数据跟踪是企业版才有的功能吧,目前使用的都是标准版,更换所有的sql版本不太现实(而且实现这种变动同步太复杂,很难保证一致性)。

    非常感谢各位的回复,不知道是否还有其他可能性?比如DPM?不知道各位有没有其他解决方案,不局限于使用SQL实现


    Microsoft

    2012年10月10日 1:34
  • 关注一下


    给我写信: QQ我:点击这里给我发消息

    2012年10月10日 4:03
  • 数据文件很大,每个数据库都有几十G,而且每天都数据变动比较多,因此通过快照或者SSIS,触发器等方式实现是不可能的任务,

    更改数据跟踪是企业版才有的功能吧,目前使用的都是标准版,更换所有的sql版本不太现实(而且实现这种变动同步太复杂,很难保证一致性)。

    非常感谢各位的回复,不知道是否还有其他可能性?比如DPM?不知道各位有没有其他解决方案,不局限于使用SQL实现


    Microsoft

    表级别,不是数据库级别,因此你的评估应该是基于表的,而且,你应该基于表去评估增量变化的数据

    如果 触发器之类的增量模式无法实现的话,就算你为表加上主键,用复制去做,也无法做到,它们要传输的数据基本是相同的

    2012年10月10日 4:18
  • 数据文件很大,每个数据库都有几十G,而且每天都数据变动比较多,因此通过快照或者SSIS,触发器等方式实现是不可能的任务,

    更改数据跟踪是企业版才有的功能吧,目前使用的都是标准版,更换所有的sql版本不太现实(而且实现这种变动同步太复杂,很难保证一致性)。

    非常感谢各位的回复,不知道是否还有其他可能性?比如DPM?不知道各位有没有其他解决方案,不局限于使用SQL实现


    Microsoft

    表级别,不是数据库级别,因此你的评估应该是基于表的,而且,你应该基于表去评估增量变化的数据

    如果 触发器之类的增量模式无法实现的话,就算你为表加上主键,用复制去做,也无法做到,它们要传输的数据基本是相同的

    可能是我的表达有误,还是我的概念本身不清晰,数据库难道不包括表吗?

    我需要同步我的数据库到数据中心服务器上,那么表做为数据库的子集难道不应该包含在内吗?

    评估的要求是从A服务器上的数据库同步到B上的数据库应该是完全一致的,不仅仅是表,也包含触发器,存储过程,自定义函数。。。。。


    麻将

    2012年10月10日 5:29
  • 邹建的意思是你主需要复制你需要同步的表,而不需要整个数据库同步。 Replication可以只复制你需要同步的表(Article)而不需要将整个数据库的数据同步(除非你是需要的),这样的话可以减轻压力。

    另外你能容忍的同步延迟时间是多少?如果不及时的话为什么不能用SSIS或者TRIGGER?

    2012年10月10日 5:43
  • 邹建的意思是你主需要复制你需要同步的表,而不需要整个数据库同步。 Replication可以只复制你需要同步的表(Article)而不需要将整个数据库的数据同步(除非你是需要的),这样的话可以减轻压力。

    另外你能容忍的同步延迟时间是多少?如果不及时的话为什么不能用SSIS或者TRIGGER?

    首先我需要的是同步整个数据库,而不仅仅是表,也包含触发器,存储过程,自定义函数等等,也就是说我需要的是一个异地备份方案,所以仅仅是表是无法满足我的需要多,

    同步延时可以在24小时左右,使用SSIS或者trigger这个工作量太大,而且很难做到完整性,准确性和一致性。


    麻将

    2012年10月10日 5:48
  • 可以试试SNAPSHOT REPLICATION。
    2012年10月10日 5:55
  • 那你就用SNAPSHOT REPLICATION试试看

    就以每个分公司50G数据库算,十个就是500G,每个分公司2-4M的专线,一次快照需要多久才能完成?,总不能为了这个将专线升级为100M吧,我想老板做到第一件事情就是将我fire。

    麻将

    2012年10月10日 6:02
  • 呵呵 我们只是提提建议,因为毕竟不知道你的环境是什么样的配置。
    2012年10月10日 6:12
  • 有时候软件实现不了的话,确实需要升级硬件,比如数据库有瓶颈,找不到解决方案的话,最后还是要升级硬件,大家都已经出谋划策了。

    我相信大家的方案都是经过实践经验的,经过考虑的

    如有冒犯,请原谅


    给我写信: QQ我:点击这里给我发消息

    2012年10月10日 6:31
  • 有时候软件实现不了的话,确实需要升级硬件,比如数据库有瓶颈,找不到解决方案的话,最后还是要升级硬件,大家都已经出谋划策了。

    我相信大家的方案都是经过实践经验的,经过考虑的

    如有冒犯,请原谅


    给我写信: QQ我:点击这里给我发消息

    扯远了,这和硬件完全没有关系。

    麻将

    2012年10月10日 6:33
  • 1.既然是新的项目,必然有预算的。这块如果在开始做预算的时候没考虑,就应该拉出来打板子。

    2.对于同步的实时程度和你预算大小基本成正比,想花费很少的钱,又想很快,我想这个谁也做不了。

    3.看上去最经济的办法就是定时做差异备份,然后传送到中心然后恢复。当然同步时间差必须能够忍受。

    4.如果数据量大,想获得较短的同步差异时间,不增加带宽是不可能的。(和硬件还是有点毛关系的)。


    family as water

    2012年10月10日 6:47
  • 1.既然是新的项目,必然有预算的。这块如果在开始做预算的时候没考虑,就应该拉出来打板子。

    2.对于同步的实时程度和你预算大小基本成正比,想花费很少的钱,又想很快,我想这个谁也做不了。

    3.看上去最经济的办法就是定时做差异备份,然后传送到中心然后恢复。当然同步时间差必须能够忍受。

    4.如果数据量大,想获得较短的同步差异时间,不增加带宽是不可能的。(和硬件还是有点毛关系的)。


    family as water

    1.预算肯定有,但是明显这种增加带宽的需求是不现实的,我不知道你是否了解从2M的专线升级到100M的专线费用有多高?很明显这种方案明显的不切实际。

    2.预算的多少和实施程度是否成正比表示怀疑,关键是方案本身就不切实际,我不知道有哪家公司会对500G以上的数据库通过网络每天做快照同步,

    3.就每天的数据增量部分,现有的带宽已经完成足够(实验已经证明过)。

    无论如何非常感谢各位的帮助,但明显现在越扯越远了,呵呵。


    麻将

    2012年10月10日 6:56
  • 因为楼主开始提问的时候,就是考虑用复制技术,这个是基于数据库中的对象的(简单地说,就是表级别的,当然,它也支持存储过程/视图什么的),所以被误导了

    整个库的复制技术,SQL Server支持的方式是数据库镜像(2005开始),事务日志传送,和2012新推出的Always On,但是都是奥拓,没有汇集数据的意思

    不知道你放到数据中心的目的是否包含了这个,如果包含了这个,则需要自己再写程序处理

    2012年10月10日 7:48
  • 如果只是做DR,用LOG SHIPPING
    2012年10月10日 8:07
  • 如果只是做DR,用LOG SHIPPING

    本地的完整备份是否会影响LOG SHIPPING?

    麻将

    2012年10月10日 9:00
  • 因为楼主开始提问的时候,就是考虑用复制技术,这个是基于数据库中的对象的(简单地说,就是表级别的,当然,它也支持存储过程/视图什么的),所以被误导了

    整个库的复制技术,SQL Server支持的方式是数据库镜像(2005开始),事务日志传送,和2012新推出的Always On,但是都是奥拓,没有汇集数据的意思

    不知道你放到数据中心的目的是否包含了这个,如果包含了这个,则需要自己再写程序处理

    无需汇集数据,仅仅就是各个数据库在数据中心的一个个镜像数据库,作为远程备份的方案。


    麻将

    2012年10月10日 9:04
  • 完整备份不会影响LOG SHIPPING,做DR Log shipping是一个不错的选择。

    2012年10月10日 9:17
  • I'm second for log shipping in this case.
    2012年10月10日 13:00
  • Sql Server 自带的Log shipping 或则自己写个Log Shipping

    Good Luck

    2012年10月10日 14:12
  • 做过同步项目,增量<无主键的表没法增量,只能FULL>,异地或COM口传输数据都有

    若有预算,欢迎联系ME。。技术方案或完整实现、部署均可,足够的灵活性、性能


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2012年10月11日 1:00
  • COM口传输数据是局域网传输还是公网里传输呢,dgdba大侠

    给我写信: QQ我:点击这里给我发消息

    2012年10月11日 1:28
  • COM is direct connection, no network involved.
    2012年10月11日 2:41
  • COM is direct connection, no network involved.

    弱弱的问一句,com端口直连,是通过什么连接几百甚至上千公里距离的两台服务器?

    麻将

    2012年10月11日 5:09
  • COM is direct connection, no network involved.

    弱弱的问一句,com端口直连,是通过什么连接几百甚至上千公里距离的两台服务器?

    麻将

    同样的疑问。
    2012年10月11日 8:04
  • It's very old and slow way I used in 90's, not sure how many people will use it nowadays. 
    2012年10月11日 13:03
  • 真的有吗?

    给我写信: QQ我:点击这里给我发消息

    2012年10月11日 15:47
  • 以前使用过LABLE 打印机用COM口的不过后来都改用网卡了,网络肯定比COM速度好。
    2012年10月12日 1:12
  • Remember modem? Maybe you too young :-)
    2012年10月12日 1:30
  • 我2002年开始上网的,那时候还插电话线56Kmodem


    给我写信: QQ我:点击这里给我发消息

    2012年10月12日 2:13
  • 扯。。COM口当然是近距离<一两米>内啦。。但又两个网段物理隔离的情况,就是安全No.1

    未来若COM规范或接口升级到异地或无线时,记得通知我


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2012年10月12日 3:09
  • dgdba大侠你又在卖广告呢。。。

    给我写信: QQ我:点击这里给我发消息

    2012年10月12日 5:32
  • 正在进行事务日志传送带测试,完成后会将结果贴上来

    谢谢各位


    麻将

    2012年10月12日 5:34
  • 若是真大侠,都不用沦为江湖郎中吧。。呵

    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2012年10月12日 9:07