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

Log:
 r6868@frost:  paul | 2006-01-29 14:56:11 -0600
 Cleanup revisions.


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


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

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-29 21:32:03 UTC (rev 1107)
+++ trunk/refman-4.1/innodb.xml	2006-01-29 21:32:25 UTC (rev 1108)
@@ -1292,7 +1292,7 @@
           For the greatest possible durability and consistency in a
           replication setup you should use
           <literal>innodb_flush_log_at_trx_commit=1</literal>,
-          <literal>sync-binlog=1</literal>, and
+          <literal>sync_binlog=1</literal>, and
           <literal>innodb_safe_binlog</literal> in your master server
           <filename>my.cnf</filename> file.
         </para>

Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2006-01-29 21:32:03 UTC (rev 1107)
+++ trunk/refman-4.1/replication.xml	2006-01-29 21:32:25 UTC (rev 1108)
@@ -112,7 +112,7 @@
           to the slave to reduce the query processing load of the
           master. Statements that modify data should still be sent to
           the master so that the master and slave do not get out of
-          sync. This load-balancing strategy is effective if
+          synchrony. This load-balancing strategy is effective if
           non-updating queries dominate, but that is the normal case.
         </para>
       </listitem>
@@ -1456,7 +1456,7 @@
       replication setup using <literal>InnoDB</literal> with
       transactions you should use
       <literal>innodb_flush_log_at_trx_commit=1</literal>,
-      <literal>sync-binlog=1</literal>, and
+      <literal>sync_binlog=1</literal>, and
       <literal>innodb_safe_binlog</literal> in your master
       <filename>my.cnf</filename> file.
     </para>
@@ -2109,7 +2109,7 @@
           If you update transactional tables from non-transactional
           tables inside a
           <literal>BEGIN</literal>/<literal>COMMIT</literal> sequence,
-          updates to the binary log may be out of sync if the
+          updates to the binary log may be out of synchrony if the
           non-transactional table is updated before the transaction
           commits. This is because the transaction is written to the
           binary log only when it is committed.
@@ -3596,7 +3596,7 @@
       of this is that, at any given time, the slave is not guaranteed to
       be in synchrony with the master unless you take some special
       measures. In the future, we will have the option to block the
-      master until at least one slave is in sync.
+      master until at least one slave is synchronized.
     </para>
 
     <para>
@@ -4326,11 +4326,11 @@
         <para>
           Verify that no user error is involved. For example, if you
           update the slave outside of the slave thread, the data goes
-          out of sync, and you can have unique key violations on
+          out of synchrony, and you can have unique key violations on
           updates. In this case, the slave thread stops and waits for
-          you to clean up the tables manually to bring them in sync.
-          <emphasis>This is not a replication problem. It is a problem
-          with outside interference causing replication to
+          you to clean up the tables manually to bring them into
+          synchrony. <emphasis>This is not a replication problem. It is
+          a problem with outside interference causing replication to
           fail.</emphasis>
         </para>
       </listitem>

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-29 21:32:03 UTC (rev 1107)
+++ trunk/refman-5.0/innodb.xml	2006-01-29 21:32:25 UTC (rev 1108)
@@ -1293,7 +1293,7 @@
           For the greatest possible durability and consistency in a
           replication setup you should use
           <literal>innodb_flush_log_at_trx_commit=1</literal>,
