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

  • From: "Peter B. Volk" <PeterB.Volk@xxxxxxx>
  • To: <mysql-dde@xxxxxxxxxxxxx>
  • Date: Thu, 8 Dec 2005 18:06:29 +0100

guten abend

(good afternoon in german)
  ----- Original Message ----- 
  From: Fabricio Mota 
  To: Peter B. Volk 
  Cc: mim 
  Sent: Wednesday, December 07, 2005 5:08 PM
  Subject: Re: P/F/U Keys in LDD

  Boa tarde

  (good afternoom in portuguese)
    ----- Original Message ----- 
    From: Peter B. Volk 
    To: Fabricio Mota 
    Sent: Wednesday, December 07, 2005 11:54 AM
    Subject: Re: P/F/U Keys in LDD


    (=Good morning in german)
      ----- Original Message ----- 
      From: Fabricio Mota 
      To: Peter B. Volk 
      Cc: mim 
      Sent: Wednesday, December 07, 2005 1:27 PM
      Subject: Re: P/F/U Keys in LDD


       (= hello in portuguese)
        Yes, but my thought is that, if a late sync is authorized for that 
command, then it's because the remote server - to be informed lately about new 
occurrences - does not deicide if the operation might be aborted or commited. 
That would happen if this server only must to know about the new ocurrance, and 
eventually perform internal modifications to correspond to the specified 

          [Peter]Ok sounds good sofar.

          For example:

          In case of RDD late sync, consider that no global rules could never 
allow a single server to refuse any insert, delete or update command 
differently from the others. Quite it is true as described in, that a 
RDD table will never be allowed to refer a table type but RDD or LDD (from the 
same cluster, please add this for me in spec :) ). By this way, we ensure that 
every local consistance for RDD tables will be identical for any servers.

          [Peter]Correct. So once the dataset is inserted there is no way back.

      Late sync could work well - both for RDD and LDD - with any of two 
hypothesis below:

      H1) Server is already down before the transaction begins;
      H2) Server becomes down after the transaction is commited;
      H3) Server becomes down during the transaction process, in a uncommited 
      H4) Down server comes up during the transaction process.

      For H1 and H2 I think it could work well (don't you?)
      For H3 and H4, I imagine the following solutions (comment if do you agree 
with me or not):

      H3: Server holds its state (persistently), and wait for the next late 
sync for complete its operation. The resource is completely blocked (once the 
server is out of the cluster), and it will only be freed again after come back 
and synchronize the rest of transaction. Note that late sync should involve 
also general commit and rollback commands (deicided by the active cluster).

      H4: Since the server was already down, two options could be considered:
          a) Server keeps itself out of transaction, and awaits its commitment 
for synchronize itself.
          b) Server synchronizes with the current buffer, and comes in the 
transaction after regularized;

      [Peter]I would perfer H4b. since the server needs to resync with the 
cluster anyway once it was down. 

  Me too.

      So, if the server fails during a opened transaction, it will block the 
resource, and wait for get in the cluster again to perform the rest of the 
operation, with commit or rollback.

      [Peter]Well since the 2PC transaction will be used to controll the 
transaction of a query the transaction needs to rollback once a server involved 
in the transaction goes down. 

  Yes, good observation. 2PC and late-sync does not talk the same language. It 
needs to be thought about.

      This would mean that if a server coems back up again then it need to go 
though its undo logs and undo any uncomitted transaction. I don't think that it 
would be good to accept a half of a transaction then the server goes down and 
the server refetches the rest of the transaction. I think this would break the 
theorie of transaction. Espacially what happens if a server is down for ever 
because it drowned in a lake because a DBA was pissed off?
  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).

  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)
  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
  3.) LDD tables are only partialy late synct. The only syncing to do is the GI 
update right? So a late sync could only be done if there was an agreement on 
the u/f/p keys. AND Inserts and updatesare imidiatly synct  and delets are late 
synct. 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.

  Still other thought of mine, is that during the server membership after a 
crash, it just may be considered an active member if all late-sync operations 
to be performed successfully. (I think I will star this email too, to avoid I 
forget it all.. haha).
      But do you agree that when it come back to the active-cluster, it will 
agree with the cluster? I think that, although the active-cluster servers could 
allow late sync as I propose here, when a single server is down from cluster, 
it must prohibit insert, update or delete commands. What do you think now?

      [Peter]Yes it should resync with the cluster. (Very important). The 
cluster should also prevent select to be executed as long as the GI can not say 
with 100% sec. that ther down server does not have any data that is required 
for that operation. U/D could be handled the same way. => only U/D when the GI 
can say that no data needs to be touched on the down server.

  Well, what I did put in spec is that, for any operation S/I/U/D, all of them 
will be allowed if the request is not redirected to the down server. Consider 
that I previous processing will be done to separate which request will be sent 
to each server. Consider also that the request might involve only other servers 
but it.

  In pratice, I think nothing is needed to be done else to prevent it. Since 
the request will be preparated to be sent to the server, and internally handled 
by connection object. So, when it notices that connection is lost, it will 
naturally raise an exception such as "server S is down. Connection is 
terminated", or something like it.
            here is a modified master system that might be a bit more apealing: 
there is not one master for the whole cluster and not one master for one single 
GI but a master for each key that should be inserted into the index. this would 
mean the following: there are 5 servers (1-5) in the whole cluster. each server 
handles every 5th key. this means: the master of the key would be calculated by 
key MOD 5. So when server 1 receives an insert into a table with a key=7 then 
server 2 (7 MOD 5) would be the "master" of the key. This server has always has 
all keys that have key MOD 5==2. so this way server 2 can enshure the uniquness 
for this key. 

          But if it is an alphanumeric column? and a blob? And futurely, an 
OpenGIS geometry or an (invented here) new Marcian type? :)

          Alphanumeric: interpret the char as an int 
          blob: interpret the blob as integer (a rather big integer or only use 
the first x bytes)
          OpenGis: Don't know what they look like. 
          Marcian: use the hair color multiplied with the frequency of the 
transwarp engine from his spaceship 
          Any other: simply define a mathimatical function to calculate the 
whole thing

      Ok, I think I understood now the meaning of  "hash function" for this 
purpose. The important is to ensure that each value will have a related master 
server, Right? Maybe it works :)

      [Peter] konkret krass richtig (= corret in a german slang)

      But how do you propose the replication to ensure redundance of master 
servers per record class?

      [Peter]By defining 2 hash functions. the first is always used to coose 
the server if the server is up. once the first hash function does not work 
because the master server is down then the second hash function is used to be 
used etc.etc.
  Hummm, I would prefer that everybody to have the same ability to makeshift 
during faults. I'm partidary of the idea of justice for all... :) 

  [Peter]Hmm ok I'll have to think of a different Idea then.....

Other related posts: