[mysql-dde] Re: Fw: P/F/U Keys in LDD

  • From: "Peter B. Volk" <peter.benjamin.volk@xxxxxxxxxxxxxxxxx>
  • To: <mysql-dde@xxxxxxxxxxxxx>
  • Date: Thu, 15 Dec 2005 00:46:05 +0100

----- Original Message ----- 
From: "Fabricio Mota" <fabricio.mota@xxxxxxxxx>
To: <mysql-dde@xxxxxxxxxxxxx>
Sent: Tuesday, December 13, 2005 1:09 AM
Subject: [mysql-dde] Re: Fw: P/F/U Keys in LDD


> Ich bin zurück,
> (hahahahaha)
>
>
> 2005/12/12, Peter B. Volk <PeterB.Volk@xxxxxxx>:
> >
> > ----- Original Message -----
> > From: Fabricio Mota
> > To: mysql-dde@xxxxxxxxxxxxx
> > Sent: Friday, December 09, 2005 2:57 AM
> > Subject: [mysql-dde] Re: Fw: P/F/U Keys in LDD
> >
> >
> > Buenas notches (that's not my language! hahaha)
> >
> >      Oh yes, I didn't think about the lake. And the late-sync protocol
> > does not specifies to be water-resistent :). You've got the reason.
Maybe
> > it's better to make the unplugged server to rollback, and the cluster to
> > bufferize logs from entire transaction for its future recovery.
> >      Another thing about it I was thinking today is to ensure agreement
of
> > buffer, that is, to replicate the buffer log for all servers in late
> > sinchronization. That's because of to prevent another fault to damage
the
> > global consistence. What do you think?
> >
> >      [Peter]Well we'll need somesort of a global log anyway. Not only
for
> > these un- and redo stuff but also for replication (see next email).
> > Yes, of course. I think global logs must be another starred point to be
> > submitted to our analysis (wow, how many things!!!)
> >
> >      By the way, in general manner do you agree with late
synchronization?
> >
> >      [Peter]I would agree under the following conditions (feel free to
> > disagree):
> >
> >      1.) RDD table can always be late synct (since they are only
> > management tables and 90% of queries against these tables are selects)
> > Yes, I agree fully. Late sync must be applied in some situations to
help,
> > and not to degrade.
> >
> >
> >      2.) There is an upper bound for late sync. This means that there is
a
> > some time (e.g. 10sec.) where the sync commands can be delayed. but
after
> > this time the sync mußt be done
> > I can't understand it clearly.
> >
> > [Peter] I mean that a late synch should not bee toooooo late. so the
sync
> > should be done with an upper bound in time. so the queries are not
suppost
> > to be in the late sync queue for longer than 10 Sec. or so. This is
simply a
> > livlyness property
> >
> >
> >
> >      3.) LDD tables are only partialy late synct. The only syncing to do
> > is the GI update right?
> > I think so.
> >
> >      So a late sync could only be done if there was an agreement on the
> > u/f/p keys.
> > I agree. Maybe we will need to have means to ensure agreement within
> > dynamic operations. Maybe a flag per table, with a agreement protocol, I
> > don't know yet. But it must be a trusted mean to ensure a safe late
sync.
> >
> > [Peter]Well need to star this point until we have decided how to do the
> > u/f/p key validation
>
>
> Ok. Point starred. Command executed in 0.005s. :)
>
>      AND Inserts and updates are imidiatly synct  and delets are late
synct.
> > In true, I think late sync for I/U/D might be allowed only if the
faultous
> > server and the targeted server are different. That's important to avoid
to
> > prohibit full access to the island-server, during a network fail, for
> > example, and at the same time, to ensure consistence.
> >
> >
> >
> >      This is because if there was a deletion the remote server would
still
> > query the server but the server would only return an empty set. Inserts
mußt
> > be synct in time because there is a kind of filter that the GI can set
to
> > optimize the number of remote server queried. Same applies for updates.
> >
> > This I also did not understand clearly.
> >
> > [Peter] imagine 2 servers. A query is set of on S1. S1 needs data from
S2.
> > S1 needs to querie S2 to retrive the data he needs. in the mean time S2
has
> > executed a query that deleted exactly those rows that S1 needs. No data
was
> > effected on S1. Now S1 queries S2. Without late sync for Deletes the
> > Transaction would need to be delayed because the GI on S1 is not up to
date
> > and S1 can only query S1 if the lock on GI is released. With late sync
S1
> > can query S2 without any problems because the GI modification only has
> > optimization effects.
>
>
> Well I think we're agreeing in a point: late sync, for the most it is
used,
> it must always ensure consistence. What you announced is a *time window
*of
> inconsistence.
>
> What I would propose for that is: when any operation is performed,
although
> a server is down or incommunicable - late-sync targeted or not - no
> operation targeted to it must be allowed.

Yes Yes give me more.....

>
> The fundamentals of late-sync - in my concept, of course - is that it must
> be an passive and *rightless* element of the transaction, unable to decide
> if it could be performed or not. If he is an active element (such as:
delete
> * from LDDTable where Server = 1 ----- note that here, for example, Server
1
> is an active element), then late sync is not suitable. This violates the
*lemma
> 4 *of late sync.

I fully agree

>
> Imagine: if in the delete query, there is an foreign key related to any of
> these records? If we allow to delete it (with server down), it could be a
> disaster!

Yes I agree. But once the Delete was executed an found as valid (in terms of
consistency) on one server (what ever consistency method it uses) then the
other servers would only need to executed since a server wold have already
evaluated it.

>
>
> --
> >
> > 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
>
> MySql-DDE discussion list
> www.freelists.org/
>

MySql-DDE discussion list
www.freelists.org/

Other related posts: