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

  • From: "Fabricio Mota" <fabricio.oliveira@xxxxxxxxxxxxxxxx>
  • To: <mysql-dde@xxxxxxxxxxxxx>
  • Date: Thu, 15 Dec 2005 09:56:52 -0200

Hey Guy...
Very good you being thinking about it, that's because I was think about the 
same, and taking almost the same way. 

Let's go:

----- Original Message ----- 
From: "Peter B. Volk" <peter.benjamin.volk@xxxxxxxxxxxxxxxxx>
To: <mysql-dde@xxxxxxxxxxxxx>
Sent: Wednesday, December 14, 2005 9:38 PM
Subject: [mysql-dde] Re: Fw: P/F/U Keys in LDD


> Hey,
> 
> I've been thinking:
> 
> so what about this one:
> 
> S1 receives a query. There is in I/U on a P/U/F key index. S1 evaluates the
> insert. If the Key kan be inserted (no key violation) then S1 starts to
> sernd the GI insert to the other servers synchroniously. 

I don't understand how different could be the majority decision from only-one 
decision about a GI insertion...
GI wouldn't be synchronized among servers?

> After the majority
> of the servers have agreed on the Insert then the update is commited. Else
> it is rolled back. The sending to the remote servers should be done on a
> rotation princible. so if we have S1 to S8 and S4 receives the query then it
> would send the update to S5,S6,S7,S8,S1 etc. This way we would avoid massive
> collision with other GI updates. Also this removes the master server you are
> worried about.
> 






> What do you think of that?
> 
> Peter
> 
> 
> ----- Original Message ----- 
> From: "Fabricio Mota" <fabricio.mota@xxxxxxxxx>
> To: <mysql-dde@xxxxxxxxxxxxx>
> Sent: Tuesday, December 13, 2005 1:16 AM
> Subject: [mysql-dde] Re: Fw: P/F/U Keys in LDD
> 
> 
>> Sorry, I missed to answer one:
>> 2005/12/12, Fabricio Mota <fabricio.mota@xxxxxxxxx>:
>> >
>> > 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
>> >
>> >
>> Yes, this make sense. But the problem is: once late sync was authorized,
> the
>> command was buffered and the transaction was commited, I think it is very
>> necessary that the remaining buffered command being sent to the recipient
>> before it to be reintegrated to group. Otherwise, the server might come
>> inconsistent.
>>
>> The exception was if the server fell in the lake :). But if it happen, and
>> there are no means to recovery the server state, then the DBA must pull
> out
>> the server from the cluster, using *alter cluster drop <dde_server> *
>> command.
>>
>> So, if this command being performed successfully, ALL pending late sync in
>> buffer must be purged.
>>
>> Hey, I will star that too, I think I did not explain it in spec!!!!
>>
>>
>>
>> >       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
>> >
>>
>>
>>
>> --
>>
>> Sem mais,
>>
>> Fabricio Mota
>> Oda Mae Brown - Aprecie sem moderação.
>> http://www.odamaebrown.com.br
>>
>> MySql-DDE discussion list
>> www.freelists.org/
>>
> 
> MySql-DDE discussion list
> www.freelists.org/
> 
>
MySql-DDE discussion list
www.freelists.org/

Other related posts: