[mysql-dde] Re: Fw: P/F/U Keys in LDD
- From: "Peter B. Volk" <PeterB.Volk@xxxxxxx>
- To: <mysql-dde@xxxxxxxxxxxxx>
- Date: Tue, 13 Dec 2005 00:48:11 +0100
----- 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
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.
--
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:
