List:Commits« Previous MessageNext Message »
From:paul Date:January 29 2006 10:55pm
Subject:svn commit - mysqldoc@docsrva: r1112 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-29 23:55:04 +0100 (Sun, 29 Jan 2006)
New Revision: 1112

Log:
 r6876@frost:  paul | 2006-01-29 16:54:02 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/replication.xml
   trunk/refman-5.0/replication.xml
   trunk/refman-5.1/replication.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6875
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6876
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588

Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2006-01-29 22:54:41 UTC (rev 1111)
+++ trunk/refman-4.1/replication.xml	2006-01-29 22:55:04 UTC (rev 1112)
@@ -1380,14 +1380,14 @@
 </programlisting>
 
         <para>
-          The following table shows the maximum length for the string
-          options:
+          The following table shows the maximum allowable length for the
+          string-valued options:
         </para>
 
         <informaltable>
           <tgroup cols="2">
-            <colspec colwidth="40*"/>
             <colspec colwidth="20*"/>
+            <colspec colwidth="20*"/>
             <tbody>
               <row>
                 <entry><literal>MASTER_HOST</literal></entry>
@@ -1430,18 +1430,19 @@
 
     <para>
       If you have forgotten to set the <literal>server-id</literal>
-      value for the master, slaves are not able to connect to it.
+      option for the master, slaves cannot connect to it.
     </para>
 
     <para>
       If you have forgotten to set the <literal>server-id</literal>
-      value for the slave, you get the following error in the slave's
+      option for the slave, you get the following error in the slave's
       error log:
     </para>
 
 <programlisting>
-Warning: You should set server-id to a non-0 value if master_host is set;
-we will force server id to 2, but this MySQL server will not act as a slave.
+Warning: You should set server-id to a non-0 value if master_host
+is set; we will force server id to 2, but this MySQL server will
+not act as a slave.
 </programlisting>
 
     <para>
@@ -1457,21 +1458,24 @@
       processed. Do <emphasis>not</emphasis> remove or edit these files
       unless you know exactly what you are doing and fully understand
       the implications. Even in that case, it is preferred that you use
-      the <literal>CHANGE MASTER TO</literal> statement.
+      the <literal>CHANGE MASTER TO</literal> statement to change
+      replication parameters. The slave will use the values specified in
+      the statement to update the status files automatically.
     </para>
 
     <para>
       <emphasis role="bold">Note</emphasis>: The content of
-      <filename>master.info</filename> overrides some of the options
-      specified on the command line or in <filename>my.cnf</filename>.
-      See <xref linkend="replication-options"/>, for more details.
+      <filename>master.info</filename> overrides some of the server
+      options specified on the command line or in
+      <filename>my.cnf</filename>. See
+      <xref linkend="replication-options"/>, for more details.
     </para>
 
     <para>
-      Once you have a snapshot, you can use it to set up other slaves by
-      following the slave portion of the procedure just described. You
-      do not need to take another snapshot of the master; you can use
-      the same one for each slave.
+      Once you have a snapshot of the master, you can use it to set up
+      other slaves by following the slave portion of the procedure just
+      described. You do not need to take another snapshot of the master;
+      you can use the same one for each slave.
     </para>
 
   </section>
@@ -1486,11 +1490,12 @@
     </para>
 
     <para>
-      <emphasis role="bold">Note</emphasis>: You cannot replicate from a
-      master that uses a newer binary log format to a slave that uses an
-      older format (for example, from MySQL 4.1 to MySQL 3.23.) This has
-      significant consequences for upgrading servers in a replication
-      setup, as described in <xref linkend="replication-upgrade"/>.
+      <emphasis role="bold">Note</emphasis>: You
+      <emphasis>cannot</emphasis> replicate from a master that uses a
+      newer binary log format to a slave that uses an older format (for
+      example, from MySQL 4.1 to MySQL 3.23.) This has significant
+      consequences for upgrading servers in a replication setup, as
+      described in <xref linkend="replication-upgrade"/>.
     </para>
 
     <para>
@@ -1659,10 +1664,9 @@
 
       <listitem>
         <para>
-          Replication is done correctly with
-          <literal>AUTO_INCREMENT</literal>,
+          Replication of <literal>AUTO_INCREMENT</literal>,
           <literal>LAST_INSERT_ID()</literal>, and
-          <literal>TIMESTAMP</literal> values.
+          <literal>TIMESTAMP</literal> values is done correctly.
         </para>
       </listitem>
 
@@ -1670,7 +1674,7 @@
         <para>
           The <literal>USER()</literal>, <literal>UUID()</literal>, and
           <literal>LOAD_FILE()</literal> functions are replicated
-          without changes and thus do not work reliably on the slave.
+          without change and thus do not work reliably on the slave.
           This is also true for <literal>CONNECTION_ID()</literal> in
           slave versions older than 4.1.1. The
           <emphasis role="bold">new</emphasis>
@@ -1691,15 +1695,16 @@
         <para>
           <emphasis>The following restriction applies to statement-based
           replication only, not to row-based replication.</emphasis> The
-          functions handling user-level locks:
           <literal>GET_LOCK()</literal>,
           <literal>RELEASE_LOCK()</literal>,
-          <literal>IS_FREE_LOCK()</literal>,
-          <literal>IS_USED_LOCK()</literal> are replicated without the
-          slave knowing the concurrency context on master; so these
-          functions should not be used to insert into a master's table
-          as the content on slave would differ (i.e. do not do
-          <literal>INSERT INTO mytable VALUES(GET_LOCK(...))</literal>).
+          <literal>IS_FREE_LOCK()</literal>, and
+          <literal>IS_USED_LOCK()</literal> functions that handle
+          user-level locks are replicated without the slave knowing the
+          concurrency context on master. Therefore, these functions
+          should not be used to insert into a master's table because the
+          content on the slave would differ. (For example, do not issue
+          a statement such as <literal>INSERT INTO mytable
+          VALUES(GET_LOCK(...))</literal>.)
         </para>
       </listitem>
 
@@ -1709,30 +1714,30 @@
           replicated as of MySQL 4.0.14. The
           <literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
           <literal>SQL_AUTO_IS_NULL</literal>, and
-          <literal>TABLE_TYPE</literal> (same as
-          <literal>STORAGE_ENGINE</literal>) variables are not
-          replicated in MySQL 4.1 or earlier versions.
+          <literal>storage_engine</literal> (also known as
+          <literal>table_type</literal>) variables are not replicated in
+          MySQL 4.1 or earlier versions.
         </para>
       </listitem>
 
       <listitem>
         <para>
           The following applies to replication between MySQL servers
-          using different character sets:
+          that use different character sets:
         </para>
 
         <orderedlist>
 
           <listitem>
             <para>
-              You must <emphasis role="bold">always</emphasis> use the
-              same <emphasis role="bold">global</emphasis> character set
-              and collation (<option>--character-set-server</option>,
-              <option>--collation-server</option>) on the master and the
-              slave. Otherwise, you may get duplicate-key errors on the
-              slave, because a key that is regarded as unique in the
-              master's character set may not be unique in the slave's
-              character set.
+              You must <emphasis>always</emphasis> use the same
+              <emphasis>global</emphasis> character set and collation on
+              the master and the slave. (These are controlled by the
+              <option>--character-set-server</option> and
+              <option>--collation-server</option> options.) Otherwise,
+              you may get duplicate-key errors on the slave, because a
+              key that is unique in the master character set might not
+              be unique in the slave character set.
             </para>
           </listitem>
 

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-29 22:54:41 UTC (rev 1111)
+++ trunk/refman-5.0/replication.xml	2006-01-29 22:55:04 UTC (rev 1112)
@@ -1311,14 +1311,14 @@
 </programlisting>
 
         <para>
-          The following table shows the maximum length for the string
-          options:
+          The following table shows the maximum allowable length for the
+          string-valued options:
         </para>
 
         <informaltable>
           <tgroup cols="2">
-            <colspec colwidth="40*"/>
             <colspec colwidth="20*"/>
+            <colspec colwidth="20*"/>
             <tbody>
               <row>
                 <entry><literal>MASTER_HOST</literal></entry>
@@ -1361,18 +1361,19 @@
 
     <para>
       If you have forgotten to set the <literal>server-id</literal>
-      value for the master, slaves are not able to connect to it.
+      option for the master, slaves cannot connect to it.
     </para>
 
     <para>
       If you have forgotten to set the <literal>server-id</literal>
-      value for the slave, you get the following error in the slave's
+      option for the slave, you get the following error in the slave's
       error log:
     </para>
 
 <programlisting>
-Warning: You should set server-id to a non-0 value if master_host is set;
-we will force server id to 2, but this MySQL server will not act as a slave.
+Warning: You should set server-id to a non-0 value if master_host
+is set; we will force server id to 2, but this MySQL server will
+not act as a slave.
 </programlisting>
 
     <para>
@@ -1388,21 +1389,24 @@
       processed. Do <emphasis>not</emphasis> remove or edit these files
       unless you know exactly what you are doing and fully understand
       the implications. Even in that case, it is preferred that you use
-      the <literal>CHANGE MASTER TO</literal> statement.
+      the <literal>CHANGE MASTER TO</literal> statement to change
+      replication parameters. The slave will use the values specified in
+      the statement to update the status files automatically.
     </para>
 
     <para>
       <emphasis role="bold">Note</emphasis>: The content of
-      <filename>master.info</filename> overrides some of the options
-      specified on the command line or in <filename>my.cnf</filename>.
-      See <xref linkend="replication-options"/>, for more details.
+      <filename>master.info</filename> overrides some of the server
+      options specified on the command line or in
+      <filename>my.cnf</filename>. See
+      <xref linkend="replication-options"/>, for more details.
     </para>
 
     <para>
-      Once you have a snapshot, you can use it to set up other slaves by
-      following the slave portion of the procedure just described. You
-      do not need to take another snapshot of the master; you can use
-      the same one for each slave.
+      Once you have a snapshot of the master, you can use it to set up
+      other slaves by following the slave portion of the procedure just
+      described. You do not need to take another snapshot of the master;
+      you can use the same one for each slave.
     </para>
 
   </section>
@@ -1420,14 +1424,6 @@
     </para>
 
     <para>
-      <emphasis role="bold">Note</emphasis>: You cannot replicate from a
-      master that uses a newer binary log format to a slave that uses an
-      older format (for example, from MySQL 5.0 to MySQL 4.1.) This has
-      significant consequences for upgrading servers in a replication
-      setup, as described in <xref linkend="replication-upgrade"/>.
-    </para>
-
-    <para>
       We recommend using the most recent MySQL version available because
       replication capabilities are continually being improved. We also
       recommend using the same version for both the master and the
@@ -1440,6 +1436,15 @@
     </para>
 
     <para>
+      <emphasis role="bold">Note</emphasis>: You
+      <emphasis>cannot</emphasis> replicate from a master that uses a
+      newer binary log format to a slave that uses an older format (for
+      example, from MySQL 5.0 to MySQL 4.1.) This has significant
+      implications for upgrading replication servers, as described in
+      <xref linkend="replication-upgrade"/>.
+    </para>
+
+    <para>
       The preceding information pertains to replication compatibility at
       the protocol level. However, there can be other constraints, such
       as SQL-level compatibility issues. For example, a &current-series;
@@ -1467,8 +1472,8 @@
 
       <para>
         This section applies to upgrading replication from MySQL 3.23,
-        4.0, or 4.1 to &current-series;. A 4.0 server should be 4.0.3 or
-        newer.
+        4.0, or 4.1 to MySQL &current-series;. A 4.0 server should be
+        4.0.3 or newer.
       </para>
 
       <para>
@@ -1497,10 +1502,10 @@
 
       <para>
         In other words, there are no measures to take when upgrading to
-        &current-series;, except that the slaves must be
+        MySQL &current-series;, except that the slaves must be MySQL
         &current-series; before you can upgrade the master to
         &current-series;. Note that downgrading from &current-series; to
