Author: mcbrown
Date: 2007-02-06 15:22:41 +0100 (Tue, 06 Feb 2007)
New Revision: 4810
Log:
Adding 'common tasks' section
Minor fixes
Modified:
branches/repupdate/5.1/replication-configuration.xml
branches/repupdate/5.1/replication-implementation.xml
branches/repupdate/5.1/replication-notes.xml
branches/repupdate/5.1/replication-solutions.xml
branches/repupdate/5.1/replication-topology.xml
branches/repupdate/5.1/replication.xml
Modified: branches/repupdate/5.1/replication-configuration.xml
===================================================================
--- branches/repupdate/5.1/replication-configuration.xml 2007-02-06 11:22:03 UTC (rev 4809)
+++ branches/repupdate/5.1/replication-configuration.xml 2007-02-06 14:22:41 UTC (rev 4810)
Changed blocks: 12, Lines Added: 275, Lines Deleted: 45; 15065 bytes
@@ -59,11 +59,6 @@
</para>
<para>
- Once replication is configured and setup it should require very
- little administration or monitoring.
- </para>
-
- <para>
In this section the setup and configuration required for replication
environment is described, including step-by-step instructions for
creating a new replication environment. The major components of this
@@ -95,8 +90,8 @@
<listitem>
<para>
- Detailed information on the different configuration options that
- apply to replication is provided in
+ Detailed information on the different configuration options and
+ variables that apply to replication is provided in
<xref linkend="replication-options"/>.
</para>
</listitem>
@@ -1049,10 +1044,12 @@
When you have additional slaves
</para>
- <para>The two practical
- limitations on the length of time you can wait are the amount of
- disk space available to retain binary logs on the master and the
- length of time it takes the slave to catch up.</para>
+ <para>
+ The two practical limitations on the length of time you can wait
+ are the amount of disk space available to retain binary logs on
+ the master and the length of time it takes the slave to catch
+ up.
+ </para>
<orderedlist>
@@ -1454,17 +1451,19 @@
<title>Comparison of Statement-Based Versus Row-Based Replication</title>
<para>
- Each binary logging format has advantages and disadvantages. For most
- users, the mixed-based replication format should be fine and should
- provide the best combination of data integrity and performance. If, however,
- you want to take advantage of the differences in the replication format
- when performing specific updates or large data inserts, then the
- information in this section summarizes the advantages and disadvantages
- of the row and statement based formats.
+ Each binary logging format has advantages and disadvantages. For
+ most users, the mixed-based replication format should be fine
+ and should provide the best combination of data integrity and
+ performance. If, however, you want to take advantage of the
+ differences in the replication format when performing specific
+ updates or large data inserts, then the information in this
+ section summarizes the advantages and disadvantages of the row
+ and statement based formats.
</para>
<para>
- <emphasis role="bold">Advantages of statement-based replication:</emphasis>
+ <emphasis role="bold">Advantages of statement-based
+ replication:</emphasis>
</para>
<itemizedlist>
@@ -1499,20 +1498,21 @@
</listitem>
<listitem>
-
<para>
- You can use a slave with a higher version than that used on the
- master, even when there is a different row structure in the table.
- This can be useful if you are unable to upgrade the master but want
- to take advantage of features in a recent slave version, perhaps for
- testing and evaluation purposes.
+ You can use a slave with a higher version than that used on
+ the master, even when there is a different row structure in
+ the table. This can be useful if you are unable to upgrade
+ the master but want to take advantage of features in a
+ recent slave version, perhaps for testing and evaluation
+ purposes.
</para>
</listitem>
</itemizedlist>
<para>
- <emphasis role="bold">Disadvantages of statement-based replication:</emphasis>
+ <emphasis role="bold">Disadvantages of statement-based
+ replication:</emphasis>
</para>
<itemizedlist>
@@ -1614,10 +1614,11 @@
<listitem>
<para>
- For complex queries, the statement must be evaluated and executed on
- the slave before the rows are updated or inserted. With row-based
- replication, the slave only has to run the statement to apply the
- differences, not the full query.
+ For complex queries, the statement must be evaluated and
+ executed on the slave before the rows are updated or
+ inserted. With row-based replication, the slave only has to
+ run the statement to apply the differences, not the full
+ query.
</para>
</listitem>
@@ -1638,9 +1639,10 @@
<listitem>
<para>
- If there is an error in evaluation on the slave, particularly when executing
- complex queries, then using statement based replication may slowly
- increase the margin of error across the affected rows over time.
+ If there is an error in evaluation on the slave,
+ particularly when executing complex queries, then using
+ statement based replication may slowly increase the margin
+ of error across the affected rows over time.
</para>
</listitem>
@@ -1653,7 +1655,8 @@
</itemizedlist>
<para>
- <emphasis role="bold"> Advantages of row-based replication:</emphasis>
+ <emphasis role="bold"> Advantages of row-based
+ replication:</emphasis>
</para>
<itemizedlist>
@@ -1758,7 +1761,8 @@
</itemizedlist>
<para>
- <emphasis role="bold">Disadvantages of row-based replication:</emphasis>
+ <emphasis role="bold">Disadvantages of row-based
+ replication:</emphasis>
</para>
<itemizedlist>
@@ -1855,7 +1859,7 @@
<section id="replication-options">
- <title>Replication Startup Options</title>
+ <title>Replication Options and Variables</title>
<remark role="todo">
This section says that it describes slave options, but there are
@@ -2049,11 +2053,12 @@
</programlisting>
<para>
- The following list describes the options and variables used for controlling
- replication. Many of these options can be reset while the server
- is running by using the <literal>CHANGE MASTER TO</literal>
- statement. Others, such as the <option>--replicate-*</option>
- options, can be set only when the slave server starts.
+ The following list describes the options and variables used for
+ controlling replication. Many of these options can be reset while
+ the server is running by using the <literal>CHANGE MASTER
+ TO</literal> statement. Others, such as the
+ <option>--replicate-*</option> options, can be set only when the
+ slave server starts.
</para>
<itemizedlist>
@@ -3144,16 +3149,241 @@
</remark>
</section>
-<!--
+
<section id="replication-administration">
<title>Common Replication Administration Tasks[TODO:Write]</title>
<para>
- TODO
+ Once replication has been started it should execute without
+ requiring a significant form of regular administration. Depending
+ on your replication environment, you will want to check the
+ replication status of each slave either periodically, daily, or
+ even more frequently.
</para>
+ <section id="replication-administration-status">
+
+ <title>Checking Replication Status</title>
+
+ <para>
+ The most common task when managing a replication process is to
+ ensure that replication is taking place and that there have been
+ no errors between the slave and the master.
+ </para>
+
+ <para>
+ The primary command for this is <literal>SHOW SLAVE
+ STATUS</literal> which you must execute on each slave:
+ </para>
+
+<programlisting>mysql> SHOW SLAVE STATUS\G
+*************************** 1. row ***************************
+ Slave_IO_State: Waiting for master to send event
+ Master_Host: master1
+ Master_User: root
+ Master_Port: 3306
+ Connect_Retry: 60
+ Master_Log_File: mysql-bin.000004
+ Read_Master_Log_Pos: 931
+ Relay_Log_File: slave1-relay-bin.000056
+ Relay_Log_Pos: 950
+ Relay_Master_Log_File: mysql-bin.000004
+ Slave_IO_Running: Yes
+ Slave_SQL_Running: Yes
+ Replicate_Do_DB:
+ Replicate_Ignore_DB:
+ Replicate_Do_Table:
+ Replicate_Ignore_Table:
+ Replicate_Wild_Do_Table:
+Replicate_Wild_Ignore_Table:
+ Last_Errno: 0
+ Last_Error:
+ Skip_Counter: 0
+ Exec_Master_Log_Pos: 931
+ Relay_Log_Space: 1365
+ Until_Condition: None
+ Until_Log_File:
+ Until_Log_Pos: 0
+ Master_SSL_Allowed: No
+ Master_SSL_CA_File:
+ Master_SSL_CA_Path:
+ Master_SSL_Cert:
+ Master_SSL_Cipher:
+ Master_SSL_Key:
+ Seconds_Behind_Master: 0
+1 row in set (0.01 sec)</programlisting>
+
+ <para>
+ The key fields from the status report to examine are:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>Slave_IO_State</literal> — indicates the
+ current status of the slave. See
+ <xref linkend="slave-io-thread-states"/>, and
+ <xref linkend="slave-sql-thread-states"/>, for more
+ information.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>Slave_IO_Running</literal> — shows whether
+ the IO thread for the reading the master's binary log is
+ running.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>Slave_SQL_Running</literal> — shows whether
+ the SQL thread for the executing events in the relay log is
+ running.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>Last_Error</literal> — shows the last error
+ registered when processing the relay log. Ideally this
+ should be blank, indicating no errors.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>Seconds_Behind_Master</literal> — shows the
+ number of seconds that the slave SQL thread is behind
+ processing the master binary log. A high number (or an
+ increasing one) can indicate that the slave is unable to
+ cope with the large number of queries from the master.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ On the master, you can check the status of slaves by examining
+ the list of running processes. Slaves execute the
+ <literal>Binlog Dump</literal> command:
+ </para>
+
+<programlisting>mysql> SHOW PROCESSLIST \G;
+*************************** 4. row ***************************
+ Id: 10
+ User: root
+ Host: slave1:58371
+ db: NULL
+Command: Binlog Dump
+ Time: 777
+ State: Has sent all binlog to slave; waiting for binlog to be updated
+ Info: NULL</programlisting>
+
+ <para>
+ Because it is the slave that drives the core of the replication
+ process, very little information is available in this report.
+ </para>
+
+ <para>
+ If you have used the <literal>--report-host</literal> option,
+ then the <literal>SHOW SLAVE HOSTS</literal> statement will show
+ basic information about connected slaves:
+ </para>
+
+<programlisting>mysql> SHOW SLAVE HOSTS;
++-----------+--------+------+-------------------+-----------+
+| Server_id | Host | Port | Rpl_recovery_rank | Master_id |
++-----------+--------+------+-------------------+-----------+
+| 10 | slave1 | 3306 | 0 | 1 |
++-----------+--------+------+-------------------+-----------+
+1 row in set (0.00 sec)
+</programlisting>
+
+ <para>
+ The output includes the ID of the slave server, the value of the
+ <literal>--report-host</literal> option, the connecting port,
+ master ID and the priority of the slave for receiving binary log
+ updates.
+ </para>
+
+ </section>
+
+ <section id="replication-administration-pausing">
+
+ <title>Pausing Replication on Slave</title>
+
+ <para>
+ You can stop and start the replication of statements on the
+ slave using the <literal>STOP SLAVE</literal> and <literal>START
+ SLAVE</literal> commands.
+ </para>
+
+ <para>
+ To stop execution of the binary log from the master, use
+ <literal>STOP SLAVE</literal>:
+ </para>
+
+<programlisting>mysql> STOP SLAVE;</programlisting>
+
+ <para>
+ When execution is stopped, the slave does not read the binary
+ log from the master (the <literal>IO_THREAD</literal>) and stops
+ processing events from the relay log that have not yet been
+ executed (the <literal>SQL_THREAD</literal>). You can pause
+ either the IO or SQL threads individually by specifying the
+ thread type. For example:
+ </para>
+
+<programlisting>mysql> STOP SLAVE IO_THREAD;</programlisting>
+
+ <para>
+ Stopping the SQL thread can be useful if you want to perform a
+ backup or other task on a slave that only processes events from
+ the master. The IO thread will continue to be read from the
+ master, but not executed, which will make it easier for the
+ slave to catch up when you start slave operations again.
+ </para>
+
+ <para>
+ Stopping the IO thread will allow the statements in the relay
+ log to be executed up until the point where the relay log as
+ ceased to receive new events. Using this option can be useful
+ when you want to pause execution to allow the slave to catch up
+ with events from the master, when you want to perform
+ administration on the slave but ensure you have the latest
+ updates to a specific point. This method can also be used to
+ pause execution on the slave while you conduct administration on
+ the master while ensuring that there is not a massive backlog of
+ events to be executed when replication is started again.
+ </para>
+
+ <para>
+ To start execution again, use the <literal>START SLAVE</literal>
+ statement:
+ </para>
+
+<programlisting>mysql> START SLAVE;</programlisting>
+
+ <para>
+ If necessary, you can start either the
+ <literal>IO_THREAD</literal> or <literal>SQL_THREAD</literal>
+ threads individually.
+ </para>
+
+ </section>
+
+<!--
+ <section id="replication-administration-logclear">
+
+ <title>Clearing Binary Logs</title>
+
+ </section>
+-->
+
</section>
--->
-
+
</section>
Modified: branches/repupdate/5.1/replication-implementation.xml
===================================================================
--- branches/repupdate/5.1/replication-implementation.xml 2007-02-06 11:22:03 UTC (rev 4809)
+++ branches/repupdate/5.1/replication-implementation.xml 2007-02-06 14:22:41 UTC (rev 4810)
Changed blocks: 12, Lines Added: 823, Lines Deleted: 803; 70476 bytes
@@ -9,114 +9,111 @@
<!ENTITY % versions.entities SYSTEM "../../../trunk/refman-5.1/versions.ent">
%versions.entities;
]>
+<section id="replication-implementation">
- <section id="replication-implementation">
+ <title>Replication Implementation[TODO:Rewrite]</title>
- <title>Replication Implementation[TODO:Rewrite]</title>
+ <indexterm>
+ <primary>master/slave setup</primary>
+ </indexterm>
- <indexterm>
- <primary>master/slave setup</primary>
- </indexterm>
+ <para>
+ MySQL replication is based on the master server keeping track of all
+ changes to your databases (updates, deletes, and so on) in its
+ binary logs. Therefore, to use replication, you must enable binary
+ logging on the master server. See <xref linkend="binary-log"/>.
+ </para>
+ <para>
+ Each slave server receives from the master the saved updates that
+ the master has recorded in its binary log, so that the slave can
+ execute the same updates on its copy of the data.
+ </para>
+
+ <para>
+ 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>
+ 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 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
+ <option>--master-connect-retry</option> option controls the retry
+ interval. The default is 60 seconds.
+ </para>
+
+ <para>
+ Each slave keeps track of where it left off when it last read from
+ its master server. The master has no knowledge of how many slaves it
+ has or which ones are up to date at any given time.
+ </para>
+
+ <section id="replication-implementation-details">
+
+ <title>Replication Implementation Details</title>
+
<para>
- MySQL replication is based on the master server keeping track of
- all changes to your databases (updates, deletes, and so on) in its
- binary logs. Therefore, to use replication, you must enable binary
- logging on the master server. See <xref linkend="binary-log"/>.
+ MySQL replication capabilities are implemented using three threads
+ (one on the master server and two on the slave). When a
+ <literal>START SLAVE</literal> statement is issued on a slave
+ server, the slave creates an I/O thread, which connects to the
+ master and asks it to send the updates 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
+ the updates that the master <literal>Binlog Dump</literal> thread
+ sends and copies them 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 to read the relay logs
+ and to execute the updates they contain.
</para>
<para>
- Each slave server receives from the master the saved updates that
- the master has recorded in its binary log, so that the slave can
- execute the same updates on its copy of the data.
+ In the preceding description, there are three threads per
+ master/slave connection. A master that has multiple slaves creates
+ one thread for each currently-connected slave, and each slave has
+ its own I/O and SQL threads.
</para>
<para>
- 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.
+ The slave uses two threads so that reading updates from the master
+ and executing them can be separated into two independent tasks.
+ Thus, the task of reading statements is not slowed down if
+ statement execution is slow. For example, if the slave server has
+ not been running for a while, its I/O thread can quickly fetch all
+ the binary log contents from the master when the slave starts,
+ even if the SQL thread lags far behind. 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 stored locally in the slave's relay logs, ready for
+ execution the next time that the slave starts. This enables the
+ master server to purge its binary logs sooner because it no longer
+ needs to wait for the slave to fetch their contents.
</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 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
- <option>--master-connect-retry</option> option controls the retry
- interval. The default is 60 seconds.
+ The <literal>SHOW PROCESSLIST</literal> statement provides
+ information that tells you what is happening on the master and on
+ the slave regarding replication. The following example illustrates
+ how the three threads show up in the output from <literal>SHOW
+ PROCESSLIST</literal>.
</para>
<para>
- Each slave keeps track of where it left off when it last read from
- its master server. The master has no knowledge of how many slaves
- it has or which ones are up to date at any given time.
+ On the master server, the output from <literal>SHOW
+ PROCESSLIST</literal> looks like this:
</para>
- <section id="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 a
- <literal>START SLAVE</literal> statement is issued on a slave
- server, the slave creates an I/O thread, which connects to the
- master and asks it to send the updates 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 the updates that the master <literal>Binlog
- Dump</literal> thread sends and copies them 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 to read the relay logs and to execute the updates they
- contain.
- </para>
-
- <para>
- In the preceding description, there are three threads per
- master/slave connection. A master that has multiple slaves
- creates one thread for each currently-connected slave, and each
- slave has its own I/O and SQL threads.
- </para>
-
- <para>
- The slave uses two threads so that reading updates from the
- master and executing them can be separated into two independent
- tasks. Thus, the task of reading statements is not slowed down
- if statement execution is slow. For example, if the slave server
- has not been running for a while, its I/O thread can quickly
- fetch all the binary log contents from the master when the slave
- starts, even if the SQL thread lags far behind. 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 stored locally in the
- slave's relay logs, ready for execution the next time that the
- slave starts. This enables the master server to purge its binary
- logs sooner because it no longer needs to wait for the slave to
- fetch their contents.
- </para>
-
- <para>
- The <literal>SHOW PROCESSLIST</literal> statement provides
- information that tells you what is happening on the master and
- on the slave regarding replication. The following example
- illustrates how the three threads show up in the output from
- <literal>SHOW PROCESSLIST</literal>.
- </para>
-
- <para>
- On the master server, the output from <literal>SHOW
- PROCESSLIST</literal> looks like this:
- </para>
-
<programlisting>
mysql> <userinput>SHOW PROCESSLIST\G</userinput>
*************************** 1. row ***************************
@@ -131,20 +128,20 @@
Info: NULL
</programlisting>
- <para>
- Here, thread 2 is a <literal>Binlog Dump</literal> replication
- thread for a connected slave. The <literal>State</literal>
- information indicates that all outstanding updates have been
- sent to the slave and that the master is waiting for more
- updates to occur. If you see no <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>
+ <para>
+ Here, thread 2 is a <literal>Binlog Dump</literal> replication
+ thread for a connected slave. The <literal>State</literal>
+ information indicates that all outstanding updates have been sent
+ to the slave and that the master is waiting for more updates to
+ occur. If you see no <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>
- <para>
- On the slave server, the output from <literal>SHOW
- PROCESSLIST</literal> looks like this:
- </para>
+ <para>
+ On the slave server, the output from <literal>SHOW
+ PROCESSLIST</literal> looks like this:
+ </para>
<programlisting>
mysql> <userinput>SHOW PROCESSLIST\G</userinput>
@@ -169,344 +166,371 @@
Info: NULL
</programlisting>
- <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. At the time that the <literal>SHOW PROCESSLIST</literal>
- was run, both threads were idle, waiting for further updates.
- </para>
+ <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. At
+ the time that the <literal>SHOW PROCESSLIST</literal> was run,
+ both threads were idle, waiting for further updates.
+ </para>
+ <para>
+ 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>Replication Master Thread States</title>
+
<para>
- The value in the <literal>Time</literal> column can show how
- late the slave is compared to the master. See
- <xref linkend="replication-faq"/>.
+ 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 see no
+ <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>
- <section id="master-thread-states">
+ <itemizedlist>
- <title>Replication Master Thread States</title>
+ <listitem>
+ <para>
+ <literal>Sending binlog event to slave</literal>
+ </para>
- <para>
- 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 see no
- <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>
+ <para>
+ 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>
- <itemizedlist>
+ <listitem>
+ <para>
+ <literal>Finished reading one binlog; switching to next
+ binlog</literal>
+ </para>
- <listitem>
- <para>
- <literal>Sending binlog event to slave</literal>
- </para>
+ <para>
+ The thread has finished reading a binary log file and is
+ opening the next one to send to the slave.
+ </para>
+ </listitem>
- <para>
- 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>
+ <listitem>
+ <para>
+ <literal>Has sent all binlog to slave; waiting for binlog to
+ be updated</literal>
+ </para>
- <listitem>
- <para>
- <literal>Finished reading one binlog; switching to next
- binlog</literal>
- </para>
+ <para>
+ The thread has read all outstanding updates from the binary
+ 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>
- <para>
- The thread has finished reading a binary log file and is
- opening the next one to send to the slave.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting to finalize termination</literal>
+ </para>
- <listitem>
- <para>
- <literal>Has sent all binlog to slave; waiting for binlog
- to be updated</literal>
- </para>
+ <para>
+ A very brief state that occurs as the thread is stopping.
+ </para>
+ </listitem>
- <para>
- The thread has read all outstanding updates from the
- binary 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>
+ </itemizedlist>
- <listitem>
- <para>
- <literal>Waiting to finalize termination</literal>
- </para>
+ </section>
- <para>
- A very brief state that occurs as the thread is stopping.
- </para>
- </listitem>
+ <section id="slave-io-thread-states">
- </itemizedlist>
+ <title>Replication Slave I/O Thread States</title>
- </section>
+ <para>
+ The following list shows the most common states you see in the
+ <literal>State</literal> column for a slave server I/O thread.
+ This state also appears in the <literal>Slave_IO_State</literal>
+ column displayed by <literal>SHOW SLAVE STATUS</literal>, so you
+ can get a good view of what is happening by using that
+ statement.
+ </para>
- <section id="slave-io-thread-states">
+ <itemizedlist>
- <title>Replication Slave I/O Thread States</title>
+ <listitem>
+ <para>
+ <literal>Connecting to master</literal>
+ </para>
- <para>
- The following list shows the most common states you see in the
- <literal>State</literal> column for a slave server I/O thread.
- This state also appears in the
- <literal>Slave_IO_State</literal> column displayed by
- <literal>SHOW SLAVE STATUS</literal>, so you can get a good
- view of what is happening by using that statement.
- </para>
+ <para>
+ The thread is attempting to connect to the master.
+ </para>
+ </listitem>
- <itemizedlist>
+ <listitem>
+ <para>
+ <literal>Checking master version</literal>
+ </para>
- <listitem>
- <para>
- <literal>Connecting to master</literal>
- </para>
+ <para>
+ A state that occurs very briefly, after the connection to
+ the master is established.
+ </para>
+ </listitem>
- <para>
- The thread is attempting to connect to the master.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Registering slave on master</literal>
+ </para>
- <listitem>
- <para>
- <literal>Checking master version</literal>
- </para>
+ <para>
+ A state that occurs very briefly after the connection to the
+ master is established.
+ </para>
+ </listitem>
- <para>
- A state that occurs very briefly, after the connection to
- the master is established.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Requesting binlog dump</literal>
+ </para>
- <listitem>
- <para>
- <literal>Registering slave on master</literal>
- </para>
+ <para>
+ A state that occurs very briefly, 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>
- <para>
- A state that occurs very briefly after the connection to
- the master is established.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting to reconnect after a failed binlog dump
+ request</literal>
+ </para>
- <listitem>
- <para>
- <literal>Requesting binlog dump</literal>
- </para>
+ <para>
+ If the binary log dump request failed (due to
+ disconnection), the thread goes into this state while it
+ sleeps, then tries to reconnect periodically. The interval
+ between retries can be specified using the
+ <option>--master-connect-retry</option> option.
+ </para>
+ </listitem>
- <para>
- A state that occurs very briefly, 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>
+ <listitem>
+ <para>
+ <literal>Reconnecting after a failed binlog dump
+ request</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting to reconnect after a failed binlog dump
- request</literal>
- </para>
+ <para>
+ The thread is trying to reconnect to the master.
+ </para>
+ </listitem>
- <para>
- If the binary log dump request failed (due to
- disconnection), the thread goes into this state while it
- sleeps, then tries to reconnect periodically. The interval
- between retries can be specified using the
- <option>--master-connect-retry</option> option.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting for master to send event</literal>
+ </para>
- <listitem>
- <para>
- <literal>Reconnecting after a failed binlog dump
- request</literal>
- </para>
+ <para>
+ The thread has connected to the master and is waiting for
+ binary log events to arrive. This can last for a long time
+ if the master is idle. If the wait lasts for
+ <literal>slave_net_timeout</literal> seconds, a timeout
+ occurs. At that point, the thread considers the connection
+ to be broken and makes an attempt to reconnect.
+ </para>
+ </listitem>
- <para>
- The thread is trying to reconnect to the master.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Queueing master event to the relay log</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting for master to send event</literal>
- </para>
+ <para>
+ The thread has read an event and is copying it to the relay
+ log so that the SQL thread can process it.
+ </para>
+ </listitem>
- <para>
- The thread has connected to the master and is waiting for
- binary log events to arrive. This can last for a long time
- if the master is idle. If the wait lasts for
- <literal>slave_net_timeout</literal> seconds, a timeout
- occurs. At that point, the thread considers the connection
- to be broken and makes an attempt to reconnect.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting to reconnect after a failed master event
+ read</literal>
+ </para>
- <listitem>
- <para>
- <literal>Queueing master event to the relay log</literal>
- </para>
+ <para>
+ An error occurred while reading (due to disconnection). The
+ thread is sleeping for
+ <literal>master-connect-retry</literal> seconds before
+ attempting to reconnect.
+ </para>
+ </listitem>
- <para>
- The thread has read an event and is copying it to the
- relay log so that the SQL thread can process it.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Reconnecting after a failed master event
+ read</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting to reconnect after a failed master event
- read</literal>
- </para>
+ <para>
+ The thread is trying to reconnect to the master. When
+ connection is established again, the state becomes
+ <literal>Waiting for master to send event</literal>.
+ </para>
+ </listitem>
- <para>
- An error occurred while reading (due to disconnection).
- The thread is sleeping for
- <literal>master-connect-retry</literal> seconds before
- attempting to reconnect.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting for the slave SQL thread to free enough
+ relay log space</literal>
+ </para>
- <listitem>
- <para>
- <literal>Reconnecting after a failed master event
- read</literal>
- </para>
+ <para>
+ You are using a non-zero
+ <literal>relay_log_space_limit</literal> value, and the
+ relay logs have grown large enough 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.
+ </para>
+ </listitem>
- <para>
- The thread is trying to reconnect to the master. When
- connection is established again, the state becomes
- <literal>Waiting for master to send event</literal>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting for slave mutex on exit</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting for the slave SQL thread to free enough
- relay log space</literal>
- </para>
+ <para>
+ A state that occurs briefly as the thread is stopping.
+ </para>
+ </listitem>
- <para>
- You are using a non-zero
- <literal>relay_log_space_limit</literal> value, and the
- relay logs have grown large enough 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.
- </para>
- </listitem>
+ </itemizedlist>
- <listitem>
- <para>
- <literal>Waiting for slave mutex on exit</literal>
- </para>
+ </section>
- <para>
- A state that occurs briefly as the thread is stopping.
- </para>
- </listitem>
+ <section id="slave-sql-thread-states">
- </itemizedlist>
+ <title>Replication Slave SQL Thread States</title>
- </section>
+ <para>
+ The following list shows the most common states you may see in
+ the <literal>State</literal> column for a slave server SQL
+ thread:
+ </para>
- <section id="slave-sql-thread-states">
+ <itemizedlist>
- <title>Replication Slave SQL Thread States</title>
+ <listitem>
+ <para>
+ <literal>Reading event from the relay log</literal>
+ </para>
- <para>
- The following list shows the most common states you may see in
- the <literal>State</literal> column for a slave server SQL
- thread:
- </para>
+ <para>
+ The thread has read an event from the relay log so that the
+ event can be processed.
+ </para>
+ </listitem>
- <itemizedlist>
+ <listitem>
+ <para>
+ <literal>Has read all relay log; waiting for the slave I/O
+ thread to update it</literal>
+ </para>
- <listitem>
- <para>
- <literal>Reading event from the relay log</literal>
- </para>
+ <para>
+ 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>
- <para>
- The thread has read an event from the relay log so that
- the event can be processed.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting for slave mutex on exit</literal>
+ </para>
- <listitem>
- <para>
- <literal>Has read all relay log; waiting for the slave I/O
- thread to update it</literal>
- </para>
+ <para>
+ A very brief state that occurs as the thread is stopping.
+ </para>
+ </listitem>
- <para>
- 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>
+ </itemizedlist>
- <listitem>
- <para>
- <literal>Waiting for slave mutex on exit</literal>
- </para>
+ <para>
+ The <literal>State</literal> column for the I/O thread may also
+ show the text of a statement. This indicates that the thread has
+ read an event from the relay log, extracted the statement from
+ it, and is executing it.
+ </para>
- <para>
- A very brief state that occurs as the thread is stopping.
- </para>
- </listitem>
+ </section>
- </itemizedlist>
+ <section id="slave-logs">
- <para>
- The <literal>State</literal> column for the I/O thread may
- also show the text of a statement. This indicates that the
- thread has read an event from the relay log, extracted the
- statement from it, and is executing it.
- </para>
+ <title>Replication Relay and Status Files</title>
- </section>
+ <para>
+ During replication the MySQL server creates a number of files
+ that are used to hold the relayed binary log from the master,
+ and record information about the current status and location
+ within the relayed log. There are three file types used in the
+ process:
+ </para>
- <section id="slave-logs">
+ <itemizedlist>
- <title>Replication Relay and Status Files</title>
+ <listitem>
+ <para>
+ The <emphasis>relay log</emphasis> consists of the events
+ read from the binary log of the master. Events in this
+ binary log are executed on the slave as part of the
+ replication thread.
+ </para>
+ </listitem>
-<para>During replication the MySQL server creates a number of files that are
- used to hold the relayed binary log from the master, and record information
- about the current status and location within the relayed log. There are three
- file types used in the process:</para>
+ <listitem>
+ <para>
+ The <emphasis>master.info</emphasis> file contains the
+ status and current configuration information for the slave's
+ connectivity to the master. The file holds information on
+ the master hostname, login credentials, and the current
+ position within the master's binary log.
+ </para>
+ </listitem>
-<itemizedlist>
- <listitem><para>The <emphasis>relay log</emphasis> consists of the events read
- from the binary log of the master. Events in this binary log are executed on
- the slave as part of the replication thread. </para></listitem>
- <listitem><para>The <emphasis>master.info</emphasis> file contains the status
- and current configuration information for the slave's connectivity to the
- master. The file holds information on the master hostname, login
- credentials, and the current position within the master's binary log. </para></listitem>
- <listitem><para>The <emphasis>relay.info</emphasis> file holds the status
- information about the execution point within the slave's relay log files.</para></listitem>
-</itemizedlist>
-
- <para>The relationship between the three files and the replication
- process is as follows. The <filename>master.info</filename> file retains the point within
- the master binary log that has been read from the master. These read
- events are written to the relay log. The <filename>relay.info</filename> file
- records the position within the relay log of the statements that have
- been executed. </para>
-
- <section id="slave-logs-relaylog">
- <title>The Slave Relay Log</title>
+ <listitem>
+ <para>
+ The <emphasis>relay.info</emphasis> file holds the status
+ information about the execution point within the slave's
+ relay log files.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The relationship between the three files and the replication
+ process is as follows. The <filename>master.info</filename> file
+ retains the point within the master binary log that has been
+ read from the master. These read events are written to the relay
+ log. The <filename>relay.info</filename> file records the
+ position within the relay log of the statements that have been
+ executed.
+ </para>
+
+ <section id="slave-logs-relaylog">
+
+ <title>The Slave Relay Log</title>
+
<para>
By default, relay logs filenames have the form
<filename><replaceable>host_name</replaceable>-relay-bin.<replaceable>nnnnnn</replaceable></filename>,
@@ -519,6 +543,7 @@
log index filename is
<filename><replaceable>host_name</replaceable>-relay-bin.index</filename>.
</para>
+
<para>
By default, the slave server creates relay log files in its
data directory. The default filenames can be overridden with
@@ -589,15 +614,16 @@
</itemizedlist>
- </section>
-
- <section id="slave-logs-status">
- <title>The Slave Status Files</title>
+ </section>
+ <section id="slave-logs-status">
+
+ <title>The Slave Status Files</title>
+
<para>
- A slave replication server creates two small files
- in the data directory. These <emphasis>status files</emphasis>
- are named <filename>master.info</filename> and
+ A slave replication server creates two small files in the data
+ directory. These <emphasis>status files</emphasis> are named
+ <filename>master.info</filename> and
<filename>relay-log.info</filename> by default. Their names
can be changed by using the
<option>--master-info-file</option> and
@@ -642,14 +668,13 @@
<row>
<entry>2</entry>
<entry><literal>Master_Log_File</literal></entry>
- <entry>The name of the master binary log currently being read
- from the master.</entry>
+ <entry>The name of the master binary log currently being read from the master.</entry>
</row>
<row>
<entry>3</entry>
<entry><literal>Read_Master_Log_Pos</literal></entry>
- <entry>The current position within the master binary log that
- have been read from the master. </entry>
+ <entry>The current position within the master binary log that have been read
+ from the master.</entry>
</row>
<row>
<entry>4</entry>
@@ -659,7 +684,7 @@
<row>
<entry>5</entry>
<entry><literal>Master_User</literal></entry>
- <entry>The username used to connect to the master. </entry>
+ <entry>The username used to connect to the master.</entry>
</row>
<row>
<entry>6</entry>
@@ -674,13 +699,13 @@
<row>
<entry>8</entry>
<entry><literal>Connect_Retry</literal></entry>
- <entry>The period (in seconds) that the slave will wait before
- trying to reconnect to the master.</entry>
+ <entry>The period (in seconds) that the slave will wait before trying to
+ reconnect to the master.</entry>
</row>
<row>
<entry>9</entry>
<entry><literal>Master_SSL_Allowed</literal></entry>
- <entry>Indicates whether the server supports SSL connections. </entry>
+ <entry>Indicates whether the server supports SSL connections.</entry>
</row>
<row>
<entry>10</entry>
@@ -695,7 +720,7 @@
<row>
<entry>12</entry>
<entry><literal>Master_SSL_Cert</literal></entry>
- <entry>The name of the SSL certificate file. </entry>
+ <entry>The name of the SSL certificate file.</entry>
</row>
<row>
<entry>13</entry>
@@ -737,20 +762,20 @@
<row>
<entry>2</entry>
<entry><literal>Relay_Log_Pos</literal></entry>
- <entry>The current position within the relay log file. Events up
- to this position have been executed on the slave database.</entry>
+ <entry>The current position within the relay log file. Events up to this
+ position have been executed on the slave database.</entry>
</row>
<row>
<entry>3</entry>
<entry><literal>Relay_Master_Log_File</literal></entry>
- <entry>The name of the master binary log file from which the
- events in the relay log file were read.</entry>
+ <entry>The name of the master binary log file from which the events in the
+ relay log file were read.</entry>
</row>
<row>
<entry>4</entry>
<entry><literal>Exec_Master_Log_Pos</literal></entry>
- <entry>The equivalent position within the master's binary log
- file of events that have already been executed. </entry>
+ <entry>The equivalent position within the master's binary log file of events
+ that have already been executed.</entry>
</row>
</tbody>
</tgroup>
@@ -767,485 +792,480 @@
system, <literal>SHOW SLAVE STATUS</literal> should be used.
</para>
+ </section>
- </section>
- </section>
-
</section>
- <section id="replication-rules">
+ </section>
- <title>How Servers Evaluate Replication Rules</title>
+ <section id="replication-rules">
- <para>
- If a master server does not write a statement to its binary log,
- the statement is not replicated. If the server does log the
- statement, the statement is sent to all slaves and each slave
- determines whether to execute it or ignore it.
- </para>
+ <title>How Servers Evaluate Replication Rules</title>
- <para>
- On the master you can control which databases write events to the binary
- log using the <option>--binlog-do-db</option> and
- <option>--binlog-ignore-db</option> options to control binary
- logging. For a description of the rules that servers use in
- evaluating these options, see <xref linkend="binary-log"/>. You should
- not use these options to control the databases and tables that are
- replicated, instead, use filtering on the slave to control the
- events that are executed on the slave.
- </para>
+ <para>
+ If a master server does not write a statement to its binary log,
+ the statement is not replicated. If the server does log the
+ statement, the statement is sent to all slaves and each slave
+ determines whether to execute it or ignore it.
+ </para>
- <para>
- On the slave side, decisions about whether to execute or ignore
- statements received from the master are made according to the
- <option>--replicate-*</option> options that the slave was
- started with. (See <xref linkend="replication-options"/>.) The
- slave evaluates these options using the following procedure,
- which first checks the database-level options and then the
- table-level options.
- </para>
+ <para>
+ On the master you can control which databases write events to the
+ binary log using the <option>--binlog-do-db</option> and
+ <option>--binlog-ignore-db</option> options to control binary
+ logging. For a description of the rules that servers use in
+ evaluating these options, see <xref linkend="binary-log"/>. You
+ should not use these options to control the databases and tables
+ that are replicated, instead, use filtering on the slave to
+ control the events that are executed on the slave.
+ </para>
- <para>
- In the simplest case, when there are no
- <option>--replicate-*</option> options, the procedure yields the
- result that the slave executes all statements that it receives
- from the master. Otherwise, the result depends on the particular
- options given. In general, to make it easier to determine what
- effect an option set will have, it is recommended that you avoid
- mixing <quote>do</quote> and <quote>ignore</quote> options, or
- wildcard and non-wildcard options.
- </para>
+ <para>
+ On the slave side, decisions about whether to execute or ignore
+ statements received from the master are made according to the
+ <option>--replicate-*</option> options that the slave was started
+ with. (See <xref linkend="replication-options"/>.) The slave
+ evaluates these options using the following procedure, which first
+ checks the database-level options and then the table-level
+ options.
+ </para>
- <para>
- <emphasis role="bold">Stage 1. Check the database
- options.</emphasis>
- </para>
+ <para>
+ In the simplest case, when there are no
+ <option>--replicate-*</option> options, the procedure yields the
+ result that the slave executes all statements that it receives
+ from the master. Otherwise, the result depends on the particular
+ options given. In general, to make it easier to determine what
+ effect an option set will have, it is recommended that you avoid
+ mixing <quote>do</quote> and <quote>ignore</quote> options, or
+ wildcard and non-wildcard options.
+ </para>
- <para>
- At this stage, the slave checks whether there are any
- <option>--replicate-do-db</option> or
- <option>--replicate-ignore-db</option> options that specify
- database-specific conditions:
- </para>
+ <para>
+ <emphasis role="bold">Stage 1. Check the database
+ options.</emphasis>
+ </para>
- <itemizedlist>
+ <para>
+ At this stage, the slave checks whether there are any
+ <option>--replicate-do-db</option> or
+ <option>--replicate-ignore-db</option> options that specify
+ database-specific conditions:
+ </para>
- <listitem>
- <para>
- <emphasis>No</emphasis>: Permit the statement and proceed to
- the table-checking stage.
- </para>
- </listitem>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Test the options using the same
- rules as for the <option>--binlog-do-db</option> and
- <option>--binlog-ignore-db</option> options to determine
- whether to permit or ignore the statement. What is the
- result of the test?
- </para>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: Permit the statement and proceed to
+ the table-checking stage.
+ </para>
+ </listitem>
- <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Test the options using the same
+ rules as for the <option>--binlog-do-db</option> and
+ <option>--binlog-ignore-db</option> options to determine
+ whether to permit or ignore the statement. What is the result
+ of the test?
+ </para>
- <listitem>
- <para>
- <emphasis>Permit</emphasis>: Do not execute the
- statement immediately. Defer the decision and proceed to
- the table-checking stage.
- </para>
- </listitem>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>Ignore</emphasis>: Ignore the statement and
- exit.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>Permit</emphasis>: Do not execute the statement
+ immediately. Defer the decision and proceed to the
+ table-checking stage.
+ </para>
+ </listitem>
- </itemizedlist>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>Ignore</emphasis>: Ignore the statement and
+ exit.
+ </para>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
+ </listitem>
- <para>
- This stage can permit a statement for further option-checking,
- or cause it to be ignored. However, statements that are
- permitted at this stage are not actually executed yet. Instead,
- they pass to the following stage that checks the table options.
- </para>
+ </itemizedlist>
- <para>
- <emphasis role="bold">Stage 2. Check the table
- options.</emphasis>
- </para>
+ <para>
+ This stage can permit a statement for further option-checking, or
+ cause it to be ignored. However, statements that are permitted at
+ this stage are not actually executed yet. Instead, they pass to
+ the following stage that checks the table options.
+ </para>
- <para>
- First, as a preliminary condition, the slave checks whether
- statement-based replication is enabled. If so and the statement
- occurs within a stored function, execute the statement and exit.
- (If row-based replication is enabled, the slave does not know
- whether a statement occurred within a stored function on the
- master, so this condition does not apply.)
- </para>
+ <para>
+ <emphasis role="bold">Stage 2. Check the table options.</emphasis>
+ </para>
- <para>
- Next, the slave checks for table options and evaluates them. If
- the server reaches this point, it executes all statements if
- there are no table options. If there are <quote>do</quote> table
- options, the statement must match one of them if it is to be
- executed; otherwise, it is ignored. If there are any
- <quote>ignore</quote> options, all statements are executed
- except those that match any <quote>ignore</quote> option. The
- following steps describe how this evaluation occurs in more
- detail.
- </para>
+ <para>
+ First, as a preliminary condition, the slave checks whether
+ statement-based replication is enabled. If so and the statement
+ occurs within a stored function, execute the statement and exit.
+ (If row-based replication is enabled, the slave does not know
+ whether a statement occurred within a stored function on the
+ master, so this condition does not apply.)
+ </para>
- <orderedlist>
+ <para>
+ Next, the slave checks for table options and evaluates them. If
+ the server reaches this point, it executes all statements if there
+ are no table options. If there are <quote>do</quote> table
+ options, the statement must match one of them if it is to be
+ executed; otherwise, it is ignored. If there are any
+ <quote>ignore</quote> options, all statements are executed except
+ those that match any <quote>ignore</quote> option. The following
+ steps describe how this evaluation occurs in more detail.
+ </para>
- <listitem>
- <para>
- Are there any <option>--replicate-*-table</option> options?
- </para>
+ <orderedlist>
- <itemizedlist>
+ <listitem>
+ <para>
+ Are there any <option>--replicate-*-table</option> options?
+ </para>
- <listitem>
- <para>
- <emphasis>No</emphasis>: There are no table
- restrictions, so all statements match. Execute the
- statement and exit.
- </para>
- </listitem>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: There are table restrictions.
- Evaluate the tables to be updated against them. There
- might be multiple tables to update, so loop through the
- following steps for each table looking for a matching
- option. In this case, the behavior depends on whether
- statement-based replication or row-based replication is
- enabled:
- </para>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: There are no table restrictions,
+ so all statements match. Execute the statement and exit.
+ </para>
+ </listitem>
- <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: There are table restrictions.
+ Evaluate the tables to be updated against them. There
+ might be multiple tables to update, so loop through the
+ following steps for each table looking for a matching
+ option. In this case, the behavior depends on whether
+ statement-based replication or row-based replication is
+ enabled:
+ </para>
- <listitem>
- <para>
- <emphasis>Statement-based replication</emphasis>:
- Proceed to the next step and begin evaluating the
- table options in the order shown (first the non-wild
- options, and then the wild options). Only tables
- that are to be updated are compared to the options.
- For example, if the statement is <literal>INSERT
- INTO sales SELECT * FROM prices</literal>, only
- <literal>sales</literal> is compared to the
- options). If several tables are to be updated
- (multiple-table statement), the first table that
- matches <quote>do</quote> or <quote>ignore</quote>
- wins. That is, the server checks the first table
- against the options. If no decision could be made,
- it checks the second table against the options, and
- so on.
- </para>
- </listitem>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>Row-based replication</emphasis>: All
- table row changes are filtered individually. For
- multiple-table updates, each table is filtered
- separately according to the options. Some updates
- may be executed and some not, depending on the
- options and the changes to be made. Row-based
- replication correctly handles cases that would not
- replicate correctly with statement-based
- replication, as in this example which assumes that
- tables in the <literal>foo</literal> database should
- be replicated:
- </para>
+ <listitem>
+ <para>
+ <emphasis>Statement-based replication</emphasis>:
+ Proceed to the next step and begin evaluating the
+ table options in the order shown (first the non-wild
+ options, and then the wild options). Only tables that
+ are to be updated are compared to the options. For
+ example, if the statement is <literal>INSERT INTO
+ sales SELECT * FROM prices</literal>, only
+ <literal>sales</literal> is compared to the options).
+ If several tables are to be updated (multiple-table
+ statement), the first table that matches
+ <quote>do</quote> or <quote>ignore</quote> wins. That
+ is, the server checks the first table against the
+ options. If no decision could be made, it checks the
+ second table against the options, and so on.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis>Row-based replication</emphasis>: All table
+ row changes are filtered individually. For
+ multiple-table updates, each table is filtered
+ separately according to the options. Some updates may
+ be executed and some not, depending on the options and
+ the changes to be made. Row-based replication
+ correctly handles cases that would not replicate
+ correctly with statement-based replication, as in this
+ example which assumes that tables in the
+ <literal>foo</literal> database should be replicated:
+ </para>
+
<programlisting>
mysql> <userinput>USE bar;</userinput>
mysql> <userinput>INSERT INTO foo.sometable VALUES (1);</userinput>
</programlisting>
- </listitem>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- <listitem>
- <para>
- Are there any <option>--replicate-do-table</option> options?
- </para>
+ <listitem>
+ <para>
+ Are there any <option>--replicate-do-table</option> options?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: Proceed to the next step.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: Proceed to the next step.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Does the table match any of
- them?
- </para>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: Proceed to the next step.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: Proceed to the next step.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Execute the statement and
- exit.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Execute the statement and
+ exit.
+ </para>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- <listitem>
- <para>
- Are there any <option>--replicate-ignore-table</option>
- options?
- </para>
+ <listitem>
+ <para>
+ Are there any <option>--replicate-ignore-table</option>
+ options?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: Proceed to the next step.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: Proceed to the next step.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Does the table match any of
- them?
- </para>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: Proceed to the next step.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: Proceed to the next step.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Ignore the statement and
- exit.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Ignore the statement and
+ exit.
+ </para>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- <listitem>
- <para>
- Are there any <option>--replicate-wild-do-table</option>
- options?
- </para>
+ <listitem>
+ <para>
+ Are there any <option>--replicate-wild-do-table</option>
+ options?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: Proceed to the next step.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: Proceed to the next step.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Does the table match any of
- them?
- </para>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: Proceed to the next step.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: Proceed to the next step.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Execute the statement and
- exit.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Execute the statement and
+ exit.
+ </para>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- <listitem>
- <para>
- Are there any <option>--replicate-wild-ignore-table</option>
- options?
- </para>
+ <listitem>
+ <para>
+ Are there any <option>--replicate-wild-ignore-table</option>
+ options?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: Proceed to the next step.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: Proceed to the next step.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Does the table match any of
- them?
- </para>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Does the table match any of
+ them?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: Proceed to the next step.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: Proceed to the next step.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Ignore the statement and
- exit.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Ignore the statement and
+ exit.
+ </para>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- <listitem>
- <para>
- No <option>--replicate-*-table</option> option was matched.
- Is there another table to test against these options?
- </para>
+ <listitem>
+ <para>
+ No <option>--replicate-*-table</option> option was matched. Is
+ there another table to test against these options?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: We have now tested all tables
- to be updated and could not match any option. Are there
- <option>--replicate-do-table</option> or
- <option>--replicate-wild-do-table</option> options?
- </para>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: We have now tested all tables to
+ be updated and could not match any option. Are there
+ <option>--replicate-do-table</option> or
+ <option>--replicate-wild-do-table</option> options?
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <emphasis>No</emphasis>: There were no
- <quote>do</quote> table options, so no explicit
- <quote>do</quote> match is required. Execute the
- statement and exit.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>No</emphasis>: There were no
+ <quote>do</quote> table options, so no explicit
+ <quote>do</quote> match is required. Execute the
+ statement and exit.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: There were
- <quote>do</quote> table options, so the statement is
- executed only with an explicit match to one of them.
- Ignore the statement and exit.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: There were <quote>do</quote>
+ table options, so the statement is executed only with
+ an explicit match to one of them. Ignore the statement
+ and exit.
+ </para>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- <listitem>
- <para>
- <emphasis>Yes</emphasis>: Loop.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <emphasis>Yes</emphasis>: Loop.
+ </para>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </listitem>
- </orderedlist>
+ </orderedlist>
- <para>
- Examples:
- </para>
+ <para>
+ Examples:
+ </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- No <option>--replicate-*</option> options at all
- </para>
+ <listitem>
+ <para>
+ No <option>--replicate-*</option> options at all
+ </para>
- <para>
- The slave executes all statements that it receives from the
- master.
- </para>
- </listitem>
+ <para>
+ The slave executes all statements that it receives from the
+ master.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <option>--replicate-*-db</option> options, but no table
- options
- </para>
+ <listitem>
+ <para>
+ <option>--replicate-*-db</option> options, but no table
+ options
+ </para>
- <para>
- The slave permits or ignores statements using the database
- options. Then it executes all statements permitted by those
- options because there are no table restrictions.
- </para>
- </listitem>
+ <para>
+ The slave permits or ignores statements using the database
+ options. Then it executes all statements permitted by those
+ options because there are no table restrictions.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <option>--replicate-*-table</option> options, but no
- database options
- </para>
+ <listitem>
+ <para>
+ <option>--replicate-*-table</option> options, but no database
+ options
+ </para>
- <para>
- All statements are permitted at the database-checking stage
- because there are no database conditions. The slave executes
- or ignores statements based on the table options.
- </para>
- </listitem>
+ <para>
+ All statements are permitted at the database-checking stage
+ because there are no database conditions. The slave executes
+ or ignores statements based on the table options.
+ </para>
+ </listitem>
- <listitem>
- <para>
- A mix of database and table options
- </para>
+ <listitem>
+ <para>
+ A mix of database and table options
+ </para>
- <para>
- The slave permits or ignores statements using the database
- options. Then it evaluates all statements permitted by those
- options according to the table options. In some cases, this
- process can yield what might seem a counterintuitive result.
- Consider the following set of options:
- </para>
+ <para>
+ The slave permits or ignores statements using the database
+ options. Then it evaluates all statements permitted by those
+ options according to the table options. In some cases, this
+ process can yield what might seem a counterintuitive result.
+ Consider the following set of options:
+ </para>
<programlisting>
[mysqld]
@@ -1253,30 +1273,30 @@
replicate-do-table = db2.mytbl2
</programlisting>
- <para>
- Suppose that <literal>db1</literal> is the default database
- and the slave receives this statement:
- </para>
+ <para>
+ Suppose that <literal>db1</literal> is the default database
+ and the slave receives this statement:
+ </para>
<programlisting>
INSERT INTO mytbl1 VALUES(1,2,3);
</programlisting>
- <para>
- The database is <literal>db1</literal>, which matches the
- <option>--replicate-do-db</option> option at the
- database-checking stage. The algorithm then proceeds to the
- table-checking stage. If there were no table options, the
- statement would be executed. However, because the options
- include a <quote>do</quote> table option, the statement must
- match if it is to be executed. The statement does not match,
- so it is ignored. (The same would happen for any table in
- <literal>db1</literal>.)
- </para>
- </listitem>
+ <para>
+ The database is <literal>db1</literal>, which matches the
+ <option>--replicate-do-db</option> option at the
+ database-checking stage. The algorithm then proceeds to the
+ table-checking stage. If there were no table options, the
+ statement would be executed. However, because the options
+ include a <quote>do</quote> table option, the statement must
+ match if it is to be executed. The statement does not match,
+ so it is ignored. (The same would happen for any table in
+ <literal>db1</literal>.)
+ </para>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
+ </section>
- </section>
+</section>
Modified: branches/repupdate/5.1/replication-notes.xml
===================================================================
--- branches/repupdate/5.1/replication-notes.xml 2007-02-06 11:22:03 UTC (rev 4809)
+++ branches/repupdate/5.1/replication-notes.xml 2007-02-06 14:22:41 UTC (rev 4810)
Changed blocks: 2, Lines Added: 5, Lines Deleted: 5; 1324 bytes
@@ -222,9 +222,9 @@
<literal>character_set_server</literal> value, you should
design your <literal>CREATE TABLE</literal> statements so
that tables in those databases do not implicitly rely on the
- database default character set. A good
- workaround is to state the character set and collation
- explicitly in <literal>CREATE TABLE</literal> statements.
+ database default character set. A good workaround is to
+ state the character set and collation explicitly in
+ <literal>CREATE TABLE</literal> statements.
</para>
</listitem>
@@ -720,8 +720,8 @@
<para>
You may replicate from a master to a slave where the number of
- columns in the table on the slave is larger than the number
- of columns in the corresponding table on the master.
+ columns in the table on the slave is larger than the number of
+ columns in the corresponding table on the master.
</para>
<para>
Modified: branches/repupdate/5.1/replication-solutions.xml
===================================================================
--- branches/repupdate/5.1/replication-solutions.xml 2007-02-06 11:22:03 UTC (rev 4809)
+++ branches/repupdate/5.1/replication-solutions.xml 2007-02-06 14:22:41 UTC (rev 4810)
Changed blocks: 2, Lines Added: 10, Lines Deleted: 11; 2227 bytes
@@ -205,12 +205,12 @@
Another alternative for <literal>mysqldump</literal> is to
disable engine types that you do not want to use on the slave
before using the dump to build the data on the slave. For
- example, you can add the <option>--skip-innodb</option>
- option on your slave to disable the <literal>InnoDB</literal>
- engine. If a specific engine does not exist, MySQL will use
- the default engine type, usually <literal>MyISAM</literal>. If
- you want to disable further engines in this way, you may want
- to consider building a special binary to be used on the slave
+ example, you can add the <option>--skip-innodb</option> option
+ on your slave to disable the <literal>InnoDB</literal> engine.
+ If a specific engine does not exist, MySQL will use the
+ default engine type, usually <literal>MyISAM</literal>. If you
+ want to disable further engines in this way, you may want to
+ consider building a special binary to be used on the slave
that only supports the engines you want.
</para>
</listitem>
@@ -611,11 +611,10 @@
replication functionality to the remainder of the slaves in
the replication structure. Master 2 is the only machine
allowed to connect to Master 2. Master 2 also has binary
- logging enabled, and the
- <option>--log-slave-updates</option> so that replication
- instructions from Master 1 are also written to Master 2's
- binary log so that they can then be replicated to the real
- slaves.
+ logging enabled, and the <option>--log-slave-updates</option>
+ so that replication instructions from Master 1 are also
+ written to Master 2's binary log so that they can then be
+ replicated to the real slaves.
</para>
</listitem>
Modified: branches/repupdate/5.1/replication-topology.xml
===================================================================
--- branches/repupdate/5.1/replication-topology.xml 2007-02-06 11:22:03 UTC (rev 4809)
+++ branches/repupdate/5.1/replication-topology.xml 2007-02-06 14:22:41 UTC (rev 4810)
Changed blocks: 10, Lines Added: 69, Lines Deleted: 71; 8269 bytes
@@ -10,33 +10,33 @@
%versions.entities;
]>
<section id="replication-topology">
-
+
<title>Replication Topologies</title>
-
+
<para>
MySQL supports many different topologies for replication. Which
- topology you use will depend on your requirements and what you
- want to use replication to achieve.
+ topology you use will depend on your requirements and what you want
+ to use replication to achieve.
</para>
-
+
<itemizedlist>
-
+
<listitem>
<para>
<emphasis role="bold">Single slave</emphasis>
</para>
</listitem>
-
+
</itemizedlist>
-
+
<section id="replication-topology-single-slave">
-
+
<title>Replication with a Single Slave</title>
-
+
<para>
Replication with a single slave
</para>
-
+
<figure id="figure-replication-slave-single">
<title>Replication with a single slave</title>
<mediaobject>
@@ -50,17 +50,17 @@
</textobject>
</mediaobject>
</figure>
-
+
</section>
-
+
<section id="replication-topology-multi-slave">
-
+
<title>Replication with Multiple Slaves</title>
-
+
<para>
Replication with multiple slaves
</para>
-
+
<figure id="figure-replication-slaves-multiple">
<title>Replication with multiple slaves</title>
<mediaobject>
@@ -70,22 +70,21 @@
format="PNG" lang="en"/>
</imageobject>
<textobject>
- <phrase lang="en">Replication with a multiple
- slaves</phrase>
+ <phrase lang="en">Replication with a multiple slaves</phrase>
</textobject>
</mediaobject>
</figure>
-
+
</section>
-
+
<section id="replication-topology-twin-master">
-
+
<title>Replication with Two Masters</title>
-
+
<para>
Replication with multiple masters
</para>
-
+
<figure id="figure-replication-twinmaster">
<title>Replication with twin masters</title>
<mediaobject>
@@ -99,19 +98,19 @@
</textobject>
</mediaobject>
</figure>
-
+
<section id="replication-auto-increment">
-
+
<title>Auto-Increment in Multiple-Master Replication</title>
-
+
<para>
When multiple servers are configured as replication masters,
- special steps must be taken to prevent key collisions when
- using <literal>AUTO_INCREMENT</literal> columns, otherwise
- multiple masters may attempt to use the same
+ special steps must be taken to prevent key collisions when using
+ <literal>AUTO_INCREMENT</literal> columns, otherwise multiple
+ masters may attempt to use the same
<literal>AUTO_INCREMENT</literal> value when inserting rows.
</para>
-
+
<para>
The <literal>auto_increment_increment</literal> and
<literal>auto_increment_offset</literal> system variables help
@@ -120,14 +119,14 @@
variables has a default and minimum value of 1, and a maximum
value of 65,535.
</para>
-
+
<para>
These two variables affect <literal>AUTO_INCREMENT</literal>
column behavior as follows:
</para>
-
+
<itemizedlist>
-
+
<listitem>
<para>
<literal>auto_increment_increment</literal> controls the
@@ -135,17 +134,17 @@
<literal>AUTO_INCREMENT</literal> values.
</para>
</listitem>
-
+
<listitem>
<para>
<literal>auto_increment_offset</literal> determines the
- starting point for <literal>AUTO_INCREMENT</literal>
- column values.
+ starting point for <literal>AUTO_INCREMENT</literal> column
+ values.
</para>
</listitem>
-
+
</itemizedlist>
-
+
<para>
By choosing non-conflicting values for these variables on
different masters, servers in a multiple-master configuration
@@ -154,46 +153,45 @@
<replaceable>N</replaceable> master servers, set the variables
like this:
</para>
-
+
<itemizedlist>
-
+
<listitem>
<para>
Set <literal>auto_increment_increment</literal> to
<replaceable>N</replaceable> on each master.
</para>
</listitem>
-
+
<listitem>
<para>
- Set each of the <replaceable>N</replaceable> masters to
- have a different <literal>auto_increment_offset</literal>,
- using the values 1, 2, …,
- <replaceable>N</replaceable>.
+ Set each of the <replaceable>N</replaceable> masters to have
+ a different <literal>auto_increment_offset</literal>, using
+ the values 1, 2, …, <replaceable>N</replaceable>.
</para>
</listitem>
-
+
</itemizedlist>
-
+
<para>
For additional information about
<literal>auto_increment_increment</literal> and
<literal>auto_increment_offset</literal>, see
<xref linkend="server-system-variables" />.
</para>
-
+
</section>
-
+
</section>
-
+
<section id="replication-topology-circular">
-
+
<title>Replication with Circular Masters</title>
-
+
<para>
Multiple masters
</para>
-
+
<para>
It is safe to connect servers in a circular master/slave
relationship if you use the <option>--log-slave-updates</option>
@@ -201,7 +199,7 @@
<xref
linkend="figure-replication-multimaster-chain"/>.
</para>
-
+
<figure id="figure-replication-multimaster-circular">
<title>Replication with multiple masters in a circular topology</title>
<mediaobject>
@@ -212,42 +210,42 @@
</imageobject>
<textobject>
<phrase lang="en">Replication with multiple masters in a
- circular topology</phrase>
+ circular topology</phrase>
</textobject>
</mediaobject>
</figure>
-
+
<para>
However, many statements do not work correctly in this kind of
setup unless your client code is written to take care of the
potential problems that can occur from updates that occur in
different sequence on different servers.
</para>
-
+
<para>
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
+ 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 applied is significant.
</para>
-
+
</section>
-
+
<section id="replication-topology-chain">
-
+
<title>Replication Chains</title>
-
+
<para>
TODO
</para>
-
+
<figure id="figure-replication-multimaster-chain">
<title>Replication with multiple masters in a chain topology</title>
<mediaobject>
@@ -257,18 +255,18 @@
format="PNG" lang="en"/>
</imageobject>
<textobject>
- <phrase lang="en">Replication with multiple masters in a
- chain topology</phrase>
+ <phrase lang="en">Replication with multiple masters in a chain
+ topology</phrase>
</textobject>
</mediaobject>
</figure>
-
+
</section>
-
+
<section id="replication-topology-multimaster-toone">
-
+
<title>Replicating Multiple Masters to One Slave</title>
-
+
</section>
-
+
</section>
Modified: branches/repupdate/5.1/replication.xml
===================================================================
--- branches/repupdate/5.1/replication.xml 2007-02-06 11:22:03 UTC (rev 4809)
+++ branches/repupdate/5.1/replication.xml 2007-02-06 14:22:41 UTC (rev 4810)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 5; 1217 bytes
@@ -125,6 +125,7 @@
linkend="replication-options"/>
</para>
+<!--
<para>
Through different master/slave combinations there are a number of
different potential replication topologies, including single
@@ -132,6 +133,7 @@
information, see <xref
linkend="replication-topology"/>.
</para>
+-->
<para>
You can use replication to solve a number of different problems,
@@ -162,18 +164,19 @@
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="replication-configuration.xml" />
-
+
+<!--
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="replication-topology.xml" />
-
+ -->
+
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="replication-solutions.xml" />
-
+
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="replication-notes.xml" />
-
+
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="replication-implementation.xml" />
-
</chapter>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r4810 - branches/repupdate/5.1 | mcbrown | 6 Feb |
