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

  • From: Fabricio Mota <fabricio.mota@xxxxxxxxx>
  • To: mysql-dde@xxxxxxxxxxxxx
  • Date: Thu, 8 Dec 2005 22:57:50 -0300

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.

  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.

  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.


Sem mais,

Fabricio Mota
Oda Mae Brown - Aprecie sem moderação.

Other related posts: