Hey, Guy... Another thought... I think anyway we take, maybe it's important to make servers know about its communication in both ways: ahead and back. In other works, any choice we do, we could manage our graph with bidiretional arrows. I think a way to do that is to keep, among each server, a variable (per server) with four states to identify it's communication to each other one. That is, instead of {ALIVE, DOWN}, we could manage it as something like {ALIVE, ACTIVE, PASSIVE, DOWN} Where: *alive:* both communication ways are operating; *active:* the server only access to the remote (he is only client); *passive:* the server is only accessed from the remote (he is only server); *down:* both connection ways are down. How could it works? With a 2 bits variable, where the first bit represents the connection to the remote, and the last bit represents the connection from remote to it. So: *00 - Down;* *01 - Passive;* *10 - Active;* *11 - Alive;* So, When a server *A *successfully connects to a server *B*: 1) *A *Marks its reference to *B* with 1 in the first bit. 2) *B *Marks its reference to *A* with 1 in the last bit. And when a connection from a server *A *to a server *B *fails: 1) *A *Marks its reference to *B* with 0 in the first bit. 2) *B *Marks its reference to *A* with 0 in the last bit. I think that's enough to completelly map the bilateral graph. What do you think? 2005/12/10, Fabricio Mota <fabricio.mota@xxxxxxxxx>: > > Hummm, Yeah, that's a possibility. But that's a kind of reliable > musticast! > > 2005/12/10, Peter B. Volk <PeterB.Volk@xxxxxxx>: > > > > Hey, > > well S3 could perform operations but either S1 or S2 would not be able > > to do so. An idea would be to use S3 as a kind of a proxy since it can query > > alll servers. So S1 would receive a query but since it is not in the > > majority group but it can talk with someone in the majority then S1 would > > send the query to S3 and S3 could execute the query as it its origin was > > from S3. > > > > Now using the servers a proxies for this type of error should be > > something like v2 or something like that. > > > > What do you think? > > ----- Original Message ----- > > From: Fabricio Mota > > To: mysql-dde@xxxxxxxxxxxxx > > Sent: Friday, December 09, 2005 12:57 AM > > Subject: [mysql-dde] Re: Connection Fail > > > > > > Ok, Peter. > > > > Your idea works. But don't you think that we could be losing > > availability unnecessarily? That's because, once both S1 and S2 are > > available for S3, S3 could be able to perform operations, although it is > > prohibited. > > > > FM > > > > Hey Peter, > > > > I was thinking a bit more about connection liveness and server > > liveness management, and I've got another problem: visibility is a > > bidiretional property. > > That is: suppose a cluster with 3 servers, S1, S2 and S3. At the > > first moment, everybody sees everybody. > > But in a second moment, due a network transient, S1 stops to see > > S2, although S2 still sees S1. That means, only connection from S1 (as > > client) to S2 (as server) failed. So, I think that there are no Islands > > here, only a non-complete graph will be found. > > > > Of course, S3 will not be prohibited to perform any operation, > > because it completely sees everybody. > > > > But what about S1 and S2? > > > > Well, if we (eventually) consider to use any billateral > > management, so S2 will be also able to perform operations origined by it. > > That's because it also sees everybody. > > > > But S1 will try perform active-cluster operations under > > late-synchronization proceeding. So, it will do that is needed communicating > > with S3, and could save a buffer to inform modifications to S2 later. > > > > It could be dangerous if we imagine a RDD updating example, as > > above: > > > > 1. S1 updates MyRDDTable, because it is protected under > > majority-criteria law. > > 1.1 S1 updates itself; > > 1.2 S1 sends update command to S3; > > 1.3 S1 creates a buffer (late sync) for when S2 come active > > again; > > > > 2. And a little after, S2 try to update MyRDDTable, since it is > > protected under majority-criteria law, too. > > 1.1 S2 updates itself (before to receive buffered command from > > S1, it's very bad!); > > 1.2 S2 sends update command to S3; > > 1.3 S2 sends update command to S1 (ishhhh); > > > > How do you suggest to solve it? > > > > [Peter] Hmmm good question. Once S1 doesnt see S2 anymore S2 is > > suspected by S1 to be down and communicates this to S3 since S3 can see all > > of them ther is a classification of this error -> networkerror. Then S1-3 > > should decide on who should be taken out of the cluster S1 or S2. > > > > How does that sound? > > > > Peter > > > > > > > > -- > > > > Sem mais, > > > > Fabricio Mota > > Oda Mae Brown - Aprecie sem moderação. > > http://www.odamaebrown.com.br > > > > > > > > > > -- > > > > Sem mais, > > > > Fabricio Mota > > Oda Mae Brown - Aprecie sem moderação. > > http://www.odamaebrown.com.br > > MySql-DDE discussion list > > www.freelists.org/ > > > > > > > -- > > Sem mais, > > Fabricio Mota > Oda Mae Brown - Aprecie sem moderação. > http://www.odamaebrown.com.br > -- Sem mais, Fabricio Mota Oda Mae Brown - Aprecie sem moderação. http://www.odamaebrown.com.br MySql-DDE discussion list www.freelists.org/