Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?

[Rob Wultsch]

On Thu, Jun 24, 2010 at 2:46 AM, Konstantin Osipov <kostja@stripped> wrote:
> * Rob Wultsch <wultsch@stripped> [10/06/24 13:07]:
>> >> > - To allow easy file system level backups of the databases
>> >> > - To prepare a database for a snapshot
>> >> > - (Optional) Flush things to disk, so that a restart is faster.
>> >> I have seen many people use it as a general-purpose write barrier.
>> >> For example, in Alex Davies's new High Availability Cookbook, he
>> >> suggests using it before SET GLOBAL read_only = 1, to be sure the
>> >> change has really taken effect for all connections when performing a
>> >> failover.
>> > Starting from 5.0, a useless suggestion.
>> > SET GLOBAL read_only is implemented by means of FTWRL.
>> I am not sure such a harsh judgment is justified.
>>
>> FTWR causes connections to hang while read_only causes errors. I don't
>> think it takes too much mental gymnastics to see that as possibly
>> useful. I could imagine someone trying to avoid excessive errors by
>> setting FTWRL on the existing master, changing the connection
>> parameter (or moving an IP), killing connections if applicable on the
>> old master and then throwing RO on the old master.
>
> I can see a point in using FTWRL over read_only to avoid
> unnecessary errors, but not (sic) "to be sure the change has really
> taken effect".

Perhaps the connections are normally short lived and rare. With FTWRL
they would hang and could be easily traced by the administrator.
Without user stats it would be difficult to track down a front end box
that had not been correctly updated.

>>
>> The proposed behavior would be my preference for FTWR behavior.
>
> I.e. you think it's OK to wait for started transactions to
> complete?


That would be my strong preference.


-- 
Rob Wultsch
wultsch@stripped