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.1 | paul | 29 Jan |
