On Sat, 2008-01-12 at 14:12 +0100, Matej Knopp wrote: > On Jan 12, 2008 1:04 PM, C. Bergström <[EMAIL PROTECTED]> wrote: > > > > > > On Thu, 2008-01-10 at 13:35 +0100, Matej Knopp wrote: > > > > > > Ideally, NodeB ought to "catch up" when it joins the cluster by > > > > > > syncing the content in the disk page stores at that time. I > > > think > > > > > > it's a flaw we should track and fix at some point. > > > > > > > > > > > > Nice job, Matej! > > > > > > > > Well, I'm afraid as Igor said this is not possible to do without > > > having container specific code. So when currently a new node catch up > > > it only gets the last page for each pagemap. > > > > > > > On Wed, 2008-01-09 at 22:35 -0800, Igor Vaynberg wrote: > > > > > this cant be accomplished transparently. we would need our own > > > network > > > > > connection, node discovery, blah blah blah. loses a bit of appeal. > > > Yeah. This is actually not that difficult to do, there are frameworks > > > such as tribes that do this quite nicely. The main problem is that we > > > don't know the topology. We don't know which node is backed by which > > > node, so we would do lot of unnecearry copying. I don't see any easy > > > way to implement this. > > > > > > > I'm intending to stir the pot a bit, but why are we kicking this > > > > further? Igor is absolutely right.. For something simple, currently > > > > in the linux kernel try > > > > > > > > drbd [1] > > > > > > > > 1) Nodes can catch up/sync > > > > 2) It'll be faster than anything you can do inside java > > > > 3) transparent to the application > > > > 4) debugged and proven to work inside a production env > > > > 5) means you can revert your changes and we don't have to worry/test > > > > anything > > > > ----------------------------------- > > > > > > > > To be honest you may be on the right path long term and I don't > > > > currently have a better suggestion, but we are really reinventing the > > > > wheel here which leads me to be highly cautious. > > > > > > Reinventing the wheels? How does drbd handle the topology. Does it > > > know which nodes are backed by which node? Usually in more > > > sophisticated environment each node in cluster is backed by one other > > > node forming a ring and the container can be in charge of forming the > > > topology. How does drbd handle scenario like that? > > > > The thing is, we don't really care what the topology is. The only > requirement is that the session gets immediately deserialized once it > is replicated to other node, which should be either default or at > least configurable on most containers. > > So we let the container manage the replication topology. All we need > is to be notified when the session is replicated (pagemap > serialization and deserialization). All other approaches would require > container specific code.
Yeah.. well. when node A fails over to node B and user clicks the back button is the end goal to handle that gracefully. I was just suggesting a trivial way to accomplish the replication of the DiskPageStore's actual files. This works around app container specifics for this point. Also you realize you responded to your own question asking about topology.. ./C --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
