List:Commits« Previous MessageNext Message »
From:paul Date:January 29 2006 9:32pm
Subject:svn commit - mysqldoc@docsrva: r1109 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-29 22:32:47 +0100 (Sun, 29 Jan 2006)
New Revision: 1109

Log:
 r6869@frost:  paul | 2006-01-29 15:27:16 -0600
 General revisions.
 Clean up initial RBR section a bit.


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:6868
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6869
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 21:32:25 UTC (rev 1108)
+++ trunk/refman-4.1/replication.xml	2006-01-29 21:32:47 UTC (rev 1109)
@@ -120,9 +120,9 @@
       <listitem>
         <para>
           Another benefit of using replication is that you can perform
-          backups using a slave server without disturbing the master.
-          The master continues to process updates while the backup is
-          being made. See <xref linkend="backup"/>.
+          database backups using a slave server without disturbing the
+          master. The master continues to process updates while the
+          backup is being made. See <xref linkend="backup"/>.
         </para>
       </listitem>
 
@@ -140,7 +140,7 @@
 
     <para>
       MySQL replication is based on the master server keeping track of
-      all changes to your databases (updates, deletes, and so on) in the
+      all changes to your databases (updates, deletes, and so on) in its
       binary logs. Therefore, to use replication, you must enable binary
       logging on the master server. See <xref linkend="binary-log"/>.
     </para>
@@ -164,14 +164,14 @@
 
     <para>
       One way to copy the master's data to the slave is to use the
-      <literal>LOAD DATA FROM MASTER</literal> statement. Be aware that
+      <literal>LOAD DATA FROM MASTER</literal> statement. However,
       <literal>LOAD DATA FROM MASTER</literal> is available only as of
-      MySQL 4.0.0 and currently works only if all the tables on the
-      master are <literal>MyISAM</literal> type. Also, this statement
-      acquires a global read lock, so no updates on the master are
-      possible while the tables are being transferred to the slave. When
-      we implement lock-free hot table backup, this global read lock
-      will no longer be necessary.
+      MySQL 4.0.0 and works only if all the tables on the master use the
+      <literal>MyISAM</literal> storage engine. In addition, this
+      statement acquires a global read lock, so no updates on the master
+      are possible while the tables are being transferred to the slave.
+      When we implement lock-free hot table backup, this global read
+      lock will no longer be necessary.
     </para>
 
     <para>
@@ -191,15 +191,15 @@
       it connects to the master and waits for updates to process. If the
       master fails, or the slave loses connectivity with your master,
       the slave keeps trying to connect periodically until it is able to
-      resume listening for updates. The retry interval is controlled by
-      the <option>--master-connect-retry</option> option. The default is
-      60 seconds.
+      resume listening for updates. The
+      <option>--master-connect-retry</option> option controls the retry
+      interval. The default is 60 seconds.
     </para>
 
     <para>
-      Each slave keeps track of where it left off. The master server has
-      no knowledge of how many slaves there are or of which ones are up
-      to date at any given time.
+      Each slave keeps track of where it left off when it last read from
+      its master server. The master has no knowledge of how many slaves
+      it has or which ones are up to date at any given time.
     </para>
 
   </section>

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-29 21:32:25 UTC (rev 1108)
+++ trunk/refman-5.0/replication.xml	2006-01-29 21:32:47 UTC (rev 1109)
@@ -124,9 +124,9 @@
       <listitem>
         <para>
           Another benefit of using replication is that you can perform
-          backups using a slave server without disturbing the master.
-          The master continues to process updates while the backup is
-          being made. See <xref linkend="backup"/>.
+          database backups using a slave server without disturbing the
+          master. The master continues to process updates while the
+          backup is being made. See <xref linkend="backup"/>.
         </para>
       </listitem>
 
@@ -144,7 +144,7 @@
 
     <para>
       MySQL replication is based on the master server keeping track of
-      all changes to your databases (updates, deletes, and so on) in the
+      all changes to your databases (updates, deletes, and so on) in its
       binary logs. Therefore, to use replication, you must enable binary
       logging on the master server. See <xref linkend="binary-log"/>.
     </para>
@@ -168,14 +168,13 @@
 
     <para>
       One way to copy the master's data to the slave is to use the
-      <literal>LOAD DATA FROM MASTER</literal> statement. Be aware that
-      <literal>LOAD DATA FROM MASTER</literal> currently works only if
-      all the tables on the master use the <literal>MyISAM</literal>
-      storage engine. In addition, this statement acquires a global read
-      lock, so no updates on the master are possible while the tables
-      are being transferred to the slave. When we implement lock-free
-      hot table backup, this global read lock will no longer be
-      necessary.
+      <literal>LOAD DATA FROM MASTER</literal> statement. However,
+      <literal>LOAD DATA FROM MASTER</literal> works only if all the
+      tables on the master use the <literal>MyISAM</literal> storage
+      engine. In addition, this statement acquires a global read lock,
+      so no updates on the master are possible while the tables are
+      being transferred to the slave. When we implement lock-free hot
+      table backup, this global read lock will no longer be necessary.
     </para>
 
     <para>
@@ -195,15 +194,15 @@
       it connects to the master and waits for updates to process. If the
       master fails, or the slave loses connectivity with your master,
       the slave keeps trying to connect periodically until it is able to
-      resume listening for updates. The retry interval is controlled by
-      the <option>--master-connect-retry</option> option. The default is
-      60 seconds.
+      resume listening for updates. The
+      <option>--master-connect-retry</option> option controls the retry
+      interval. The default is 60 seconds.
     </para>
 
     <para>
-      Each slave keeps track of where it left off. The master server has
-      no knowledge of how many slaves there are or of which ones are up
-      to date at any given time.
+      Each slave keeps track of where it left off when it last read from
+      its master server. The master has no knowledge of how many slaves
+      it has or which ones are up to date at any given time.
     </para>
 
   </section>

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-29 21:32:25 UTC (rev 1108)
+++ trunk/refman-5.1/replication.xml	2006-01-29 21:32:47 UTC (rev 1109)
@@ -155,9 +155,9 @@
       <listitem>
         <para>
           Another benefit of using replication is that you can perform
-          backups using a slave server without disturbing the master.
-          The master continues to process updates while the backup is
-          being made. See <xref linkend="backup"/>.
+          database backups using a slave server without disturbing the
+          master. The master continues to process updates while the
+          backup is being made. See <xref linkend="backup"/>.
         </para>
       </listitem>
 
@@ -175,7 +175,7 @@
 
     <para>
       MySQL replication is based on the master server keeping track of
-      all changes to your databases (updates, deletes, and so on) in the
+      all changes to your databases (updates, deletes, and so on) in its
       binary logs. Therefore, to use replication, you must enable binary
       logging on the master server. See <xref linkend="binary-log"/>.
     </para>
@@ -199,14 +199,13 @@
 
     <para>
       One way to copy the master's data to the slave is to use the
-      <literal>LOAD DATA FROM MASTER</literal> statement. Be aware that
-      <literal>LOAD DATA FROM MASTER</literal> currently works only if
-      all the tables on the master use the <literal>MyISAM</literal>
-      storage engine. In addition, this statement acquires a global read
-      lock, so no updates on the master are possible while the tables
-      are being transferred to the slave. When we implement lock-free
-      hot table backup, this global read lock will no longer be
-      necessary.
+      <literal>LOAD DATA FROM MASTER</literal> statement. However,
+      <literal>LOAD DATA FROM MASTER</literal> works only if all the
+      tables on the master use the <literal>MyISAM</literal> storage
+      engine. In addition, this statement acquires a global read lock,
+      so no updates on the master are possible while the tables are
+      being transferred to the slave. When we implement lock-free hot
+      table backup, this global read lock will no longer be necessary.
     </para>
 
     <para>
