[mysql-dde] Re: Connection Fail

  • From: Fabricio Mota <fabricio.mota@xxxxxxxxx>
  • To: mysql-dde@xxxxxxxxxxxxx
  • Date: Sat, 10 Dec 2005 22:22:05 -0300

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/

Other related posts: