bk commit - mysqldoc@docsrva tree (jon:1.2724)

[jon]

Below is the list of changes that have just been committed into a local
mysqldoc repository of jon. When jon does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.2724 05/05/30 16:33:43 jon@stripped +1 -0
  In 4.1.1+, NO_WRITE_TO_BINLOG or LOCAL option 
  keeps OPTIMIZE TABLE from being written to binlog 
  (and thus keeps it from being replicated).

  Docs/manual.texi
    1.2945 05/05/30 16:33:38 jon@stripped +6 -4
    In 4.1.1+, NO_WRITE_TO_BINLOG or LOCAL option 
    keeps OPTIMIZE TABLE from being written to binlog 
    (and thus keeps it from being replicated).

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	jon
# Host:	gigan.site
# Root:	/home/jon/bk/mysqldoc

--- 1.2944/Docs/manual.texi	2005-05-28 04:49:02 +10:00
+++ 1.2945/Docs/manual.texi	2005-05-30 16:33:38 +10:00
@@ -61856,10 +61856,12 @@
 Note that MySQL locks the table during the time @code{OPTIMIZE TABLE} is
 running.
 
-Before MySQL 4.1.1, @code{OPTIMIZE TABLE} statements are not written
-to the binary log. As of MySQL 4.1.1, they are written to the binary
-log unless the optional @code{NO_WRITE_TO_BINLOG} keyword
-(or its alias @code{LOCAL}) is used.
+Before MySQL 4.1.1, @code{OPTIMIZE TABLE} statements are not written to the
+binary log. As of MySQL 4.1.1, they are written to the binary log unless the
+optional @code{NO_WRITE_TO_BINLOG} keyword(or its alias @code{LOCAL}) is used.
+This has been done so that @code{OPTIMIZE TABLE} commands used on a MySQL server
+acting as a replication master will be replicated by default to the replication
+slave.
 
 
 @node REPAIR TABLE, RESTORE TABLE, OPTIMIZE TABLE, Table maintenance SQL