Author: paul
Date: 2006-01-30 05:31:49 +0100 (Mon, 30 Jan 2006)
New Revision: 1117
Log:
r6887@frost: paul | 2006-01-29 21:37:27 -0600
General revisions.
Modified:
trunk/
trunk/refman-5.0/replication.xml
trunk/refman-5.1/replication.xml
trunk/refman-common/titles.en.ent
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6886
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6887
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml 2006-01-30 04:31:33 UTC (rev 1116)
+++ trunk/refman-5.0/replication.xml 2006-01-30 04:31:49 UTC (rev 1117)
@@ -4392,8 +4392,9 @@
<para>
When multiple servers are configured as replication masters,
special steps must be taken to prevent key collisions when using
- auto_increment, otherwise multiple masters may attempt to use the
- same auto_increment value when inserting rows.
+ <literal>AUTO_INCREMENT</literal> columns, otherwise multiple
+ masters may attempt to use the same
+ <literal>AUTO_INCREMENT</literal> value when inserting rows.
</para>
<para>
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2006-01-30 04:31:33 UTC (rev 1116)
+++ trunk/refman-5.1/replication.xml 2006-01-30 04:31:49 UTC (rev 1117)
@@ -4290,7 +4290,7 @@
<para>
<emphasis role="bold">Q</emphasis>: How do I tell whether a master
- server is using statement-based or row-based replication logging
+ server is using statement-based or row-based binary logging
format?
</para>
@@ -4325,30 +4325,35 @@
<title>&title-replication-sbr-rbr;</title>
<para>
- Advantages of statement-based replication are:
+ Each binary logging format has advantages and disadvantages. This
+ section summarizes them to give you a better basis for choosing
+ the format most appropriate for your situation.
</para>
+ <para>
+ Advantages of statement-based replication:
+ </para>
+
<itemizedlist>
<listitem>
<para>
- Proven technology (existed in MySQL since 3.23).
+ Proven technology that has existed in MySQL since 3.23.
</para>
</listitem>
<listitem>
<para>
- Smaller log files (when using updates or deletes that affects
- many rows, much smaller log files). Because log files are
- smaller, they take up less storage space and are faster to
- back up.
+ Smaller log files. When updates or deletes affect many rows,
+ <emphasis>much</emphasis> smaller log files. Smaller log files
+ require less storage space and are faster to back up.
</para>
</listitem>
<listitem>
<para>
- Log files contain all statements that made any changes, which
- allow them to be used to audit the database.
+ Log files contain all statements that made any changes, so
+ they can be used to audit the database.
</para>
</listitem>
@@ -4361,8 +4366,12 @@
</listitem>
<listitem>
+ <remark role="todo">
+ [pd] What does this mean?
+ </remark>
+
<para>
- Slave may be a newer version of MySQL with a different row
+ A slave can be a newer version of MySQL with a different row
structure.
</para>
</listitem>
@@ -4370,7 +4379,7 @@
</itemizedlist>
<para>
- Disadvantages of statement-based replication are:
+ Disadvantages of statement-based replication:
</para>
<itemizedlist>
@@ -4378,21 +4387,21 @@
<listitem>
<para>
Not all <literal>UPDATE</literal> statements can be
- replicated: Any non-deterministic behavior, for example when
- using random functions in an SQL statement, is hard to
- replicate when using statement-based replication. When using a
- non-deterministic user-defined function (UDF), it is not
- possible to replicate the result using statement-based
- replication, while row-based replication will just replicate
- the value returned by the UDF.
+ replicated: Any non-deterministic behavior (for example, when
+ using random functions in an SQL statement) is hard to
+ replicate when using statement-based replication. For
+ statements that use a non-deterministic user-defined function
+ (UDF), it is not possible to replicate the result using
+ statement-based replication, whereas row-based replication
+ will just replicate the value returned by the UDF.
</para>
</listitem>
<listitem>
<para>
- Statements that use a UDF (user-defined function) which is
- non-deterministic (value depends on other things than the
- given parameters) cannot be replicated properly.
+ Statements cannot be replicated properly if they use a UDF
+ that is non-deterministic (its value depends on other things
+ than the given parameters).
</para>
</listitem>
@@ -4439,16 +4448,16 @@
<listitem>
<para>
- <literal>INSERT … SELECT</literal> requires more
- row-level locks than with row-level replication.
+ <literal>INSERT ... SELECT</literal> requires a greater number
+ of row-level locks than with row-based replication.
</para>
</listitem>
<listitem>
<para>
<literal>UPDATE</literal> statements that require a table scan
- (that is don't use indexes in the <literal>WHERE</literal>
- clause) have to lock more rows than with row-level
+ (because no index is used in the <literal>WHERE</literal>
+ clause) must lock a greater number of rows than with row-based
replication.
</para>
</listitem>
@@ -4456,13 +4465,16 @@
<listitem>
<para>
For <literal>InnoDB</literal>: An <literal>INSERT</literal>
- statement that uses <literal>auto_increment</literal> will
- block other non-conflicting <literal>INSERT</literal>
- statements.
+ statement that uses <literal>AUTO_INCREMENT</literal> blocks
+ other non-conflicting <literal>INSERT</literal> statements.
</para>
</listitem>
<listitem>
+ <remark role="todo">
+ [pd] What does "apply data" mean?
+ </remark>
+
<para>
Slower to apply data on slave for complex queries.
</para>
@@ -4472,18 +4484,22 @@
<para>
Stored functions (not stored procedures) will execute with the
same <literal>NOW()</literal> value as the calling statement.
- (This may be regarded both as a bad and a good thing.)
+ (This may be regarded both as a bad thing and a good thing.)
</para>
</listitem>
<listitem>
<para>
- Deterministic UDFs (user-defined functions) must be applied on
- the slaves.
+ Deterministic UDFs must be applied on the slaves.
</para>
</listitem>
<listitem>
+ <remark role="todo">
+ [pd] "getting something wrong"? Does this mean "when errors
+ occur"?
+ </remark>
+
<para>
When getting something wrong on the slave, the difference
between master and slave will grow with time.
@@ -4499,59 +4515,59 @@
</itemizedlist>
<para>
- Advantages of row-level replication are:
+ Advantages of row-based replication:
</para>
<itemizedlist>
<listitem>
<para>
- Everything can be replicated; safest form of replication. Note
- that currently, DDL (data definition language) statements such
- as <literal>CREATE TABLE</literal> are replicated using
- statement-based replication, while DML (data manipulation
- language) statements, as well as <literal>GRANT</literal> and
- <literal>REVOKE</literal> statements, are replicated using
- row-based-replication. For statements like <literal>CREATE
- … SELECT</literal>, a <literal>CREATE</literal>
- statement is generated from the table definition and
- replicated statement-based, while the row insertions are
- replicated row-based.
+ Everything can be replicated. This is the safest form of
+ replication. Note that currently, DDL (data definition
+ language) statements such as <literal>CREATE TABLE</literal>
+ are replicated using statement-based replication, while DML
+ (data manipulation language) statements, as well as
+ <literal>GRANT</literal> and <literal>REVOKE</literal>
+ statements, are replicated using row-based-replication. For
+ statements like <literal>CREATE ... SELECT</literal>, a
+ <literal>CREATE</literal> statement is generated from the
+ table definition and replicated statement-based, while the row
+ insertions are replicated row-based.
</para>
</listitem>
<listitem>
<para>
- Same technology as most other database management systems
- (easier to explain to database administrators used to other
- systems).
+ The technology is the same as most other database management
+ systems; knowledge about other systems transfers to MySQL.
</para>
</listitem>
<listitem>
<para>
- In many cases, faster to apply data on the slave on tables
- with primary keys.
+ In many cases, it is faster to apply data on the slave for
+ tables that have primary keys.
</para>
</listitem>
<listitem>
<para>
- Less locks needed (thus higher concurrency) on the master for:
+ Fewer locks needed (andthus higher concurrency) on the master
+ for the following types of statements:
</para>
<itemizedlist>
<listitem>
<para>
- <literal>INSERT … SELECT</literal>
+ <literal>INSERT ... SELECT</literal>
</para>
</listitem>
<listitem>
<para>
<literal>INSERT</literal> statements with
- <literal>auto_increment</literal>
+ <literal>AUTO_INCREMENT</literal>
</para>
</listitem>
@@ -4568,7 +4584,7 @@
<listitem>
<para>
- Less locks on the slave for any <literal>INSERT</literal>,
+ Fewer locks on the slave for any <literal>INSERT</literal>,
<literal>UPDATE</literal>, or <literal>DELETE</literal>
statement.
</para>
@@ -4584,14 +4600,14 @@
</itemizedlist>
<para>
- Disadvantages of row-level replication are:
+ Disadvantages of row-based replication:
</para>
<itemizedlist>
<listitem>
<para>
- Bigger log files (much bigger in some cases).
+ Larger log files (much larger in some cases).
</para>
</listitem>
@@ -4606,34 +4622,33 @@
<para>
When using row-based replication to replicate a statement (for
example, an <literal>UPDATE</literal> or
- <literal>DELETE</literal> statement), each changed row has to
- be written to the binary log. In contrast, when using
- statement-based replication only the statement is written to
- the binary log. If the statement changes a lot of rows,
- row-based replication may write significantly more data to the
- binary log. In these cases the binary log will be locked for
- longer times to write the data, which may cause concurrency
- problems.
+ <literal>DELETE</literal> statement), each changed row must be
+ written to the binary log. In contrast, when using
+ statement-based replication, only the statement is written to
+ the binary log. If the statement changes many rows, row-based
+ replication may write significantly more data to the binary
+ log. In these cases the binary log will be locked for a longer
+ time to write the data, which may cause concurrency problems.
</para>
</listitem>
<listitem>
<para>
- Deterministic UDFs that generate big <literal>BLOB</literal>s
- will be notably slower to replicate.
+ Deterministic UDFs that generate large <literal>BLOB</literal>
+ values will be notably slower to replicate.
</para>
</listitem>
<listitem>
<para>
- One can't examine the logs to see what statements were
+ You cannot examine the logs to see what statements were
executed.
</para>
</listitem>
<listitem>
<para>
- One can't see on the slave what statements were received from
+ You cannot see on the slave what statements were received from
the master and executed.
</para>
</listitem>
@@ -4926,8 +4941,9 @@
<para>
When multiple servers are configured as replication masters,
special steps must be taken to prevent key collisions when using
- auto_increment, otherwise multiple masters may attempt to use
- the same auto_increment value when inserting rows.
+ <literal>AUTO_INCREMENT</literal> columns, otherwise multiple
+ masters may attempt to use the same
+ <literal>AUTO_INCREMENT</literal> value when inserting rows.
</para>
<para>
Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent 2006-01-30 04:31:33 UTC (rev 1116)
+++ trunk/refman-common/titles.en.ent 2006-01-30 04:31:49 UTC (rev 1117)
@@ -1422,7 +1422,7 @@
<!ENTITY title-replace-for-manpage "a string-replacement utility">
<!ENTITY title-replace-for-manual "A String-Replacement Utility">
<!ENTITY title-replication "Replication in MySQL">
-<!ENTITY title-replication-auto-increment "Auto-Increment in Multi-Master Replication">
+<!ENTITY title-replication-auto-increment "Auto-Increment in Multiple-Master Replication">
<!ENTITY title-replication-bugs "How to Report Replication Bugs or Problems">
<!ENTITY title-replication-compatibility "Replication Compatibility Between MySQL Versions">
<!ENTITY title-replication-faq "Replication FAQ">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1117 - in trunk: . refman-5.0 refman-5.1 refman-common | paul | 30 Jan |
