* 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
> The proposed behavior would be my preference for FTWR behavior.
I.e. you think it's OK to wait for started transactions to
I guess the decision makes no difference on true OLTP sites,
but we learned that some 2-tier and GUI applications tend to keep
a transaction open while waiting on user input. Since FTWRL is an
integral part of backup in MySQL, we apparently will have to keep
it "old style", only to not break backups on these lame sites.