[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 

      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 
  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 


  Sem mais,

  Fabricio Mota
  Oda Mae Brown - Aprecie sem moderação.
MySql-DDE discussion list

Other related posts: