svn commit - mysqldoc@docsrva: r10015 - in trunk: refman-5.0 refman-5.1 refman-6.0

[jon]

Author: jstephens
Date: 2008-02-26 14:35:09 +0100 (Tue, 26 Feb 2008)
New Revision: 10015

Log:

NO_DIR_IN_CREATE SQL mode is not replicated; however, it is preserved by
mysqlbinlog (Thanks, Sven!)



Modified:
   trunk/refman-5.0/replication-notes.xml
   trunk/refman-5.1/replication-notes.xml
   trunk/refman-6.0/replication-notes.xml


Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml	2008-02-26 13:16:58 UTC (rev 10014)
+++ trunk/refman-5.0/replication-notes.xml	2008-02-26 13:35:09 UTC (rev 10015)
Changed blocks: 1, Lines Added: 19, Lines Deleted: 6; 1771 bytes

@@ -963,15 +963,28 @@
 
       <para>
         The <literal>FOREIGN_KEY_CHECKS</literal>,
-        <literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
-        and <literal>SQL_AUTO_IS_NULL</literal> variables are all
-        replicated in MySQL &current-series;. The
-        <literal>storage_engine</literal> system variable (also known as
-        <literal>table_type</literal>) is not yet replicated, which is a
-        good thing for replication between different storage engines.
+        <literal>UNIQUE_CHECKS</literal>, and
+        <literal>SQL_AUTO_IS_NULL</literal> variables are all
+        replicated.
       </para>
 
       <para>
+        <literal>SQL_MODE</literal> is also replicated except for the
+        <literal>NO_DIR_IN_CREATE</literal> mode. However, when
+        <command>mysqlbinlog</command> parses a <literal>SET @@SQL_MODE
+        = <replaceable>value</replaceable></literal> statement, the full
+        <replaceable>value</replaceable>, including
+        <literal>NO_DIR_IN_CREATE</literal>, is passed to the receiving
+        server.
+      </para>
+
+      <para>
+        The <literal>storage_engine</literal> system variable is not
+        replicated, which is a good thing for replication between
+        different storage engines.
+      </para>
+
+      <para>
         Starting from MySQL 5.0.3 (master and slave), replication works
         even if the master and slave have different global character set
         variables. Starting from MySQL 5.0.4 (master and slave),


Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml	2008-02-26 13:16:58 UTC (rev 10014)
+++ trunk/refman-5.1/replication-notes.xml	2008-02-26 13:35:09 UTC (rev 10015)
Changed blocks: 1, Lines Added: 19, Lines Deleted: 7; 1797 bytes

@@ -1664,16 +1664,28 @@
 
       <para>
         The <literal>FOREIGN_KEY_CHECKS</literal>,
-        <literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
-        and <literal>SQL_AUTO_IS_NULL</literal> variables are all
-        replicated (this has been true since MySQL 5.0). The
-        <literal>storage_engine</literal> system variable (also known as
-        <literal>table_type</literal>) is not yet replicated in MySQL
-        5.1, which is a good thing for replication between different
-        storage engines.
+        <literal>UNIQUE_CHECKS</literal>, and
+        <literal>SQL_AUTO_IS_NULL</literal> variables are all
+        replicated.
       </para>
 
       <para>
+        <literal>SQL_MODE</literal> is also replicated except for the
+        <literal>NO_DIR_IN_CREATE</literal> mode. However, when
+        <command>mysqlbinlog</command> parses a <literal>SET @@SQL_MODE
+        = <replaceable>value</replaceable></literal> statement, the full
+        <replaceable>value</replaceable>, including
+        <literal>NO_DIR_IN_CREATE</literal>, is passed to the receiving
+        server.
+      </para>
+
+      <para>
+        The <literal>storage_engine</literal> system variable is not
+        replicated, which is a good thing for replication between
+        different storage engines.
+      </para>
+
+      <para>
         Session variables are not replicated properly when used in
         statements that update tables. For example, <literal>SET
         MAX_JOIN_SIZE=1000</literal> followed by <literal>INSERT INTO


Modified: trunk/refman-6.0/replication-notes.xml
===================================================================
--- trunk/refman-6.0/replication-notes.xml	2008-02-26 13:16:58 UTC (rev 10014)
+++ trunk/refman-6.0/replication-notes.xml	2008-02-26 13:35:09 UTC (rev 10015)
Changed blocks: 1, Lines Added: 19, Lines Deleted: 6; 1743 bytes

@@ -1633,15 +1633,28 @@
 
       <para>
         The <literal>FOREIGN_KEY_CHECKS</literal>,
-        <literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
-        and <literal>SQL_AUTO_IS_NULL</literal> variables are all
-        replicated (this has been true since MySQL 5.0). The
-        <literal>storage_engine</literal> system variable is not yet
-        replicated in MySQL 5.1, which is a good thing for replication
-        between different storage engines.
+        <literal>UNIQUE_CHECKS</literal>, and
+        <literal>SQL_AUTO_IS_NULL</literal> variables are all
+        replicated.
       </para>
 
       <para>
+        <literal>SQL_MODE</literal> is also replicated except for the
+        <literal>NO_DIR_IN_CREATE</literal> mode. However, when
+        <command>mysqlbinlog</command> parses a <literal>SET @@SQL_MODE
+        = <replaceable>value</replaceable></literal> statement, the full
+        <replaceable>value</replaceable>, including
+        <literal>NO_DIR_IN_CREATE</literal>, is passed to the receiving
+        server.
+      </para>
+
+      <para>
+        The <literal>storage_engine</literal> system variable is not
+        replicated, which is a good thing for replication between
+        different storage engines.
+      </para>
+
+      <para>
         Session variables are not replicated properly when used in
         statements that update tables. For example, <literal>SET
         MAX_JOIN_SIZE=1000</literal> followed by <literal>INSERT INTO