@@ -226,15 +225,15 @@
       it connects to the master and waits for updates to process. If the
       master fails, or the slave loses connectivity with your master,
       the slave keeps trying to connect periodically until it is able to
-      resume listening for updates. The retry interval is controlled by
-      the <option>--master-connect-retry</option> option. The default is
-      60 seconds.
+      resume listening for updates. The
+      <option>--master-connect-retry</option> option controls the retry
+      interval. The default is 60 seconds.
     </para>
 
     <para>
-      Each slave keeps track of where it left off. The master server has
-      no knowledge of how many slaves there are or of which ones are up
-      to date at any given time.
+      Each slave keeps track of where it left off when it last read from
+      its master server. The master has no knowledge of how many slaves
+      it has or which ones are up to date at any given time.
     </para>
 
   </section>
@@ -244,9 +243,14 @@
     <title>&title-replication-row-based;</title>
 
     <para>
-      <remark role="todo">
-        [SH] Provide a definition of row-based replication.
-      </remark>
+      Replication capabilities in MySQL originally were based on
+      propagation of SQL statements from master to slave. This is called
+      <firstterm>statement-based replication</firstterm> (SBR). As of
+      MySQL 5.1.5, another basis for replication is available. This is
+      called <firstterm>row-based replication</firstterm> (RBR). Instead
+      of sending SQL statements to the slave, the master writes events
+      to its binary log that indicate how individual table rows are
+      effected.
     </para>
 
     <para>
@@ -258,98 +262,67 @@
     </para>
 
     <para>
-      Row-based replication is available as of MySQL 5.1.5.
+      If you build MySQL from source, row-based replication is
+      unavailable unless you invoke <command>configure</command> with
+      the <option>--with-row-based-replication</option> option.
     </para>
 
     <para>
-      If you're building MySQL from source, it must be compiled with the
-      <option>--with-row-based-replication</option> switch to
-      <command>configure</command> to enable row-based replication.
+      MySQL Server use statement-based replication by default, even if
+      it has been configured with support for row-based replication. To
+      cause row-based replication to be used, start the server with the
+      <option>--binlog-format=row</option> option to enable row-based
+      replication globally (for all client connections). The option also
+      automatically turns on
+      <literal>innodb_locks_unsafe_for_binlog</literal>, which is safe
+      when row-based replication is used.
     </para>
 
     <para>
-      Even with row-based replication enabled, MySQL will still default
-      to using statement-based replication. If you want to use row-based
-      replication instead, you have to start the MySQL server with this
-      option:
+      Statement-based replication can be chosen at server startup either
+      by specifying <option>--binlog-format=statement</option> or by not
+      using the <option>--binlog-format</option> option at all.
     </para>
 
-<programlisting>
---binlog-format=row
-</programlisting>
-
-    <para>
-      This enables row-based replication
-      <emphasis>server-wide</emphasis>, and automatically turns on
-      <option>innodb_locks_unsafe_for_binlog</option> as it is safe in
-      this case.
-    </para>
-
 <!-- Remove comment when WL#2712 is implemented    
-    <para>
-      Setting <option>- -binlog-format=row</option> has the same effect
-      as setting the dynamic server system variable
-      <literal>BINLOG_FORMAT</literal> to a value of
-      <literal>ROW</literal>, like this:
-    </para>
 
-<programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'ROW';</userinput>
-</programlisting>
-
     <para>
-      Alternatively, you can set it to a value of <literal>2</literal>:
+      The logging format also can be selected at runtime. To specify the
+      format globally for all clients, set the global value of the
+      <literal>binlog_format</literal> system variable. To select
+      row-based format, use either of these statements:
     </para>
 
 <programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 2;</userinput>
