Author: paul
Date: 2008-06-24 19:58:10 +0200 (Tue, 24 Jun 2008)
New Revision: 11020
Log:
r32213@frost: paul | 2008-06-24 12:48:43 -0500
Revisions to binary logging material.
Modified:
trunk/refman-4.1/dba-core.xml
trunk/refman-4.1/programs-admin-util.xml
trunk/refman-5.0/dba-core.xml
trunk/refman-5.0/programs-admin-util-core.xml
trunk/refman-5.0/stored-procedures.xml
trunk/refman-5.1/dba-core.xml
trunk/refman-5.1/programs-admin-util-core.xml
trunk/refman-5.1/stored-procedures.xml
trunk/refman-6.0/dba-core.xml
trunk/refman-6.0/programs-admin-util-core.xml
trunk/refman-6.0/stored-procedures.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:32208
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31778
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:32213
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31778
Modified: trunk/refman-4.1/dba-core.xml
===================================================================
--- trunk/refman-4.1/dba-core.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-4.1/dba-core.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 6, Lines Added: 55, Lines Deleted: 35; 6237 bytes
@@ -9642,9 +9642,37 @@
rows). Statements are stored in the form of
<quote>events</quote> that describe the modifications. The
binary log also contains information about how long each
- statement took that updated data.
+ statement took that updated data. The binary log has two
+ important purposes:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ For replication, the binary log is used on master
+ replication servers as a record of the statements to be sent
+ to slave servers. The master server sends the events
+ contained in its binary log to its slaves, which execute
+ those events to make the same data changes that were made on
+ the master. See
+ <xref linkend="replication-implementation"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Certain data recovery operations require use of the binary
+ log. After a backup file has been restored, the events in
+ the binary log that were recorded after the backup was made
+ are re-executed. These events bring databases up to date
+ from the point of the backup. See
+ <xref linkend="recovery-from-backups"/>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<note>
<para>
The binary log has replaced the old update log, which is being
@@ -9665,15 +9693,6 @@
<xref linkend="query-log"/>.
</para>
- <para>
- The primary purpose of the binary log is to be able to update
- databases during a restore operation as fully as possible,
- because the binary log contains all updates done after a backup
- was made. The binary log is also used on master replication
- servers as a record of the statements to be sent to slave
- servers. See <xref linkend="replication"/>.
- </para>
-
<formalpara role="mnmas">
<title>MySQL Enterprise</title>
@@ -9717,24 +9736,25 @@
<para>
<command>mysqld</command> appends a numeric extension to the
- binary log basename. The number increases each time the server
- creates a new log file, thus creating an ordered series of
- files. The server creates a new binary log file each time it
- starts or flushes the logs. The server also creates a new binary
- log file automatically when the current log's size reaches
- <literal>max_binlog_size</literal>. A binary log file may become
- larger than <literal>max_binlog_size</literal> if you are using
- large transactions because a transaction is written to the file
- in one piece, never split between files.
+ binary log basename to generate binary log filenames. The number
+ increases each time the server creates a new log file, thus
+ creating an ordered series of files. The server creates a new
+ file in the series each time it starts or flushes the logs. The
+ server also creates a new binary log file automatically when the
+ current log's size reaches <literal>max_binlog_size</literal>. A
+ binary log file may become larger than
+ <literal>max_binlog_size</literal> if you are using large
+ transactions because a transaction is written to the file in one
+ piece, never split between files.
</para>
<para>
To keep track of which binary log files have been used,
<command>mysqld</command> also creates a binary log index file
- that contains the names of all used binary log files. By default
- this has the same basename as the binary log file, with the
- extension <literal>'.index'</literal>. You can change the name
- of the binary log index file with the
+ that contains the names of all used binary log files. By
+ default, this has the same basename as the binary log file, with
+ the extension <literal>'.index'</literal>. You can change the
+ name of the binary log index file with the
<option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>
option. You should not manually edit this file while
<command>mysqld</command> is running; doing so would confuse
@@ -9742,10 +9762,11 @@
</para>
<para>
- Replication slave servers by default do not write to their own
- binary log any statements that are received from the replication
- master. To cause these statements to be logged, start the slave
- with the <option>--log-slave-updates</option> option.
+ You can delete all binary log files with the <literal>RESET
+ MASTER</literal> statement, or a subset of them with
+ <literal>PURGE MASTER LOGS</literal>. See
+ <xref linkend="reset"/>, and
+ <xref linkend="purge-master-logs"/>.
</para>
<para>
@@ -9758,14 +9779,6 @@
</para>
<para>
- You can delete all binary log files with the <literal>RESET
- MASTER</literal> statement, or a subset of them with
- <literal>PURGE MASTER LOGS</literal>. See
- <xref linkend="reset"/>, and
- <xref linkend="purge-master-logs"/>.
- </para>
-
- <para>
The binary log format has some known limitations that can affect
recovery from backups, especially in old versions. These
caveats, which also affect replication, are listed at
@@ -9781,6 +9794,13 @@
</para>
<para>
+ A replication slave server by default does not write to its own
+ binary log any data modifications that are received from the
+ replication master. To log these modifications, start the slave
+ with the <option>--log-slave-updates</option> option.
+ </para>
+
+ <para>
You can use the following options to <command>mysqld</command>
to affect what is logged to the binary log. See also the
discussion that follows this option list.
Modified: trunk/refman-4.1/programs-admin-util.xml
===================================================================
--- trunk/refman-4.1/programs-admin-util.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-4.1/programs-admin-util.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 2, Lines Added: 8, Lines Deleted: 10; 1642 bytes
@@ -3600,13 +3600,16 @@
<title>Description</title>
<para>
- The binary log files that the server generates are written in
- binary format. To examine these files in text format, use the
- <command>mysqlbinlog</command> utility. It is available as of
+ The server's binary log consists of files that contain
+ <quote>events</quote> that describe modifications to database
+ contents. The server writes binary log files in binary format.
+ To display these files in text format, use the
+ <command>mysqlbinlog</command> utility, which is available as of
MySQL 3.23.14. You can also use <command>mysqlbinlog</command>
- to read relay log files written by a slave server in a
+ to display relay log files written by a slave server in a
replication setup. Relay logs have the same format as binary log
- files.
+ files. The binary log and relay log are discussed further in
+ <xref linkend="binary-log"/>, and <xref linkend="slave-logs"/>.
</para>
<para>
@@ -3657,11 +3660,6 @@
</para>
<para>
- Binary logs and relay logs are discussed further in
- <xref linkend="binary-log"/>, and <xref linkend="slave-logs"/>.
- </para>
-
- <para>
<command>mysqlbinlog</command> supports the following options:
</para>
Modified: trunk/refman-5.0/dba-core.xml
===================================================================
--- trunk/refman-5.0/dba-core.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-5.0/dba-core.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 6, Lines Added: 55, Lines Deleted: 35; 6259 bytes
@@ -11394,9 +11394,37 @@
<literal>DELETE</literal> which matched no rows). Statements are
stored in the form of <quote>events</quote> that describe the
modifications. The binary log also contains information about
- how long each statement took that updated data.
+ how long each statement took that updated data. The binary log
+ has two important purposes:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ For replication, the binary log is used on master
+ replication servers as a record of the statements to be sent
+ to slave servers. The master server sends the events
+ contained in its binary log to its slaves, which execute
+ those events to make the same data changes that were made on
+ the master. See
+ <xref linkend="replication-implementation"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Certain data recovery operations require use of the binary
+ log. After a backup file has been restored, the events in
+ the binary log that were recorded after the backup was made
+ are re-executed. These events bring databases up to date
+ from the point of the backup. See
+ <xref linkend="recovery-from-backups"/>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<note>
<para>
The binary log has replaced the old update log, which is no
@@ -11416,15 +11444,6 @@
<xref linkend="query-log"/>.
</para>
- <para>
- The primary purpose of the binary log is to be able to update
- databases during a restore operation as fully as possible,
- because the binary log contains all updates done after a backup
- was made. The binary log is also used on master replication
- servers as a record of the statements to be sent to slave
- servers. See <xref linkend="replication"/>.
- </para>
-
<formalpara role="mnmas">
<title>MySQL Enterprise</title>
@@ -11479,24 +11498,25 @@
<para>
<command>mysqld</command> appends a numeric extension to the
- binary log basename. The number increases each time the server
- creates a new log file, thus creating an ordered series of
- files. The server creates a new binary log file each time it
- starts or flushes the logs. The server also creates a new binary
- log file automatically when the current log's size reaches
- <literal>max_binlog_size</literal>. A binary log file may become
- larger than <literal>max_binlog_size</literal> if you are using
- large transactions because a transaction is written to the file
- in one piece, never split between files.
+ binary log basename to generate binary log filenames. The number
+ increases each time the server creates a new log file, thus
+ creating an ordered series of files. The server creates a new
+ file in the series each time it starts or flushes the logs. The
+ server also creates a new binary log file automatically when the
+ current log's size reaches <literal>max_binlog_size</literal>. A
+ binary log file may become larger than
+ <literal>max_binlog_size</literal> if you are using large
+ transactions because a transaction is written to the file in one
+ piece, never split between files.
</para>
<para>
To keep track of which binary log files have been used,
<command>mysqld</command> also creates a binary log index file
- that contains the names of all used binary log files. By default
- this has the same basename as the binary log file, with the
- extension <literal>'.index'</literal>. You can change the name
- of the binary log index file with the
+ that contains the names of all used binary log files. By
+ default, this has the same basename as the binary log file, with
+ the extension <literal>'.index'</literal>. You can change the
+ name of the binary log index file with the
<option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>
option. You should not manually edit this file while
<command>mysqld</command> is running; doing so would confuse
@@ -11504,10 +11524,11 @@
</para>
<para>
- Replication slave servers by default do not write to their own
- binary log any statements that are received from the replication
- master. To cause these statements to be logged, start the slave
- with the <option>--log-slave-updates</option> option.
+ You can delete all binary log files with the <literal>RESET
+ MASTER</literal> statement, or a subset of them with
+ <literal>PURGE MASTER LOGS</literal>. See
+ <xref linkend="reset"/>, and
+ <xref linkend="purge-master-logs"/>.
</para>
<para>
@@ -11517,14 +11538,6 @@
</para>
<para>
- You can delete all binary log files with the <literal>RESET
- MASTER</literal> statement, or a subset of them with
- <literal>PURGE MASTER LOGS</literal>. See
- <xref linkend="reset"/>, and
- <xref linkend="purge-master-logs"/>.
- </para>
-
- <para>
The binary log format has some known limitations that can affect
recovery from backups. See
<xref linkend="replication-features"/>.
@@ -11536,6 +11549,13 @@
</para>
<para>
+ A replication slave server by default does not write to its own
+ binary log any data modifications that are received from the
+ replication master. To log these modifications, start the slave
+ with the <option>--log-slave-updates</option> option.
+ </para>
+
+ <para>
You can use the following options to <command>mysqld</command>
to affect what is logged to the binary log. See also the
discussion that follows this option list.
Modified: trunk/refman-5.0/programs-admin-util-core.xml
===================================================================
--- trunk/refman-5.0/programs-admin-util-core.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-5.0/programs-admin-util-core.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 5, Lines Added: 13, Lines Deleted: 18; 2938 bytes
@@ -3620,12 +3620,16 @@
<title>Description</title>
<para>
- The binary log files that the server generates are written in
- binary format. To examine these files in text format, use the
+ The server's binary log consists of files that contain
+ <quote>events</quote> that describe modifications to database
+ contents. The server writes binary log files in binary format.
+ To display these files in text format, use the
<command>mysqlbinlog</command> utility. You can also use
- <command>mysqlbinlog</command> to read relay log files written
- by a slave server in a replication setup. Relay logs have the
- same format as binary log files.
+ <command>mysqlbinlog</command> to display relay log files
+ written by a slave server in a replication setup. Relay logs
+ have the same format as binary log files. The binary log and
+ relay log are discussed further in <xref linkend="binary-log"/>,
+ and <xref linkend="slave-logs"/>.
</para>
<para>
@@ -3675,17 +3679,12 @@
use the <option>--read-from-remote-server</option> option.
</para>
- <para>
- Binary logs and relay logs are discussed further in
- <xref linkend="binary-log"/>, and <xref linkend="slave-logs"/>.
- </para>
+ <para condition="dynamic:optvar:commandoptions" role="5.0:mysqlbinlog:all"/>
<para>
<command>mysqlbinlog</command> supports the following options:
</para>
- <para condition="dynamic:optvar:commandoptions" role="5.0:mysqlbinlog:all"/>
-
<itemizedlist>
<listitem>
@@ -4712,7 +4711,7 @@
<listitem>
<para>
<literal>Flags</literal>: 16 flags. Currently, the following
- flags are used. The others are reserved for the future.
+ flags are used. The others are reserved for future use.
</para>
<informaltable>
@@ -4759,10 +4758,6 @@
</tbody>
</tgroup>
</informaltable>
-
- <para>
- The other flags are reserved for future use.
- </para>
</listitem>
</itemizedlist>
@@ -4871,12 +4866,12 @@
shell> <userinput>mysqlhotcopy <replaceable>db_name</replaceable>./~<replaceable>regex</replaceable>/</userinput>
</programlisting>
+ <para condition="dynamic:optvar:commandoptions" role="5.0:mysqlhotcopy:all"/>
+
<para>
<command>mysqlhotcopy</command> supports the following options:
</para>
- <para condition="dynamic:optvar:commandoptions" role="5.0:mysqlhotcopy:all"/>
-
<itemizedlist>
<listitem>
Modified: trunk/refman-5.0/stored-procedures.xml
===================================================================
--- trunk/refman-5.0/stored-procedures.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-5.0/stored-procedures.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 3; 980 bytes
@@ -2607,9 +2607,11 @@
<listitem>
<para>
- For replication, the master server sends the events contained
- in its binary log to its slaves, which execute those events to
- make the same data changes that were made on the master. See
+ For replication, the binary log is used on master replication
+ servers as a record of the statements to be sent to slave
+ servers. The master server sends the events contained in its
+ binary log to its slaves, which execute those events to make
+ the same data changes that were made on the master. See
<xref linkend="replication-implementation"/>.
</para>
</listitem>
Modified: trunk/refman-5.1/dba-core.xml
===================================================================
--- trunk/refman-5.1/dba-core.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-5.1/dba-core.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 6, Lines Added: 55, Lines Deleted: 35; 6314 bytes
@@ -12415,9 +12415,37 @@
<literal>DELETE</literal> which matched no rows). Statements are
stored in the form of <quote>events</quote> that describe the
modifications. The binary log also contains information about
- how long each statement took that updated data.
+ how long each statement took that updated data. The binary log
+ has two important purposes:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ For replication, the binary log is used on master
+ replication servers as a record of the statements to be sent
+ to slave servers. The master server sends the events
+ contained in its binary log to its slaves, which execute
+ those events to make the same data changes that were made on
+ the master. See
+ <xref linkend="replication-implementation"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Certain data recovery operations require use of the binary
+ log. After a backup file has been restored, the events in
+ the binary log that were recorded after the backup was made
+ are re-executed. These events bring databases up to date
+ from the point of the backup. See
+ <xref linkend="recovery-from-backups"/>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<para>
The binary log is not used for statements such as
<literal>SELECT</literal> or <literal>SHOW</literal> that do not
@@ -12435,15 +12463,6 @@
<xref linkend="binary-log-formats"/>.
</para>
- <para>
- The primary purpose of the binary log is to be able to update
- databases during a restore operation as fully as possible,
- because the binary log contains all updates done after a backup
- was made. The binary log is also used on master replication
- servers as a record of the statements to be sent to slave
- servers. See <xref linkend="replication"/>.
- </para>
-
<formalpara role="mnmas">
<title>MySQL Enterprise</title>
@@ -12498,24 +12517,25 @@
<para>
<command>mysqld</command> appends a numeric extension to the
- binary log basename. The number increases each time the server
- creates a new log file, thus creating an ordered series of
- files. The server creates a new binary log file each time it
- starts or flushes the logs. The server also creates a new binary
- log file automatically when the current log's size reaches
- <literal>max_binlog_size</literal>. A binary log file may become
- larger than <literal>max_binlog_size</literal> if you are using
- large transactions because a transaction is written to the file
- in one piece, never split between files.
+ binary log basename to generate binary log filenames. The number
+ increases each time the server creates a new log file, thus
+ creating an ordered series of files. The server creates a new
+ file in the series each time it starts or flushes the logs. The
+ server also creates a new binary log file automatically when the
+ current log's size reaches <literal>max_binlog_size</literal>. A
+ binary log file may become larger than
+ <literal>max_binlog_size</literal> if you are using large
+ transactions because a transaction is written to the file in one
+ piece, never split between files.
</para>
<para>
To keep track of which binary log files have been used,
<command>mysqld</command> also creates a binary log index file
- that contains the names of all used binary log files. By default
- this has the same basename as the binary log file, with the
- extension <literal>'.index'</literal>. You can change the name
- of the binary log index file with the
+ that contains the names of all used binary log files. By
+ default, this has the same basename as the binary log file, with
+ the extension <literal>'.index'</literal>. You can change the
+ name of the binary log index file with the
<option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>
option. You should not manually edit this file while
<command>mysqld</command> is running; doing so would confuse
@@ -12523,10 +12543,11 @@
</para>
<para>
- Replication slave servers by default do not write to their own
- binary log any statements that are received from the replication
- master. To cause these statements to be logged, start the slave
- with the <option>--log-slave-updates</option> option.
+ You can delete all binary log files with the <literal>RESET
+ MASTER</literal> statement, or a subset of them with
+ <literal>PURGE MASTER LOGS</literal>. See
+ <xref linkend="reset"/>, and
+ <xref linkend="purge-master-logs"/>.
</para>
<para>
@@ -12536,14 +12557,6 @@
</para>
<para>
- You can delete all binary log files with the <literal>RESET
- MASTER</literal> statement, or a subset of them with
- <literal>PURGE MASTER LOGS</literal>. See
- <xref linkend="reset"/>, and
- <xref linkend="purge-master-logs"/>.
- </para>
-
- <para>
The binary log format has some known limitations that can affect
recovery from backups. See
<xref linkend="replication-features"/>.
@@ -12555,6 +12568,13 @@
</para>
<para>
+ A replication slave server by default does not write to its own
+ binary log any data modifications that are received from the
+ replication master. To log these modifications, start the slave
+ with the <option>--log-slave-updates</option> option.
+ </para>
+
+ <para>
You can use the following options to <command>mysqld</command>
to affect what is logged to the binary log. See also the
discussion that follows this option list.
Modified: trunk/refman-5.1/programs-admin-util-core.xml
===================================================================
--- trunk/refman-5.1/programs-admin-util-core.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-5.1/programs-admin-util-core.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 5, Lines Added: 13, Lines Deleted: 18; 2938 bytes
@@ -3620,12 +3620,16 @@
<title>Description</title>
<para>
- The binary log files that the server generates are written in
- binary format. To examine these files in text format, use the
+ The server's binary log consists of files that contain
+ <quote>events</quote> that describe modifications to database
+ contents. The server writes binary log files in binary format.
+ To display these files in text format, use the
<command>mysqlbinlog</command> utility. You can also use
- <command>mysqlbinlog</command> to read relay log files written
- by a slave server in a replication setup. Relay logs have the
- same format as binary log files.
+ <command>mysqlbinlog</command> to display relay log files
+ written by a slave server in a replication setup. Relay logs
+ have the same format as binary log files. The binary log and
+ relay log are discussed further in <xref linkend="binary-log"/>,
+ and <xref linkend="slave-logs"/>.
</para>
<para>
@@ -3675,17 +3679,12 @@
use the <option>--read-from-remote-server</option> option.
</para>
- <para>
- Binary logs and relay logs are discussed further in
- <xref linkend="binary-log"/>, and <xref linkend="slave-logs"/>.
- </para>
+ <para condition="dynamic:optvar:commandoptions" role="5.1:mysqlbinlog:all"/>
<para>
<command>mysqlbinlog</command> supports the following options:
</para>
- <para condition="dynamic:optvar:commandoptions" role="5.1:mysqlbinlog:all"/>
-
<itemizedlist>
<listitem>
@@ -4832,7 +4831,7 @@
<listitem>
<para>
<literal>Flags</literal>: 16 flags. Currently, the following
- flags are used. The others are reserved for the future.
+ flags are used. The others are reserved for future use.
</para>
<informaltable>
@@ -4879,10 +4878,6 @@
</tbody>
</tgroup>
</informaltable>
-
- <para>
- The other flags are reserved for future use.
- </para>
</listitem>
</itemizedlist>
@@ -4991,12 +4986,12 @@
shell> <userinput>mysqlhotcopy <replaceable>db_name</replaceable>./~<replaceable>regex</replaceable>/</userinput>
</programlisting>
+ <para condition="dynamic:optvar:commandoptions" role="5.1:mysqlhotcopy:all"/>
+
<para>
<command>mysqlhotcopy</command> supports the following options:
</para>
- <para condition="dynamic:optvar:commandoptions" role="5.1:mysqlhotcopy:all"/>
-
<itemizedlist>
<listitem>
Modified: trunk/refman-5.1/stored-procedures.xml
===================================================================
--- trunk/refman-5.1/stored-procedures.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-5.1/stored-procedures.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 3; 980 bytes
@@ -2566,9 +2566,11 @@
<listitem>
<para>
- For replication, the master server sends the events contained
- in its binary log to its slaves, which execute those events to
- make the same data changes that were made on the master. See
+ For replication, the binary log is used on master replication
+ servers as a record of the statements to be sent to slave
+ servers. The master server sends the events contained in its
+ binary log to its slaves, which execute those events to make
+ the same data changes that were made on the master. See
<xref linkend="replication-implementation"/>.
</para>
</listitem>
Modified: trunk/refman-6.0/dba-core.xml
===================================================================
--- trunk/refman-6.0/dba-core.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-6.0/dba-core.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 6, Lines Added: 61, Lines Deleted: 32; 6616 bytes
@@ -12238,9 +12238,37 @@
<literal>DELETE</literal> which matched no rows). Statements are
stored in the form of <quote>events</quote> that describe the
modifications. The binary log also contains information about
- how long each statement took that updated data.
+ how long each statement took that updated data. The binary log
+ has two important purposes:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ For replication, the binary log is used on master
+ replication servers as a record of the statements to be sent
+ to slave servers. The master server sends the events
+ contained in its binary log to its slaves, which execute
+ those events to make the same data changes that were made on
+ the master. See
+ <xref linkend="replication-implementation"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Certain data recovery operations require use of the binary
+ log. After a backup file has been restored, the events in
+ the binary log that were recorded after the backup was made
+ are re-executed. These events bring databases up to date
+ from the point of the backup. See
+ <xref linkend="recovery-from-backups"/>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<para>
The binary log is not used for statements such as
<literal>SELECT</literal> or <literal>SHOW</literal> that do not
@@ -12250,12 +12278,12 @@
</para>
<para>
- The primary purpose of the binary log is to be able to update
- databases during a restore operation as fully as possible,
- because the binary log contains all updates done after a backup
- was made. The binary log is also used on master replication
- servers as a record of the statements to be sent to slave
- servers. See <xref linkend="replication"/>.
+ The format of the events recorded in the binary log is dependent
+ on the binary logging format. Three format types are supported,
+ row-based logging, statement-based logging and mixed-base
+ logging. The binary logging format used depends on the MySQL
+ version. For more information on logging formats, see
+ <xref linkend="binary-log-formats"/>.
</para>
<formalpara role="mnmas">
@@ -12312,24 +12340,25 @@
<para>
<command>mysqld</command> appends a numeric extension to the
- binary log basename. The number increases each time the server
- creates a new log file, thus creating an ordered series of
- files. The server creates a new binary log file each time it
- starts or flushes the logs. The server also creates a new binary
- log file automatically when the current log's size reaches
- <literal>max_binlog_size</literal>. A binary log file may become
- larger than <literal>max_binlog_size</literal> if you are using
- large transactions because a transaction is written to the file
- in one piece, never split between files.
+ binary log basename to generate binary log filenames. The number
+ increases each time the server creates a new log file, thus
+ creating an ordered series of files. The server creates a new
+ file in the series each time it starts or flushes the logs. The
+ server also creates a new binary log file automatically when the
+ current log's size reaches <literal>max_binlog_size</literal>. A
+ binary log file may become larger than
+ <literal>max_binlog_size</literal> if you are using large
+ transactions because a transaction is written to the file in one
+ piece, never split between files.
</para>
<para>
To keep track of which binary log files have been used,
<command>mysqld</command> also creates a binary log index file
- that contains the names of all used binary log files. By default
- this has the same basename as the binary log file, with the
- extension <literal>'.index'</literal>. You can change the name
- of the binary log index file with the
+ that contains the names of all used binary log files. By
+ default, this has the same basename as the binary log file, with
+ the extension <literal>'.index'</literal>. You can change the
+ name of the binary log index file with the
<option>--log-bin-index[=<replaceable>file_name</replaceable>]</option>
option. You should not manually edit this file while
<command>mysqld</command> is running; doing so would confuse
@@ -12337,10 +12366,11 @@
</para>
<para>
- Replication slave servers by default do not write to their own
- binary log any statements that are received from the replication
- master. To cause these statements to be logged, start the slave
- with the <option>--log-slave-updates</option> option.
+ You can delete all binary log files with the <literal>RESET
+ MASTER</literal> statement, or a subset of them with
+ <literal>PURGE MASTER LOGS</literal>. See
+ <xref linkend="reset"/>, and
+ <xref linkend="purge-master-logs"/>.
</para>
<para>
@@ -12350,14 +12380,6 @@
</para>
<para>
- You can delete all binary log files with the <literal>RESET
- MASTER</literal> statement, or a subset of them with
- <literal>PURGE MASTER LOGS</literal>. See
- <xref linkend="reset"/>, and
- <xref linkend="purge-master-logs"/>.
- </para>
-
- <para>
The binary log format has some known limitations that can affect
recovery from backups. See
<xref linkend="replication-features"/>.
@@ -12369,6 +12391,13 @@
</para>
<para>
+ A replication slave server by default does not write to its own
+ binary log any data modifications that are received from the
+ replication master. To log these modifications, start the slave
+ with the <option>--log-slave-updates</option> option.
+ </para>
+
+ <para>
You can use the following options to <command>mysqld</command>
to affect what is logged to the binary log. See also the
discussion that follows this option list.
Modified: trunk/refman-6.0/programs-admin-util-core.xml
===================================================================
--- trunk/refman-6.0/programs-admin-util-core.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-6.0/programs-admin-util-core.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 5, Lines Added: 13, Lines Deleted: 18; 2938 bytes
@@ -3620,12 +3620,16 @@
<title>Description</title>
<para>
- The binary log files that the server generates are written in
- binary format. To examine these files in text format, use the
+ The server's binary log consists of files that contain
+ <quote>events</quote> that describe modifications to database
+ contents. The server writes binary log files in binary format.
+ To display these files in text format, use the
<command>mysqlbinlog</command> utility. You can also use
- <command>mysqlbinlog</command> to read relay log files written
- by a slave server in a replication setup. Relay logs have the
- same format as binary log files.
+ <command>mysqlbinlog</command> to display relay log files
+ written by a slave server in a replication setup. Relay logs
+ have the same format as binary log files. The binary log and
+ relay log are discussed further in <xref linkend="binary-log"/>,
+ and <xref linkend="slave-logs"/>.
</para>
<para>
@@ -3675,17 +3679,12 @@
use the <option>--read-from-remote-server</option> option.
</para>
- <para>
- Binary logs and relay logs are discussed further in
- <xref linkend="binary-log"/>, and <xref linkend="slave-logs"/>.
- </para>
+ <para condition="dynamic:optvar:commandoptions" role="6.0:mysqlbinlog:all"/>
<para>
<command>mysqlbinlog</command> supports the following options:
</para>
- <para condition="dynamic:optvar:commandoptions" role="6.0:mysqlbinlog:all"/>
-
<itemizedlist>
<listitem>
@@ -4827,7 +4826,7 @@
<listitem>
<para>
<literal>Flags</literal>: 16 flags. Currently, the following
- flags are used. The others are reserved for the future.
+ flags are used. The others are reserved for future use.
</para>
<informaltable>
@@ -4874,10 +4873,6 @@
</tbody>
</tgroup>
</informaltable>
-
- <para>
- The other flags are reserved for future use.
- </para>
</listitem>
</itemizedlist>
@@ -4986,12 +4981,12 @@
shell> <userinput>mysqlhotcopy <replaceable>db_name</replaceable>./~<replaceable>regex</replaceable>/</userinput>
</programlisting>
+ <para condition="dynamic:optvar:commandoptions" role="6.0:mysqlhotcopy:all"/>
+
<para>
<command>mysqlhotcopy</command> supports the following options:
</para>
- <para condition="dynamic:optvar:commandoptions" role="6.0:mysqlhotcopy:all"/>
-
<itemizedlist>
<listitem>
Modified: trunk/refman-6.0/stored-procedures.xml
===================================================================
--- trunk/refman-6.0/stored-procedures.xml 2008-06-24 17:27:12 UTC (rev 11019)
+++ trunk/refman-6.0/stored-procedures.xml 2008-06-24 17:58:10 UTC (rev 11020)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 3; 980 bytes
@@ -2564,9 +2564,11 @@
<listitem>
<para>
- For replication, the master server sends the events contained
- in its binary log to its slaves, which execute those events to
- make the same data changes that were made on the master. See
+ For replication, the binary log is used on master replication
+ servers as a record of the statements to be sent to slave
+ servers. The master server sends the events contained in its
+ binary log to its slaves, which execute those events to make
+ the same data changes that were made on the master. See
<xref linkend="replication-implementation"/>.
</para>
</listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r11020 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul | 24 Jun |
