Hi!
>>>>> "Mats" == Mats Kindahl <mats@stripped> writes:
<cut>
>> What exactly is the recent change ?
>>
>> I am a bit confused here as a customer's told me how the change
>> in 5.0 had broken the data on their slaves and when discussing this
>> got to belive that we before wrote all non-transactional statements
>> directly to the binary log.
Mats> Well, we did in one particular case: when a "non-transactional" statement was
Mats> first in a transaction.
In other words, you broke every single application that is only using
MyISAM tables but are using BEGIN and COMMIT too ?
<cut>
Mats> It would be interesting to see the *real* example of the sequence that they have
Mats> instead of just examples of what does not work. I suspect that the problem is
Mats> caused by several unrelated changes in 5.1, and not by a single "fix."
If you don't anymore log non-transactional tables until commit, then
it can easily explain why customers has problems. You are basicly
crashing setups where people are using a lot of MyISAM tables, which
we know a lot of people are doing.
(You can't avoid sending the BEGIN ... COMMIT as some people have
frameworks that automaticly is doing this).
<cut>
>> If you are ONLY using non-transactional tables, this will cause a
>> serious problem if you are using BEGIN/COMMIT in your code!
Mats> Exactly, but this has been the case since 4.1, so it is nothing new. This was
Mats> one of the first things that I spotted out when I started with MySQL.
In 4.1 and 5.0, before the change, only using non-transactional tables
where 100 % safe even if you used BEGIN/COMMIT as nothing was cached.
It's the new change that brakes things, not the old behavior that was
safe in this context!
Another thing that breaks now:
BEGIN
INSERT INTO non-transcatinal TABLE
CRASH
If the insert is cached, the master and slave will now have different data.
This I think is unacceptable!
Regards,
Monty