-        older versions does not work so simply: you must ensure that any
+        older versions does not work so simply: You must ensure that any
         &current-series; binary logs or relay logs have been fully
         processed, so that you can remove them before proceeding with
         the downgrade.
@@ -1608,10 +1613,9 @@
 
       <listitem>
         <para>
-          Replication is done correctly with
-          <literal>AUTO_INCREMENT</literal>,
+          Replication of <literal>AUTO_INCREMENT</literal>,
           <literal>LAST_INSERT_ID()</literal>, and
-          <literal>TIMESTAMP</literal> values.
+          <literal>TIMESTAMP</literal> values is done correctly.
         </para>
       </listitem>
 
@@ -1619,7 +1623,7 @@
         <para>
           The <literal>USER()</literal>, <literal>UUID()</literal>, and
           <literal>LOAD_FILE()</literal> functions are replicated
-          without changes and thus do not work reliably on the slave.
+          without change and thus do not work reliably on the slave.
         </para>
       </listitem>
 
@@ -1627,15 +1631,16 @@
         <para>
           <emphasis>The following restriction applies to statement-based
           replication only, not to row-based replication.</emphasis> The
-          functions handling user-level locks:
           <literal>GET_LOCK()</literal>,
           <literal>RELEASE_LOCK()</literal>,
-          <literal>IS_FREE_LOCK()</literal>,
-          <literal>IS_USED_LOCK()</literal> are replicated without the
-          slave knowing the concurrency context on master; so these
-          functions should not be used to insert into a master's table
-          as the content on slave would differ (i.e. do not do
-          <literal>INSERT INTO mytable VALUES(GET_LOCK(...))</literal>).
+          <literal>IS_FREE_LOCK()</literal>, and
+          <literal>IS_USED_LOCK()</literal> functions that handle
+          user-level locks are replicated without the slave knowing the
+          concurrency context on master. Therefore, these functions
+          should not be used to insert into a master's table because the
+          content on the slave would differ. (For example, do not issue
+          a statement such as <literal>INSERT INTO mytable
+          VALUES(GET_LOCK(...))</literal>.)
         </para>
       </listitem>
 
@@ -1645,10 +1650,10 @@
           <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>TABLE_TYPE</literal>, also known as
-          <literal>STORAGE_ENGINE</literal> variable is not yet
-          replicated, which is a good thing for replication between
-          different storage engines.
+          <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.
         </para>
       </listitem>
 
@@ -1665,21 +1670,21 @@
       <listitem>
         <para>
           The following applies to replication between MySQL servers
-          using different character sets:
+          that use different character sets:
         </para>
 
         <orderedlist>
 
           <listitem>
             <para>
-              You must <emphasis role="bold">always</emphasis> use the
-              same <emphasis role="bold">global</emphasis> character set
-              and collation (<option>--character-set-server</option>,
-              <option>--collation-server</option>) on the master and the
-              slave. Otherwise, you may get duplicate-key errors on the
-              slave, because a key that is regarded as unique in the
-              master's character set may not be unique in the slave's
-              character set.
+              You must <emphasis>always</emphasis> use the same
+              <emphasis>global</emphasis> character set and collation on
+              the master and the slave. (These are controlled by the
+              <option>--character-set-server</option> and
+              <option>--collation-server</option> options.) Otherwise,
+              you may get duplicate-key errors on the slave, because a
+              key that is unique in the master character set might not
+              be unique in the slave character set.
             </para>
           </listitem>
 

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-29 22:54:41 UTC (rev 1111)
+++ trunk/refman-5.1/replication.xml	2006-01-29 22:55:04 UTC (rev 1112)
@@ -1485,14 +1485,14 @@
 </programlisting>
 
         <para>
-          The following table shows the maximum length for the string
-          options:
+          The following table shows the maximum allowable length for the
+          string-valued options:
         </para>
 
         <informaltable>
           <tgroup cols="2">
-            <colspec colwidth="40*"/>
             <colspec colwidth="20*"/>
