Author: mcbrown
Date: 2007-02-06 15:49:51 +0100 (Tue, 06 Feb 2007)
New Revision: 4812
Log:
Reformatting the implementation section to make the sections flow better, new introduction.
Modified:
branches/repupdate/5.1/replication-implementation.xml
branches/repupdate/5.1/replication-solutions.xml
branches/repupdate/5.1/replication-topology.xml
Modified: branches/repupdate/5.1/replication-implementation.xml
===================================================================
--- branches/repupdate/5.1/replication-implementation.xml 2007-02-06 14:24:46 UTC (rev 4811)
+++ branches/repupdate/5.1/replication-implementation.xml 2007-02-06 14:49:51 UTC (rev 4812)
Changed blocks: 2, Lines Added: 563, Lines Deleted: 546; 46203 bytes
@@ -14,49 +14,76 @@
<title>Replication Implementation[TODO:Rewrite]</title>
<indexterm>
- <primary>master/slave setup</primary>
+ <primary>replication implementation</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"/>.
+ The basic mechanics of replication is based on the master server
+ keeping track of all changes to your databases (updates, deletes,
+ and so on) in its binary logs. The binary log serves as a written
+ record of each to the database from the moment the database was
+ started. The binary log contains records of all the statements which
+ edit or modify either the database structure or the data that the
+ structure contains. Typically <literal>SELECT</literal> statements
+ are not recorded, as they do not modify the database data or
+ structure.
</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.
+ Each slave that connects to the master receives a copy of the binary
+ log, and executes the events within the binary log. This has the
+ effect of repeating the original statements and changes just as they
+ were made on the master. Tables are created or their structure
+ modified, and data is inserted, deleted and updated according to the
+ statements that were originally executed on the master.
</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.
+ Because each slave is independent, the replaying of the statements
+ in the masters binary log can occur on each slave that is connected
+ to the master. In addition, because each slave only receives a copy
+ of the binary log by requesting it from the master (it pulls the
+ data from the master, rather than the master pushing the data to the
+ slave), the slave is able to read and update the copy of the
+ database at it's own pace and rate and can start and stop the
+ replication process at will without affecting the master or the
+ slaves ability to update to the latest database status.
</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.
+ For more information on the specifics of the replication
+ implementation, see
+ <xref linkend="replication-implementation-details"/>.
</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.
+ Slaves and masters report their status in respect of the replication
+ process regularly so that you can monitor the situation. For
+ information on slave states, see
+ <xref linkend="slave-io-thread-states"/>, and
+ <xref
+ linkend="slavesql-thread-states"/>. For master states, see
+ <xref
+ linkend="master-thread-states"/>.
</para>
+ <para>
+ The master binary log is written to a local relay log on the slave
+ before it is processed. The slave also records information about the
+ current position with the master's binary log and the local relayed
+ log. See <xref
+ linkend="slave-logs"/>.
+ </para>
+
+ <para>
+ Databases and tables are updated on the slave accordingly to a set
+ of rules that are applied according to the various configuration
+ options and variables that control statement evaluation. For details
+ on how these rules are applied, see
+ <xref
+ linkend="replication-rules"/>.
+ </para>
+
<section id="replication-implementation-details">
<title>Replication Implementation Details</title>
@@ -180,620 +207,610 @@
<xref linkend="replication-faq"/>.
</para>
- <section id="master-thread-states">
+ </section>
- <title>Replication Master Thread States</title>
+ <section id="master-thread-states">
- <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>
+ <title>Replication Master Thread States</title>
- <itemizedlist>
+ <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>
- <listitem>
- <para>
- <literal>Sending binlog event to slave</literal>
- </para>
+ <itemizedlist>
- <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>Sending binlog event to slave</literal>
+ </para>
- <listitem>
- <para>
- <literal>Finished reading one binlog; switching to next
- binlog</literal>
- </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>
- <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>Finished reading one binlog; switching to next
+ binlog</literal>
+ </para>
- <listitem>
- <para>
- <literal>Has sent all binlog to slave; waiting for binlog to
- be updated</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>
- 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>
+ <listitem>
+ <para>
+ <literal>Has sent all binlog to slave; waiting for binlog to
+ be updated</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting to finalize termination</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>
- A very brief state that occurs as the thread is stopping.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting to finalize termination</literal>
+ </para>
- </itemizedlist>
+ <para>
+ A very brief state that occurs as the thread is stopping.
+ </para>
+ </listitem>
- </section>
+ </itemizedlist>
- <section id="slave-io-thread-states">
+ </section>
- <title>Replication Slave I/O Thread States</title>
+ <section id="slave-io-thread-states">
- <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>
+ <title>Replication Slave I/O Thread States</title>
- <itemizedlist>
+ <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>
- <listitem>
- <para>
- <literal>Connecting to master</literal>
- </para>
+ <itemizedlist>
- <para>
- The thread is attempting to connect to the master.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Connecting to master</literal>
+ </para>
- <listitem>
- <para>
- <literal>Checking master version</literal>
- </para>
+ <para>
+ The thread is attempting to connect to the master.
+ </para>
+ </listitem>
- <para>
- A state that occurs very briefly, after the connection to
- the master is established.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Checking master version</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.
+ </para>
+ </listitem>
- <para>
- A state that occurs very briefly after the connection to the
- master is established.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Registering slave on master</literal>
+ </para>
- <listitem>
- <para>
- <literal>Requesting binlog dump</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. 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>Requesting binlog dump</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting to reconnect after a failed binlog dump
- request</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>
- 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 to reconnect after a failed binlog dump
+ request</literal>
+ </para>
- <listitem>
- <para>
- <literal>Reconnecting after a failed binlog dump
- request</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>
- The thread is trying to reconnect to the master.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Reconnecting after a failed binlog dump
+ request</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting for master to send event</literal>
- </para>
+ <para>
+ The thread is trying to reconnect to the master.
+ </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 for master to send event</literal>
+ </para>
- <listitem>
- <para>
- <literal>Queueing master event to the relay log</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 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>Queueing master event to the relay log</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting to reconnect after a failed master event
- read</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>
- 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 to reconnect after a failed master event
+ read</literal>
+ </para>
- <listitem>
- <para>
- <literal>Reconnecting after a failed master event
- read</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 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>Reconnecting after a failed master event
+ read</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting for the slave SQL thread to free enough
- relay log space</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>
- 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>
+ <listitem>
+ <para>
+ <literal>Waiting for the slave SQL thread to free enough relay
+ log space</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting for slave mutex on exit</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>
- A state that occurs briefly as the thread is stopping.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting for slave mutex on exit</literal>
+ </para>
- </itemizedlist>
+ <para>
+ A state that occurs briefly as the thread is stopping.
+ </para>
+ </listitem>
- </section>
+ </itemizedlist>
- <section id="slave-sql-thread-states">
+ </section>
- <title>Replication Slave SQL Thread States</title>
+ <section id="slave-sql-thread-states">
- <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>
+ <title>Replication Slave SQL Thread States</title>
- <itemizedlist>
+ <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>
- <listitem>
- <para>
- <literal>Reading event from the relay log</literal>
- </para>
+ <itemizedlist>
- <para>
- The thread has read an event from the relay log so that the
- event can be processed.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Reading event from the relay log</literal>
+ </para>
- <listitem>
- <para>
- <literal>Has read all relay log; waiting for the slave I/O
- thread to update it</literal>
- </para>
+ <para>
+ The thread has read an event from the relay log so that the
+ event can be processed.
+ </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>
+ <listitem>
+ <para>
+ <literal>Has read all relay log; waiting for the slave I/O
+ thread to update it</literal>
+ </para>
- <listitem>
- <para>
- <literal>Waiting for slave mutex on exit</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>
- A very brief state that occurs as the thread is stopping.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Waiting for slave mutex on exit</literal>
+ </para>
- </itemizedlist>
+ <para>
+ A very brief state that occurs as the thread is stopping.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <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>
+
+ </section>
+
+ <section id="slave-logs">
+
+ <title>Replication Relay and Status Files</title>
+
+ <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>
+
+ <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>
+
<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.
+ By default, relay logs filenames have the form
+ <filename><replaceable>host_name</replaceable>-relay-bin.<replaceable>nnnnnn</replaceable></filename>,
+ where <replaceable>host_name</replaceable> is the name of the
+ slave server host and <replaceable>nnnnnn</replaceable> is a
+ sequence number. Successive relay log files are created using
+ successive sequence numbers, beginning with
+ <literal>000001</literal>. The slave uses an index file to track
+ the relay log files currently in use. The default relay log
+ index filename is
+ <filename><replaceable>host_name</replaceable>-relay-bin.index</filename>.
</para>
- </section>
+ <para>
+ By default, the slave server creates relay log files in its data
+ directory. The default filenames can be overridden with the
+ <option>--relay-log</option> and
+ <option>--relay-log-index</option> server options. See
+ <xref linkend="replication-options"/>.
+ </para>
- <section id="slave-logs">
+ <para>
+ Relay logs have the same format as binary logs and can be read
+ using <command>mysqlbinlog</command>. The SQL thread
+ automatically deletes each relay log file as soon as it has
+ executed all events in the file and no longer needs it. There is
+ no explicit mechanism for deleting relay logs because the SQL
+ thread takes care of doing so. However, <literal>FLUSH
+ LOGS</literal> rotates relay logs, which influences when the SQL
+ thread deletes them.
+ </para>
- <title>Replication Relay and Status Files</title>
-
<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:
+ A slave server creates a new relay log file under the following
+ conditions:
</para>
<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.
+ Each time the I/O thread starts.
</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.
+ When the logs are flushed; for example, with <literal>FLUSH
+ LOGS</literal> or <command>mysqladmin flush-logs</command>.
</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.
+ When the size of the current relay log file becomes too
+ large. The meaning of <quote>too large</quote> is determined
+ as follows:
</para>
- </listitem>
- </itemizedlist>
+ <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>
+ <listitem>
+ <para>
+ If the value of <literal>max_relay_log_size</literal> is
+ greater than 0, that is the maximum relay log file size.
+ </para>
+ </listitem>
- <section id="slave-logs-relaylog">
+ <listitem>
+ <para>
+ If the value of <literal>max_relay_log_size</literal> is
+ 0, <literal>max_binlog_size</literal> determines the
+ maximum relay log file size.
+ </para>
+ </listitem>
- <title>The Slave Relay Log</title>
+ </itemizedlist>
+ </listitem>
- <para>
- By default, relay logs filenames have the form
- <filename><replaceable>host_name</replaceable>-relay-bin.<replaceable>nnnnnn</replaceable></filename>,
- where <replaceable>host_name</replaceable> is the name of the
- slave server host and <replaceable>nnnnnn</replaceable> is a
- sequence number. Successive relay log files are created using
- successive sequence numbers, beginning with
- <literal>000001</literal>. The slave uses an index file to
- track the relay log files currently in use. The default relay
- log index filename is
- <filename><replaceable>host_name</replaceable>-relay-bin.index</filename>.
- </para>
+ </itemizedlist>
- <para>
- By default, the slave server creates relay log files in its
- data directory. The default filenames can be overridden with
- the <option>--relay-log</option> and
- <option>--relay-log-index</option> server options. See
- <xref linkend="replication-options"/>.
- </para>
+ </section>
- <para>
- Relay logs have the same format as binary logs and can be read
- using <command>mysqlbinlog</command>. The SQL thread
- automatically deletes each relay log file as soon as it has
- executed all events in the file and no longer needs it. There
- is no explicit mechanism for deleting relay logs because the
- SQL thread takes care of doing so. However, <literal>FLUSH
- LOGS</literal> rotates relay logs, which influences when the
- SQL thread deletes them.
- </para>
+ <section id="slave-logs-status">
- <para>
- A slave server creates a new relay log file under the
- following conditions:
- </para>
+ <title>The Slave Status Files</title>
- <itemizedlist>
+ <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
+ <filename>relay-log.info</filename> by default. Their names can
+ be changed by using the <option>--master-info-file</option> and
+ <option>--relay-log-info-file</option> options. See
+ <xref linkend="replication-options"/>.
+ </para>
- <listitem>
- <para>
- Each time the I/O thread starts.
- </para>
- </listitem>
+ <para>
+ The two status files contain information like that shown in the
+ output of the <literal>SHOW SLAVE STATUS</literal> statement,
+ which is discussed in <xref linkend="replication-slave-sql"/>.
+ Because the status files are stored on disk, they survive a
+ slave server's shutdown. The next time the slave starts up, it
+ reads the two files to determine how far it has proceeded in
+ reading binary logs from the master and in processing its own
+ relay logs.
+ </para>
- <listitem>
- <para>
- When the logs are flushed; for example, with
- <literal>FLUSH LOGS</literal> or <command>mysqladmin
- flush-logs</command>.
- </para>
- </listitem>
+ <para>
+ The I/O thread updates the <filename>master.info</filename>
+ file. The following table shows the correspondence between the
+ lines in the file and the columns displayed by <literal>SHOW
+ SLAVE STATUS</literal>.
+ </para>
- <listitem>
- <para>
- When the size of the current relay log file becomes too
- large. The meaning of <quote>too large</quote> is
- determined as follows:
- </para>
+ <informaltable>
+ <tgroup cols="3">
+ <colspec colwidth="15*"/>
+ <colspec colwidth="35*"/>
+ <colspec colwidth="50*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Line</emphasis></entry>
+ <entry><emphasis role="bold">Status Column</emphasis></entry>
+ <entry><emphasis role="bold">Description</emphasis></entry>
+ </row>
+ <row>
+ <entry>1</entry>
+ <entry/>
+ <entry>Number of lines in the file</entry>
+ </row>
+ <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>
+ </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>
+ </row>
+ <row>
+ <entry>4</entry>
+ <entry><literal>Master_Host</literal></entry>
+ <entry>The hostname of the master.</entry>
+ </row>
+ <row>
+ <entry>5</entry>
+ <entry><literal>Master_User</literal></entry>
+ <entry>The username used to connect to the master.</entry>
+ </row>
+ <row>
+ <entry>6</entry>
+ <entry>Password (not shown by <literal>SHOW SLAVE STATUS</literal>)</entry>
+ <entry>The password used to connect to the master.</entry>
+ </row>
+ <row>
+ <entry>7</entry>
+ <entry><literal>Master_Port</literal></entry>
+ <entry>The network port used to connect to the master.</entry>
+ </row>
+ <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>
+ </row>
+ <row>
+ <entry>9</entry>
+ <entry><literal>Master_SSL_Allowed</literal></entry>
+ <entry>Indicates whether the server supports SSL connections.</entry>
+ </row>
+ <row>
+ <entry>10</entry>
+ <entry><literal>Master_SSL_CA_File</literal></entry>
+ <entry>The file used for the Certificate Authority (CA) certificate.</entry>
+ </row>
+ <row>
+ <entry>11</entry>
+ <entry><literal>Master_SSL_CA_Path</literal></entry>
+ <entry>The path to the Certificate Authority (CA) certificates.</entry>
+ </row>
+ <row>
+ <entry>12</entry>
+ <entry><literal>Master_SSL_Cert</literal></entry>
+ <entry>The name of the SSL certificate file.</entry>
+ </row>
+ <row>
+ <entry>13</entry>
+ <entry><literal>Master_SSL_Cipher</literal></entry>
+ <entry>The name of the cipher in use for the SSL connection.</entry>
+ </row>
+ <row>
+ <entry>14</entry>
+ <entry><literal>Master_SSL_Key</literal></entry>
+ <entry>The name of the SSL key file.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
- <itemizedlist>
+ <para>
+ The SQL thread updates the <filename>relay-log.info</filename>
+ file. The following table shows the correspondence between the
+ lines in the file and the columns displayed by <literal>SHOW
+ SLAVE STATUS</literal>.
+ </para>
- <listitem>
- <para>
- If the value of <literal>max_relay_log_size</literal>
- is greater than 0, that is the maximum relay log file
- size.
- </para>
- </listitem>
+ <informaltable>
+ <tgroup cols="3">
+ <colspec colwidth="15*"/>
+ <colspec colwidth="35*"/>
+ <colspec colwidth="50*"/>
+ <tbody>
+ <row>
+ <entry><emphasis role="bold">Line</emphasis></entry>
+ <entry><emphasis role="bold">Status Column</emphasis></entry>
+ <entry><emphasis role="bold">Description</emphasis></entry>
+ </row>
+ <row>
+ <entry>1</entry>
+ <entry><literal>Relay_Log_File</literal></entry>
+ <entry>The name of the current relay log file.</entry>
+ </row>
+ <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>
+ </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>
+ </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>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
- <listitem>
- <para>
- If the value of <literal>max_relay_log_size</literal>
- is 0, <literal>max_binlog_size</literal> determines
- the maximum relay log file size.
- </para>
- </listitem>
+ <para>
+ The contents of the <filename>relay-log.info</filename> file and
+ the states shown by the <literal>SHOW SLAVE STATES</literal>
+ command may not match if the <filename>relay-log.info</filename>
+ file has not been flushed to disk. Ideally, you should only view
+ <filename>relay-log.info</filename> on a slave that is offline
+ (i.e. <literal>mysqld</literal> is not running). For a running
+ system, <literal>SHOW SLAVE STATUS</literal> should be used.
+ </para>
- </itemizedlist>
- </listitem>
-
- </itemizedlist>
-
- </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
- <filename>relay-log.info</filename> by default. Their names
- can be changed by using the
- <option>--master-info-file</option> and
- <option>--relay-log-info-file</option> options. See
- <xref linkend="replication-options"/>.
- </para>
-
- <para>
- The two status files contain information like that shown in
- the output of the <literal>SHOW SLAVE STATUS</literal>
- statement, which is discussed in
- <xref linkend="replication-slave-sql"/>. Because the status
- files are stored on disk, they survive a slave server's
- shutdown. The next time the slave starts up, it reads the two
- files to determine how far it has proceeded in reading binary
- logs from the master and in processing its own relay logs.
- </para>
-
- <para>
- The I/O thread updates the <filename>master.info</filename>
- file. The following table shows the correspondence between the
- lines in the file and the columns displayed by <literal>SHOW
- SLAVE STATUS</literal>.
- </para>
-
- <informaltable>
- <tgroup cols="3">
- <colspec colwidth="15*"/>
- <colspec colwidth="35*"/>
- <colspec colwidth="50*"/>
- <tbody>
- <row>
- <entry><emphasis role="bold">Line</emphasis></entry>
- <entry><emphasis role="bold">Status Column</emphasis></entry>
- <entry><emphasis role="bold">Description</emphasis></entry>
- </row>
- <row>
- <entry>1</entry>
- <entry/>
- <entry>Number of lines in the file</entry>
- </row>
- <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>
- </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>
- </row>
- <row>
- <entry>4</entry>
- <entry><literal>Master_Host</literal></entry>
- <entry>The hostname of the master.</entry>
- </row>
- <row>
- <entry>5</entry>
- <entry><literal>Master_User</literal></entry>
- <entry>The username used to connect to the master.</entry>
- </row>
- <row>
- <entry>6</entry>
- <entry>Password (not shown by <literal>SHOW SLAVE STATUS</literal>)</entry>
- <entry>The password used to connect to the master.</entry>
- </row>
- <row>
- <entry>7</entry>
- <entry><literal>Master_Port</literal></entry>
- <entry>The network port used to connect to the master.</entry>
- </row>
- <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>
- </row>
- <row>
- <entry>9</entry>
- <entry><literal>Master_SSL_Allowed</literal></entry>
- <entry>Indicates whether the server supports SSL connections.</entry>
- </row>
- <row>
- <entry>10</entry>
- <entry><literal>Master_SSL_CA_File</literal></entry>
- <entry>The file used for the Certificate Authority (CA) certificate.</entry>
- </row>
- <row>
- <entry>11</entry>
- <entry><literal>Master_SSL_CA_Path</literal></entry>
- <entry>The path to the Certificate Authority (CA) certificates.</entry>
- </row>
- <row>
- <entry>12</entry>
- <entry><literal>Master_SSL_Cert</literal></entry>
- <entry>The name of the SSL certificate file.</entry>
- </row>
- <row>
- <entry>13</entry>
- <entry><literal>Master_SSL_Cipher</literal></entry>
- <entry>The name of the cipher in use for the SSL connection.</entry>
- </row>
- <row>
- <entry>14</entry>
- <entry><literal>Master_SSL_Key</literal></entry>
- <entry>The name of the SSL key file.</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>
- The SQL thread updates the <filename>relay-log.info</filename>
- file. The following table shows the correspondence between the
- lines in the file and the columns displayed by <literal>SHOW
- SLAVE STATUS</literal>.
- </para>
-
- <informaltable>
- <tgroup cols="3">
- <colspec colwidth="15*"/>
- <colspec colwidth="35*"/>
- <colspec colwidth="50*"/>
- <tbody>
- <row>
- <entry><emphasis role="bold">Line</emphasis></entry>
- <entry><emphasis role="bold">Status Column</emphasis></entry>
- <entry><emphasis role="bold">Description</emphasis></entry>
- </row>
- <row>
- <entry>1</entry>
- <entry><literal>Relay_Log_File</literal></entry>
- <entry>The name of the current relay log file.</entry>
- </row>
- <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>
- </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>
- </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>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>
- The contents of the <filename>relay-log.info</filename> file
- and the states shown by the <literal>SHOW SLAVE
- STATES</literal> command may not match if the
- <filename>relay-log.info</filename> file has not been flushed
- to disk. Ideally, you should only view
- <filename>relay-log.info</filename> on a slave that is offline
- (i.e. <literal>mysqld</literal> is not running). For a running
- system, <literal>SHOW SLAVE STATUS</literal> should be used.
- </para>
-
- </section>
-
</section>
</section>
Modified: branches/repupdate/5.1/replication-solutions.xml
===================================================================
--- branches/repupdate/5.1/replication-solutions.xml 2007-02-06 14:24:46 UTC (rev 4811)
+++ branches/repupdate/5.1/replication-solutions.xml 2007-02-06 14:49:51 UTC (rev 4812)
Changed blocks: 6, Lines Added: 11, Lines Deleted: 11; 3142 bytes
@@ -337,10 +337,10 @@
to communicate with the replication master when a write is
required. You can see a sample replication layout for this
scenario in <xref
- linkend="figure-replication-scaleout"/>.
+ linkend="figure_replication-scaleout"/>.
</para>
- <figure id="figure-replication-scaleout">
+ <figure id="figure_replication-scaleout">
<title>Using replication to improve the performance during scaleout</title>
<mediaobject>
<imageobject>
@@ -441,10 +441,10 @@
you may want to distribute different sales data to different
departments to help spread the load during data analysis. A sample
of this layout is shown in
- <xref linkend="figure-replication-multi-db"/>.
+ <xref linkend="figure_replication-multi-db"/>.
</para>
- <figure id="figure-replication-multi-db">
+ <figure id="figure_replication-multi-db">
<title>Using replication to replicate separate DBs to multiple hosts</title>
<mediaobject>
<imageobject>
@@ -470,7 +470,7 @@
<para>
For example, to support the separation as shown in
<xref
- linkend="figure-replication-multi-db"/>, you would
+ linkend="figure_replication-multi-db"/>, you would
configure each slave as follows before enabling replication using
<literal>START SLAVE</literal>:
</para>
@@ -572,10 +572,10 @@
connect to this primary slave for their individual replication
requirements. A sample of this structure is shown in
<xref
- linkend="figure-replication-performance"/>.
+ linkend="figure_replication-performance"/>.
</para>
- <figure id="figure-replication-performance">
+ <figure id="figure_replication-performance">
<title>Using an additional replication host to improve performance</title>
<mediaobject>
<imageobject>
@@ -720,10 +720,10 @@
and <literal>CHANGE MASTER TO</literal> statement on the other
slaves. For example, assume that you have the structure shown in
<xref
- linkend="figure-replication-redundancy-before"/>.
+ linkend="figure_replication-redundancy-before"/>.
</para>
- <figure id="figure-replication-redundancy-before">
+ <figure id="figure_replication-redundancy-before">
<title>Redundancy using replication, initial structure</title>
<mediaobject>
<imageobject>
@@ -824,10 +824,10 @@
<para>
The resulting server structure is shown in
<xref
- linkend="figure-replication-redundancy-after"/>.
+ linkend="figure_replication-redundancy-after"/>.
</para>
- <figure id="figure-replication-redundancy-after">
+ <figure id="figure_replication-redundancy-after">
<title>Redundancy using replication, after master failure</title>
<mediaobject>
<imageobject>
Modified: branches/repupdate/5.1/replication-topology.xml
===================================================================
--- branches/repupdate/5.1/replication-topology.xml 2007-02-06 14:24:46 UTC (rev 4811)
+++ branches/repupdate/5.1/replication-topology.xml 2007-02-06 14:49:51 UTC (rev 4812)
Changed blocks: 5, Lines Added: 6, Lines Deleted: 6; 1893 bytes
@@ -37,7 +37,7 @@
Replication with a single slave
</para>
- <figure id="figure-replication-slave-single">
+ <figure id="figure_replication-slave-single">
<title>Replication with a single slave</title>
<mediaobject>
<imageobject>
@@ -61,7 +61,7 @@
Replication with multiple slaves
</para>
- <figure id="figure-replication-slaves-multiple">
+ <figure id="figure_replication-slaves-multiple">
<title>Replication with multiple slaves</title>
<mediaobject>
<imageobject>
@@ -85,7 +85,7 @@
Replication with multiple masters
</para>
- <figure id="figure-replication-twinmaster">
+ <figure id="figure_replication-twinmaster">
<title>Replication with twin masters</title>
<mediaobject>
<imageobject>
@@ -197,10 +197,10 @@
relationship if you use the <option>--log-slave-updates</option>
option. That means that you can create a setup as shown in
<xref
- linkend="figure-replication-multimaster-chain"/>.
+ linkend="figure_replication-multimaster-chain"/>.
</para>
- <figure id="figure-replication-multimaster-circular">
+ <figure id="figure_replication-multimaster-circular">
<title>Replication with multiple masters in a circular topology</title>
<mediaobject>
<imageobject>
@@ -246,7 +246,7 @@
TODO
</para>
- <figure id="figure-replication-multimaster-chain">
+ <figure id="figure_replication-multimaster-chain">
<title>Replication with multiple masters in a chain topology</title>
<mediaobject>
<imageobject>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r4812 - branches/repupdate/5.1 | mcbrown | 6 Feb |
