> From: Egor Egorov <[EMAIL PROTECTED]> > Date: Thu, 3 Jul 2003 10:51:08 +0000 (UTC) > Subject: Re: replicating FLUSH LOGS > > "Bill Easton" <[EMAIL PROTECTED]> wrote: > > Under MySQL 3.23, FLUSH LOGS was replicated. Under 4.0.13, this appears to > > no longer be the case. > > > > Was this intentional? Could it be put back the way it was? > > > > We do backups by, at a time of low usage, (1) FLUSH LOGS on the master, (2) > > Dump the master database, (3) repeat 1 and 2 until there were no updates > > during the dump. (We've only had to repeat once.) It was useful to know > > that both the master and the slave had a binlog starting from the time of > > the dump. > > FLUSH LOGS has never been replicated.
You are correct, in that "FLUSH LOGS" was never written to the binlog. However, it used to be that when a FLUSH LOGS command was given on the master, the slave also started a new binlog. (At least, assuming the slave had binlog and log-slave-updates enabled.) Example follows with master 3.23.49 on Linux and slave 4.0.1 on Windows 2000. I'm pretty sure it happened with a 3.23.49 slave as well. ON SLAVE: C:\>dir \mysql\data ... 07/03/2003 10:21p 201 testslave.001 07/03/2003 10:20p 16 testslave.index ... ON MASTER: mysql> flush logs; Query OK, 0 rows affected (0.00 sec) ON SLAVE: C:\>dir \mysql\data ... 07/03/2003 10:21p 260 testslave.001 07/03/2003 10:21p 55 testslave.002 07/03/2003 10:21p 32 testslave.index ... I note that on 3.23, after FLUSH LOGS, the end of the binary log looks like this: # at 138 #030704 2:21:46 server id 1 Rotate to rcapdcs.142 # at 162 #030704 2:21:46 server id 1 Stop On 4.0.13, the "Stop" line is not there. Perhaps that's what triggers the log change on the slave. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
