Below is the list of changes that have just been committed into a local
mysqldoc repository of jon. When jon does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.3460 05/09/03 04:22:50 jon@stripped +5 -0
replicaiton.xml:
version 4.1 edits;
sync & cleanup diffs with other refman trees.
Update 4.1 Status.
refman/replication.xml
1.28 05/09/03 04:22:48 jon@stripped +558 -433
Sync & cleanup diffs.
refman-5.1/replication.xml
1.19 05/09/03 04:22:48 jon@stripped +62 -48
Sync & cleanup diffs.
refman-5.0/replication.xml
1.19 05/09/03 04:22:48 jon@stripped +59 -45
Sync & cleanup diffs.
refman-4.1/replication.xml
1.26 05/09/03 04:22:48 jon@stripped +511 -451
Version-specific edits.
refman-4.1/Status
1.18 05/09/03 04:22:48 jon@stripped +1 -1
Updating...
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jon
# Host: gigan.
# Root: /home/jon/bk/mysqldoc
--- 1.17/refman-4.1/Status 2005-09-02 23:27:27 +10:00
+++ 1.18/refman-4.1/Status 2005-09-03 04:22:48 +10:00
@@ -13,10 +13,10 @@
mysql-apis
introduction
innodb
+ replication
- 4.1 chapters awaiting major edits:
tutorial
- replication
using-mysql-programs
error-handling
limits
--- 1.18/refman-5.1/replication.xml 2005-09-01 02:15:22 +10:00
+++ 1.19/refman-5.1/replication.xml 2005-09-03 04:22:48 +10:00
@@ -768,7 +768,8 @@
<listitem>
<para>
When the size of the current relay log file becomes too
- large. The meaning of "too large" is determined as follows:
+ large. The meaning of <quote>too large</quote> is determined
+ as follows:
</para>
<itemizedlist>
@@ -925,11 +926,11 @@
</remark>
<para>
- When you back up your slave's data, you should back up these two
- files as well, along with the relay log files. They are needed
- to resume replication after you restore the slave's data. If you
- lose the relay logs but still have the
- <filename>relay-log.info</filename> file, you can examine it to
+ When you back up the slave's data, you should back up these two
+ small files as well, along with the relay log files. They are
+ needed to resume replication after you restore the slave's data.
+ If you lose the relay logs but still have the
+ <filename>relay-log.info</filename> file, you can check it to
determine how far the SQL thread has executed in the master
binary logs. Then you can use <literal>CHANGE MASTER
TO</literal> with the <literal>MASTER_LOG_FILE</literal> and
@@ -1185,20 +1186,20 @@
<para>
If you are using <literal>InnoDB</literal> tables, ideally you
- should use the <literal>InnoDB Hot Backup</literal> tool. It
- takes a consistent snapshot without acquiring any locks on the
- master server, and records the log name and offset
- corresponding to the snapshot to be later used on the slave.
- <literal>InnoDB Hot Backup</literal> is a non-free
- (commercial) additional tool that is not included in the
- standard MySQL distribution. See the <literal>InnoDB Hot
- Backup</literal> home page at
- <ulink url="http://www.innodb.com/manual.php"/> for detailed
- information and screenshots.
+ should use the <command><literal>InnoDB</literal> Hot
+ Backup</command> tool, which takes a consistent snapshot
+ without acquiring any locks on the master server, and records
+ the log name and offset corresponding to the snapshot to be
+ later used on the slave. <command>Hot Backup</command> is an
+ additional non-free (commercial) tool that is not included in
+ the standard MySQL distribution. See the
+ <command><literal>InnoDB</literal> Hot Backup</command> home
+ page at <ulink url="http://www.innodb.com/manual.php"/> for
+ detailed information.
</para>
<para>
- Without the <literal>Hot Backup</literal> tool, the quickest
+ Without the <command>Hot Backup</command> tool, the quickest
way to take a binary snapshot of <literal>InnoDB</literal>
tables is to shut down the master server and copy the
<literal>InnoDB</literal> data files, log files, and table
@@ -1305,7 +1306,7 @@
<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
+ <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
@@ -1428,7 +1429,8 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the slave, you get the following error in its error log:
+ value for the slave, you get the following error in the slave's
+ error log:
</para>
<programlisting>
@@ -1446,10 +1448,10 @@
one file named <filename>master.info</filename> and another named
<filename>relay-log.info</filename>. The slave uses these two
files to keep track of how much of the master's binary log it has
- processed. <emphasis role="bold">Do not</emphasis> remove or edit
- these files, unless you really know what you are doing and
- understand the implications. Even in that case, it is preferred
- that you use the <literal>CHANGE MASTER TO</literal> statement.
+ processed. Do <emphasis>not</emphasis> remove or edit these files
+ unless you know exactly what you are doing and fully understand
+ the implications. Even in that case, it is preferred that you use
+ the <literal>CHANGE MASTER TO</literal> statement.
</para>
<para>
@@ -1573,6 +1575,16 @@
can remove them before proceeding with the downgrade.
</para>
+<!-- Remove the comment when we have RBR in place.
+ <para>
+ Note that downgrading a replication setup to a previous version
+ cannot be done once you've switched from statement-based to
+ row-based replication, and after the first row-based statement
+ has been written to the binlog. See
+ <xref linkend="replication-row-based"/>.
+ </para>
+-->
+
</section>
</section>
@@ -1883,13 +1895,14 @@
<listitem>
<para>
- It is possible for the data on the master and slave to diverge
- if a query is designed in such a way that the data
- modification is non-deterministic; that is, if it is left up
- to the actions of the query optimizer. (This is generally not
- a good practice in any case, even outside of replication.) For
- a detailed explanation of this issue, see
- <xref linkend="open-bugs"/>.
+ <emphasis>The following restriction applies to statement-based
+ replication only, not to row-based replication</emphasis>: It
+ is possible for the data on the master and slave to become
+ different if a query is designed in such a way that the data
+ modification is non-deterministic; that is, left to the will
+ of the query optimizer. (This is in general not a good
+ practice, even outside of replication.) For a detailed
+ explanation of this issue, see <xref linkend="open-bugs"/>.
</para>
</listitem>
@@ -2021,8 +2034,9 @@
relationship with the <option>--log-slave-updates</option>
option specified. Note, however, that many statements do not
work correctly in this kind of setup unless your client code
- is written to take care of that can occur from updates that
- occur in different sequences on different servers.
+ is written to take care of the potential problems that can
+ occur from updates that occur in different sequence on
+ different servers.
</para>
<para>
@@ -2038,14 +2052,14 @@
</programlisting>
<para>
- Server IDs are encoded in the binary log events, so server A
- knows when an event that it reads was originally created by
- itself and does not execute the event (unless server A was
- started with the <option>--replicate-same-server-id</option>
- option, which is meaningful only in rare setups). Thus, there
- are no infinite loops. However, this circular setup works only
- if you perform no conflicting updates between the tables. In
- other words, if you insert data into both A and C, you should
+ Server IDs are encoded in binary log events, so server A knows
+ when an event that it reads was originally created by itself
+ and does not execute the event (unless server A was started
+ with the <option>--replicate-same-server-id</option> option,
+ which is meaningful only in rare cases). Thus, there are no
+ infinite loops. This type of circular setup works only if
+ you perform no conflicting updates between the tables. In
+ other words, if you insert data in both A and C, you should
never insert a row in A that may have a key that conflicts
with a row inserted in C. You should also not update the same
rows on two servers if the order in which the updates are
@@ -2611,8 +2625,8 @@
<para>
Places an upper limit on the total size of all relay logs on
- the slave (a value of 0 means the size is unlimited). This is
- useful for a slave server host that has limited disk space.
+ the slave (a value of 0 means <quote>unlimited</quote>). This
+ is useful for a slave server host that has limited disk space.
When the limit is reached, the I/O thread stops reading binary
log events from the master server until the SQL thread has
caught up and deleted some unused relay logs. Note that this
@@ -2908,7 +2922,7 @@
</listitem>
<listitem>
- <remark>
+ <remark role="note">
Currently this option is of no real interest; it is meant for
failover replication, which is not yet implemented.
</remark>
@@ -2927,9 +2941,9 @@
</listitem>
<listitem>
- <remark>
+ <remark role="note">
Currently this option is of no real interest; it is meant for
- failover replication, which is not yet implemented yet.
+ failover replication, which is not yet implemented.
</remark>
<para>
@@ -3061,7 +3075,7 @@
<listitem>
<para>
- Are there some <option>--replicate-do-db</option> or
+ Are there any <option>--replicate-do-db</option> or
<option>--replicate-ignore-db</option> rules?
</para>
@@ -3158,7 +3172,7 @@
<listitem>
<para>
- Are there some <option>--replicate-do-table</option> rules?
+ Are there any <option>--replicate-do-table</option> rules?
</para>
<itemizedlist>
@@ -3566,7 +3580,7 @@
<listitem>
<para>
- On the master, execute these 2 statements:
+ On the master, execute these statements:
</para>
<programlisting>
--- 1.25/refman-4.1/replication.xml 2005-09-01 02:15:19 +10:00
+++ 1.26/refman-4.1/replication.xml 2005-09-03 04:22:48 +10:00
@@ -54,9 +54,10 @@
<para>
We suggest that you visit our Web site at
- <ulink url="http://www.mysql.com"/> often and read updates to this
- chapter. Replication is constantly being improved, and we update the
- manual frequently with the most current information.
+ <ulink url="http://www.mysql.com"/> frequently as well as check for
+ revisions to this chapter. Replication is constantly being improved,
+ and we update the manual regularly with the most current
+ information.
</para>
<section id="replication-intro">
@@ -77,7 +78,7 @@
</para>
<para>
- A slave server can also serve as a master if you want to set up
+ A slave server can itself serve as a master if you want to set up
chained replication servers.
</para>
@@ -152,14 +153,14 @@
</para>
<para>
- It is <emphasis role="bold">very important</emphasis> to realize
- that the binary log is simply a record starting from the fixed
- point in time at which you enable binary logging. Any slaves that
- you set up need copies of the databases on your master as they
- existed at the moment you enabled binary logging on the master. If
- you start your slaves with databases that are not the same as what
- was on the master <emphasis role="bold">when the binary log was
- started</emphasis>, your slaves may fail.
+ It is <emphasis>extremely</emphasis> important to realize that the
+ binary log is simply a record starting from the fixed point in
+ time at which you enable binary logging. Any slaves that you set
+ up need copies of the databases on your master <emphasis>as they
+ existed at the moment you enabled binary logging on the
+ master</emphasis>. If you start your slaves with databases that
+ are not in the same state as those on the master when the binary
+ log was started, your slaves are quite likely to fail.
</para>
<para>
@@ -180,26 +181,26 @@
the master is relatively small, or if a prolonged read lock on the
master is acceptable. While the actual speed of <literal>LOAD DATA
FROM MASTER</literal> may vary from system to system, a good rule
- of thumb for how long it takes is 1 second per 1MB of data. That
- is only a rough estimate, but you should get close to it if both
- master and slave are equivalent to 700MHz Pentium performance and
- are connected through a 100MBit/s network.
+ of thumb for how long it takes is 1 second per 1MB of data. This
+ is a rough estimate, but you should find it fairly accurate if
+ both master and slave are equivalent to 700MHz Pentium CPUs in
+ performance and are connected through a 100Mbps network.
</para>
<para>
After the slave has been set up with a copy of the master's data,
it connects to the master and waits for updates to process. If the
- master goes away or the slave loses connectivity with your master,
- it keeps trying to connect periodically until it is able to
- reconnect and resume listening for updates. The retry interval is
- controlled by the <option>--master-connect-retry</option> option.
- The default is 60 seconds.
+ master fails, or the slave loses connectivity with your master,
+ the slave keeps trying to connect periodically until it is able to
+ resume listening for updates. The retry interval is controlled by
+ the <option>--master-connect-retry</option> option. The default is
+ 60 seconds.
</para>
<para>
Each slave keeps track of where it left off. The master server has
- no knowledge of how many slaves there are or which ones are up to
- date at any given time.
+ no knowledge of how many slaves there are or of which ones are up
+ to date at any given time.
</para>
</section>
@@ -210,24 +211,25 @@
<para>
MySQL replication capabilities are implemented using three threads
- (one on the master server and two on the slave). When
+ (one on the master server and two on the slave). When a
<literal>START SLAVE</literal> is issued, the slave creates an I/O
- thread. The I/O thread connects to the master and asks it to send
- the statements recorded in its binary logs. The master creates a
+ thread, which connects to the master and asks it to send the
+ statements recorded in its binary logs. The master creates a
thread to send the binary log contents to the slave. This thread
can be identified as the <literal>Binlog Dump</literal> thread in
the output of <literal>SHOW PROCESSLIST</literal> on the master.
The slave I/O thread reads what the master <literal>Binlog
- Dump</literal> thread sends and simply copies it to some local
- files in the slave's data directory called relay logs. The third
- thread is the SQL thread, which the slave creates to read the
- relay logs and execute the updates they contain.
+ Dump</literal> thread sends and copies this data to local files,
+ known as <emphasis>relay logs</emphasis>, in the slave's data
+ directory. The third thread is the SQL thread, which the slave
+ creates in order to read the relay logs and to execute the updates
+ they contain.
</para>
<para>
- In the preceding description, there are three threads per slave.
- For a master that has multiple slaves, it creates one thread for
- each currently connected slave, and each slave has its own I/O and
+ In the preceding description, there are three threads per slave. A
+ master that has multiple slaves creates one thread for each slave
+ that is currently connected slave; each slave has its own I/O and
SQL threads.
</para>
@@ -248,10 +250,11 @@
thread lags far behind and may take hours to catch up. If the
slave stops before the SQL thread has executed all the fetched
statements, the I/O thread has at least fetched everything so that
- a safe copy of the statements is locally stored in the slave's
- relay logs for execution when next the slave starts. This allows
- the binary logs to be purged on the master, because it no longer
- need wait for the slave to fetch their contents.
+ a safe copy of the statements is stored locally in the slave's
+ relay logs, ready for execution the next time that the slave
+ starts. This allows the binary logs to be purged on the master,
+ because it no longer needs to wait for the slave to fetch their
+ contents.
</para>
<para>
@@ -325,12 +328,13 @@
<para>
This information indicates that thread 10 is the I/O thread that
is communicating with the master server, and thread 11 is the SQL
- thread that is processing the updates stored in the relay logs.
- Currently, both threads are idle, waiting for further updates.
+ thread that is processing the updates stored in the relay logs. At
+ the time that the <literal>SHOW PROCESSLIST</literal> was run,
+ both threads were idle, waiting for further updates.
</para>
<para>
- Note that the value in the <literal>Time</literal> column can tell
+ Note that the value in the <literal>Time</literal> column can show
how late the slave is compared to the master. See
<xref linkend="replication-faq"/>.
</para>
@@ -340,11 +344,12 @@
<title id="title-master-thread-states">&title-master-thread-states;</title>
<para>
- The following list shows the most common states you see in the
- <literal>State</literal> column for the master's <literal>Binlog
- Dump</literal> thread. If you don't see any <literal>Binlog
- Dump</literal> threads on a master server, replication is not
- running. That is, no slaves currently are connected.
+ The following list shows the most common states you may see in
+ the <literal>State</literal> column for the master's
+ <literal>Binlog Dump</literal> thread. If you don't see any
+ <literal>Binlog Dump</literal> threads on a master server, this
+ means that replication is not running — that is, that no
+ slaves are currently connected.
</para>
<itemizedlist>
@@ -355,10 +360,10 @@
</para>
<para>
- Binary logs consist of events, where an event is usually an
- update statement plus some other information. The thread has
- read an event from the binary log and is sending it to the
- slave.
+ Binary logs consist of <emphasis>events</emphasis>, where an
+ event is usually an update plus some other information. The
+ thread has read an event from the binary log and is now
+ sending it to the slave.
</para>
</listitem>
@@ -382,9 +387,9 @@
<para>
The thread has read all outstanding updates from the binary
- logs and sent them to the slave. It is idle, waiting for new
- events to appear in the binary log resulting from new update
- statements being executed on the master.
+ logs and sent them to the slave. The thread is now idle,
+ waiting for new events to appear in the binary log resulting
+ from new updates occurring on the master.
</para>
</listitem>
@@ -434,8 +439,8 @@
</para>
<para>
- A very brief state that occurs just after the connection to
- the master is established.
+ A state that occurs very briefly, immediately after the
+ connection to the master is established.
</para>
</listitem>
@@ -445,8 +450,8 @@
</para>
<para>
- A very brief state that occurs just after the connection to
- the master is established.
+ A state that occurs very briefly immediately after the
+ connection to the master is established.
</para>
</listitem>
@@ -456,10 +461,11 @@
</para>
<para>
- A very brief state that occurs just after the connection to
- the master is established. The thread sends to the master a
- request for the contents of its binary logs, starting from
- the requested binary log filename and position.
+ A state that occurs very briefly, immediately after the
+ connection to the master is established. The thread sends to
+ the master a request for the contents of its binary logs,
+ starting from the requested binary log filename and
+ position.
</para>
</listitem>
@@ -551,10 +557,10 @@
<para>
You are using a non-zero
<literal>relay_log_space_limit</literal> value, and the
- relay logs have grown so much that their combined size
- exceeds this value. The I/O thread is waiting until the SQL
- thread frees enough space by processing relay log contents
- so that it can delete some relay log files.
+ relay logs have grown until their combined size exceeds this
+ value. The I/O thread is waiting until the SQL thread frees
+ enough space by processing relay log contents so that it can
+ delete some relay log files.
</para>
</listitem>
@@ -564,7 +570,7 @@
</para>
<para>
- A very brief state that occurs as the thread is stopping.
+ A state that occurs briefly as the thread is stopping.
</para>
</listitem>
@@ -577,8 +583,9 @@
<title id="title-slave-sql-thread-states">&title-slave-sql-thread-states;</title>
<para>
- The following list shows the most common states you see in the
- <literal>State</literal> column for a slave server SQL thread:
+ The following list shows the most common states you may see in
+ the <literal>State</literal> column for a slave server SQL
+ thread:
</para>
<itemizedlist>
@@ -589,8 +596,8 @@
</para>
<para>
- The thread has read an event from the relay log so that it
- can process it.
+ The thread has read an event from the relay log so that the
+ event can be processed.
</para>
</listitem>
@@ -601,9 +608,9 @@
</para>
<para>
- The thread has processed all events in the relay log files
- and is waiting for the I/O thread to write new events to the
- relay log.
+ The thread has processed all events in the relay log files,
+ and is now waiting for the I/O thread to write new events to
+ the relay log.
</para>
</listitem>
@@ -651,8 +658,8 @@
</para>
<para>
- Relay logs have the same format as binary logs, so you can use
- <command>mysqlbinlog</command> to read them. A relay log is
+ Relay logs have the same format as binary logs, and can be read
+ using <command>mysqlbinlog</command>. A relay log is
automatically deleted by the SQL thread as soon as it has
executed all its events and no longer needs it). There is no
explicit mechanism for deleting relay logs, because the SQL
@@ -670,9 +677,7 @@
<listitem>
<para>
When the I/O thread starts for the first time after the
- slave server starts. (In MySQL 5.0, a new relay log is
- created each time the I/O thread starts, not just the first
- time.)
+ slave server starts.
</para>
</listitem>
@@ -715,8 +720,8 @@
<para>
A slave replication server creates two additional small files in
- the data directory. These are status files and are named
- <filename>master.info</filename> and
+ the data directory. These <emphasis>status files</emphasis> are
+ named <filename>master.info</filename> and
<filename>relay-log.info</filename> by default. They contain
information like that shown in the output of the <literal>SHOW
SLAVE STATUS</literal> statement (see
@@ -853,7 +858,7 @@
The <filename>relay-log.info</filename> file is updated by the
SQL thread. The correspondence between the lines in the file and
the columns displayed by <literal>SHOW SLAVE STATUS</literal> is
- as follows:
+ shown here:
</para>
<informaltable>
@@ -887,19 +892,12 @@
<remark role="todo">
This stuff about backups is out of place. We haven't even
- </remark>
-
- <remark>
described how to set up replication yet, much less worry about
- backups.
- </remark>
-
- <remark>
- Create a new Backup Issues within this chapter?
+ backups. Create a new Backup Issues within this chapter?
</remark>
<para>
- When you back up your slave's data, you should back up these two
+ When you back up the slave's data, you should back up these two
small files as well, along with the relay log files. They are
needed to resume replication after you restore the slave's data.
If you lose the relay logs but still have the
@@ -908,8 +906,8 @@
binary logs. Then you can use <literal>CHANGE MASTER
TO</literal> with the <literal>MASTER_LOG_FILE</literal> and
<literal>MASTER_LOG_POS</literal> options to tell the slave to
- re-read the binary logs from that point. This requires that the
- binary logs still exist on the master server.
+ re-read the binary logs from that point. Of course, this
+ requires that the binary logs still exist on the master server.
</para>
<para>
@@ -934,15 +932,15 @@
<title id="title-replication-howto">&title-replication-howto;</title>
<para>
- Here is a quick description of how to set up complete replication
+ Here is a brief description of how to set up complete replication
of your current MySQL server. It assumes that you want to
- replicate all your databases and have not configured replication
- before. You need to shut down your master server briefly to
- complete the steps outlined here.
+ replicate all databases on the master and have not previously
+ configured replication. You need to shut down your master server
+ briefly to complete the steps outlined here.
</para>
<para>
- The procedure is written in terms of setting up a single slave,
+ This procedure is written in terms of setting up a single slave,
but you can use it to set up multiple slaves.
</para>
@@ -983,7 +981,7 @@
<para>
Please do not report bugs until you have verified that the
- problem is present in the latest release.
+ problem is present in the latest MySQL release.
</para>
</listitem>
@@ -993,7 +991,9 @@
can use to connect. This account must be given the
<literal>REPLICATION SLAVE</literal> privilege. If the account
is used only for replication (which is recommended), you don't
- need to grant any additional privileges.
+ need to grant any additional privileges. (For informaiton
+ about setting up user accounts and privileges, see
+ <xref linkend="user-account-management"/>.)
</para>
<para>
@@ -1079,7 +1079,7 @@
</para>
<para>
- Leave the client running from which you issue the
+ Leave running the client from which you issue the
<literal>FLUSH TABLES</literal> statement so that the read
lock remains in effect. (If you exit the client, the lock is
released.) Then take a snapshot of the data on your master
@@ -1168,20 +1168,20 @@
<para>
If you are using <literal>InnoDB</literal> tables, ideally you
- should use the <literal>InnoDB Hot Backup</literal> tool. It
- takes a consistent snapshot without acquiring any locks on the
- master server, and records the log name and offset
- corresponding to the snapshot to be later used on the slave.
- <literal>InnoDB Hot Backup</literal> is a non-free
- (commercial) additional tool that is not included in the
- standard MySQL distribution. See the <literal>InnoDB Hot
- Backup</literal> home page at
- <ulink url="http://www.innodb.com/manual.php"/> for detailed
- information and screenshots.
+ should use the <command><literal>InnoDB</literal> Hot
+ Backup</command> tool, which takes a consistent snapshot
+ without acquiring any locks on the master server, and records
+ the log name and offset corresponding to the snapshot to be
+ later used on the slave. <command>Hot Backup</command> is an
+ additional non-free (commercial) tool that is not included in
+ the standard MySQL distribution. See the
+ <command><literal>InnoDB</literal> Hot Backup</command> home
+ page at <ulink url="http://www.innodb.com/manual.php"/> for
+ detailed information.
</para>
<para>
- Without the <literal>Hot Backup</literal> tool, the quickest
+ Without the <command>Hot Backup</command> tool, the quickest
way to take a binary snapshot of <literal>InnoDB</literal>
tables is to shut down the master server and copy the
<literal>InnoDB</literal> data files, log files, and table
@@ -1286,9 +1286,9 @@
</para>
<para>
- If you don't specify a <literal>server-id</literal> value, it
+ 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
+ <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
@@ -1412,7 +1412,8 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the slave, you get the following error in its error log:
+ value for the slave, you get the following error in the slave's
+ error log:
</para>
<programlisting>
@@ -1430,17 +1431,17 @@
one file named <filename>master.info</filename> and another named
<filename>relay-log.info</filename>. The slave uses these two
files to keep track of how much of the master's binary log it has
- processed. <emphasis role="bold">Do not</emphasis> remove or edit
- these files, unless you really know what you are doing and
- understand the implications. Even in that case, it is preferred
- that you use the <literal>CHANGE MASTER TO</literal> statement.
+ processed. Do <emphasis>not</emphasis> remove or edit these files
+ unless you know exactly what you are doing and fully understand
+ the implications. Even in that case, it is preferred that you use
+ the <literal>CHANGE MASTER TO</literal> statement.
</para>
<para>
<emphasis role="bold">Note</emphasis>: The content of
- <filename>master.info</filename> overrides some options specified
- on the command line or in <filename>my.cnf</filename>. See
- <xref linkend="replication-options"/> for more details.
+ <filename>master.info</filename> overrides some of the options
+ specified on the command line or in <filename>my.cnf</filename>.
+ See <xref linkend="replication-options"/> for more details.
</para>
<para>
@@ -1467,19 +1468,14 @@
<title id="title-replication-compatibility">&title-replication-compatibility;</title>
<para>
- The original binary log format was developed in MySQL 3.23. It
- changed in MySQL 4.0, and again in MySQL 5.0.0. The binary log
- format as implemented in MySQL 5.0 is considerably different than
- that used in previous versions. Major changes were made in MySQL
- 5.0.3 (for improvements to handling of character sets and
- <literal>LOAD DATA INFILE</literal>) and 5.0.4 (for improvements
- to handling of time zones).
+ The original binary log format was developed in MySQL 3.23. It was
+ changed in MySQL 4.0.
</para>
<para>
<emphasis role="bold">Note</emphasis>: You cannot replicate from a
master that uses a newer binary log format to a slave that uses an
- older format (for example, from MySQL 5.0 to MySQL 4.1.) This has
+ older format (for example, from MySQL 4.1 to MySQL 3.23.) This has
significant consequences for upgrading servers in a replication
setup, as described in <xref linkend="replication-upgrade"/>.
</para>
@@ -1502,10 +1498,8 @@
As a general rule, we recommended using recent MySQL versions,
because replication capabilities are continually being improved.
We also recommend using the same version for both the master and
- the slave. We recommend upgrading master and slave running alpha
- or beta versions to new versions. Replication from a 5.0.3 master
- to a 5.0.2 slave will fail; from a 5.0.4 master to a 5.0.3 slave
- will also fail.
+ the slave. We recommend upgrading masters and slaves running alpha
+ or beta versions to new versions.
</para>
</section>
@@ -1680,7 +1674,7 @@
old implementation of <literal>PASSWORD()</literal>. (Note
that the <literal>PASSWORD()</literal> implementation in MySQL
4.1.0 differs from every other version of MySQL. It is best to
- avoid 4.1.0 in a replication situation.)
+ avoid 4.1.0 in a replication scenario.)
</para>
</listitem>
@@ -1705,60 +1699,76 @@
The <literal>FOREIGN_KEY_CHECKS</literal> variable is
replicated as of MySQL 4.0.14. The
<literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
- and <literal>SQL_AUTO_IS_NULL</literal> variables are
- replicated as of 5.0.0. The <literal>TABLE_TYPE</literal>,
- also known as <literal>STORAGE_ENGINE</literal> variable is
- not yet replicated, which is a good thing for replication
- between different storage engines.
+ <literal>SQL_AUTO_IS_NULL</literal>,
+ and <literal>TABLE_TYPE</literal> (same as
+ <literal>STORAGE_ENGINE</literal>) variables are not
+ replicated in MySQL 4.1 or earlier versions.
</para>
</listitem>
<listitem>
<para>
- Starting from MySQL 5.0.3 (master and slave), replication
- works fine even if the master and slave have different global
- character set variables. Starting from MySQL 5.0.4 (master and
- slave), replication works fine even if the master and slave
- have different global timezone variables.
+ The following applies to replication between MySQL servers
+ using different character sets:
</para>
- </listitem>
- <listitem>
- <para>
- This paragraph applies to replication between MySQL servers
- using different character sets where the master runs MySQL 4.1
- (and slave runs 4.1 or newer). First, you must ALWAYS use the
- same <emphasis role="bold">global</emphasis> character set and
- collation (<option>--default-character-set</option>,
- <option>--default-collation</option>) on the master and the
- slave. Otherwise, you may get duplicate-key errors on the
- slave, because a key that is regarded as unique in the
- master's character set may not be unique in the slave's
- character set. Second, if the master is strictly older than
- MySQL 4.1.3, the character set of the session should never be
- made different from its global value (in other words, don't
- use <literal>SET NAMES</literal>, <literal>SET CHARACTER
- SET</literal> etc) because this character set change is not
- known to the slave. If the master is 4.1.3 or newer, and the
- slave too, the session can freely set its local value of
- character set variables (<literal>NAMES</literal>,
- <literal>CHARACTER SET</literal>,
- <literal>COLLATION_CLIENT</literal>,
- <literal>COLLATION_SERVER</literal> etc) as these settings are
- written to the binary log and then known to the slave. The
- session however is prevented from changing the
- <emphasis role="bold">global</emphasis> value of these; as
- said previously the master and slave must always have
- identical global character set values. There also is one last
- limitation: if on the master you have databases with different
- character sets from the global
- <literal>collation_server</literal> value, you should design
- your <literal>CREATE TABLE</literal> statements so that they
- don't implicitly rely on the default database's character set,
- because there currently is a bug (Bug #2326); a good
- workaround is to explicitly state the character set and
- collation in a clause of the <literal>CREATE TABLE</literal>.
- </para>
+ <orderedlist>
+
+ <listitem>
+ <para>
+ You must <emphasis role="bold">always</emphasis> use the
+ same <emphasis role="bold">global</emphasis> character set
+ and collation (<option>--default-character-set</option>,
+ <option>--default-collation</option>) on the master and
+ the slave. Otherwise, you may get duplicate-key errors on
+ the slave, because a key that is regarded as unique in the
+ master's character set may not be unique in the slave's
+ character set.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the master is older than MySQL 4.1.3, then the
+ character set of the session should never be made
+ different from its global value (in other words, do not
+ use <literal>SET NAMES</literal>, <literal>SET CHARACTER
+ SET</literal>, and so on) because this character set
+ change is not known to the slave. If both the master and
+ the slave are 4.1.3 or newer, the session can freely set
+ local values for character set variables (such as
+ <literal>NAMES</literal>, <literal>CHARACTER
+ SET</literal>, <literal>COLLATION_CLIENT</literal>, and
+ <literal>COLLATION_SERVER</literal>) as these settings are
+ written to the binary log and so known to the slave.
+ However, the session is prevented from changing the
+ <emphasis role="bold">global</emphasis> value of these; as
+ stated previously, the master and slave must always have
+ identical global character set values.
+ </para>
+ </listitem>
+
+ <listitem>
+ <remark role="todo">
+ Ask Bar about this bug - looks like it should have been
+ taken care of in WL#807 which was marked Completed on
+ 2005-07-08. Fixed in 4.1.13/4.1.14 and 5.0.9/5.0.10?
+ </remark>
+
+ <para>
+ If on the master you have databases with different
+ character sets from the global
+ <literal>collation_server</literal> value, you should
+ design your <literal>CREATE TABLE</literal> statements so
+ that they do not implicitly rely on the default database's
+ character set, because there currently is a bug (Bug
+ #2326); a good workaround is to state the character set
+ and collation explicitly in <literal>CREATE
+ TABLE</literal>.
+ </para>
+ </listitem>
+
+ </orderedlist>
</listitem>
<listitem>
@@ -1782,9 +1792,6 @@
<para>
<literal>CONVERT_TZ(...,...,@global.time_zone)</literal> is
not properly replicated.
- <literal>CONVERT_TZ(...,...,@session.time_zone)</literal> is
- properly replicated only if master and slave are 5.0.4 or
- newer.
</para>
</listitem>
@@ -1794,24 +1801,25 @@
statements which update tables; for example: <literal>SET
MAX_JOIN_SIZE=1000; INSERT INTO mytable
VALUES(@MAX_JOIN_SIZE);</literal> will not insert the same
- data on master and on slave. This does not applie to the
- common <literal>SET TIME_ZONE=...; INSERT INTO mytable
- VALUES(CONVERT_TZ(...,...,@time_zone))</literal>, which is
- fixed in MySQL 5.0.4.
+ data on the master and on the slave.
</para>
</listitem>
<listitem>
+ <remark role="todo">
+ Check on the restart issue...
+ </remark>
+
<para>
It is possible to replicate transactional tables on the master
using non-transactional tables on the slave. For example, you
can replicate an <literal>InnoDB</literal> master table as a
<literal>MyISAM</literal> slave table. However, if you do
this, there are problems if the slave is stopped in the middle
- of a <literal>BEGIN/COMMIT</literal> block, because the slave
- restarts at the beginning of the <literal>BEGIN</literal>
- block. This issue is on our TODO and will be fixed in the near
- future.
+ of a <literal>BEGIN</literal>/<literal>COMMIT</literal> block,
+ because the slave restarts at the beginning of the
+ <literal>BEGIN</literal> block. This issue is on our TODO and
+ will be fixed in the near future.
</para>
</listitem>
@@ -1820,10 +1828,7 @@
Update statements that refer to user variables (that is,
variables of the form
<literal>@<replaceable>var_name</replaceable></literal>) are
- badly replicated in 3.23 and 4.0. This is fixed in 4.1. Note
- that user variable names are case insensitive starting from
- MySQL 5.0. You should take this into account when setting up
- replication between 5.0 and an older version.
+ badly replicated in 3.23 and 4.0. This is fixed in 4.1.
</para>
</listitem>
@@ -1836,8 +1841,8 @@
<listitem>
<para>
- Starting from MySQL 4.1.11 and 5.0.3, there is a global system
- variable <literal>slave_transaction_retries</literal>: If the
+ Starting from MySQL 4.1.11, there is a global system variable
+ <literal>slave_transaction_retries</literal>: If the
replication slave SQL thread fails to execute a transaction
because of an <literal>InnoDB</literal> deadlock or exceeded
InnoDB's <literal>innodb_lock_wait_timeout</literal> or
@@ -1846,10 +1851,9 @@
<literal>TransactionInactiveTimeout</literal>, it
automatically retries
<literal>slave_transaction_retries</literal> times before
- stopping with an error. The default value is 0 in MySQL 4.1
- and 10 in MySQL 5.0. Starting from MySQL 4.1.11 and 5.0.4, the
- total count of retries can be seen in <literal>SHOW
- STATUS</literal>, see
+ stopping with an error. The default value is 0 in MySQL 4.1.
+ Starting from MySQL 4.1.11, the total count of retries can be
+ seen in <literal>SHOW STATUS</literal>; see
<xref linkend="server-status-variables"/>.
</para>
</listitem>
@@ -1875,26 +1879,25 @@
<listitem>
<para>
<emphasis>The following restriction applies to statement-based
- replication only, not to row-based replication.</emphasis> It
+ replication only, not to row-based replication</emphasis>: It
is possible for the data on the master and slave to become
different if a query is designed in such a way that the data
modification is non-deterministic; that is, left to the will
- of the query optimizer. (That generally is not a good practice
- anyway, even outside of replication!). For a detailed
+ of the query optimizer. (This is in general not a good
+ practice, even outside of replication.) For a detailed
explanation of this issue, see <xref linkend="open-bugs"/>.
</para>
</listitem>
<listitem>
<para>
- The following paragraph is no longer true if master and slave
- are both running MySQL version 5.0.4 or newer. If on master a
- <literal>LOAD DATA INFILE</literal> is interrupted in the
- middle (integrity constraint violation, killed connection...),
- the slave skips this <literal>LOAD DATA INFILE</literal>
- entirely. It means that if this command permanently
- inserted/updated some table records before being interrupted,
- these modifications won't be replicated to the slave.
+ If on the master a <literal>LOAD DATA INFILE</literal> is
+ interrupted (for example, by a integrity constraint violation
+ or a killed connection), the slave skips this <literal>LOAD
+ DATA INFILE</literal> entirely. This means that if this
+ command permanently inserted or updated table records before
+ being interrupted, these modifications are
+ <emphasis>not</emphasis> replicated to the slave.
</para>
</listitem>
@@ -1921,7 +1924,7 @@
<literal>LOCAL</literal>). Exceptions are that <literal>FLUSH
LOGS</literal>, <literal>FLUSH MASTER</literal>,
<literal>FLUSH SLAVE</literal>, and <literal>FLUSH TABLES WITH
- READ LOCK</literal> are not logged in any case. (Any of them
+ READ LOCK</literal> are not logged in any case. (Any of these
may cause problems if replicated to a slave.) For a syntax
example, see <xref linkend="flush"/>.
</para>
@@ -1929,12 +1932,8 @@
<listitem>
<para>
- MySQL only supports one master and many slaves. Later we will
- add a voting algorithm to automatically change master if
- something goes wrong with the current master. We will also
- introduce <quote>agent</quote> processes to help do load
- balancing by sending <literal>SELECT</literal> queries to
- different slaves.
+ MySQL 4.1 and earlier support only replication scenarios
+ involving one master and many slaves.
</para>
</listitem>
@@ -1946,23 +1945,22 @@
effect as follows: The first time that the master uses each
<literal>MEMORY</literal> table after startup, it notifies
slaves that the table needs to be emptied by writing a
- <literal>DELETE FROM</literal> statement for the table to its
+ <literal>DELETE FROM</literal> statement for that table to the
binary log. See <xref linkend="memory-storage-engine"/> for
- more details.
+ more information.
</para>
</listitem>
<listitem>
<para>
- Temporary tables are replicated with the exception of the case
- that you shut down the slave server (not just the slave
- threads) and you have some replicated temporary tables that
- are used in update statements that have not yet been executed
- on the slave. If you shut down the slave server, the temporary
- tables needed by those updates no longer are available when
- the slave starts again. To avoid this problem, do not shut
- down the slave while it has temporary tables open. Instead,
- use this procedure:
+ Temporary tables are replicated except in the case where you
+ shut down the slave server (not just the slave threads) and
+ you have replicated temporary tables that are used in updates
+ that have not yet been executed on the slave. If you shut down
+ the slave server, the temporary tables needed by those updates
+ are no longer available when the slave is restarted. To avoid
+ this problem, do not shut down the slave while it has
+ temporary tables open. Instead, use the following procedure:
</para>
<orderedlist>
@@ -2004,7 +2002,7 @@
</orderedlist>
<para>
- We have plans to fix this problem in the near future.
+ We plan to fix this problem in the near future.
</para>
</listitem>
@@ -2023,17 +2021,21 @@
This means that you can create a setup such as this:
</para>
+ <remark role="todo">
+ Create a figure for this.
+ </remark>
+
<programlisting>
A -> B -> C -> A
</programlisting>
<para>
- Server IDs are encoded in the binary log events, so server A
- knows when an event that it reads was originally created by
- itself and does not execute the event (unless server A was
- started with the <option>--replicate-same-server-id</option>
- option, which is meaningful only in rare setups). Thus, there
- are no infinite loops. But this circular setup works only if
+ Server IDs are encoded in binary log events, so server A knows
+ when an event that it reads was originally created by itself
+ and does not execute the event (unless server A was started
+ with the <option>--replicate-same-server-id</option> option,
+ which is meaningful only in rare cases). Thus, there are no
+ infinite loops. This type of circular setup works only if
you perform no conflicting updates between the tables. In
other words, if you insert data in both A and C, you should
never insert a row in A that may have a key that conflicts
@@ -2109,9 +2111,10 @@
<listitem>
<para>
If you update transactional tables from non-transactional
- tables inside a <literal>BEGIN/COMMIT</literal> segment,
- updates to the binary log may be out of sync if some thread
- changes the non-transactional table before the transaction
+ tables inside a
+ <literal>BEGIN</literal>/<literal>COMMIT</literal> sequence,
+ updates to the binary log may be out of sync 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.
</para>
@@ -2146,12 +2149,11 @@
INFILE</literal> from a 3.23 master, the values of the
<literal>Exec_Master_Log_Pos</literal> and
<literal>Relay_Log_Space</literal> columns of <literal>SHOW
- SLAVE STATUS</literal> become incorrect. The incorrectness of
- <literal>Exec_Master_Log_Pos</literal> causes a problem when
+ SLAVE STATUS</literal> become incorrect. The inaccuracy in
+ <literal>Exec_Master_Log_Pos</literal> causes problems when
you stop and restart replication; so it is a good idea to
correct the value before this, by doing <literal>FLUSH
- LOGS</literal> on the master. These bugs are fixed in MySQL
- 5.0.0 slaves.
+ LOGS</literal> on the master.
</para>
</listitem>
@@ -2199,23 +2201,14 @@
<title id="title-replication-options">&title-replication-options;</title>
<remark role="todo">
- This section says that it describes slave options, but there
- </remark>
-
- <remark>
- are master options that need to be listed as well, like
- </remark>
-
- <remark>
+ This section says that it describes slave options, but there are
+ master options that need to be listed as well, like
show-slave-auth-info.
</remark>
<remark role="todo">
- There really should be a separate section devoted to the use
- </remark>
-
- <remark>
- and structure of master.info, and how it interacts with startup
+ There really should be a separate section devoted to the use and
+ structure of master.info, and how it interacts with startup
options.
</remark>
@@ -2342,11 +2335,11 @@
<para>
If no <filename>master.info</filename> file exists when the slave
- server starts, it uses values for those options that are specified
- in option files or on the command line. This occurs when you start
- the server as a replication slave for the very first time, or when
- you have run <literal>RESET SLAVE</literal> and shut down and
- restarted the slave server.
+ server starts, it uses the values for those options that are
+ specified in option files or on the command line. This occurs when
+ you start the server as a replication slave for the very first
+ time, or when you have run <literal>RESET SLAVE</literal> and then
+ have shut down and restarted the slave.
</para>
<para>
@@ -2450,9 +2443,10 @@
<para>
That is, A serves as the master for the slave B, and B serves
as the master for the slave C. For this to work, B must be
- both a master and a slave. You must start both A and B with
- <option>--log-bin</option> to enable binary logging, and B
- with the <option>--log-slave-updates</option> option.
+ both a master <emphasis>and</emphasis> a slave. You must start
+ both A and B with <option>--log-bin</option> to enable binary
+ logging, and B with the <option>--log-slave-updates</option>
+ option.
</para>
</listitem>
@@ -2473,8 +2467,9 @@
</para>
<para>
- This option is not limited to replication use only. It
- produces warnings across a spectrum of server activities.
+ Note that the effects of this option are not limited to
+ replication. It produces warnings across a spectrum of server
+ activities.
</para>
</listitem>
@@ -2742,7 +2737,8 @@
An example of what does not work as you might expect: If the
slave is started with <option>--replicate-do-db=sales</option>
and you issue the following statements on the master, the
- <literal>UPDATE</literal> statement is not replicated:
+ <literal>UPDATE</literal> statement is
+ <emphasis>not</emphasis> replicated:
</para>
<programlisting>
@@ -2758,13 +2754,13 @@
<para>
The main reason for this
- <quote>just-check-the-default-database</quote> behavior is
+ <quote>check-just-the-default-database</quote> behavior is
that it's difficult from the statement alone to know whether
or not it should be replicated (for example, if you are using
multiple-table <literal>DELETE</literal> or multiple-table
<literal>UPDATE</literal> statements that go across multiple
- databases). It's also very fast to just check the default
- database.
+ databases). It is also faster to check only the default
+ database rather than all databases if there is no need.
</para>
</listitem>
@@ -2794,9 +2790,9 @@
<literal>USE</literal>) is <replaceable>db_name</replaceable>.
To specify more than one database to ignore, use this option
multiple times, once for each database. You should not use
- this option if you are using cross-database updates and you
- don't want these updates to be replicated. Please read the
- notes that follow this option list.
+ this option if you are using cross-database updates and you do
+ not want these updates to be replicated. Please read the notes
+ that follow this option list.
</para>
<para>
@@ -2804,7 +2800,8 @@
slave is started with
<option>--replicate-ignore-db=sales</option> and you issue the
following statements on the master, the
- <literal>UPDATE</literal> statement is not replicated:
+ <literal>UPDATE</literal> statement is
+ <emphasis>not</emphasis> replicated:
</para>
<programlisting>
@@ -2992,11 +2989,7 @@
<remark>
For the moment, this option is of no real interest; it is
- meant for failover
- </remark>
-
- <remark>
- replication, which is not implemented yet.
+ meant for failover replication, which is not implemented yet.
</remark>
<para>
@@ -3019,11 +3012,7 @@
<remark>
For the moment, this option is of no real interest; it is
- meant for failover
- </remark>
-
- <remark>
- replication, which is not implemented yet.
+ meant for failover replication, which is not implemented yet.
</remark>
<para>
@@ -3049,7 +3038,7 @@
</para>
<para>
- If this option is set to 1, use compression of the
+ If this option is set to 1, use compression for the
slave/master protocol if both the slave and the master support
it.
</para>
@@ -3113,12 +3102,12 @@
<para>
Do not use this option unless you fully understand why you are
- getting the errors. If there are no bugs in your replication
- setup and client programs, and no bugs in MySQL itself, an
- error that stops replication should never occur.
- Indiscriminate use of this option results in slaves becoming
- hopelessly out of sync with the master, and you have no idea
- why.
+ getting errors. If there are no bugs in your replication setup
+ and client programs, and no bugs in MySQL itself, an error
+ that stops replication should never occur. Indiscriminate use
+ of this option results in slaves becoming hopelessly out of
+ sync with the master, with you having no idea why this has
+ occurred.
</para>
<para>
@@ -3129,13 +3118,14 @@
</para>
<para>
- You can (but should not) also use the very non-recommended
+ You can also (but should not) use the very non-recommended
value of <literal>all</literal> which ignores all error
- messages and keeps barging along regardless of what happens.
- Needless to say, if you use it, we make no promises regarding
- your data integrity. Please do not complain if your data on
- the slave is not anywhere close to what it is on the master in
- this case. You have been warned.
+ messages and keeps going regardless of what happens. Needless
+ to say, if you use it, we make no guarantees regarding
+ integrity the integrity of your data. Please do not complain
+ (or file bug reports) in this case if the slave's data is not
+ anywhere close to what it is on the master. <emphasis>You have
+ been warned</emphasis>.
</para>
<para>
@@ -3160,7 +3150,7 @@
<listitem>
<para>
- Are there some <option>--replicate-do-db</option> or
+ Are there any <option>--replicate-do-db</option> or
<option>--replicate-ignore-db</option> rules?
</para>
@@ -3168,7 +3158,8 @@
<listitem>
<para>
- Yes: Test them as for <option>--binlog-do-db</option> and
+ <emphasis>Yes</emphasis>: Test them as for
+ <option>--binlog-do-db</option> and
<option>--binlog-ignore-db</option> (see
<xref linkend="binary-log"/>). What is the result of the
test?
@@ -3184,8 +3175,8 @@
<listitem>
<para>
- Execute the statement: Don't execute it immediately,
- defer the decision, go to the next step.
+ Execute the statement: Do not execute it immediately;
+ defer the decision; proceed to the next step.
</para>
</listitem>
@@ -3203,29 +3194,29 @@
<listitem>
<para>
- Are there some <option>--replicate-*-table</option> rules?
+ Are there any <option>--replicate-*-table</option> rules?
</para>
<itemizedlist>
<listitem>
<para>
- No: Execute the query and exit.
+ <emphasis>No</emphasis>: Execute the query and exit.
</para>
</listitem>
<listitem>
<para>
- Yes: Go to the next step. Only tables that are to be
- updated are compared to the rules (<literal>INSERT INTO
- sales SELECT * FROM prices</literal>: only
- <literal>sales</literal> are compared to the rules). If
- several tables are to be updated (multiple-table
- statement), the first matching table (matching
- <quote>do</quote> or <quote>ignore</quote>) wins. That is,
- the first table is compared to the rules. Then, if no
- decision could be mad, the second table is compared to the
- rules, and so forth.
+ <emphasis>Yes</emphasis>: Proceed to the next step. Only
+ tables that are to be updated are compared to the rules
+ (<literal>INSERT INTO sales SELECT * FROM
+ prices</literal>: only <literal>sales</literal> is
+ compared to the rules). If several tables are to be
+ updated (multiple-table statement), the first matching
+ table (matching <quote>do</quote> or
+ <quote>ignore</quote>) wins. That is, the first table is
+ compared to the rules. Then, if no decision could be made,
+ the second table is compared to the rules, and so on.
</para>
</listitem>
@@ -3234,27 +3225,28 @@
<listitem>
<para>
- Are there some <option>--replicate-do-table</option> rules?
+ Are there any <option>--replicate-do-table</option> rules?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Does the table match any of them?
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Execute the query and exit.
+ <emphasis>Yes</emphasis>: Execute the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3263,7 +3255,7 @@
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3272,28 +3264,28 @@
<listitem>
<para>
- Are there some <option>--replicate-ignore-table</option>
- rules?
+ Are there any <option>--replicate-ignore-table</option> rules?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Does the table match any of them?
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: Ignore the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3302,7 +3294,7 @@
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3311,7 +3303,7 @@
<listitem>
<para>
- Are there some <option>--replicate-wild-do-table</option>
+ Are there any <option>--replicate-wild-do-table</option>
rules?
</para>
@@ -3319,20 +3311,21 @@
<listitem>
<para>
- Yes: Does the table match any of them?
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Execute the query and exit.
+ <emphasis>Yes</emphasis>: Execute the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3341,7 +3334,7 @@
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3350,7 +3343,7 @@
<listitem>
<para>
- Are there some <option>--replicate-wild-ignore-table</option>
+ Are there any <option>--replicate-wild-ignore-table</option>
rules?
</para>
@@ -3358,20 +3351,21 @@
<listitem>
<para>
- Yes: Does the table match any of them?
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: Ignore the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3380,7 +3374,7 @@
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3397,14 +3391,14 @@
<listitem>
<para>
- Yes: Loop.
+ <emphasis>Yes</emphasis>: Loop.
</para>
</listitem>
<listitem>
<para>
- No: We have tested all tables to be updated and could not
- match any rule. Are there
+ <emphasis>No</emphasis>: We have now tested all tables to
+ be updated and could not match any rule. Are there
<option>--replicate-do-table</option> or
<option>--replicate-wild-do-table</option> rules?
</para>
@@ -3413,13 +3407,13 @@
<listitem>
<para>
- Yes: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: Ignore the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Execute the query and exit.
+ <emphasis>No</emphasis>: Execute the query and exit.
</para>
</listitem>
@@ -3437,6 +3431,14 @@
<title id="title-replication-faq">&title-replication-faq;</title>
+<!--
+ TODO: If I were to change this to a <qanda[set]/>, how badly would
+ Paul kill me...? ;)
+
+ More seriously, it would be nice to structure the Q-and-A bits
+ better - perhaps using 2-item itemized lists? /JS
+-->
+
<para>
<emphasis role="bold">Q</emphasis>: How do I configure a slave if
the master is running and I do not want to stop it?
@@ -3446,7 +3448,7 @@
<emphasis role="bold">A</emphasis>: There are several options. If
you have taken a backup of the master at some point and recorded
the binary log name and offset (from the output of <literal>SHOW
- MASTER STATUS</literal> ) corresponding to the snapshot, use the
+ MASTER STATUS</literal>) corresponding to the snapshot, use the
following procedure:
</para>
@@ -3575,13 +3577,13 @@
<para>
<emphasis role="bold">A</emphasis>: No, it does not. The slave can
go down or stay disconnected for hours or even days, then
- reconnect and catch up on the updates. For example, you can set up
- a master/slave relationship over a dial-up link where the link is
- up only sporadically and for short periods of time. The
- implication of this is that, at any given time, the slave is not
- guaranteed to be in sync 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.
+ reconnect and catch up on updates. For example, you can set up a
+ master/slave relationship over a dial-up link where the link is up
+ only sporadically and for short periods of time. The implication
+ of this is that, at any given time, the slave is not guaranteed to
+ be in sync 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.
</para>
<para>
@@ -3601,6 +3603,11 @@
<xref linkend="replication-implementation-details"/>.
</para>
+ <remark role="todo">
+ Check following in light of changes to TIMESTAMP in recent
+ versions. /JS
+ </remark>
+
<para>
When the slave SQL thread executes an event read from the master,
it modifies its own time to the event timestamp (this is why
@@ -3693,10 +3700,11 @@
co-master 1. Thus, when the update of client A makes it to
co-master 2, it produces tables that are different than what you
have on co-master 1, even after all the updates from co-master 2
- have also propagated. This means that you should not co-chain two
- servers in a two-way replication relationship unless you are sure
- that your updates can safely happen in any order, or unless you
- take care of mis-ordered updates somehow in the client code.
+ have also propagated. This means that you should not chain two
+ servers together in a two-way replication relationship unless you
+ are sure that your updates can safely happen in any order, or
+ unless you take care of mis-ordered updates somehow in the client
+ code.
</para>
<para>
@@ -3788,9 +3796,9 @@
<para>
<literal>safe_</literal> in each function name means that the
- function takes care of handling all the error conditions. You can
- use different names for the functions. The important thing is to
- have a unified interface for connecting for reads, connecting for
+ function takes care of handling all error conditions. You can use
+ different names for the functions. The important thing is to have
+ a unified interface for connecting for reads, connecting for
writes, doing a read, and doing a write.
</para>
@@ -3801,9 +3809,9 @@
just described are able to take advantage of a master/slave
configuration, even one involving multiple slaves. The code is a
lot easier to maintain, and adding troubleshooting options is
- trivial. You just need to modify one or two functions; for
- example, to log how long each statement took, or which statement
- among your many thousands gave you an error.
+ trivial. You need modify only one or two functions; for example,
+ to log how long each statement took, or which statement among
+ those issued gave you an error.
</para>
<para>
@@ -3850,8 +3858,8 @@
1,200 reads per second with no writes, the average write is twice
as slow as the average read, and the relationship is linear. Let
us suppose that the master and each slave have the same capacity,
- and that we have one master and N slaves. Then we have for each
- server (master or slave):
+ and that we have one master and <replaceable>N</replaceable>
+ slaves. Then we have for each server (master or slave):
</para>
<para>
@@ -3859,23 +3867,24 @@
</para>
<para>
- <literal>reads = 9 × writes / (N + 1) </literal> (reads are
- split, but writes go to all servers)
+ <literal>reads = 9 × writes / (<replaceable>N</replaceable>
+ + 1)</literal> (reads are split, but writes go to all servers)
</para>
<para>
- <literal>9 × writes / (N + 1) + 2 × writes =
- 1200</literal>
+ <literal>9 × writes / (<replaceable>N</replaceable> + 1) + 2
+ × writes = 1200</literal>
</para>
<para>
- <literal>writes = 1200 / (2 + 9/(N+1)) </literal>
+ <literal>writes = 1200 / (2 +
+ 9/(<replaceable>N</replaceable>+1))</literal>
</para>
<para>
The last equation indicates that the maximum number of writes for
- N slaves, given a maximum possible read rate of 1,200 per minute
- and a ratio of nine reads per write.
+ <replaceable>N</replaceable> slaves, given a maximum possible read
+ rate of 1,200 per minute and a ratio of nine reads per write.
</para>
<para>
@@ -3886,35 +3895,40 @@
<listitem>
<para>
- If N = 0 (which means we have no replication), our system can
- handle about 1200/11 = 109 writes per second.
+ If <replaceable>N</replaceable> = 0 (which means we have no
+ replication), our system can handle about 1200/11 = 109 writes
+ per second.
</para>
</listitem>
<listitem>
<para>
- If N = 1, we get up to 184 writes per second.
+ If <replaceable>N</replaceable> = 1, we get up to 184 writes
+ per second.
</para>
</listitem>
<listitem>
<para>
- If N = 8, we get up to 400 writes per second.
+ If <replaceable>N</replaceable> = 8, we get up to 400 writes
+ per second.
</para>
</listitem>
<listitem>
<para>
- If N = 17, we get up to 480 writes per second.
+ If <replaceable>N</replaceable> = 17, we get up to 480 writes
+ per second.
</para>
</listitem>
<listitem>
<para>
- Eventually, as N approaches infinity (and our budget negative
- infinity), we can get very close to 600 writes per second,
- increasing system throughput about 5.5 times. However, with
- only eight servers, we increased it almost four times.
+ Eventually, as <replaceable>N</replaceable> approaches
+ infinity (and our budget negative infinity), we can get very
+ close to 600 writes per second, increasing system throughput
+ about 5.5 times. However, with only eight servers, we increase
+ it nearly four times.
</para>
</listitem>
@@ -3925,10 +3939,10 @@
neglect several other factors that could turn out to be
significant on your system. In many cases, you may not be able to
perform a computation similar to the one just shown that
- accurately predicts what will happen on your system if you add N
- replication slaves. However, answering the following questions
- should help you decide whether and how much replication will
- improve the performance of your system:
+ accurately predicts what will happen on your system if you add
+ <replaceable>N</replaceable> replication slaves. However,
+ answering the following questions should help you decide if and by
+ how much replication will improve the performance of your system:
</para>
<itemizedlist>
@@ -3963,9 +3977,9 @@
<para>
<emphasis role="bold">A</emphasis>: With the currently available
features, you would have to set up a master and a slave (or
- several slaves), and write a script that monitors the master to
- see whether it is up. Then instruct your applications and the
- slaves to change master in case of failure. Some suggestions:
+ several slaves), and to write a script that monitors the master to
+ see if it is up. Then instruct your applications and the slaves to
+ change master in case of failure. Some suggestions:
</para>
<itemizedlist>
@@ -3989,14 +4003,18 @@
<listitem>
<para>
You should run your slaves with the <option>--log-bin</option>
- option and without <option>--log-slave-updates</option>. This
- way the slave is ready to become a master as soon as you issue
- <literal>STOP SLAVE</literal>; <literal>RESET
+ option and without <option>--log-slave-updates</option>. In
+ this way, the slave is ready to become a master as soon as you
+ issue <literal>STOP SLAVE</literal>; <literal>RESET
MASTER</literal>, and <literal>CHANGE MASTER TO</literal> on
the other slaves. For example, assume that you have the
following setup:
</para>
+ <remark role="todo">
+ Replace this with an actual diagram.
+ </remark>
+
<programlisting>
WC
\
@@ -4009,17 +4027,27 @@
</programlisting>
<para>
- M means the master, S the slaves, WC the clients that issue
+ <emphasis role="bold">M</emphasis> means the master,
+ <emphasis role="bold">S</emphasis> the slaves,
+ <emphasis role="bold">WC</emphasis> the clients issuing
database writes and reads; clients that issue only database
- reads are not represented, because they need not switch. S1,
- S2, and S3 are slaves running with <option>--log-bin</option>
- and without <option>--log-slave-updates</option>. Because
- updates received by a slave from the master are not logged in
- the binary log unless <option>--log-slave-updates</option> is
- specified, the binary log on each slave is empty. If for some
- reason M becomes unavailable, you can pick one slave to become
- the new master. For example, if you pick S1, all WC should be
- redirected to S1, and S2 and S3 should replicate from S1.
+ reads are not represented, because they need not switch.
+ <emphasis role="bold">S1</emphasis>,
+ <emphasis role="bold">S2</emphasis>, and
+ <emphasis role="bold">S3</emphasis> are slaves running with
+ <option>--log-bin</option> and without
+ <option>--log-slave-updates</option>. Because updates received
+ by a slave from the master are not logged in the binary log
+ unless <option>--log-slave-updates</option> is specified, the
+ binary log on each slave is empty. If for some reason
+ <emphasis role="bold">M</emphasis> becomes unavailable, you
+ can pick one of the slaves to become the new master. For
+ example, if you pick <emphasis role="bold">S1</emphasis>, all
+ <emphasis role="bold">WC</emphasis> should be redirected to
+ <emphasis role="bold">S1</emphasis>, and
+ <emphasis role="bold">S2</emphasis> and
+ <emphasis role="bold">S3</emphasis> should then replicate from
+ <emphasis role="bold">S1</emphasis>.
</para>
<para>
@@ -4028,36 +4056,55 @@
IO_THREAD</literal>, then check the output of <literal>SHOW
PROCESSLIST</literal> until you see <literal>Has read all
relay log</literal>. When this is true for all slaves, they
- can be reconfigured to the new setup. On the slave S1 being
- promoted to become the master, issue <literal>STOP
- SLAVE</literal> and <literal>RESET MASTER</literal>.
+ can be reconfigured to the new setup. On the slave
+ <emphasis role="bold">S1</emphasis> being promoted to become
+ the master, issue <literal>STOP SLAVE</literal> and
+ <literal>RESET MASTER</literal>.
</para>
<para>
- On the other slaves S2 and S3, use <literal>STOP
+ On the other slaves <emphasis role="bold">S2</emphasis> and
+ <emphasis role="bold">S3</emphasis>, use <literal>STOP
SLAVE</literal> and <literal>CHANGE MASTER TO
MASTER_HOST='S1'</literal> (where <literal>'S1'</literal>
- represents the real hostname of S1). To <literal>CHANGE
+ represents the real hostname of
+ <emphasis role="bold">S1</emphasis>). To <literal>CHANGE
MASTER</literal>, add all information about how to connect to
- S1 from S2 or S3 (user, password, port). In <literal>CHANGE
- MASTER</literal>, there is no need to specify the name of S1's
- binary log or binary log position to read from: We know it is
- the first binary log and position 4, which are the defaults
- for <literal>CHANGE MASTER</literal>. Finally, use
- <literal>START SLAVE</literal> on S2 and S3.
+ <emphasis role="bold">S1</emphasis> from
+ <emphasis role="bold">S2</emphasis> or
+ <emphasis role="bold">S3</emphasis>
+ (<replaceable>user</replaceable>,
+ <replaceable>password</replaceable>,
+ <replaceable>port</replaceable>). In <literal>CHANGE
+ MASTER</literal>, there is no need to specify the name of
+ <emphasis role="bold">S1</emphasis>'s binary log or binary log
+ position to read from: We know it is the first binary log and
+ position 4, which are the defaults for <literal>CHANGE
+ MASTER</literal>. Finally, use <literal>START SLAVE</literal>
+ on <emphasis role="bold">S2</emphasis> and
+ <emphasis role="bold">S3</emphasis>.
</para>
<para>
- Then instruct all WC to direct their statements to S1. From
- that point on, all updates statements sent by WC to S1 are
- written to the binary log of S1, which contains every update
- statement sent to S1 since M died.
+ Then instruct all <emphasis role="bold">WC</emphasis> to
+ direct their statements to
+ <emphasis role="bold">S1</emphasis>. From that point on, all
+ updates statements sent by <emphasis role="bold">WC</emphasis>
+ to <emphasis role="bold">S1</emphasis> are written to the
+ binary log of <emphasis role="bold">S1</emphasis>, which then
+ contains every update statement sent to
+ <emphasis role="bold">S1</emphasis> since
+ <emphasis role="bold">M</emphasis> died.
</para>
<para>
The result is this configuration:
</para>
+ <remark role="todo">
+ Replace with actual diagram (graphic).
+ </remark>
+
<programlisting>
WC
/
@@ -4072,16 +4119,27 @@
</programlisting>
<para>
- When M is up again, you just have to issue on it the same
- <literal>CHANGE MASTER</literal> as the one issued on S2 and
- S3, so that M becomes a slave of S1 and picks all the WC
- writes it has missed while it was down. To make M a master
- again (because it is the most powerful machine, for example),
- use the preceding procedure as if S1 was unavailable and M was
- to be the new master. During the procedure, don't forget to
- run <literal>RESET MASTER</literal> on M before making S1, S2,
- and S3 slaves of M. Otherwise, they may pick up old WC writes
- from before the point at which M became unavailable.
+ When <emphasis role="bold">M</emphasis> is up again, you must
+ issue on it the same <literal>CHANGE MASTER</literal> as that
+ issued on <emphasis role="bold">S2</emphasis> and
+ <emphasis role="bold">S3</emphasis>, so that
+ <emphasis role="bold">M</emphasis> becomes a slave of
+ <emphasis role="bold">S1</emphasis> and picks up all the
+ <emphasis role="bold">WC</emphasis> writes that it missed
+ while it was down. To make <emphasis role="bold">M</emphasis>
+ a master again (because it is the most powerful machine, for
+ example), use the preceding procedure as if
+ <emphasis role="bold">S1</emphasis> was unavailable and
+ <emphasis role="bold">M</emphasis> was to be the new master.
+ During this procedure, do not forget to run <literal>RESET
+ MASTER</literal> on <emphasis role="bold">M</emphasis> before
+ making <emphasis role="bold">S1</emphasis>,
+ <emphasis role="bold">S2</emphasis>, and
+ <emphasis role="bold">S3</emphasis> slaves of
+ <emphasis role="bold">M</emphasis>. Otherwise, they may pick
+ up old <emphasis role="bold">WC</emphasis> writes from before
+ the point at which <emphasis role="bold">M</emphasis> became
+ unavailable.
</para>
</listitem>
@@ -4360,7 +4418,7 @@
<para>
<emphasis role="bold">Check the error log for
messages</emphasis>. Many users have lost time by not doing
- this early enough.
+ this early enough after encountering problems.
</para>
</listitem>
@@ -4400,13 +4458,13 @@
<listitem>
<para>
- If the slave was running before but has stopped, the reason
- usually is that some statement that succeeded on the master
- failed on the slave. This should never happen if you have
- taken a proper snapshot of the master, and never modify the
- data on the slave outside of the slave thread. If it does, it
- is a bug or you have encountered one of the known replication
- limitations described in
+ If the slave was running previously but has stopped, the
+ reason usually is that some statement that succeeded on the
+ master failed on the slave. This should never happen if you
+ have taken a proper snapshot of the master, and never modified
+ the data on the slave outside of the slave thread. If it does,
+ it is a bug or you have encountered one of the known
+ replication limitations described in
<xref linkend="replication-features"/>. If it is a bug, see
<xref linkend="replication-bugs"/> for instructions on how to
report it.
@@ -4448,13 +4506,13 @@
</para>
<programlisting>
-mysql> <userinput>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n;</userinput>
+mysql> <userinput>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = <replaceable>n</replaceable>;</userinput>
mysql> <userinput>START SLAVE;</userinput>
</programlisting>
<para>
- The value of <literal>n</literal> should be 1 if the next
- statement from the master does not use
+ The value of <replaceable>n</replaceable> should be 1 if
+ the next statement from the master does not use
<literal>AUTO_INCREMENT</literal> or
<literal>LAST_INSERT_ID()</literal>. Otherwise, the value
should be 2. The reason for using a value of 2 for
@@ -4467,11 +4525,12 @@
<listitem>
<para>
If you are sure that the slave started out perfectly
- synchronized with the master, and no one has updated the
- tables involved outside of slave thread, then presumably
- the discrepancy is the result of a bug. If you are running
- the most recent version, please report the problem. If you
- are running an older version of MySQL, try upgrading.
+ synchronized with the master, and that no one has updated
+ the tables involved outside of the slave thread, then
+ presumably the discrepancy is the result of a bug. If you
+ are running the most recent version, please report the
+ problem. If you are running an older version of MySQL, try
+ upgrading to the latest production release.
</para>
</listitem>
@@ -4489,17 +4548,17 @@
<para>
When you have determined that there is no user error involved, and
replication still either does not work at all or is unstable, it
- is time to send us a bug report. We need to get as much
+ is time to send us a bug report. We need to obtain as much
information as possible from you to be able to track down the bug.
- Please do spend some time and effort preparing a good bug report.
+ Please spend some time and effort in preparing a good bug report.
</para>
<para>
If you have a repeatable test case that demonstrates the bug,
please enter it into our bugs database at
- <ulink url="http://bugs.mysql.com/"/>. If you have a phantom
- problem (one that you cannot duplicate <quote>at will</quote>),
- use the following procedure:
+ <ulink url="http://bugs.mysql.com/"/>. If you have a
+ <quote>phantom</quote> problem (one that you cannot duplicate at
+ will), then use the following procedure:
</para>
<orderedlist>
@@ -4511,17 +4570,18 @@
out of sync, 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.
- This is not a replication problem. It is a problem of outside
- interference that causes replication to fail.
+ <emphasis>This is not a replication problem. It is a problem
+ with outside interference causing replication to
+ fail.</emphasis>
</para>
</listitem>
<listitem>
<para>
Run the slave with the <option>--log-slave-updates</option>
- and <option>--log-bin</option> options. They cause the slave
- to log the updates that it receives from the master into its
- own binary logs.
+ and <option>--log-bin</option> options. These options cause
+ the slave to log the updates that it receives from the master
+ into its own binary logs.
</para>
</listitem>
@@ -4550,14 +4610,14 @@
<listitem>
<para>
The output of <literal>SHOW MASTER STATUS</literal> from
- the master at the time you have discovered the problem
+ the master at the time you discovered the problem
</para>
</listitem>
<listitem>
<para>
The output of <literal>SHOW SLAVE STATUS</literal> from
- the master at the time you have discovered the problem
+ the master at the time you discovered the problem
</para>
</listitem>
@@ -4573,13 +4633,13 @@
<listitem>
<para>
Use <command>mysqlbinlog</command> to examine the binary logs.
- The following should be helpful to find the trouble query, for
+ The following should be helpful to find the problem query, for
example:
</para>
<programlisting>
shell> <userinput>mysqlbinlog -j pos_from_slave_status \</userinput>
- <userinput>/path/to/log_from_slave_status | head</userinput>
+ <userinput><replaceable>/path/to/log_from_slave_status</replaceable> | head</userinput>
</programlisting>
</listitem>
--- 1.27/refman/replication.xml 2005-09-01 02:15:23 +10:00
+++ 1.28/refman/replication.xml 2005-09-03 04:22:48 +10:00
@@ -6,12 +6,12 @@
%fixedchars.entities;
<!ENTITY % title.entities SYSTEM "refman-common/titles.ent">
%title.entities;
- <!ENTITY % versions.entities SYSTEM "versions.ent">
+ <!ENTITY % versions.entities SYSTEM "versions.ent">
%versions.entities;
]>
-<chapter id='replication'>
+<chapter id="replication">
- <title id='title-replication'>&title-replication;</title>
+ <title id="title-replication">&title-replication;</title>
<indexterm type="concept">
<primary>replication</primary>
@@ -32,7 +32,9 @@
<secondary>increasing with replication</secondary>
</indexterm>
-<!-- Need better intro summary of what the sections here are -->
+ <remark>
+ Need better intro summary of what the sections here are
+ </remark>
<para>
Replication capabilities allowing the databases on one MySQL server
@@ -52,14 +54,15 @@
<para>
We suggest that you visit our Web site at
- <ulink url="http://www.mysql.com"/> often and read updates to this
- chapter. Replication is constantly being improved, and we update the
- manual frequently with the most current information.
+ <ulink url="http://www.mysql.com"/> frequently as well as check for
+ revisions to this chapter. Replication is constantly being improved,
+ and we update the manual regularly with the most current
+ information.
</para>
<section id="replication-intro">
- <title id='title-replication-intro'>&title-replication-intro;</title>
+ <title id="title-replication-intro">&title-replication-intro;</title>
<para>
MySQL 3.23.15 and up features support for one-way replication. One
@@ -75,7 +78,7 @@
</para>
<para>
- A slave server can also serve as a master if you want to set up
+ A slave server can itself serve as a master if you want to set up
chained replication servers.
</para>
@@ -161,7 +164,7 @@
<section id="replication-implementation">
- <title id='title-replication-implementation'>&title-replication-implementation;</title>
+ <title id="title-replication-implementation">&title-replication-implementation;</title>
<indexterm type="concept">
<primary>master/slave setup</primary>
@@ -181,14 +184,14 @@
</para>
<para>
- It is <emphasis role="bold">very important</emphasis> to realize
- that the binary log is simply a record starting from the fixed
- point in time at which you enable binary logging. Any slaves that
- you set up need copies of the databases on your master as they
- existed at the moment you enabled binary logging on the master. If
- you start your slaves with databases that are not the same as what
- was on the master <emphasis role="bold">when the binary log was
- started</emphasis>, your slaves may fail.
+ It is <emphasis>extremely</emphasis> important to realize that the
+ binary log is simply a record starting from the fixed point in
+ time at which you enable binary logging. Any slaves that you set
+ up need copies of the databases on your master <emphasis>as they
+ existed at the moment you enabled binary logging on the
+ master</emphasis>. If you start your slaves with databases that
+ are not in the same state as those on the master when the binary
+ log was started, your slaves are quite likely to fail.
</para>
<para>
@@ -209,26 +212,26 @@
the master is relatively small, or if a prolonged read lock on the
master is acceptable. While the actual speed of <literal>LOAD DATA
FROM MASTER</literal> may vary from system to system, a good rule
- of thumb for how long it takes is 1 second per 1MB of data. That
- is only a rough estimate, but you should get close to it if both
- master and slave are equivalent to 700MHz Pentium performance and
- are connected through a 100MBit/s network.
+ of thumb for how long it takes is 1 second per 1MB of data. This
+ is a rough estimate, but you should find it fairly accurate if
+ both master and slave are equivalent to 700MHz Pentium CPUs in
+ performance and are connected through a 100Mbps network.
</para>
<para>
After the slave has been set up with a copy of the master's data,
it connects to the master and waits for updates to process. If the
- master goes away or the slave loses connectivity with your master,
- it keeps trying to connect periodically until it is able to
- reconnect and resume listening for updates. The retry interval is
- controlled by the <option>--master-connect-retry</option> option.
- The default is 60 seconds.
+ master fails, or the slave loses connectivity with your master,
+ the slave keeps trying to connect periodically until it is able to
+ resume listening for updates. The retry interval is controlled by
+ the <option>--master-connect-retry</option> option. The default is
+ 60 seconds.
</para>
<para>
Each slave keeps track of where it left off. The master server has
- no knowledge of how many slaves there are or which ones are up to
- date at any given time.
+ no knowledge of how many slaves there are or of which ones are up
+ to date at any given time.
</para>
</section>
@@ -291,28 +294,29 @@
<section id="replication-implementation-details">
- <title id='title-replication-implementation-details'>&title-replication-implementation-details;</title>
+ <title id="title-replication-implementation-details">&title-replication-implementation-details;</title>
<para>
MySQL replication capabilities are implemented using three threads
- (one on the master server and two on the slave). When
+ (one on the master server and two on the slave). When a
<literal>START SLAVE</literal> is issued, the slave creates an I/O
- thread. The I/O thread connects to the master and asks it to send
- the statements recorded in its binary logs. The master creates a
+ thread, which connects to the master and asks it to send the
+ statements recorded in its binary logs. The master creates a
thread to send the binary log contents to the slave. This thread
can be identified as the <literal>Binlog Dump</literal> thread in
the output of <literal>SHOW PROCESSLIST</literal> on the master.
The slave I/O thread reads what the master <literal>Binlog
- Dump</literal> thread sends and simply copies it to some local
- files in the slave's data directory called relay logs. The third
- thread is the SQL thread, which the slave creates to read the
- relay logs and execute the updates they contain.
+ Dump</literal> thread sends and copies this data to local files,
+ known as <emphasis>relay logs</emphasis>, in the slave's data
+ directory. The third thread is the SQL thread, which the slave
+ creates in order to read the relay logs and to execute the updates
+ they contain.
</para>
<para>
- In the preceding description, there are three threads per slave.
- For a master that has multiple slaves, it creates one thread for
- each currently connected slave, and each slave has its own I/O and
+ In the preceding description, there are three threads per slave. A
+ master that has multiple slaves creates one thread for each slave
+ that is currently connected slave; each slave has its own I/O and
SQL threads.
</para>
@@ -333,10 +337,11 @@
thread lags far behind and may take hours to catch up. If the
slave stops before the SQL thread has executed all the fetched
statements, the I/O thread has at least fetched everything so that
- a safe copy of the statements is locally stored in the slave's
- relay logs for execution when next the slave starts. This allows
- the binary logs to be purged on the master, because it no longer
- need wait for the slave to fetch their contents.
+ a safe copy of the statements is stored locally in the slave's
+ relay logs, ready for execution the next time that the slave
+ starts. This allows the binary logs to be purged on the master,
+ because it no longer needs to wait for the slave to fetch their
+ contents.
</para>
<para>
@@ -410,26 +415,28 @@
<para>
This information indicates that thread 10 is the I/O thread that
is communicating with the master server, and thread 11 is the SQL
- thread that is processing the updates stored in the relay logs.
- Currently, both threads are idle, waiting for further updates.
+ thread that is processing the updates stored in the relay logs. At
+ the time that the <literal>SHOW PROCESSLIST</literal> was run,
+ both threads were idle, waiting for further updates.
</para>
<para>
- Note that the value in the <literal>Time</literal> column can tell
+ Note that the value in the <literal>Time</literal> column can show
how late the slave is compared to the master. See
<xref linkend="replication-faq"/>.
</para>
<section id="master-thread-states">
- <title id='title-master-thread-states'>&title-master-thread-states;</title>
+ <title id="title-master-thread-states">&title-master-thread-states;</title>
<para>
- The following list shows the most common states you see in the
- <literal>State</literal> column for the master's <literal>Binlog
- Dump</literal> thread. If you don't see any <literal>Binlog
- Dump</literal> threads on a master server, replication is not
- running. That is, no slaves currently are connected.
+ The following list shows the most common states you may see in
+ the <literal>State</literal> column for the master's
+ <literal>Binlog Dump</literal> thread. If you don't see any
+ <literal>Binlog Dump</literal> threads on a master server, this
+ means that replication is not running — that is, that no
+ slaves are currently connected.
</para>
<itemizedlist>
@@ -440,10 +447,10 @@
</para>
<para>
- Binary logs consist of events, where an event is usually an
- update statement plus some other information. The thread has
- read an event from the binary log and is sending it to the
- slave.
+ Binary logs consist of <emphasis>events</emphasis>, where an
+ event is usually an update plus some other information. The
+ thread has read an event from the binary log and is now
+ sending it to the slave.
</para>
</listitem>
@@ -467,9 +474,9 @@
<para>
The thread has read all outstanding updates from the binary
- logs and sent them to the slave. It is idle, waiting for new
- events to appear in the binary log resulting from new update
- statements being executed on the master.
+ logs and sent them to the slave. The thread is now idle,
+ waiting for new events to appear in the binary log resulting
+ from new updates occurring on the master.
</para>
</listitem>
@@ -489,7 +496,7 @@
<section id="slave-io-thread-states">
- <title id='title-slave-io-thread-states'>&title-slave-io-thread-states;</title>
+ <title id="title-slave-io-thread-states">&title-slave-io-thread-states;</title>
<para>
The following list shows the most common states you see in the
@@ -519,8 +526,8 @@
</para>
<para>
- A very brief state that occurs just after the connection to
- the master is established.
+ A state that occurs very briefly, immediately after the
+ connection to the master is established.
</para>
</listitem>
@@ -530,8 +537,8 @@
</para>
<para>
- A very brief state that occurs just after the connection to
- the master is established.
+ A state that occurs very briefly immediately after the
+ connection to the master is established.
</para>
</listitem>
@@ -541,10 +548,11 @@
</para>
<para>
- A very brief state that occurs just after the connection to
- the master is established. The thread sends to the master a
- request for the contents of its binary logs, starting from
- the requested binary log filename and position.
+ A state that occurs very briefly, immediately after the
+ connection to the master is established. The thread sends to
+ the master a request for the contents of its binary logs,
+ starting from the requested binary log filename and
+ position.
</para>
</listitem>
@@ -636,10 +644,10 @@
<para>
You are using a non-zero
<literal>relay_log_space_limit</literal> value, and the
- relay logs have grown so much that their combined size
- exceeds this value. The I/O thread is waiting until the SQL
- thread frees enough space by processing relay log contents
- so that it can delete some relay log files.
+ relay logs have grown until their combined size exceeds this
+ value. The I/O thread is waiting until the SQL thread frees
+ enough space by processing relay log contents so that it can
+ delete some relay log files.
</para>
</listitem>
@@ -649,7 +657,7 @@
</para>
<para>
- A very brief state that occurs as the thread is stopping.
+ A state that occurs briefly as the thread is stopping.
</para>
</listitem>
@@ -659,11 +667,12 @@
<section id="slave-sql-thread-states">
- <title id='title-slave-sql-thread-states'>&title-slave-sql-thread-states;</title>
+ <title id="title-slave-sql-thread-states">&title-slave-sql-thread-states;</title>
<para>
- The following list shows the most common states you see in the
- <literal>State</literal> column for a slave server SQL thread:
+ The following list shows the most common states you may see in
+ the <literal>State</literal> column for a slave server SQL
+ thread:
</para>
<itemizedlist>
@@ -674,8 +683,8 @@
</para>
<para>
- The thread has read an event from the relay log so that it
- can process it.
+ The thread has read an event from the relay log so that the
+ event can be processed.
</para>
</listitem>
@@ -686,9 +695,9 @@
</para>
<para>
- The thread has processed all events in the relay log files
- and is waiting for the I/O thread to write new events to the
- relay log.
+ The thread has processed all events in the relay log files,
+ and is now waiting for the I/O thread to write new events to
+ the relay log.
</para>
</listitem>
@@ -715,7 +724,7 @@
<section id="slave-logs">
- <title id='title-slave-logs'>&title-slave-logs;</title>
+ <title id="title-slave-logs">&title-slave-logs;</title>
<para>
By default, relay logs are named using filenames of the form
@@ -736,8 +745,8 @@
</para>
<para>
- Relay logs have the same format as binary logs, so you can use
- <command>mysqlbinlog</command> to read them. A relay log is
+ Relay logs have the same format as binary logs, and can be read
+ using <command>mysqlbinlog</command>. A relay log is
automatically deleted by the SQL thread as soon as it has
executed all its events and no longer needs it). There is no
explicit mechanism for deleting relay logs, because the SQL
@@ -800,8 +809,8 @@
<para>
A slave replication server creates two additional small files in
- the data directory. These are status files and are named
- <filename>master.info</filename> and
+ the data directory. These <emphasis>status files</emphasis> are
+ named <filename>master.info</filename> and
<filename>relay-log.info</filename> by default. They contain
information like that shown in the output of the <literal>SHOW
SLAVE STATUS</literal> statement (see
@@ -938,7 +947,7 @@
The <filename>relay-log.info</filename> file is updated by the
SQL thread. The correspondence between the lines in the file and
the columns displayed by <literal>SHOW SLAVE STATUS</literal> is
- as follows:
+ shown here:
</para>
<informaltable>
@@ -970,14 +979,14 @@
</tgroup>
</informaltable>
-<!-- TODO: This stuff about backups is out of place. We haven't even -->
-
-<!-- described how to set up replication yet, much less worry about backups. -->
-
-<!-- Create a new Backup Issues within this chapter? -->
+ <remark role="todo">
+ This stuff about backups is out of place. We haven't even
+ described how to set up replication yet, much less worry about
+ backups. Create a new Backup Issues within this chapter?
+ </remark>
<para>
- When you back up your slave's data, you should back up these two
+ When you back up the slave's data, you should back up these two
small files as well, along with the relay log files. They are
needed to resume replication after you restore the slave's data.
If you lose the relay logs but still have the
@@ -986,8 +995,8 @@
binary logs. Then you can use <literal>CHANGE MASTER
TO</literal> with the <literal>MASTER_LOG_FILE</literal> and
<literal>MASTER_LOG_POS</literal> options to tell the slave to
- re-read the binary logs from that point. This requires that the
- binary logs still exist on the master server.
+ re-read the binary logs from that point. Of course, this
+ requires that the binary logs still exist on the master server.
</para>
<para>
@@ -1009,18 +1018,18 @@
<section id="replication-howto">
- <title id='title-replication-howto'>&title-replication-howto;</title>
+ <title id="title-replication-howto">&title-replication-howto;</title>
<para>
- Here is a quick description of how to set up complete replication
+ Here is a brief description of how to set up complete replication
of your current MySQL server. It assumes that you want to
- replicate all your databases and have not configured replication
- before. You need to shut down your master server briefly to
- complete the steps outlined here.
+ replicate all databases on the master and have not previously
+ configured replication. You need to shut down your master server
+ briefly to complete the steps outlined here.
</para>
<para>
- The procedure is written in terms of setting up a single slave,
+ This procedure is written in terms of setting up a single slave,
but you can use it to set up multiple slaves.
</para>
@@ -1061,7 +1070,7 @@
<para>
Please do not report bugs until you have verified that the
- problem is present in the latest release.
+ problem is present in the latest MySQL release.
</para>
</listitem>
@@ -1071,7 +1080,9 @@
can use to connect. This account must be given the
<literal>REPLICATION SLAVE</literal> privilege. If the account
is used only for replication (which is recommended), you don't
- need to grant any additional privileges.
+ need to grant any additional privileges. (For informaiton
+ about setting up user accounts and privileges, see
+ <xref linkend="user-account-management"/>.)
</para>
<para>
@@ -1157,7 +1168,7 @@
</para>
<para>
- Leave the client running from which you issue the
+ Leave running the client from which you issue the
<literal>FLUSH TABLES</literal> statement so that the read
lock remains in effect. (If you exit the client, the lock is
released.) Then take a snapshot of the data on your master
@@ -1246,20 +1257,20 @@
<para>
If you are using <literal>InnoDB</literal> tables, ideally you
- should use the <literal>InnoDB Hot Backup</literal> tool. It
- takes a consistent snapshot without acquiring any locks on the
- master server, and records the log name and offset
- corresponding to the snapshot to be later used on the slave.
- <literal>InnoDB Hot Backup</literal> is a non-free
- (commercial) additional tool that is not included in the
- standard MySQL distribution. See the <literal>InnoDB Hot
- Backup</literal> home page at
- <ulink url="http://www.innodb.com/manual.php"/> for detailed
- information and screenshots.
+ should use the <command><literal>InnoDB</literal> Hot
+ Backup</command> tool, which takes a consistent snapshot
+ without acquiring any locks on the master server, and records
+ the log name and offset corresponding to the snapshot to be
+ later used on the slave. <command>Hot Backup</command> is an
+ additional non-free (commercial) tool that is not included in
+ the standard MySQL distribution. See the
+ <command><literal>InnoDB</literal> Hot Backup</command> home
+ page at <ulink url="http://www.innodb.com/manual.php"/> for
+ detailed information.
</para>
<para>
- Without the <literal>Hot Backup</literal> tool, the quickest
+ Without the <command>Hot Backup</command> tool, the quickest
way to take a binary snapshot of <literal>InnoDB</literal>
tables is to shut down the master server and copy the
<literal>InnoDB</literal> data files, log files, and table
@@ -1364,9 +1375,9 @@
</para>
<para>
- If you don't specify a <literal>server-id</literal> value, it
+ 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
+ <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
@@ -1490,7 +1501,8 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the slave, you get the following error in its error log:
+ value for the slave, you get the following error in the slave's
+ error log:
</para>
<programlisting>
@@ -1508,17 +1520,17 @@
one file named <filename>master.info</filename> and another named
<filename>relay-log.info</filename>. The slave uses these two
files to keep track of how much of the master's binary log it has
- processed. <emphasis role="bold">Do not</emphasis> remove or edit
- these files, unless you really know what you are doing and
- understand the implications. Even in that case, it is preferred
- that you use the <literal>CHANGE MASTER TO</literal> statement.
+ processed. Do <emphasis>not</emphasis> remove or edit these files
+ unless you know exactly what you are doing and fully understand
+ the implications. Even in that case, it is preferred that you use
+ the <literal>CHANGE MASTER TO</literal> statement.
</para>
<para>
<emphasis role="bold">Note</emphasis>: The content of
- <filename>master.info</filename> overrides some options specified
- on the command line or in <filename>my.cnf</filename>. See
- <xref linkend="replication-options"/> for more details.
+ <filename>master.info</filename> overrides some of the options
+ specified on the command line or in <filename>my.cnf</filename>.
+ See <xref linkend="replication-options"/> for more details.
</para>
<para>
@@ -1542,7 +1554,7 @@
<section id="replication-compatibility">
- <title id='title-replication-compatibility'>&title-replication-compatibility;</title>
+ <title id="title-replication-compatibility">&title-replication-compatibility;</title>
<para>
The original binary log format was developed in MySQL 3.23. It
@@ -1592,7 +1604,7 @@
<section id="replication-upgrade">
- <title id='title-replication-upgrade'>&title-replication-upgrade;</title>
+ <title id="title-replication-upgrade">&title-replication-upgrade;</title>
<para>
When you upgrade servers that participate in a replication setup,
@@ -1612,7 +1624,7 @@
<section id="replication-upgrade-4-0">
- <title id='title-replication-upgrade-4-0'>&title-replication-upgrade-4-0;</title>
+ <title id="title-replication-upgrade-4-0">&title-replication-upgrade-4-0;</title>
<para>
This section applies to upgrading replication from MySQL 3.23 to
@@ -1685,12 +1697,11 @@
<section id="replication-upgrade-5-0">
- <title id='title-replication-upgrade-5-0'>&title-replication-upgrade-5-0;</title>
+ <title id="title-replication-upgrade-5-0">&title-replication-upgrade-5-0;</title>
<para>
This section applies to upgrading replication from MySQL 3.23,
- 4.0, or 4.1 to 5.0.0. A 4.0 server should be 4.0.3 or newer, as
- mentioned in <xref linkend="replication-compatibility"/>.
+ 4.0, or 4.1 to 5.0. A 4.0 server should be 4.0.3 or newer.
</para>
<para>
@@ -1706,32 +1717,32 @@
<para>
When you upgrade a master from MySQL 3.23, 4.0, or 4.1 to 5.0.0,
you should first ensure that all the slaves of this master are
- 5.0.0. If that's not the case, you should first upgrade your
- slaves. To upgrade each slave, just shut it down, upgrade it to
- 5.0.0, restart it, and restart replication. The 5.0.0 slave is
- able to read its old relay logs that were written before the
- upgrade and execute the statements they contain. Relay logs
- created by the slave after the upgrade are in 5.0.0 format.
+ using the same 5.0.x release. If this is not the case, you
+ should first upgrade your slaves. To upgrade each slave, shut it
+ down, upgrade it to the appropriate 5.0.x version, restart it,
+ and restart replication. The 5.0 slave is able to read the old
+ relay logs written prior to the upgrade and to execute the
+ statements they contain. Relay logs created by the slave after
+ the upgrade are in 5.0 format.
</para>
<para>
After the slaves have been upgraded, shut down your master,
- upgrade it to 5.0.0, and restart it. The 5.0.0 master is able to
- read its old binary logs that were written before the upgrade
- and send them to the 5.0.0 slaves. The slaves recognize the old
- format and handle it properly. Binary logs created by master
- after the upgrade are in 5.0.0 format. These too are recognized
- by the 5.0.0 slaves.
+ upgrade it to the same 5.0.x release as the slaves, and restart
+ it. The 5.0 master is able to read the old binary logs written
+ prior to the upgrade and to send them to the 5.0 slaves. The
+ slaves recognize the old format and handle it properly. Binary
+ logs created by master following the upgrade are in 5.0 format.
+ These too are recognized by the 5.0 slaves.
</para>
<para>
In other words, there are no measures to take when upgrading to
- 5.0.0, except that slaves must be 5.0.0 before you can upgrade
- the master to 5.0.0. Note that downgrading from 5.0.0 to older
- versions does not work so automatically: You must ensure that
- any 5.0.0 binary logs or relay logs have been fully processed,
- so that you can remove them before proceeding with the
- downgrade.
+ 5.0, except that the slaves must be 5.0 before you can upgrade
+ the master to 5.0. Note that downgrading from 5.0 to older
+ versions does not work so simply: you must ensure that any 5.0
+ binary logs or relay logs have been fully processed, so that you
+ can remove them before proceeding with the downgrade.
</para>
</section>
@@ -1740,7 +1751,7 @@
<section id="replication-features">
- <title id='title-replication-features'>&title-replication-features;</title>
+ <title id="title-replication-features">&title-replication-features;</title>
<indexterm type="concept">
<primary>options</primary>
@@ -1831,7 +1842,7 @@
old implementation of <literal>PASSWORD()</literal>. (Note
that the <literal>PASSWORD()</literal> implementation in MySQL
4.1.0 differs from every other version of MySQL. It is best to
- avoid 4.1.0 in a replication situation.)
+ avoid 4.1.0 in a replication scenario.)
</para>
</listitem>
@@ -1856,8 +1867,8 @@
The <literal>FOREIGN_KEY_CHECKS</literal> variable is
replicated as of MySQL 4.0.14. The
<literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
- and <literal>SQL_AUTO_IS_NULL</literal> variables are
- replicated as of 5.0.0. The <literal>TABLE_TYPE</literal>,
+ and <literal>SQL_AUTO_IS_NULL</literal> variables are all
+ replicated in MySQL 5.0. The <literal>TABLE_TYPE</literal>,
also known as <literal>STORAGE_ENGINE</literal> variable is
not yet replicated, which is a good thing for replication
between different storage engines.
@@ -1876,40 +1887,67 @@
<listitem>
<para>
- This paragraph applies to replication between MySQL servers
- using different character sets where the master runs MySQL 4.1
- (and slave runs 4.1 or newer). First, you must ALWAYS use the
- same <emphasis role="bold">global</emphasis> character set and
- collation (<option>--default-character-set</option>,
- <option>--default-collation</option>) on the master and the
- slave. Otherwise, you may get duplicate-key errors on the
- slave, because a key that is regarded as unique in the
- master's character set may not be unique in the slave's
- character set. Second, if the master is strictly older than
- MySQL 4.1.3, the character set of the session should never be
- made different from its global value (in other words, don't
- use <literal>SET NAMES</literal>, <literal>SET CHARACTER
- SET</literal> etc) because this character set change is not
- known to the slave. If the master is 4.1.3 or newer, and the
- slave too, the session can freely set its local value of
- character set variables (<literal>NAMES</literal>,
- <literal>CHARACTER SET</literal>,
- <literal>COLLATION_CLIENT</literal>,
- <literal>COLLATION_SERVER</literal> etc) as these settings are
- written to the binary log and then known to the slave. The
- session however is prevented from changing the
- <emphasis role="bold">global</emphasis> value of these; as
- said previously the master and slave must always have
- identical global character set values. There also is one last
- limitation: if on the master you have databases with different
- character sets from the global
- <literal>collation_server</literal> value, you should design
- your <literal>CREATE TABLE</literal> statements so that they
- don't implicitly rely on the default database's character set,
- because there currently is a bug (Bug #2326); a good
- workaround is to explicitly state the character set and
- collation in a clause of the <literal>CREATE TABLE</literal>.
+ The following applies to replication between MySQL servers
+ using different character sets:
</para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ You must <emphasis role="bold">always</emphasis> use the
+ same <emphasis role="bold">global</emphasis> character set
+ and collation (<option>--default-character-set</option>,
+ <option>--default-collation</option>) on the master and
+ the slave. Otherwise, you may get duplicate-key errors on
+ the slave, because a key that is regarded as unique in the
+ master's character set may not be unique in the slave's
+ character set.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the master is older than MySQL 4.1.3, then the
+ character set of the session should never be made
+ different from its global value (in other words, do not
+ use <literal>SET NAMES</literal>, <literal>SET CHARACTER
+ SET</literal>, and so on) because this character set
+ change is not known to the slave. If both the master and
+ the slave are 4.1.3 or newer, the session can freely set
+ local values for character set variables (such as
+ <literal>NAMES</literal>, <literal>CHARACTER
+ SET</literal>, <literal>COLLATION_CLIENT</literal>, and
+ <literal>COLLATION_SERVER</literal>) as these settings are
+ written to the binary log and so known to the slave.
+ However, the session is prevented from changing the
+ <emphasis role="bold">global</emphasis> value of these; as
+ stated previously, the master and slave must always have
+ identical global character set values.
+ </para>
+ </listitem>
+
+ <listitem>
+ <remark role="todo">
+ Ask Bar about this bug - looks like it should have been
+ taken care of in WL#807 which was marked Completed on
+ 2005-07-08. Fixed in 4.1.13/4.1.14 and 5.0.9/5.0.10?
+ </remark>
+
+ <para>
+ If on the master you have databases with different
+ character sets from the global
+ <literal>collation_server</literal> value, you should
+ design your <literal>CREATE TABLE</literal> statements so
+ that they do not implicitly rely on the default database's
+ character set, because there currently is a bug (Bug
+ #2326); a good workaround is to state the character set
+ and collation explicitly in <literal>CREATE
+ TABLE</literal>.
+ </para>
+ </listitem>
+
+ </orderedlist>
</listitem>
<listitem>
@@ -1921,9 +1959,9 @@
time zone in which MySQL server runs by using the
<option>--timezone=<replaceable>timezone_name</replaceable></option>
option of the <filename>mysqld_safe</filename> script or by
- setting the <literal>TZ</literal> environment variable. Also
- starting from version 4.1.3 both master and slave should have
- the same default connection time zone set, that is the
+ setting the <literal>TZ</literal> environment variable. Both
+ master and slave should also have the same default connection
+ time zone setting; that is, the
<option>--default-time-zone</option> parameter should have the
same value for both master and slave.
</para>
@@ -1945,24 +1983,28 @@
statements which update tables; for example: <literal>SET
MAX_JOIN_SIZE=1000; INSERT INTO mytable
VALUES(@MAX_JOIN_SIZE);</literal> will not insert the same
- data on master and on slave. This does not applie to the
- common <literal>SET TIME_ZONE=...; INSERT INTO mytable
+ data on master and on slave. This does not apply to the common
+ <literal>SET TIME_ZONE=...; INSERT INTO mytable
VALUES(CONVERT_TZ(...,...,@time_zone))</literal>, which is
fixed in MySQL 5.0.4.
</para>
</listitem>
<listitem>
+ <remark role="todo">
+ Check on the restart issue...
+ </remark>
+
<para>
It is possible to replicate transactional tables on the master
using non-transactional tables on the slave. For example, you
can replicate an <literal>InnoDB</literal> master table as a
<literal>MyISAM</literal> slave table. However, if you do
this, there are problems if the slave is stopped in the middle
- of a <literal>BEGIN/COMMIT</literal> block, because the slave
- restarts at the beginning of the <literal>BEGIN</literal>
- block. This issue is on our TODO and will be fixed in the near
- future.
+ of a <literal>BEGIN</literal>/<literal>COMMIT</literal> block,
+ because the slave restarts at the beginning of the
+ <literal>BEGIN</literal> block. This issue is on our TODO and
+ will be fixed in the near future.
</para>
</listitem>
@@ -2026,12 +2068,12 @@
<listitem>
<para>
<emphasis>The following restriction applies to statement-based
- replication only, not to row-based replication.</emphasis> It
+ replication only, not to row-based replication</emphasis>: It
is possible for the data on the master and slave to become
different if a query is designed in such a way that the data
modification is non-deterministic; that is, left to the will
- of the query optimizer. (That generally is not a good practice
- anyway, even outside of replication!). For a detailed
+ of the query optimizer. (This is in general not a good
+ practice, even outside of replication.) For a detailed
explanation of this issue, see <xref linkend="open-bugs"/>.
</para>
</listitem>
@@ -2072,7 +2114,7 @@
<literal>LOCAL</literal>). Exceptions are that <literal>FLUSH
LOGS</literal>, <literal>FLUSH MASTER</literal>,
<literal>FLUSH SLAVE</literal>, and <literal>FLUSH TABLES WITH
- READ LOCK</literal> are not logged in any case. (Any of them
+ READ LOCK</literal> are not logged in any case. (Any of these
may cause problems if replicated to a slave.) For a syntax
example, see <xref linkend="flush"/>.
</para>
@@ -2093,27 +2135,26 @@
<para>
When a server shuts down and restarts, its
<literal>MEMORY</literal> (<literal>HEAP</literal>) tables
- become empty. As of MySQL 4.0.18, the master replicates this
- effect as follows: The first time that the master uses each
- <literal>MEMORY</literal> table after startup, it notifies
+ become empty. In MySQL 5.0, the master replicates this effect
+ as follows: The first time that the master uses each
+ <literal>MEMORY</literal> table after startup, it notifies the
slaves that the table needs to be emptied by writing a
- <literal>DELETE FROM</literal> statement for the table to its
+ <literal>DELETE FROM</literal> statement for that table to the
binary log. See <xref linkend="memory-storage-engine"/> for
- more details.
+ more information.
</para>
</listitem>
<listitem>
<para>
- Temporary tables are replicated with the exception of the case
- that you shut down the slave server (not just the slave
- threads) and you have some replicated temporary tables that
- are used in update statements that have not yet been executed
- on the slave. If you shut down the slave server, the temporary
- tables needed by those updates no longer are available when
- the slave starts again. To avoid this problem, do not shut
- down the slave while it has temporary tables open. Instead,
- use this procedure:
+ Temporary tables are replicated except in the case where you
+ shut down the slave server (not just the slave threads) and
+ you have replicated temporary tables that are used in updates
+ that have not yet been executed on the slave. If you shut down
+ the slave server, the temporary tables needed by those updates
+ are no longer available when the slave is restarted. To avoid
+ this problem, do not shut down the slave while it has
+ temporary tables open. Instead, use the following procedure:
</para>
<orderedlist>
@@ -2155,7 +2196,7 @@
</orderedlist>
<para>
- We have plans to fix this problem in the near future.
+ We plan to fix this problem in the near future.
</para>
</listitem>
@@ -2174,17 +2215,21 @@
This means that you can create a setup such as this:
</para>
+ <remark role="todo">
+ Create a figure for this.
+ </remark>
+
<programlisting>
A -> B -> C -> A
</programlisting>
<para>
- Server IDs are encoded in the binary log events, so server A
- knows when an event that it reads was originally created by
- itself and does not execute the event (unless server A was
- started with the <option>--replicate-same-server-id</option>
- option, which is meaningful only in rare setups). Thus, there
- are no infinite loops. But this circular setup works only if
+ Server IDs are encoded in binary log events, so server A knows
+ when an event that it reads was originally created by itself
+ and does not execute the event (unless server A was started
+ with the <option>--replicate-same-server-id</option> option,
+ which is meaningful only in rare cases). Thus, there are no
+ infinite loops. This type of circular setup works only if
you perform no conflicting updates between the tables. In
other words, if you insert data in both A and C, you should
never insert a row in A that may have a key that conflicts
@@ -2260,9 +2305,10 @@
<listitem>
<para>
If you update transactional tables from non-transactional
- tables inside a <literal>BEGIN/COMMIT</literal> segment,
- updates to the binary log may be out of sync if some thread
- changes the non-transactional table before the transaction
+ tables inside a
+ <literal>BEGIN</literal>/<literal>COMMIT</literal> sequence,
+ updates to the binary log may be out of sync 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.
</para>
@@ -2297,8 +2343,8 @@
INFILE</literal> from a 3.23 master, the values of the
<literal>Exec_Master_Log_Pos</literal> and
<literal>Relay_Log_Space</literal> columns of <literal>SHOW
- SLAVE STATUS</literal> become incorrect. The incorrectness of
- <literal>Exec_Master_Log_Pos</literal> causes a problem when
+ SLAVE STATUS</literal> become incorrect. The inaccuracy in
+ <literal>Exec_Master_Log_Pos</literal> causes problems when
you stop and restart replication; so it is a good idea to
correct the value before this, by doing <literal>FLUSH
LOGS</literal> on the master. These bugs are fixed in MySQL
@@ -2347,17 +2393,19 @@
<section id="replication-options">
- <title id='title-replication-options'>&title-replication-options;</title>
-
-<!-- TODO: This section says that it describes slave options, but there -->
-
-<!-- are master options that need to be listed as well, like -->
-
-<!-- show-slave-auth-info. -->
+ <title id="title-replication-options">&title-replication-options;</title>
-<!-- TODO: There really should be a separate section devoted to the use -->
-
-<!-- and structure of master.info, and how it interacts with startup options. -->
+ <remark role="todo">
+ This section says that it describes slave options, but there are
+ master options that need to be listed as well, like
+ show-slave-auth-info.
+ </remark>
+
+ <remark role="todo">
+ There really should be a separate section devoted to the use and
+ structure of master.info, and how it interacts with startup
+ options.
+ </remark>
<para>
On both the master and the slave, you must use the
@@ -2482,11 +2530,11 @@
<para>
If no <filename>master.info</filename> file exists when the slave
- server starts, it uses values for those options that are specified
- in option files or on the command line. This occurs when you start
- the server as a replication slave for the very first time, or when
- you have run <literal>RESET SLAVE</literal> and shut down and
- restarted the slave server.
+ server starts, it uses the values for those options that are
+ specified in option files or on the command line. This occurs when
+ you start the server as a replication slave for the very first
+ time, or when you have run <literal>RESET SLAVE</literal> and then
+ have shut down and restarted the slave.
</para>
<para>
@@ -2590,9 +2638,10 @@
<para>
That is, A serves as the master for the slave B, and B serves
as the master for the slave C. For this to work, B must be
- both a master and a slave. You must start both A and B with
- <option>--log-bin</option> to enable binary logging, and B
- with the <option>--log-slave-updates</option> option.
+ both a master <emphasis>and</emphasis> a slave. You must start
+ both A and B with <option>--log-bin</option> to enable binary
+ logging, and B with the <option>--log-slave-updates</option>
+ option.
</para>
</listitem>
@@ -2613,8 +2662,9 @@
</para>
<para>
- This option is not limited to replication use only. It
- produces warnings across a spectrum of server activities.
+ Note that the effects of this option are not limited to
+ replication. It produces warnings across a spectrum of server
+ activities.
</para>
</listitem>
@@ -2882,7 +2932,8 @@
An example of what does not work as you might expect: If the
slave is started with <option>--replicate-do-db=sales</option>
and you issue the following statements on the master, the
- <literal>UPDATE</literal> statement is not replicated:
+ <literal>UPDATE</literal> statement is
+ <emphasis>not</emphasis> replicated:
</para>
<programlisting>
@@ -2898,13 +2949,13 @@
<para>
The main reason for this
- <quote>just-check-the-default-database</quote> behavior is
+ <quote>check-just-the-default-database</quote> behavior is
that it's difficult from the statement alone to know whether
or not it should be replicated (for example, if you are using
multiple-table <literal>DELETE</literal> or multiple-table
<literal>UPDATE</literal> statements that go across multiple
- databases). It's also very fast to just check the default
- database.
+ databases). It is also faster to check only the default
+ database rather than all databases if there is no need.
</para>
</listitem>
@@ -2934,9 +2985,9 @@
<literal>USE</literal>) is <replaceable>db_name</replaceable>.
To specify more than one database to ignore, use this option
multiple times, once for each database. You should not use
- this option if you are using cross-database updates and you
- don't want these updates to be replicated. Please read the
- notes that follow this option list.
+ this option if you are using cross-database updates and you do
+ not want these updates to be replicated. Please read the notes
+ that follow this option list.
</para>
<para>
@@ -2944,7 +2995,8 @@
slave is started with
<option>--replicate-ignore-db=sales</option> and you issue the
following statements on the master, the
- <literal>UPDATE</literal> statement is not replicated:
+ <literal>UPDATE</literal> statement is
+ <emphasis>not</emphasis> replicated:
</para>
<programlisting>
@@ -3130,9 +3182,10 @@
other hosts.
</para>
-<!-- For the moment, this option is of no real interest; it is meant for failover -->
-
-<!-- replication, which is not implemented yet. -->
+ <remark>
+ For the moment, this option is of no real interest; it is
+ meant for failover replication, which is not implemented yet.
+ </remark>
<para>
This option is available as of MySQL 4.0.0.
@@ -3152,9 +3205,10 @@
slave. If you are not sure, leave this option unset.
</para>
-<!-- For the moment, this option is of no real interest; it is meant for failover -->
-
-<!-- replication, which is not implemented yet. -->
+ <remark>
+ For the moment, this option is of no real interest; it is
+ meant for failover replication, which is not implemented yet.
+ </remark>
<para>
This option is available as of MySQL 4.0.0.
@@ -3179,7 +3233,7 @@
</para>
<para>
- If this option is set to 1, use compression of the
+ If this option is set to 1, use compression for the
slave/master protocol if both the slave and the master support
it.
</para>
@@ -3243,12 +3297,12 @@
<para>
Do not use this option unless you fully understand why you are
- getting the errors. If there are no bugs in your replication
- setup and client programs, and no bugs in MySQL itself, an
- error that stops replication should never occur.
- Indiscriminate use of this option results in slaves becoming
- hopelessly out of sync with the master, and you have no idea
- why.
+ getting errors. If there are no bugs in your replication setup
+ and client programs, and no bugs in MySQL itself, an error
+ that stops replication should never occur. Indiscriminate use
+ of this option results in slaves becoming hopelessly out of
+ sync with the master, with you having no idea why this has
+ occurred.
</para>
<para>
@@ -3259,13 +3313,14 @@
</para>
<para>
- You can (but should not) also use the very non-recommended
+ You can also (but should not) use the very non-recommended
value of <literal>all</literal> which ignores all error
- messages and keeps barging along regardless of what happens.
- Needless to say, if you use it, we make no promises regarding
- your data integrity. Please do not complain if your data on
- the slave is not anywhere close to what it is on the master in
- this case. You have been warned.
+ messages and keeps going regardless of what happens. Needless
+ to say, if you use it, we make no guarantees regarding
+ integrity the integrity of your data. Please do not complain
+ (or file bug reports) in this case if the slave's data is not
+ anywhere close to what it is on the master. <emphasis>You have
+ been warned</emphasis>.
</para>
<para>
@@ -3290,7 +3345,7 @@
<listitem>
<para>
- Are there some <option>--replicate-do-db</option> or
+ Are there any <option>--replicate-do-db</option> or
<option>--replicate-ignore-db</option> rules?
</para>
@@ -3298,7 +3353,8 @@
<listitem>
<para>
- Yes: Test them as for <option>--binlog-do-db</option> and
+ <emphasis>Yes</emphasis>: Test them as for
+ <option>--binlog-do-db</option> and
<option>--binlog-ignore-db</option> (see
<xref linkend="binary-log"/>). What is the result of the
test?
@@ -3314,8 +3370,8 @@
<listitem>
<para>
- Execute the statement: Don't execute it immediately,
- defer the decision, go to the next step.
+ Execute the statement: Do not execute it immediately;
+ defer the decision; proceed to the next step.
</para>
</listitem>
@@ -3324,7 +3380,7 @@
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3333,20 +3389,20 @@
<listitem>
<para>
- Are we in the execution of a stored procedure or function?
+ Are we currently executing a stored procedure or function?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Execute the query and exit.
+ <emphasis>Yes</emphasis>: Execute the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3355,29 +3411,29 @@
<listitem>
<para>
- Are there some <option>--replicate-*-table</option> rules?
+ Are there any <option>--replicate-*-table</option> rules?
</para>
<itemizedlist>
<listitem>
<para>
- No: Execute the query and exit.
+ <emphasis>No</emphasis>: Execute the query and exit.
</para>
</listitem>
<listitem>
<para>
- Yes: Go to the next step. Only tables that are to be
- updated are compared to the rules (<literal>INSERT INTO
- sales SELECT * FROM prices</literal>: only
- <literal>sales</literal> are compared to the rules). If
- several tables are to be updated (multiple-table
- statement), the first matching table (matching
- <quote>do</quote> or <quote>ignore</quote>) wins. That is,
- the first table is compared to the rules. Then, if no
- decision could be mad, the second table is compared to the
- rules, and so forth.
+ <emphasis>Yes</emphasis>: Proceed to the next step. Only
+ tables that are to be updated are compared to the rules
+ (<literal>INSERT INTO sales SELECT * FROM
+ prices</literal>: only <literal>sales</literal> is
+ compared to the rules). If several tables are to be
+ updated (multiple-table statement), the first matching
+ table (matching <quote>do</quote> or
+ <quote>ignore</quote>) wins. That is, the first table is
+ compared to the rules. Then, if no decision could be made,
+ the second table is compared to the rules, and so on.
</para>
</listitem>
@@ -3386,27 +3442,28 @@
<listitem>
<para>
- Are there some <option>--replicate-do-table</option> rules?
+ Are there any <option>--replicate-do-table</option> rules?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Does the table match any of them?
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Execute the query and exit.
+ <emphasis>Yes</emphasis>: Execute the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3415,7 +3472,7 @@
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3424,28 +3481,28 @@
<listitem>
<para>
- Are there some <option>--replicate-ignore-table</option>
- rules?
+ Are there any <option>--replicate-ignore-table</option> rules?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Does the table match any of them?
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: Ignore the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3454,7 +3511,7 @@
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3463,7 +3520,7 @@
<listitem>
<para>
- Are there some <option>--replicate-wild-do-table</option>
+ Are there any <option>--replicate-wild-do-table</option>
rules?
</para>
@@ -3471,20 +3528,21 @@
<listitem>
<para>
- Yes: Does the table match any of them?
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Execute the query and exit.
+ <emphasis>Yes</emphasis>: Execute the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3493,7 +3551,7 @@
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3502,7 +3560,7 @@
<listitem>
<para>
- Are there some <option>--replicate-wild-ignore-table</option>
+ Are there any <option>--replicate-wild-ignore-table</option>
rules?
</para>
@@ -3510,20 +3568,21 @@
<listitem>
<para>
- Yes: Does the table match any of them?
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
</para>
<itemizedlist>
<listitem>
<para>
- Yes: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: Ignore the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3532,7 +3591,7 @@
<listitem>
<para>
- No: Go to the next step.
+ <emphasis>No</emphasis>: Proceed to the next step.
</para>
</listitem>
@@ -3549,14 +3608,14 @@
<listitem>
<para>
- Yes: Loop.
+ <emphasis>Yes</emphasis>: Loop.
</para>
</listitem>
<listitem>
<para>
- No: We have tested all tables to be updated and could not
- match any rule. Are there
+ <emphasis>No</emphasis>: We have now tested all tables to
+ be updated and could not match any rule. Are there
<option>--replicate-do-table</option> or
<option>--replicate-wild-do-table</option> rules?
</para>
@@ -3565,13 +3624,13 @@
<listitem>
<para>
- Yes: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: Ignore the query and exit.
</para>
</listitem>
<listitem>
<para>
- No: Execute the query and exit.
+ <emphasis>No</emphasis>: Execute the query and exit.
</para>
</listitem>
@@ -3587,7 +3646,15 @@
<section id="replication-faq">
- <title id='title-replication-faq'>&title-replication-faq;</title>
+ <title id="title-replication-faq">&title-replication-faq;</title>
+
+<!--
+ TODO: If I were to change this to a <qanda[set]/>, how badly would
+ Paul kill me...? ;)
+
+ More seriously, it would be nice to structure the Q-and-A bits
+ better - perhaps using 2-item itemized lists? /JS
+-->
<para>
<emphasis role="bold">Q</emphasis>: How do I configure a slave if
@@ -3598,7 +3665,7 @@
<emphasis role="bold">A</emphasis>: There are several options. If
you have taken a backup of the master at some point and recorded
the binary log name and offset (from the output of <literal>SHOW
- MASTER STATUS</literal> ) corresponding to the snapshot, use the
+ MASTER STATUS</literal>) corresponding to the snapshot, use the
following procedure:
</para>
@@ -3727,13 +3794,13 @@
<para>
<emphasis role="bold">A</emphasis>: No, it does not. The slave can
go down or stay disconnected for hours or even days, then
- reconnect and catch up on the updates. For example, you can set up
- a master/slave relationship over a dial-up link where the link is
- up only sporadically and for short periods of time. The
- implication of this is that, at any given time, the slave is not
- guaranteed to be in sync 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.
+ reconnect and catch up on updates. For example, you can set up a
+ master/slave relationship over a dial-up link where the link is up
+ only sporadically and for short periods of time. The implication
+ of this is that, at any given time, the slave is not guaranteed to
+ be in sync 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.
</para>
<para>
@@ -3753,6 +3820,11 @@
<xref linkend="replication-implementation-details"/>.
</para>
+ <remark role="todo">
+ Check following in light of changes to TIMESTAMP in recent
+ versions. /JS
+ </remark>
+
<para>
When the slave SQL thread executes an event read from the master,
it modifies its own time to the event timestamp (this is why
@@ -3845,10 +3917,11 @@
co-master 1. Thus, when the update of client A makes it to
co-master 2, it produces tables that are different than what you
have on co-master 1, even after all the updates from co-master 2
- have also propagated. This means that you should not co-chain two
- servers in a two-way replication relationship unless you are sure
- that your updates can safely happen in any order, or unless you
- take care of mis-ordered updates somehow in the client code.
+ have also propagated. This means that you should not chain two
+ servers together in a two-way replication relationship unless you
+ are sure that your updates can safely happen in any order, or
+ unless you take care of mis-ordered updates somehow in the client
+ code.
</para>
<para>
@@ -3940,9 +4013,9 @@
<para>
<literal>safe_</literal> in each function name means that the
- function takes care of handling all the error conditions. You can
- use different names for the functions. The important thing is to
- have a unified interface for connecting for reads, connecting for
+ function takes care of handling all error conditions. You can use
+ different names for the functions. The important thing is to have
+ a unified interface for connecting for reads, connecting for
writes, doing a read, and doing a write.
</para>
@@ -3953,9 +4026,9 @@
just described are able to take advantage of a master/slave
configuration, even one involving multiple slaves. The code is a
lot easier to maintain, and adding troubleshooting options is
- trivial. You just need to modify one or two functions; for
- example, to log how long each statement took, or which statement
- among your many thousands gave you an error.
+ trivial. You need modify only one or two functions; for example,
+ to log how long each statement took, or which statement among
+ those issued gave you an error.
</para>
<para>
@@ -4002,8 +4075,8 @@
1,200 reads per second with no writes, the average write is twice
as slow as the average read, and the relationship is linear. Let
us suppose that the master and each slave have the same capacity,
- and that we have one master and N slaves. Then we have for each
- server (master or slave):
+ and that we have one master and <replaceable>N</replaceable>
+ slaves. Then we have for each server (master or slave):
</para>
<para>
@@ -4011,23 +4084,24 @@
</para>
<para>
- <literal>reads = 9 × writes / (N + 1) </literal> (reads are
- split, but writes go to all servers)
+ <literal>reads = 9 × writes / (<replaceable>N</replaceable>
+ + 1)</literal> (reads are split, but writes go to all servers)
</para>
<para>
- <literal>9 × writes / (N + 1) + 2 × writes =
- 1200</literal>
+ <literal>9 × writes / (<replaceable>N</replaceable> + 1) + 2
+ × writes = 1200</literal>
</para>
<para>
- <literal>writes = 1200 / (2 + 9/(N+1)) </literal>
+ <literal>writes = 1200 / (2 +
+ 9/(<replaceable>N</replaceable>+1))</literal>
</para>
<para>
The last equation indicates that the maximum number of writes for
- N slaves, given a maximum possible read rate of 1,200 per minute
- and a ratio of nine reads per write.
+ <replaceable>N</replaceable> slaves, given a maximum possible read
+ rate of 1,200 per minute and a ratio of nine reads per write.
</para>
<para>
@@ -4038,35 +4112,40 @@
<listitem>
<para>
- If N = 0 (which means we have no replication), our system can
- handle about 1200/11 = 109 writes per second.
+ If <replaceable>N</replaceable> = 0 (which means we have no
+ replication), our system can handle about 1200/11 = 109 writes
+ per second.
</para>
</listitem>
<listitem>
<para>
- If N = 1, we get up to 184 writes per second.
+ If <replaceable>N</replaceable> = 1, we get up to 184 writes
+ per second.
</para>
</listitem>
<listitem>
<para>
- If N = 8, we get up to 400 writes per second.
+ If <replaceable>N</replaceable> = 8, we get up to 400 writes
+ per second.
</para>
</listitem>
<listitem>
<para>
- If N = 17, we get up to 480 writes per second.
+ If <replaceable>N</replaceable> = 17, we get up to 480 writes
+ per second.
</para>
</listitem>
<listitem>
<para>
- Eventually, as N approaches infinity (and our budget negative
- infinity), we can get very close to 600 writes per second,
- increasing system throughput about 5.5 times. However, with
- only eight servers, we increased it almost four times.
+ Eventually, as <replaceable>N</replaceable> approaches
+ infinity (and our budget negative infinity), we can get very
+ close to 600 writes per second, increasing system throughput
+ about 5.5 times. However, with only eight servers, we increase
+ it nearly four times.
</para>
</listitem>
@@ -4077,10 +4156,10 @@
neglect several other factors that could turn out to be
significant on your system. In many cases, you may not be able to
perform a computation similar to the one just shown that
- accurately predicts what will happen on your system if you add N
- replication slaves. However, answering the following questions
- should help you decide whether and how much replication will
- improve the performance of your system:
+ accurately predicts what will happen on your system if you add
+ <replaceable>N</replaceable> replication slaves. However,
+ answering the following questions should help you decide if and by
+ how much replication will improve the performance of your system:
</para>
<itemizedlist>
@@ -4115,9 +4194,9 @@
<para>
<emphasis role="bold">A</emphasis>: With the currently available
features, you would have to set up a master and a slave (or
- several slaves), and write a script that monitors the master to
- see whether it is up. Then instruct your applications and the
- slaves to change master in case of failure. Some suggestions:
+ several slaves), and to write a script that monitors the master to
+ see if it is up. Then instruct your applications and the slaves to
+ change master in case of failure. Some suggestions:
</para>
<itemizedlist>
@@ -4141,14 +4220,18 @@
<listitem>
<para>
You should run your slaves with the <option>--log-bin</option>
- option and without <option>--log-slave-updates</option>. This
- way the slave is ready to become a master as soon as you issue
- <literal>STOP SLAVE</literal>; <literal>RESET
+ option and without <option>--log-slave-updates</option>. In
+ this way, the slave is ready to become a master as soon as you
+ issue <literal>STOP SLAVE</literal>; <literal>RESET
MASTER</literal>, and <literal>CHANGE MASTER TO</literal> on
the other slaves. For example, assume that you have the
following setup:
</para>
+ <remark role="todo">
+ Replace this with an actual diagram.
+ </remark>
+
<programlisting>
WC
\
@@ -4161,17 +4244,27 @@
</programlisting>
<para>
- M means the master, S the slaves, WC the clients that issue
+ <emphasis role="bold">M</emphasis> means the master,
+ <emphasis role="bold">S</emphasis> the slaves,
+ <emphasis role="bold">WC</emphasis> the clients issuing
database writes and reads; clients that issue only database
- reads are not represented, because they need not switch. S1,
- S2, and S3 are slaves running with <option>--log-bin</option>
- and without <option>--log-slave-updates</option>. Because
- updates received by a slave from the master are not logged in
- the binary log unless <option>--log-slave-updates</option> is
- specified, the binary log on each slave is empty. If for some
- reason M becomes unavailable, you can pick one slave to become
- the new master. For example, if you pick S1, all WC should be
- redirected to S1, and S2 and S3 should replicate from S1.
+ reads are not represented, because they need not switch.
+ <emphasis role="bold">S1</emphasis>,
+ <emphasis role="bold">S2</emphasis>, and
+ <emphasis role="bold">S3</emphasis> are slaves running with
+ <option>--log-bin</option> and without
+ <option>--log-slave-updates</option>. Because updates received
+ by a slave from the master are not logged in the binary log
+ unless <option>--log-slave-updates</option> is specified, the
+ binary log on each slave is empty. If for some reason
+ <emphasis role="bold">M</emphasis> becomes unavailable, you
+ can pick one of the slaves to become the new master. For
+ example, if you pick <emphasis role="bold">S1</emphasis>, all
+ <emphasis role="bold">WC</emphasis> should be redirected to
+ <emphasis role="bold">S1</emphasis>, and
+ <emphasis role="bold">S2</emphasis> and
+ <emphasis role="bold">S3</emphasis> should then replicate from
+ <emphasis role="bold">S1</emphasis>.
</para>
<para>
@@ -4180,36 +4273,55 @@
IO_THREAD</literal>, then check the output of <literal>SHOW
PROCESSLIST</literal> until you see <literal>Has read all
relay log</literal>. When this is true for all slaves, they
- can be reconfigured to the new setup. On the slave S1 being
- promoted to become the master, issue <literal>STOP
- SLAVE</literal> and <literal>RESET MASTER</literal>.
+ can be reconfigured to the new setup. On the slave
+ <emphasis role="bold">S1</emphasis> being promoted to become
+ the master, issue <literal>STOP SLAVE</literal> and
+ <literal>RESET MASTER</literal>.
</para>
<para>
- On the other slaves S2 and S3, use <literal>STOP
+ On the other slaves <emphasis role="bold">S2</emphasis> and
+ <emphasis role="bold">S3</emphasis>, use <literal>STOP
SLAVE</literal> and <literal>CHANGE MASTER TO
MASTER_HOST='S1'</literal> (where <literal>'S1'</literal>
- represents the real hostname of S1). To <literal>CHANGE
+ represents the real hostname of
+ <emphasis role="bold">S1</emphasis>). To <literal>CHANGE
MASTER</literal>, add all information about how to connect to
- S1 from S2 or S3 (user, password, port). In <literal>CHANGE
- MASTER</literal>, there is no need to specify the name of S1's
- binary log or binary log position to read from: We know it is
- the first binary log and position 4, which are the defaults
- for <literal>CHANGE MASTER</literal>. Finally, use
- <literal>START SLAVE</literal> on S2 and S3.
+ <emphasis role="bold">S1</emphasis> from
+ <emphasis role="bold">S2</emphasis> or
+ <emphasis role="bold">S3</emphasis>
+ (<replaceable>user</replaceable>,
+ <replaceable>password</replaceable>,
+ <replaceable>port</replaceable>). In <literal>CHANGE
+ MASTER</literal>, there is no need to specify the name of
+ <emphasis role="bold">S1</emphasis>'s binary log or binary log
+ position to read from: We know it is the first binary log and
+ position 4, which are the defaults for <literal>CHANGE
+ MASTER</literal>. Finally, use <literal>START SLAVE</literal>
+ on <emphasis role="bold">S2</emphasis> and
+ <emphasis role="bold">S3</emphasis>.
</para>
<para>
- Then instruct all WC to direct their statements to S1. From
- that point on, all updates statements sent by WC to S1 are
- written to the binary log of S1, which contains every update
- statement sent to S1 since M died.
+ Then instruct all <emphasis role="bold">WC</emphasis> to
+ direct their statements to
+ <emphasis role="bold">S1</emphasis>. From that point on, all
+ updates statements sent by <emphasis role="bold">WC</emphasis>
+ to <emphasis role="bold">S1</emphasis> are written to the
+ binary log of <emphasis role="bold">S1</emphasis>, which then
+ contains every update statement sent to
+ <emphasis role="bold">S1</emphasis> since
+ <emphasis role="bold">M</emphasis> died.
</para>
<para>
The result is this configuration:
</para>
+ <remark role="todo">
+ Replace with actual diagram (graphic).
+ </remark>
+
<programlisting>
WC
/
@@ -4224,16 +4336,27 @@
</programlisting>
<para>
- When M is up again, you just have to issue on it the same
- <literal>CHANGE MASTER</literal> as the one issued on S2 and
- S3, so that M becomes a slave of S1 and picks all the WC
- writes it has missed while it was down. To make M a master
- again (because it is the most powerful machine, for example),
- use the preceding procedure as if S1 was unavailable and M was
- to be the new master. During the procedure, don't forget to
- run <literal>RESET MASTER</literal> on M before making S1, S2,
- and S3 slaves of M. Otherwise, they may pick up old WC writes
- from before the point at which M became unavailable.
+ When <emphasis role="bold">M</emphasis> is up again, you must
+ issue on it the same <literal>CHANGE MASTER</literal> as that
+ issued on <emphasis role="bold">S2</emphasis> and
+ <emphasis role="bold">S3</emphasis>, so that
+ <emphasis role="bold">M</emphasis> becomes a slave of
+ <emphasis role="bold">S1</emphasis> and picks up all the
+ <emphasis role="bold">WC</emphasis> writes that it missed
+ while it was down. To make <emphasis role="bold">M</emphasis>
+ a master again (because it is the most powerful machine, for
+ example), use the preceding procedure as if
+ <emphasis role="bold">S1</emphasis> was unavailable and
+ <emphasis role="bold">M</emphasis> was to be the new master.
+ During this procedure, do not forget to run <literal>RESET
+ MASTER</literal> on <emphasis role="bold">M</emphasis> before
+ making <emphasis role="bold">S1</emphasis>,
+ <emphasis role="bold">S2</emphasis>, and
+ <emphasis role="bold">S3</emphasis> slaves of
+ <emphasis role="bold">M</emphasis>. Otherwise, they may pick
+ up old <emphasis role="bold">WC</emphasis> writes from before
+ the point at which <emphasis role="bold">M</emphasis> became
+ unavailable.
</para>
</listitem>
@@ -4499,7 +4622,7 @@
<section id="replication-problems">
- <title id='title-replication-problems'>&title-replication-problems;</title>
+ <title id="title-replication-problems">&title-replication-problems;</title>
<para>
If you have followed the instructions, and your replication setup
@@ -4512,7 +4635,7 @@
<para>
<emphasis role="bold">Check the error log for
messages</emphasis>. Many users have lost time by not doing
- this early enough.
+ this early enough after encountering problems.
</para>
</listitem>
@@ -4552,13 +4675,13 @@
<listitem>
<para>
- If the slave was running before but has stopped, the reason
- usually is that some statement that succeeded on the master
- failed on the slave. This should never happen if you have
- taken a proper snapshot of the master, and never modify the
- data on the slave outside of the slave thread. If it does, it
- is a bug or you have encountered one of the known replication
- limitations described in
+ If the slave was running previously but has stopped, the
+ reason usually is that some statement that succeeded on the
+ master failed on the slave. This should never happen if you
+ have taken a proper snapshot of the master, and never modified
+ the data on the slave outside of the slave thread. If it does,
+ it is a bug or you have encountered one of the known
+ replication limitations described in
<xref linkend="replication-features"/>. If it is a bug, see
<xref linkend="replication-bugs"/> for instructions on how to
report it.
@@ -4600,13 +4723,13 @@
</para>
<programlisting>
-mysql> <userinput>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n;</userinput>
+mysql> <userinput>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = <replaceable>n</replaceable>;</userinput>
mysql> <userinput>START SLAVE;</userinput>
</programlisting>
<para>
- The value of <literal>n</literal> should be 1 if the next
- statement from the master does not use
+ The value of <replaceable>n</replaceable> should be 1 if
+ the next statement from the master does not use
<literal>AUTO_INCREMENT</literal> or
<literal>LAST_INSERT_ID()</literal>. Otherwise, the value
should be 2. The reason for using a value of 2 for
@@ -4619,11 +4742,12 @@
<listitem>
<para>
If you are sure that the slave started out perfectly
- synchronized with the master, and no one has updated the
- tables involved outside of slave thread, then presumably
- the discrepancy is the result of a bug. If you are running
- the most recent version, please report the problem. If you
- are running an older version of MySQL, try upgrading.
+ synchronized with the master, and that no one has updated
+ the tables involved outside of the slave thread, then
+ presumably the discrepancy is the result of a bug. If you
+ are running the most recent version, please report the
+ problem. If you are running an older version of MySQL, try
+ upgrading to the latest production release.
</para>
</listitem>
@@ -4636,22 +4760,22 @@
<section id="replication-bugs">
- <title id='title-replication-bugs'>&title-replication-bugs;</title>
+ <title id="title-replication-bugs">&title-replication-bugs;</title>
<para>
When you have determined that there is no user error involved, and
replication still either does not work at all or is unstable, it
- is time to send us a bug report. We need to get as much
+ is time to send us a bug report. We need to obtain as much
information as possible from you to be able to track down the bug.
- Please do spend some time and effort preparing a good bug report.
+ Please spend some time and effort in preparing a good bug report.
</para>
<para>
If you have a repeatable test case that demonstrates the bug,
please enter it into our bugs database at
- <ulink url="http://bugs.mysql.com/"/>. If you have a phantom
- problem (one that you cannot duplicate <quote>at will</quote>),
- use the following procedure:
+ <ulink url="http://bugs.mysql.com/"/>. If you have a
+ <quote>phantom</quote> problem (one that you cannot duplicate at
+ will), then use the following procedure:
</para>
<orderedlist>
@@ -4663,17 +4787,18 @@
out of sync, 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.
- This is not a replication problem. It is a problem of outside
- interference that causes replication to fail.
+ <emphasis>This is not a replication problem. It is a problem
+ with outside interference causing replication to
+ fail.</emphasis>
</para>
</listitem>
<listitem>
<para>
Run the slave with the <option>--log-slave-updates</option>
- and <option>--log-bin</option> options. They cause the slave
- to log the updates that it receives from the master into its
- own binary logs.
+ and <option>--log-bin</option> options. These options cause
+ the slave to log the updates that it receives from the master
+ into its own binary logs.
</para>
</listitem>
@@ -4702,14 +4827,14 @@
<listitem>
<para>
The output of <literal>SHOW MASTER STATUS</literal> from
- the master at the time you have discovered the problem
+ the master at the time you discovered the problem
</para>
</listitem>
<listitem>
<para>
The output of <literal>SHOW SLAVE STATUS</literal> from
- the master at the time you have discovered the problem
+ the master at the time you discovered the problem
</para>
</listitem>
@@ -4725,13 +4850,13 @@
<listitem>
<para>
Use <command>mysqlbinlog</command> to examine the binary logs.
- The following should be helpful to find the trouble query, for
+ The following should be helpful to find the problem query, for
example:
</para>
<programlisting>
shell> <userinput>mysqlbinlog -j pos_from_slave_status \</userinput>
- <userinput>/path/to/log_from_slave_status | head</userinput>
+ <userinput><replaceable>/path/to/log_from_slave_status</replaceable> | head</userinput>
</programlisting>
</listitem>
--- 1.18/refman-5.0/replication.xml 2005-09-01 02:15:19 +10:00
+++ 1.19/refman-5.0/replication.xml 2005-09-03 04:22:48 +10:00
@@ -768,7 +768,8 @@
<listitem>
<para>
When the size of the current relay log file becomes too
- large. The meaning of "too large" is determined as follows:
+ large. The meaning of <quote>too large</quote> is determined
+ as follows:
</para>
<itemizedlist>
@@ -925,11 +926,11 @@
</remark>
<para>
- When you back up your slave's data, you should back up these two
- files as well, along with the relay log files. They are needed
- to resume replication after you restore the slave's data. If you
- lose the relay logs but still have the
- <filename>relay-log.info</filename> file, you can examine it to
+ When you back up the slave's data, you should back up these two
+ small files as well, along with the relay log files. They are
+ needed to resume replication after you restore the slave's data.
+ If you lose the relay logs but still have the
+ <filename>relay-log.info</filename> file, you can check it to
determine how far the SQL thread has executed in the master
binary logs. Then you can use <literal>CHANGE MASTER
TO</literal> with the <literal>MASTER_LOG_FILE</literal> and
@@ -1185,20 +1186,20 @@
<para>
If you are using <literal>InnoDB</literal> tables, ideally you
- should use the <literal>InnoDB Hot Backup</literal> tool. It
- takes a consistent snapshot without acquiring any locks on the
- master server, and records the log name and offset
- corresponding to the snapshot to be later used on the slave.
- <literal>InnoDB Hot Backup</literal> is a non-free
- (commercial) additional tool that is not included in the
- standard MySQL distribution. See the <literal>InnoDB Hot
- Backup</literal> home page at
- <ulink url="http://www.innodb.com/manual.php"/> for detailed
- information and screenshots.
+ should use the <command><literal>InnoDB</literal> Hot
+ Backup</command> tool, which takes a consistent snapshot
+ without acquiring any locks on the master server, and records
+ the log name and offset corresponding to the snapshot to be
+ later used on the slave. <command>Hot Backup</command> is an
+ additional non-free (commercial) tool that is not included in
+ the standard MySQL distribution. See the
+ <command><literal>InnoDB</literal> Hot Backup</command> home
+ page at <ulink url="http://www.innodb.com/manual.php"/> for
+ detailed information.
</para>
<para>
- Without the <literal>Hot Backup</literal> tool, the quickest
+ Without the <command>Hot Backup</command> tool, the quickest
way to take a binary snapshot of <literal>InnoDB</literal>
tables is to shut down the master server and copy the
<literal>InnoDB</literal> data files, log files, and table
@@ -1305,7 +1306,7 @@
<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
+ <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
@@ -1428,7 +1429,8 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the slave, you get the following error in its error log:
+ value for the slave, you get the following error in the slave's
+ error log:
</para>
<programlisting>
@@ -1446,10 +1448,10 @@
one file named <filename>master.info</filename> and another named
<filename>relay-log.info</filename>. The slave uses these two
files to keep track of how much of the master's binary log it has
- processed. <emphasis role="bold">Do not</emphasis> remove or edit
- these files, unless you really know what you are doing and
- understand the implications. Even in that case, it is preferred
- that you use the <literal>CHANGE MASTER TO</literal> statement.
+ processed. Do <emphasis>not</emphasis> remove or edit these files
+ unless you know exactly what you are doing and fully understand
+ the implications. Even in that case, it is preferred that you use
+ the <literal>CHANGE MASTER TO</literal> statement.
</para>
<para>
@@ -1564,6 +1566,16 @@
can remove them before proceeding with the downgrade.
</para>
+<!-- Remove the comment when we have RBR in place.
+ <para>
+ Note that downgrading a replication setup to a previous version
+ cannot be done once you've switched from statement-based to
+ row-based replication, and after the first row-based statement
+ has been written to the binlog. See
+ <xref linkend="replication-row-based"/>.
+ </para>
+-->
+
</section>
</section>
@@ -1874,13 +1886,14 @@
<listitem>
<para>
- It is possible for the data on the master and slave to diverge
- if a query is designed in such a way that the data
- modification is non-deterministic; that is, if it is left up
- to the actions of the query optimizer. (This is generally not
- a good practice in any case, even outside of replication.) For
- a detailed explanation of this issue, see
- <xref linkend="open-bugs"/>.
+ <emphasis>The following restriction applies to statement-based
+ replication only, not to row-based replication</emphasis>: It
+ is possible for the data on the master and slave to become
+ different if a query is designed in such a way that the data
+ modification is non-deterministic; that is, left to the will
+ of the query optimizer. (This is in general not a good
+ practice, even outside of replication.) For a detailed
+ explanation of this issue, see <xref linkend="open-bugs"/>.
</para>
</listitem>
@@ -2012,8 +2025,9 @@
relationship with the <option>--log-slave-updates</option>
option specified. Note, however, that many statements do not
work correctly in this kind of setup unless your client code
- is written to take care of that can occur from updates that
- occur in different sequences on different servers.
+ is written to take care of the potential problems that can
+ occur from updates that occur in different sequence on
+ different servers.
</para>
<para>
@@ -2029,14 +2043,14 @@
</programlisting>
<para>
- Server IDs are encoded in the binary log events, so server A
- knows when an event that it reads was originally created by
- itself and does not execute the event (unless server A was
- started with the <option>--replicate-same-server-id</option>
- option, which is meaningful only in rare setups). Thus, there
- are no infinite loops. However, this circular setup works only
- if you perform no conflicting updates between the tables. In
- other words, if you insert data into both A and C, you should
+ Server IDs are encoded in binary log events, so server A knows
+ when an event that it reads was originally created by itself
+ and does not execute the event (unless server A was started
+ with the <option>--replicate-same-server-id</option> option,
+ which is meaningful only in rare cases). Thus, there are no
+ infinite loops. This type of circular setup works only if
+ you perform no conflicting updates between the tables. In
+ other words, if you insert data in both A and C, you should
never insert a row in A that may have a key that conflicts
with a row inserted in C. You should also not update the same
rows on two servers if the order in which the updates are
@@ -2602,8 +2616,8 @@
<para>
Places an upper limit on the total size of all relay logs on
- the slave (a value of 0 means the size is unlimited). This is
- useful for a slave server host that has limited disk space.
+ the slave (a value of 0 means <quote>unlimited</quote>). This
+ is useful for a slave server host that has limited disk space.
When the limit is reached, the I/O thread stops reading binary
log events from the master server until the SQL thread has
caught up and deleted some unused relay logs. Note that this
@@ -3052,7 +3066,7 @@
<listitem>
<para>
- Are there some <option>--replicate-do-db</option> or
+ Are there any <option>--replicate-do-db</option> or
<option>--replicate-ignore-db</option> rules?
</para>
@@ -3149,7 +3163,7 @@
<listitem>
<para>
- Are there some <option>--replicate-do-table</option> rules?
+ Are there any <option>--replicate-do-table</option> rules?
</para>
<itemizedlist>
@@ -3557,7 +3571,7 @@
<listitem>
<para>
- On the master, execute these 2 statements:
+ On the master, execute these statements:
</para>
<programlisting>
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (jon:1.3460) | jon | 2 Sep |