+            <colspec colwidth="20*"/>
             <tbody>
               <row>
                 <entry><literal>MASTER_HOST</literal></entry>
@@ -1535,18 +1535,19 @@
 
     <para>
       If you have forgotten to set the <literal>server-id</literal>
-      value for the master, slaves are not able to connect to it.
+      option for the master, slaves cannot connect to it.
     </para>
 
     <para>
       If you have forgotten to set the <literal>server-id</literal>
-      value for the slave, you get the following error in the slave's
+      option for the slave, you get the following error in the slave's
       error log:
     </para>
 
 <programlisting>
-Warning: You should set server-id to a non-0 value if master_host is set;
-we will force server id to 2, but this MySQL server will not act as a slave.
+Warning: You should set server-id to a non-0 value if master_host
+is set; we will force server id to 2, but this MySQL server will
+not act as a slave.
 </programlisting>
 
     <para>
@@ -1562,21 +1563,24 @@
       processed. Do <emphasis>not</emphasis> remove or edit these files
       unless you know exactly what you are doing and fully understand
       the implications. Even in that case, it is preferred that you use
-      the <literal>CHANGE MASTER TO</literal> statement.
+      the <literal>CHANGE MASTER TO</literal> statement to change
+      replication parameters. The slave will use the values specified in
+      the statement to update the status files automatically.
     </para>
 
     <para>
       <emphasis role="bold">Note</emphasis>: The content of
-      <filename>master.info</filename> overrides some of the options
-      specified on the command line or in <filename>my.cnf</filename>.
-      See <xref linkend="replication-options"/>, for more details.
+      <filename>master.info</filename> overrides some of the server
+      options specified on the command line or in
+      <filename>my.cnf</filename>. See
+      <xref linkend="replication-options"/>, for more details.
     </para>
 
     <para>
-      Once you have a snapshot, you can use it to set up other slaves by
-      following the slave portion of the procedure just described. You
-      do not need to take another snapshot of the master; you can use
-      the same one for each slave.
+      Once you have a snapshot of the master, you can use it to set up
+      other slaves by following the slave portion of the procedure just
+      described. You do not need to take another snapshot of the master;
+      you can use the same one for each slave.
     </para>
 
   </section>
@@ -1593,14 +1597,6 @@
     </para>
 
     <para>
-      <emphasis role="bold">Note</emphasis>: You cannot replicate from a
-      master that uses a newer binary log format to a slave that uses an
-      older format (for example, from MySQL 5.0 to MySQL 4.1.) This has
-      significant consequences for upgrading servers in a replication
-      setup, as described in <xref linkend="replication-upgrade"/>.
-    </para>
-
-    <para>
       We recommend using the most recent MySQL version available because
       replication capabilities are continually being improved. We also
       recommend using the same version for both the master and the
@@ -1613,6 +1609,15 @@
     </para>
 
     <para>
+      <emphasis role="bold">Note</emphasis>: You
+      <emphasis>cannot</emphasis> replicate from a master that uses a
+      newer binary log format to a slave that uses an older format (for
+      example, from MySQL 5.0 to MySQL 4.1.) This has significant
+      implications for upgrading replication servers, as described in
+      <xref linkend="replication-upgrade"/>.
+    </para>
+
+    <para>
       The preceding information pertains to replication compatibility at
       the protocol level. However, there can be other constraints, such
       as SQL-level compatibility issues. For example, a &current-series;
@@ -1640,8 +1645,8 @@
 
       <para>
         This section applies to upgrading replication from MySQL 3.23,
-        4.0, or 4.1 to &current-series;. A 4.0 server should be 4.0.3 or
-        newer.
+        4.0, or 4.1 to MySQL &current-series;. A 4.0 server should be
+        4.0.3 or newer.
       </para>
 
       <para>
@@ -1670,20 +1675,20 @@
 
       <para>
         In other words, there are no measures to take when upgrading to
-        &current-series;, except that the slaves must be
+        MySQL &current-series;, except that the slaves must be MySQL
         &current-series; before you can upgrade the master to
         &current-series;. Note that downgrading from &current-series; to
