FLUSH [BIN/RELAY]LOGS might have a big benefit in replication -- cleanly
marking some spot in the replication stream at the same spot on the
master and slave(s). This might lead to much cleaner scripts for
failover, etc.
(Yeah, it might not help in multi-master topologies where more than one
master is being written to.)
Rick James
MySQL Geeks - Consulting & Review
> -----Original Message-----
> From: eric.bergen@stripped
> [mailto:eric.bergen@stripped] On Behalf Of Eric Bergen
> Sent: Monday, June 09, 2008 3:25 PM
> To: Paul DuBois
> Cc: Internals List
> Subject: Re: Flush queries being written to the binary log
>
> I know it's the default. I'm just curious what the benefit of writing
> things like flush tables to the log is. It seems like it would cause
> more problems than it solves (does it solve any?).
>
> On Mon, Jun 9, 2008 at 3:22 PM, Paul DuBois <paul@stripped> wrote:
> >
> > On Jun 9, 2008, at 3:26 PM, Eric Bergen wrote:
> >
> >> Hi,
> >>
> >> I've noticed that all the flush commands (except logs,
> ironically) are
> >> written to the binary log. I thought the general idea of the binary
> >> log was to only write things that modify data. I also
> noticed that the
> >> global read lock only applies to tables and not the binary log. In
> >> 5.0.51 a flush is written to the binlog even if there is a
> global read
> >> lock. What are the guidelines for things being written to
> the binary
> >> log?
> >>
> >> Thanks,
> >>
> >> Eric
> >>
> >> -- high performance mysql consulting.
> >> http://provenscaling.com
> >
> > http://dev.mysql.com/doc/refman/5.0/en/flush.html says:
> >
> > "
> >
> > By default, FLUSH statements are written to the binary log.
> Such statements
> > used on a MySQL server acting as a replication master will
> be replicated to
> > replication slaves. Logging can be suppressed with the optional
> > NO_WRITE_TO_BINLOG keyword or its alias LOCAL.
> >
> > ...
> >
> > Note
> > FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE, and FLUSH TABLES
> WITH READ LOCK are
> > not written to the binary log in any case because they
> would cause problems
> > if replicated to a slave.
> >
> > "
> >
> > --
> > Paul DuBois
> > Sun Microsystems / MySQL Documentation Team
> > Madison, Wisconsin, USA
> > www.mysql.com
> >
> >
>
>
>
> --
> high performance mysql consulting.
> http://provenscaling.com
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:
> http://lists.mysql.com/internals?unsub=1
>
>