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. 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. 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! -- > > 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/