×

Loading...
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。

We have Notes Domino servers among North Amer, China, Brazil, Germany, Mexico, French. The quality of DB replication process depends on bandwidth of leased channels. For local replication among disparate systems, broken-down / fix is everyday life.

Communication between North America and China is terrible sometimes. Brazil is even worse !

Local systems' replication is not a sure thing as well, normally they are overnight tasks, N times per day type of replication ( bi-direction, one-direction ) sometimes causes suspicious duplicate records because processes sometimes get shattered.

The effectiveness of replication also depends on how application is designed and developed. We once have one application designed in a way of removing-all and then re-writing-all documents, which is a simple logic to refresh data for sure, but is a devastating scenario for administrator to manage replication !
Report

Replies, comments and Discussions:

  • 工作学习 / 学科技术讨论 / 请教多数据库java webservice系统方案, 请进。
    目前已经有一套java webservice系统运行在MS SQL Server 2005上。现在要在远程多建一套, 而且部分数据要同步, 如交易数据, 配置数据, 用户数据等。 请问各位有什么好的方案? 要程序实现还是有现成的数据库工具实现。先谢谢。
    • 没太看懂,“有一套java webservice系统。。。要在远程多建一套。。。”估计想解决两个database同步的问题。虽然俺不懂,但是肯定低级别解决方案可靠和有效,用数据库工具就行了,不用写高级程序,容易出错。胡说不用谢。
      • 还是要谢,我的说明有点模糊。 正如你所说的。如果有更详细的建议不妨分享一下, 在下非常感激。
        • I think the Replication in SQL Server is one way to implement what you want.
    • 信息太少了, 这已经是J2EE, 跟运行环境和persistence技术有关. 如果是EJB + Application Server Network deployment的话, 在服务器LEVEL就非常容易实现. 否则比较麻烦. 我知道有些大公司和银行都不能实现数据同步, 而要进行nightly replication.
    • You do need put more detail information here. But if I'm understanding correctly, your problem should be solved by database replication. As you're using SQL Server 2005, simply go to Help or Book Online and search Replication.
      • More details: service layer:java ws+spring, persistence layer:just spring JDBC template, DB:MSSQL2005
        • Requirements:1.some tables need synchronized in real time,e.g.user table,config table,report table. 2.some tables need standalone for specific facility, e.g transaction table
        • Seem replication is not real time, right? Correct me if any wrong. Thank you.
          • (1) It doesn't matter what kind of service layer and presentation layer you're using. It has nothing to do with the database underneath especailly from your requirements' perspective.
            (2) I agree with you that the Replication Service is not that 'real' time. But it also depends on how 'real time' you need. In your case, (user table, config table, and report table), minute-level should be sufficient. Quite often, what we need is right-time rather than real-time.
    • Using existing tools may not have good performance, and is not flexible as well. In most cases, if permitted, I always write native message queue functions, if replication process allows some delays, or, HTTP calls for real time data exchange.
      • 先谢谢各位的建议。 我还有一个想法, 可不可以在持久层同时往多个数据库操作, 但要在程序中处理transaction。
        • 惯用做法就是这样. MID-WARE COM HANDLE TRANSACTIONS. WS HANDLE DATABASES 存取.
        • That depends. In complex system, if transaction involves servers at different remote locations, operation will have huge cost ! This is better to put into task queue, and return status page to consumer when result is ready.
    • I guess it can be easliy done by database itself. Check the MS SQL virtualization or failover clustering, this can allow two server data synchronized or near synchronized.
    • 谢谢各位。以下是我的初步方案: 用SQL server 2005的replication功能;数据库有四个实例:两组(一个在线事务,一个报表)分别在不同地理位置。在线事务DB用transactional repli到报表DB, 两个报表DB之间用peer-to-peer repli。请问各位有何建议。
    • 我目前没有实际的DB replication经验, 请问朋友们有吗?性能如何? 问题多吗?谢谢。
      • We have Notes Domino servers among North Amer, China, Brazil, Germany, Mexico, French. The quality of DB replication process depends on bandwidth of leased channels. For local replication among disparate systems, broken-down / fix is everyday life.
        Communication between North America and China is terrible sometimes. Brazil is even worse !

        Local systems' replication is not a sure thing as well, normally they are overnight tasks, N times per day type of replication ( bi-direction, one-direction ) sometimes causes suspicious duplicate records because processes sometimes get shattered.

        The effectiveness of replication also depends on how application is designed and developed. We once have one application designed in a way of removing-all and then re-writing-all documents, which is a simple logic to refresh data for sure, but is a devastating scenario for administrator to manage replication !