-        older versions does not work so simply: you must ensure that any
+        older versions does not work so simply: You must ensure that any
         &current-series; binary logs or relay logs have been fully
         processed, so that you can remove them before proceeding with
         the downgrade.
       </para>
 
       <para>
-        Note that downgrading a replication setup to a previous version
-        cannot be done once you've switched from statement-based to
-        row-based replication, and after the first row-based statement
-        has been written to the binlog. See
+        Downgrading a replication setup to a previous version cannot be
+        done once you've switched from statement-based to row-based
+        replication, and after the first row-based statement has been
+        written to the binlog. See
         <xref linkend="replication-row-based"/>.
       </para>
 
@@ -1766,10 +1771,9 @@
 
       <listitem>
         <para>
-          Replication is done correctly with
-          <literal>AUTO_INCREMENT</literal>,
+          Replication of <literal>AUTO_INCREMENT</literal>,
           <literal>LAST_INSERT_ID()</literal>, and
-          <literal>TIMESTAMP</literal> values.
+          <literal>TIMESTAMP</literal> values is done correctly.
         </para>
       </listitem>
 
@@ -1777,7 +1781,7 @@
         <para>
           The <literal>USER()</literal>, <literal>UUID()</literal>, and
           <literal>LOAD_FILE()</literal> functions are replicated
-          without changes and thus do not work reliably on the slave.
+          without change and thus do not work reliably on the slave.
         </para>
       </listitem>
 
@@ -1785,15 +1789,16 @@
         <para>
           <emphasis>The following restriction applies to statement-based
           replication only, not to row-based replication.</emphasis> The
-          functions handling user-level locks:
           <literal>GET_LOCK()</literal>,
           <literal>RELEASE_LOCK()</literal>,
-          <literal>IS_FREE_LOCK()</literal>,
-          <literal>IS_USED_LOCK()</literal> are replicated without the
-          slave knowing the concurrency context on master; so these
-          functions should not be used to insert into a master's table
-          as the content on slave would differ (i.e. do not do
-          <literal>INSERT INTO mytable VALUES(GET_LOCK(...))</literal>).
+          <literal>IS_FREE_LOCK()</literal>, and
+          <literal>IS_USED_LOCK()</literal> functions that handle
+          user-level locks are replicated without the slave knowing the
+          concurrency context on master. Therefore, these functions
+          should not be used to insert into a master's table because the
+          content on the slave would differ. (For example, do not issue
+          a statement such as <literal>INSERT INTO mytable
+          VALUES(GET_LOCK(...))</literal>.)
         </para>
       </listitem>
 
@@ -1803,10 +1808,10 @@
           <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>TABLE_TYPE</literal>, also known as
-          <literal>STORAGE_ENGINE</literal> variable is not yet
-          replicated, which is a good thing for replication between
-          different storage engines.
+          <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.
         </para>
       </listitem>
 
@@ -1821,21 +1826,21 @@
       <listitem>
         <para>
           The following applies to replication between MySQL servers
-          using different character sets:
+          that use different character sets:
         </para>
 
         <orderedlist>
 
           <listitem>
             <para>
-              You must <emphasis role="bold">always</emphasis> use the
-              same <emphasis role="bold">global</emphasis> character set
-              and collation (<option>--character-set-server</option>,
-              <option>--collation-server</option>) on the master and the
-              slave. Otherwise, you may get duplicate-key errors on the
-              slave, because a key that is regarded as unique in the
-              master's character set may not be unique in the slave's
-              character set.
+              You must <emphasis>always</emphasis> use the same
+              <emphasis>global</emphasis> character set and collation on
+              the master and the slave. (These are controlled by the
+              <option>--character-set-server</option> and
+              <option>--collation-server</option> options.) Otherwise,
+              you may get duplicate-key errors on the slave, because a
+              key that is unique in the master character set might not
+              be unique in the slave character set.
             </para>
           </listitem>
 

Thread
svn commit - mysqldoc@docsrva: r1112 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul29 Jan