Author: jstephens
Date: 2008-08-09 09:49:42 +0200 (Sat, 09 Aug 2008)
New Revision: 11515
Log:
Reconcile conflicts between 5.1 and 6.0 versions of section
Plus wording, markup, other misc. fixes
Modified:
trunk/dynamic-docs/changelog/mysqld.xml
trunk/refman-5.1/replication-configuration.xml
trunk/refman-6.0/replication-configuration.xml
Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml 2008-08-09 00:22:04 UTC (rev 11514)
+++ trunk/dynamic-docs/changelog/mysqld.xml 2008-08-09 07:49:42 UTC (rev 11515)
Changed blocks: 3, Lines Added: 10, Lines Deleted: 12; 1968 bytes
@@ -16072,14 +16072,13 @@
<message>
<para>
- A slave server may switch the format
- <emphasis>automatically</emphasis> now. This happens when the
- server is running in either <literal>STATEMENT</literal> or
- <literal>MIXED</literal> format and encounters a row in the
- binary log that is written in <literal>ROW</literal> logging
- format. In that case, the slave switches to row-based
- replication temporarily for that event, and switches back to the
- previous format afterwards.
+ A slave server may now switch the replication format
+ automatically. This happens when the server is running in either
+ <literal>STATEMENT</literal> or <literal>MIXED</literal> format
+ and encounters a row in the binary log that is written in
+ <literal>ROW</literal> logging format. In that case, the slave
+ switches to row-based replication temporarily for that event,
+ and switches back to the previous format afterwards.
</para>
</message>
@@ -125583,8 +125582,7 @@
<para>
The <literal>binlog_format</literal> system variable now can be
set to a third format, <literal>MIXED</literal>, as described in
- <xref
- linkend="replication-formats"/>.
+ <xref linkend="replication-formats"/>.
</para>
</message>
@@ -130479,8 +130477,8 @@
<para>
Certain combinations of joins with mixed <literal>ON</literal>
- and <literal>USING</literal> clauses caused unknown column
- errors.
+ and <literal>USING</literal> claused caused <errortext>unknown
+ column</errortext> errors.
</para>
</message>
Modified: trunk/refman-5.1/replication-configuration.xml
===================================================================
--- trunk/refman-5.1/replication-configuration.xml 2008-08-09 00:22:04 UTC (rev 11514)
+++ trunk/refman-5.1/replication-configuration.xml 2008-08-09 07:49:42 UTC (rev 11515)
Changed blocks: 21, Lines Added: 153, Lines Deleted: 96; 18702 bytes
@@ -377,14 +377,20 @@
<para>
If you do not specify a <literal>server-id</literal> value, it
is set to 1 if you have not defined
- <literal>master-host</literal>; otherwise it is set to 2. Note
- that in the case of <literal>server-id</literal> omission, a
- master refuses connections from all slaves, and a slave refuses
- to connect to a master. Thus, omitting
- <literal>server-id</literal> is good only for backup with a
- binary log.
+ <literal>master-host</literal>; if you have set
+ <literal>master-host</literal>, then
+ <literal>server-id</literal> is set to 2.
</para>
+ <note>
+ <para>
+ If you omit <literal>server-id</literal>, a master refuses
+ connections from all slaves, and a slave refuses to connect to
+ a master. Thus, omitting <literal>server-id</literal> is good
+ only for backup with a binary log.
+ </para>
+ </note>
+
<para>
You do not have to enable binary logging on the slave for
replication to be enabled. However, if you enable binary logging
@@ -392,9 +398,9 @@
and crash recovery on the slave, and also use the slave as part
of a more complex replication topology.
-<!--For more information,
- see <xref
- linkend="replication-topology"/>.-->
+<!--
+ For more information, see <xref linkend="replication-topology"/>.
+-->
</para>
</section>
@@ -702,21 +708,21 @@
</para>
<programlisting>
-shell> mysqladmin shutdown
+shell> <userinput>mysqladmin shutdown</userinput>
</programlisting>
</listitem>
<listitem>
<para>
- Take a copy of the MySQL data files. Examples are shown
- below for common solutions - you need to choose only one of
- these solutions:
+ Make a copy of the MySQL data files. Examples are shown
+ below for common ways to do this - you need to choose only
+ one of them:
</para>
<programlisting>
-shell> tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable>
-shell> zip -r <replaceable>/tmp/db.zip</replaceable> <replaceable>./data</replaceable>
-shell> rsync --recursive <replaceable>./data</replaceable> <replaceable>/tmp/dbdata</replaceable>
+shell> <userinput>tar cf <replaceable>/tmp/db.tar</replaceable> <replaceable>./data</replaceable></userinput>
+shell> <userinput>zip -r <replaceable>/tmp/db.zip</replaceable> <replaceable>./data</replaceable></userinput>
+shell> <userinput>rsync --recursive <replaceable>./data</replaceable> <replaceable>/tmp/dbdata</replaceable></userinput>
</programlisting>
</listitem>
@@ -1310,33 +1316,36 @@
<para>
Replication capabilities in MySQL originally were based on
propagation of SQL statements from master to slave. This is
- called <emphasis>statement-based replication</emphasis> (SBR)
- and this correlates to the standard statement-based binary
- logging format. Binary logging and replication in MySQL 5.1.4
- and earlier, and all previous versions of MySQL, used this
- format.
+ called <firstterm>statement-based replication</firstterm>
+ (often abbreviated as <firstterm>SBR</firstterm>), which
+ corresponds to the standard statement-based binary logging
+ format. In MySQL 5.1.4 and earlier, binary logging and
+ replication used this format exclusively.
</para>
</listitem>
<listitem>
<para>
- Row-based binary logging logs the physical changes to
- individual table rows. In replication terms this is
- <emphasis>row-based replication</emphasis> (RBR), the master
- writes events to the binary log that indicate how individual
- table rows are affected. Support for RBR was added in MySQL
- 5.1.5.
+ Row-based binary logging logs changes in individual table
+ rows. When used with MySQL replication, this is known as
+ <firstterm>row-based replication</firstterm> (often
+ abbreviated as <firstterm>RBR</firstterm>). In row-based
+ replication, the master writes messages known as
+ <firstterm>events</firstterm> to the binary log that indicate
+ how individual table rows are changed.
</para>
</listitem>
<listitem>
<para>
- As of MySQL 5.1.8, the binary logging format can be altered on
- the fly according to the event being logged. With mixed-based
- logging (and the associated <emphasis>mixed-based
- replication</emphasis> (MBR)), statement-based logging is used
- by default, but automatically switches to row-based logging in
- particular cases as described below. See
+ As of MySQL 5.1.8, the binary logging format can be changed in
+ real time according to the event being logged when using
+ mixed-format logging. When the mixed format is in effect,
+ statement-based logging is used by default, but automatically
+ switches to row-based logging in particular cases as described
+ below. This is sometimes referred to as associated
+ <firstterm>mixed-based replication</firstterm> (abbreviated as
+ <firstterm>MBR</firstterm>). For more information, see
<xref linkend="binary-log-mixed"/>.
</para>
</listitem>
@@ -1344,40 +1353,41 @@
</itemizedlist>
<para>
- Starting with MySQL 5.1.12, mixed-based replication (that is,
- mixed-based logging) is the default format for all replication
- environment unless you specify otherwise.
+ Starting with MySQL 5.1.12, the mixed format is the for MySQL
+ replication.
</para>
<para>
- Starting with MySQL 5.1.20, the binary logging format used is
- partially determined by the storage engine being used and the
- statement being executed. For more information on mixed-based
+ Starting with MySQL 5.1.20, the binary logging format is
+ determined in part by the storage engine being used and the
+ statement being executed. For more information on mixed-format
logging and the rules governing the support of different logging
- formatsion, see <xref linkend="binary-log-mixed"/>.
+ formats, see <xref linkend="binary-log-mixed"/>.
</para>
<para>
- There are some known limitations and issues between the different
- replication formats. For a comparison that shows the advantages
- and disadvantages of statement-based and row-based replication,
- see <xref linkend="replication-sbr-rbr"/>.
+ The statement-based and row-based replication formats have
+ different issues and limitations. For a comparison of their
+ relative advantages and disadvantages, see
+ <xref linkend="replication-sbr-rbr"/>.
</para>
- <para>
- MySQL Cluster Replication makes use of row-based replication. The
- <literal>NDB</literal> storage engine is incompatible with
- statement-based replication, and <literal>NDB</literal> sets
- row-based logging format automatically. For more information, see
- <xref linkend="mysql-cluster-replication"/>.
- </para>
+ <note>
+ <para>
+ MySQL Cluster Replication always uses row-based replication, and
+ the <literal>NDBCLUSTER</literal> storage engine is incompatible
+ with statement-based replication. Using
+ <literal>NDBCLUSTER</literal> sets row-based logging format
+ automatically. For more information, see
+ <xref linkend="mysql-cluster-replication"/>.
+ </para>
+ </note>
<para>
- With MySQL's classic statement-based replication, there may be
- issues with replicating stored routines or triggers. You can avoid
- these issues by using MySQL's row-based replication instead. For a
- detailed list of issues, see
- <xref linkend="stored-procedure-logging"/>.
+ With statement-based replication, you may encounter issues with
+ replicating stored routines or triggers. You can avoid these
+ issues by using row-based replication instead. For more
+ information, see <xref linkend="stored-procedure-logging"/>.
</para>
<para>
@@ -1397,7 +1407,7 @@
<listitem>
<para>
- <link linkend="option_mysqld_sql_mode"><literal>SQL_MODE</literal></link>
+ <literal><link linkend="option_mysqld_sql_mode">SQL_MODE</link></literal>
</para>
</listitem>
@@ -1415,25 +1425,25 @@
<listitem>
<para>
- <link linkend="option_mysqld_character_set_client"><literal>CHARACTER_SET_CLIENT</literal></link>
+ <literal><link linkend="option_mysqld_character_set_client">CHARACTER_SET_CLIENT</link></literal>
</para>
</listitem>
<listitem>
<para>
- <link linkend="option_mysqld_collation_connection"><literal>COLLATION_CONNECTION</literal></link>
+ <literal><link linkend="option_mysqld_collation_connection">COLLATION_CONNECTION</link></literal>
</para>
</listitem>
<listitem>
<para>
- <link linkend="option_mysqld_collation_database"><literal>COLLATION_DATABASE</literal></link>
+ <literal><link linkend="option_mysqld_collation_database">COLLATION_DATABASE</link></literal>
</para>
</listitem>
<listitem>
<para>
- <link linkend="option_mysqld_collation_server"><literal>COLLATION_SERVER</literal></link>
+ <literal><link linkend="option_mysqld_collation_server">COLLATION_SERVER</link></literal>
</para>
</listitem>
@@ -1455,17 +1465,17 @@
<section id="replication-sbr-rbr">
- <title>Comparison of Statement-Based Versus Row-Based Replication</title>
+ <title>Comparison of Statement-Based and Row-Based Replication</title>
<para>
Each binary logging format has advantages and disadvantages. For
- most users, the mixed-based replication format should be fine
- and should provide the best combination of data integrity and
- performance. If, however, you want to take advantage of the
- differences in the replication format when performing specific
- updates or large data inserts, then the information in this
- section summarizes the advantages and disadvantages of the row
- and statement based formats.
+ most users, the mixed replication format should provide the best
+ combination of data integrity and performance. If, however, you
+ want to take advantage of the features specific to the
+ statement-based or row-based replication format when performing
+ certain tasks, then you can use the information in this section,
+ which provides a summary of their relative advantages and
+ disadvantages, to determine which is best for your needs.
</para>
<para>
@@ -1672,7 +1682,7 @@
<listitem>
<para>
- Everything can be replicated. This is the safest form of
+ All changes can be replicated. This is the safest form of
replication.
</para>
@@ -1686,29 +1696,32 @@
</para>
<para>
- For MySQL 5.1.14 and later, the <literal>mysql</literal>
+ In MySQL 5.1.14 and later, the <literal>mysql</literal>
database is not replicated. The <literal>mysql</literal>
- database is instead seen as a node specific database.
- Row-based replication is not supported on this table.
- Instead, statements that would normally update this
- information (including <literal>GRANT</literal>,
+ database is instead seen as a node-specific database.
+ Row-based replication is not supported on tables in this
+ database. Instead, statements that would normally update
+ this information — such as <literal>GRANT</literal>,
<literal>REVOKE</literal> and the manipulation of triggers,
- stored routines/procedures and views are all replicated to
- slaves using Statement based replication.
+ stored routines (including stored procedures), and views
+ — are all replicated to slaves using statement-based
+ replication.
</para>
<para>
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.
+ table definition and replicated using the statement-based
+ format, while the row insertions are replicated using the
+ row-based format.
</para>
</listitem>
<listitem>
<para>
- The technology is the same as most other database management
- systems; knowledge about other systems transfers to MySQL.
+ The technology is the same as in most other database
+ management systems; knowledge about other systems transfers
+ to MySQL.
</para>
</listitem>
@@ -2345,15 +2358,6 @@
</para>
<para>
- Because the server gives an existing
- <filename>master.info</filename> file precedence over the startup
- options just described, you might prefer not to use startup
- options for these values at all, and instead specify them by using
- the <literal>CHANGE MASTER TO</literal> statement. See
- <xref linkend="change-master-to"/>.
- </para>
-
- <para>
This example shows a more extensive use of startup options to
configure a slave server:
</para>
@@ -2369,6 +2373,17 @@
report-host=db-slave.mycompany.com
</programlisting>
+ <note>
+ <para>
+ Because the server gives an existing
+ <filename>master.info</filename> file precedence over the
+ startup options just described, you might prefer not to use
+ startup options for these values at all, and instead to specify
+ them by using the <literal>CHANGE MASTER TO</literal> statement.
+ See <xref linkend="change-master-to"/>.
+ </para>
+ </note>
+
<para>
The following list describes the options and variables used for
controlling replication. Many of these options can be reset while
@@ -2521,6 +2536,11 @@
reconnection attempts is limited by the
<option>--master-retry-count</option> option.
</para>
+
+ <para>
+ This option is deprecated as of MySQL 5.1.17, and removed in
+ MySQL 5.2.5 and later.
+ </para>
</listitem>
<listitem>
@@ -2544,6 +2564,11 @@
if it can be read. If no master host is specified, the slave
thread does not start.
</para>
+
+ <para>
+ This option is deprecated as of MySQL 5.1.17, and removed in
+ MySQL 5.2.5 and later.
+ </para>
</listitem>
<listitem>
@@ -2589,6 +2614,11 @@
the <filename>master.info</filename> file takes precedence if
it can be read. If not set, an empty password is assumed.
</para>
+
+ <para>
+ This option is deprecated as of MySQL 5.1.17, and removed in
+ MySQL 5.2.5 and later.
+ </para>
</listitem>
<listitem>
@@ -2612,6 +2642,11 @@
precedence if it can be read. If not set, the compiled-in
setting is assumed (normally 3306).
</para>
+
+ <para>
+ This option is deprecated as of MySQL 5.1.17, and removed in
+ MySQL 5.2.5 and later.
+ </para>
</listitem>
<listitem>
@@ -2637,6 +2672,17 @@
to the <option>--slave-net-timeout</option> option. The
default value is 86400.
</para>
+
+ <note>
+ <para>
+ The <command>mysqld</command> option
+ <option>--master-connect-retry</option> is deprecated as of
+ MySQL 5.1.17, and removed in MySQL 5.2.5 and later. You
+ should use the <literal>MASTER_CONNECT_RETRY</literal>
+ option for the <literal>CHANGE MASTER TO</literal> statement
+ instead.
+ </para>
+ </note>
</listitem>
<listitem>
@@ -2720,6 +2766,11 @@
<filename>master.info</filename> file take precedence if they
can be read.
</para>
+
+ <para>
+ These options are deprecated as of MySQL 5.1.17, and removed
+ in MySQL 5.2.5 and later.
+ </para>
</listitem>
<listitem>
@@ -2745,6 +2796,11 @@
precedence if it can be read. If the master username is not
set, the name <literal>test</literal> is assumed.
</para>
+
+ <para>
+ This option is deprecated as of MySQL 5.1.17, and removed in
+ MySQL 5.2.5 and later.
+ </para>
</listitem>
<listitem>
@@ -2885,9 +2941,9 @@
<para>
Disable or enable automatic purging of relay logs as soon as
- they are not needed any more. The default value is 1
- (enabled). This is a global variable that can be changed
- dynamically with <literal>SET GLOBAL relay_log_purge =
+ they are no longer needed. The default value is 1 (enabled).
+ This is a global variable that can be changed dynamically with
+ <literal>SET GLOBAL relay_log_purge =
<replaceable>N</replaceable></literal>.
</para>
</listitem>
@@ -3651,9 +3707,10 @@
before the slave considers the connection broken, aborts the
read, and tries to reconnect. The first retry occurs
immediately after the timeout. The interval between retries is
- controlled by the <literal>CHANGE MASTER TO</literal>
- statement or <option>--master-connect-retry</option> option
- and the number of reconnection attempts is limited by the
+ controlled by the <literal>MASTER_CONNECT_RETRY</literal>
+ option for the <literal>CHANGE MASTER TO</literal> statement
+ or <option>--master-connect-retry</option> option, and the
+ number of reconnection attempts is limited by the
<option>--master-retry-count</option> option. The default is
3600 seconds (one hour).
</para>
Modified: trunk/refman-6.0/replication-configuration.xml
===================================================================
Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 123 bytes
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r11515 - in trunk: dynamic-docs/changelog refman-5.1 refman-6.0 | jon | 9 Aug |