+mysql> <userinput>SET GLOBAL binlog_format = 'ROW';</userinput>
+mysql> <userinput>SET GLOBAL binlog_format = 2;</userinput>
 </programlisting>
--->
 
     <para>
-      If you want to switch back to statement-based replication, restart
-      the server without the <literal>--binlog-format=row</literal>
-      option (statement-based replication is the default) or by
-      specifiying <option>--binlog-format=statement</option> explicitly.
+      To select statement-based format, use either of these statements:
     </para>
 
-<!--  Remove comment when WL#2712 is implemented         
-      Without restarting the server, you can set the dynamic
-      server system variable, like this:
-
 <programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'STMT';</userinput>
+mysql> <userinput>SET GLOBAL binlog_format = 'STATEMENT';</userinput>
+mysql> <userinput>SET GLOBAL binlog_format = 1;</userinput>
 </programlisting>
 
     <para>
-      Alternatively, you can set it to a value of <literal>1</literal>:
+      Individual clients can control the logging format for their own
+      statements by setting the session value of
+      <literal>binlog_format</literal>. For example:
     </para>
 
 <programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 1;</userinput>
+mysql> <userinput>SET SESSION binlog_format = 'STATEMENT';</userinput>
+mysql> <userinput>SET SESSION binlog_format = 'ROW';</userinput>
 </programlisting>
 -->
 
 <!--  Remove comment when WL#2712 is implemented         
-      The dynamic server system variable even allows you to set
-      replication logging on a per-connection basis. To enable
-      statement-based logging for a thread, rather than server-wide, you
-      would issue:
-
-  <para>
-  
-<programlisting>
-mysql> <userinput>SET LOCAL BINLOG_FORMAT = 'STMT';</userinput>
-</programlisting>
-
-      Alternatively, you can set it to a value of <literal>1</literal>:
-
-<programlisting>
-mysql> <userinput>SET LOCAL BINLOG_FORMAT = 1;</userinput>
-</programlisting>
-
-      Here are two reasons why you would want to set replication logging
-      on a per-connection basis:
+    <para>
+      There are two reasons why you might want to set replication
+      logging on a per-connection basis:
     </para>
 
     <itemizedlist>
@@ -365,9 +338,9 @@
 
       <listitem>
         <para>
-          Some statements require a lot of execution on the master, but
-          create a small result set. It might therefore be beneficial to
-          replicated them row-based.
+          Some statements require a lot of execution time on the master,
+          but create a small result set. It might therefore be
+          beneficial to replicated them row-based.
         </para>
       </listitem>
 
@@ -377,38 +350,37 @@
     <para>
       Row-based replication causes <emphasis>most</emphasis> changes to
       be written to the binary log using the row-based format. Some
-      changes, however, will still be written into the binary log as
-      statements:
+      changes, however, must be written to the binary log as statements:
     </para>
 
     <itemizedlist>
 
       <listitem>
         <para>
-          <literal>ANALYZE</literal>
+          <literal>ANALYZE TABLE</literal>
         </para>
       </listitem>
 
       <listitem>
         <para>
-          <literal>REPAIR</literal>
+          <literal>REPAIR TABLE</literal>
         </para>
       </listitem>
 
       <listitem>
         <para>
-          <literal>OPTIMIZE</literal>
+          <literal>OPTIMIZE TABLE</literal>
         </para>
       </listitem>
 
     </itemizedlist>
 
     <para>
-      There is another option you can use with row-based replication:
-      <option>binlog-row-event-max-size</option>. Rows are stored into
-      the binlog in chunks not exceeding this value, which needs to be a
-      multiple of 256. If you don't specify that option, the default
-      value will be 1024.
+      The <option>--binlog-row-event-max-size</option> is available for
+      servers that are capabile of row-based replication. Rows are
+      stored into the binary log in chunks having a size in bytes not
+      exceeding the value of this option. The value must be a multiple
+      of 256. The default value is 1024.
     </para>
 
   </section>

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