[mysql-dde] Re: Fw: P/F/U Keys in LDD
- From: Fabricio Mota <fabricio.mota@xxxxxxxxx>
- To: mysql-dde@xxxxxxxxxxxxx
- Date: Mon, 12 Dec 2005 21:09:25 -0300
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/
Other related posts: