Hi, I posted a roll-up JIRA to address the general problem of network partitions. This needs to be fixed.
That said, I don't think it will be easy to fix Sequoia to work over a WAN. There are a couple of reasons for this: 1.) Network partitions inevitably lead to re-initializing data on either one side or the other side of the WAN. This is true even if you properly handle the partition itself. 2.) WAN connections have very high latency compared to a LAN. This is a problem for group communications, which either pass tokens between members or depend on message exchange to implement total ordering. For example a basic LAN with a reasonably capable switch has ping response on the order of .1ms. In theory this would allow you to order up to 10,000 messages per second assuming a message exchange for each message ordered. This is the top rate for updates. On the other hand, if you have a 30ms ping, this would imply you can order about 30 messages per second. That limits you to 30 updates per second or so. That's just not acceptable for most applications. Both of these limitations are inherent in systems that use group communication for replication. This design approach only works on networks that have LAN or near LAN availability and latency. There have been some research papers about GC over WAN but they did not look very compelling. The best way to implement WAN clustering is to use asynchronous replication to connect clusters. This is a very different approach and either requires some additional support in Sequoia or integration with database replication such as MySQL replication or PostgreSQL SLONY. Thanks, Robert P.s., please feel free to correct my math. On 3/31/08 1:54 AM, "Stefan Lischke" <[EMAIL PROTECTED]> wrote: Hi Roy, Use of Sequoia over the internet or even through some not directly connected network is very unstable. We are using this scenario but we have a lot of trouble with it, because sequoia does not handle network partitions. And network partitions occur very often in such networks. If there is a network partition, sequoia stops distributing the insert requests to all nodes, but when the connection is available again, sequoia distributes alle insert request to all nodes again without checking the state of the databases on every node. That results in ugly errors, because some rows are not present on all nodes. There is already a Bug for this https://forge.continuent.org/jira/browse/SEQUOIA-980 And maybe there will be a solution for this in near future. hth Stefan Morris, Roy wrote: > I was reading through the archives trying to figure if anyone has had > controllers > on multiple sites and it looks like at some point in 2005 this thread ends. > https://forge.continuent.org/pipermail/sequoia/2005-November/000152.html > > I didn't see any real resolution either, I am surprised there are not some > huge > installations out there that require multi-site ability. Anyway if anyone is > doing > multi-site drop me a line I'd like to avoid building a tool for this if I can. > > cheers > Roy > > > _______________________________________________ > Sequoia mailing list > [email protected] > https://forge.continuent.org/mailman/listinfo/sequoia > > > _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia -- Robert Hodges, CTO, Continuent, Inc. Email: [EMAIL PROTECTED] Mobile: +1-510-501-3728 Skype: hodgesrm
_______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