-          <literal>sync-binlog=1</literal>, and, before MySQL 5.0.3,
+          <literal>sync_binlog=1</literal>, and, before MySQL 5.0.3,
           <literal>innodb_safe_binlog</literal> in your master server
           <filename>my.cnf</filename> file.
           (<literal>innodb_safe_binlog</literal> is not needed from

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-29 21:32:03 UTC (rev 1107)
+++ trunk/refman-5.0/replication.xml	2006-01-29 21:32:25 UTC (rev 1108)
@@ -116,7 +116,7 @@
           to the slave to reduce the query processing load of the
           master. Statements that modify data should still be sent to
           the master so that the master and slave do not get out of
-          sync. This load-balancing strategy is effective if
+          synchrony. This load-balancing strategy is effective if
           non-updating queries dominate, but that is the normal case.
         </para>
       </listitem>
@@ -1384,7 +1384,7 @@
       replication setup using <literal>InnoDB</literal> with
       transactions you should use
       <literal>innodb_flush_log_at_trx_commit=1</literal>,
-      <literal>sync-binlog=1</literal>, and, before MySQL 5.0.3,
+      <literal>sync_binlog=1</literal>, and, before MySQL 5.0.3,
       <literal>innodb_safe_binlog</literal>, in the master
       <filename>my.cnf</filename> file.
       (<literal>innodb_safe_binlog</literal> is not needed from 5.0.3
@@ -2073,7 +2073,7 @@
           If you update transactional tables from non-transactional
           tables inside a
           <literal>BEGIN</literal>/<literal>COMMIT</literal> sequence,
-          updates to the binary log may be out of sync if the
+          updates to the binary log may be out of synchrony if the
           non-transactional table is updated before the transaction
           commits. This is because the transaction is written to the
           binary log only when it is committed.
@@ -3495,7 +3495,7 @@
       of this is that, at any given time, the slave is not guaranteed to
       be in synchrony with the master unless you take some special
       measures. In the future, we will have the option to block the
-      master until at least one slave is in sync.
+      master until at least one slave is synchronized.
     </para>
 
     <para>
@@ -4221,11 +4221,11 @@
         <para>
           Verify that no user error is involved. For example, if you
           update the slave outside of the slave thread, the data goes
-          out of sync, and you can have unique key violations on
+          out of synchrony, and you can have unique key violations on
           updates. In this case, the slave thread stops and waits for
-          you to clean up the tables manually to bring them in sync.
-          <emphasis>This is not a replication problem. It is a problem
-          with outside interference causing replication to
+          you to clean up the tables manually to bring them into
+          synchrony. <emphasis>This is not a replication problem. It is
+          a problem with outside interference causing replication to
           fail.</emphasis>
         </para>
       </listitem>

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-29 21:32:03 UTC (rev 1107)
+++ trunk/refman-5.1/innodb.xml	2006-01-29 21:32:25 UTC (rev 1108)
@@ -1289,7 +1289,7 @@
           For the greatest possible durability and consistency in a
           replication setup you should use
           <literal>innodb_flush_log_at_trx_commit=1</literal> and
-          <literal>sync-binlog=1</literal> in your master server
+          <literal>sync_binlog=1</literal> in your master server
           <filename>my.cnf</filename> file.
         </para>
       </listitem>

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-29 21:32:03 UTC (rev 1107)
+++ trunk/refman-5.1/replication.xml	2006-01-29 21:32:25 UTC (rev 1108)
@@ -147,7 +147,7 @@
           to the slave to reduce the query processing load of the
           master. Statements that modify data should still be sent to
           the master so that the master and slave do not get out of
-          sync. This load-balancing strategy is effective if
+          synchrony. This load-balancing strategy is effective if
           non-updating queries dominate, but that is the normal case.
         </para>
       </listitem>
@@ -1589,7 +1589,7 @@
       replication setup using <literal>InnoDB</literal> with
       transactions you should use
       <literal>innodb_flush_log_at_trx_commit=1</literal> and
-      <literal>sync-binlog=1</literal> in the master
+      <literal>sync_binlog=1</literal> in the master
       <filename>my.cnf</filename> file.
     </para>
 
@@ -2240,7 +2240,7 @@
           If you update transactional tables from non-transactional
           tables inside a
           <literal>BEGIN</literal>/<literal>COMMIT</literal> sequence,
-          updates to the binary log may be out of sync if the
+          updates to the binary log may be out of synchrony if the
           non-transactional table is updated before the transaction
           commits. This is because the transaction is written to the
           binary log only when it is committed.
@@ -3679,7 +3679,7 @@
       of this is that, at any given time, the slave is not guaranteed to
       be in synchrony with the master unless you take some special
       measures. In the future, we will have the option to block the
-      master until at least one slave is in sync.
+      master until at least one slave is synchronized.
     </para>
 
     <para>
@@ -4753,12 +4753,12 @@
           <para>
             Verify that no user error is involved. For example, if you
             update the slave outside of the slave thread, the data goes
-            out of sync, and you can have unique key violations on
+            out of synchrony, and you can have unique key violations on
             updates. In this case, the slave thread stops and waits for
-            you to clean up the tables manually to bring them in sync.
-            <emphasis>This is not a replication problem. It is a problem
-            with outside interference causing replication to
-            fail.</emphasis>
+            you to clean up the tables manually to bring them into
+            synchrony. <emphasis>This is not a replication problem. It
+            is a problem with outside interference causing replication
+            to fail.</emphasis>
           </para>
         </listitem>
 

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