[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.
http://www.odamaebrown.com.br
Other related posts:
