Author: jstephens
Date: 2008-11-11 17:17:58 +0100 (Tue, 11 Nov 2008)
New Revision: 12411
Log:
Publish multi-master replication upgrade as new section of
replication-solutions (6.0 only for now)
Rebuild dependencies
Modified:
trunk/refman-6.0/Makefile.depends
trunk/refman-6.0/replication-solutions.xml
trunk/topic-guides/topics-6.0/Makefile.depends
Modified: trunk/refman-6.0/Makefile.depends
===================================================================
--- trunk/refman-6.0/Makefile.depends 2008-11-11 15:58:13 UTC (rev 12410)
+++ trunk/refman-6.0/Makefile.depends 2008-11-11 16:17:58 UTC (rev 12411)
Changed blocks: 6, Lines Added: 66, Lines Deleted: 0; 6960 bytes
@@ -1384,7 +1384,18 @@
../refman-common/images/published/mysql-vstudioplugin-4.png \
../refman-common/images/published/redundancy-after.png \
../refman-common/images/published/redundancy-before.png \
+ ../refman-common/images/published/rpl-circular-upgrade-1.png \
+ ../refman-common/images/published/rpl-circular-upgrade-2.png \
+ ../refman-common/images/published/rpl-circular-upgrade-3.png \
+ ../refman-common/images/published/rpl-circular-upgrade-4.png \
+ ../refman-common/images/published/rpl-circular-upgrade-5.png \
+ ../refman-common/images/published/rpl-circular-upgrade-6.png \
+ ../refman-common/images/published/rpl-circular-upgrade-7.png \
+ ../refman-common/images/published/rpl-circular-upgrade-8.png \
../refman-common/images/published/rpl-create-select-failure-rbr.png \
+ ../refman-common/images/published/rpl-multi-master-linear-1.png \
+ ../refman-common/images/published/rpl-multi-master-linear-2.png \
+ ../refman-common/images/published/rpl-multi-master-linear-3.png \
../refman-common/images/published/scaleout.png \
../refman-common/images/published/se-federated-structure.png \
../refman-common/images/published/stdlb.png \
@@ -1558,7 +1569,18 @@
../refman-common/images/published/mysql-vstudioplugin-4.png \
../refman-common/images/published/redundancy-after.png \
../refman-common/images/published/redundancy-before.png \
+ ../refman-common/images/published/rpl-circular-upgrade-1.png \
+ ../refman-common/images/published/rpl-circular-upgrade-2.png \
+ ../refman-common/images/published/rpl-circular-upgrade-3.png \
+ ../refman-common/images/published/rpl-circular-upgrade-4.png \
+ ../refman-common/images/published/rpl-circular-upgrade-5.png \
+ ../refman-common/images/published/rpl-circular-upgrade-6.png \
+ ../refman-common/images/published/rpl-circular-upgrade-7.png \
+ ../refman-common/images/published/rpl-circular-upgrade-8.png \
../refman-common/images/published/rpl-create-select-failure-rbr.png \
+ ../refman-common/images/published/rpl-multi-master-linear-1.png \
+ ../refman-common/images/published/rpl-multi-master-linear-2.png \
+ ../refman-common/images/published/rpl-multi-master-linear-3.png \
../refman-common/images/published/scaleout.png \
../refman-common/images/published/se-federated-structure.png \
../refman-common/images/published/stdlb.png \
@@ -2101,6 +2123,17 @@
../refman-common/images/published/multi-db.png \
../refman-common/images/published/redundancy-after.png \
../refman-common/images/published/redundancy-before.png \
+ ../refman-common/images/published/rpl-circular-upgrade-1.png \
+ ../refman-common/images/published/rpl-circular-upgrade-2.png \
+ ../refman-common/images/published/rpl-circular-upgrade-3.png \
+ ../refman-common/images/published/rpl-circular-upgrade-4.png \
+ ../refman-common/images/published/rpl-circular-upgrade-5.png \
+ ../refman-common/images/published/rpl-circular-upgrade-6.png \
+ ../refman-common/images/published/rpl-circular-upgrade-7.png \
+ ../refman-common/images/published/rpl-circular-upgrade-8.png \
+ ../refman-common/images/published/rpl-multi-master-linear-1.png \
+ ../refman-common/images/published/rpl-multi-master-linear-2.png \
+ ../refman-common/images/published/rpl-multi-master-linear-3.png \
../refman-common/images/published/scaleout.png \
../refman-common/images/published/submaster-performance.png \
../refman-common/urls.ent \
@@ -2110,6 +2143,17 @@
../refman-common/images/published/multi-db.png \
../refman-common/images/published/redundancy-after.png \
../refman-common/images/published/redundancy-before.png \
+ ../refman-common/images/published/rpl-circular-upgrade-1.png \
+ ../refman-common/images/published/rpl-circular-upgrade-2.png \
+ ../refman-common/images/published/rpl-circular-upgrade-3.png \
+ ../refman-common/images/published/rpl-circular-upgrade-4.png \
+ ../refman-common/images/published/rpl-circular-upgrade-5.png \
+ ../refman-common/images/published/rpl-circular-upgrade-6.png \
+ ../refman-common/images/published/rpl-circular-upgrade-7.png \
+ ../refman-common/images/published/rpl-circular-upgrade-8.png \
+ ../refman-common/images/published/rpl-multi-master-linear-1.png \
+ ../refman-common/images/published/rpl-multi-master-linear-2.png \
+ ../refman-common/images/published/rpl-multi-master-linear-3.png \
../refman-common/images/published/scaleout.png \
../refman-common/images/published/submaster-performance.png
replication_solutions_SOURCES = replication-solutions.xml $(replication_solutions_INCLUDES)
@@ -2136,7 +2180,18 @@
../refman-common/images/published/multi-db.png \
../refman-common/images/published/redundancy-after.png \
../refman-common/images/published/redundancy-before.png \
+ ../refman-common/images/published/rpl-circular-upgrade-1.png \
+ ../refman-common/images/published/rpl-circular-upgrade-2.png \
+ ../refman-common/images/published/rpl-circular-upgrade-3.png \
+ ../refman-common/images/published/rpl-circular-upgrade-4.png \
+ ../refman-common/images/published/rpl-circular-upgrade-5.png \
+ ../refman-common/images/published/rpl-circular-upgrade-6.png \
+ ../refman-common/images/published/rpl-circular-upgrade-7.png \
+ ../refman-common/images/published/rpl-circular-upgrade-8.png \
../refman-common/images/published/rpl-create-select-failure-rbr.png \
+ ../refman-common/images/published/rpl-multi-master-linear-1.png \
+ ../refman-common/images/published/rpl-multi-master-linear-2.png \
+ ../refman-common/images/published/rpl-multi-master-linear-3.png \
../refman-common/images/published/scaleout.png \
../refman-common/images/published/submaster-performance.png \
../refman-common/urls.ent \
@@ -2151,7 +2206,18 @@
../refman-common/images/published/multi-db.png \
../refman-common/images/published/redundancy-after.png \
../refman-common/images/published/redundancy-before.png \
+ ../refman-common/images/published/rpl-circular-upgrade-1.png \
+ ../refman-common/images/published/rpl-circular-upgrade-2.png \
+ ../refman-common/images/published/rpl-circular-upgrade-3.png \
+ ../refman-common/images/published/rpl-circular-upgrade-4.png \
+ ../refman-common/images/published/rpl-circular-upgrade-5.png \
+ ../refman-common/images/published/rpl-circular-upgrade-6.png \
+ ../refman-common/images/published/rpl-circular-upgrade-7.png \
+ ../refman-common/images/published/rpl-circular-upgrade-8.png \
../refman-common/images/published/rpl-create-select-failure-rbr.png \
+ ../refman-common/images/published/rpl-multi-master-linear-1.png \
+ ../refman-common/images/published/rpl-multi-master-linear-2.png \
+ ../refman-common/images/published/rpl-multi-master-linear-3.png \
../refman-common/images/published/scaleout.png \
../refman-common/images/published/submaster-performance.png
replication_SOURCES = replication.xml $(replication_INCLUDES)
Modified: trunk/refman-6.0/replication-solutions.xml
===================================================================
--- trunk/refman-6.0/replication-solutions.xml 2008-11-11 15:58:13 UTC (rev 12410)
+++ trunk/refman-6.0/replication-solutions.xml 2008-11-11 16:17:58 UTC (rev 12411)
Changed blocks: 1, Lines Added: 702, Lines Deleted: 0; 24974 bytes
@@ -1046,6 +1046,708 @@
</section>
+ <section id="replication-solutions-multi-master-upgrade">
+
+ <title>Upgrading Multi-Master Replication</title>
+
+ <para>
+ This section discusses how to upgrade the MySQL server software on
+ several machines in a multi-master replication setup from an older
+ version to a newer version of the software without taking the
+ entire system offline. The procedure outlined here is intended to
+ be illustrative and not necessarily to be followed exactly as
+ written in all possible scenarios.
+ </para>
+
+ <para>
+ There are two sorts of configurations for replication involving
+ multiple masters:
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>Linear replication</title>
+
+ <para>
+ In this type of setup, one or more masters replicates to a
+ single slave. The simplest linear replication topology is
+ shown here, where a single master A replicates to a single
+ slave B:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="500" contentdepth="150" fileref="../refman-common/images/published/rpl-multi-master-linear-1.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Simplest case: single master
+ replicates to single slave</phrase>
+ </textobject>
+ </mediaobject>
+ </para>
+
+ </formalpara>
+
+ <para>
+ Of greater interest are cases where we actually have
+ multiple masters. There are two variants. The first of these
+ involves multiple masters replicating to a single common
+ slave, as shown here, where servers A and B both replicate
+ to slave C:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="500" contentdepth="250" fileref="../refman-common/images/published/rpl-multi-master-linear-2.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Multiple masters replicate to common
+ slave</phrase>
+ </textobject>
+ </mediaobject>
+
+ Similarly, in a scenario which features a single master
+ replicating to several slaves, we need only upgrade all of
+ the slaves first, and then the master.
+ </para>
+
+ <para>
+ The other variant occurs when we have a chain of MySQL
+ servers, some of which are acting as both master and slaves.
+ The following diagram depicts server A replicating to B,
+ which in turn replicates to C; here, B acts as both a master
+ and a slave:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="500" contentdepth="150" fileref="../refman-common/images/published/rpl-multi-master-linear-3.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Several MySQL servers replicate to one
+ another in turn</phrase>
+ </textobject>
+ </mediaobject>
+ </para>
+
+ <para>
+ In all three of these cases, the procedure for performing a
+ software upgrade can be developed from the simple principle
+ <quote>upgrade the slave first, then the master</quote>. In
+ the first case, we should upgrade B before upgrading A; in
+ the second, we should upgrade C, then upgrade A and B (it
+ does not matter whether we upgrade A or B first); in the
+ third case, we start by upgrading the server that acts only
+ as a slave (C), then upgrading its master (B), and so on,
+ until we reach the server acting as a master only (A),
+ upgrade it, and so complete the process.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Circular replication</title>
+
+ <para>
+ In a circular replication setup, each MySQL server acts as
+ both a master and a slave; thus, there is no
+ <quote>last</quote> server which we can use as a starting
+ point to apply <quote>upgrade the slave first, then the
+ master</quote>. We therefore require a different approach
+ to performing the upgrade, and it is for this reason that
+ the rest of this section is devoted to a discussion of
+ upgrading the MySQL server software on several hosts
+ configured in a circular replication setup.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ <formalpara>
+
+ <title>Basic scenario</title>
+
+ <para>
+ Assume that we have three servers, A, B, and C, running MySQL
+ version ¤t-series;, replicating in a circle, as shown in
+ this diagram:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="375" contentdepth="375" fileref="../refman-common/images/published/rpl-circular-upgrade-1.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Circular replication with 3 MySQL
+ servers</phrase>
+ </textobject>
+ </mediaobject>
+
+ Our objective is to upgrade, in turn, all three machines from
+ one MySQL version (for example, MySQL 5.1) to a newer MySQL
+ version (such as MySQL 6.0) without taking the system as a whole
+ out of production. We start with server C, which acts as a slave
+ of server B and a master to server A.
+ </para>
+
+ </formalpara>
+
+ <para>
+ To upgrade this server, we need to perform the following steps:
+
+ <orderedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>Stop C</title>
+
+ <para>
+ On C, execute the statement
+
+<programlisting>
+STOP SLAVE;
+</programlisting>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Create a <quote>marker</quote> event on B</title>
+
+ <para>
+ Execute a statement on B that generates an event which is
+ easily identified. For this example, we assume that there
+ is no existing table named <literal>marker</literal> in
+ the <literal>test</literal> database, and perform the
+ following statements to create it:
+
+<programlisting>
+USE test;
+CREATE TABLE marker1 (col INT);
+</programlisting>
+
+ The table schema is completely arbitrary; in fact, the
+ statement is itself completely arbitrary. The only
+ requirement is that we use an SQL statement that is unique
+ and easily identifiable for use as the
+ <quote>marker</quote>.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Find the position of the marker in the binary log</title>
+
+ <para>
+ This can be done by executing <literal role="stmt">SHOW
+ BINLOG EVENTS</literal> on B, then checking the
+ <literal>Info</literal> column in the output for an event
+ containing the <quote>marker</quote> statement. Note the
+ values of the <literal>Log_name</literal> and
+ <literal>Pos</literal> columns, which are needed for the
+ next step, where we refer to these values as
+ <replaceable>fileB</replaceable> and
+ <replaceable>posB</replaceable>, respectively.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Allow C to catch up to the marker</title>
+
+ <para>
+ Execute the following statements on C:
+
+<programlisting>
+START SLAVE UNTIL
+ MASTER_LOG_FILE=<replaceable>fileB</replaceable>,
+ MASTER_LOG_POS=<replaceable>posB</replaceable>;
+
+SELECT MASTER_POS_WAIT(<replaceable>fileB</replaceable>, <replaceable>posB</replaceable>);
+</programlisting>
+
+ This causes C to execute any remaining events sent from B
+ up to the point where the <quote>marker</quote> statement
+ was issued, and then to stop. The place of the marker in
+ the sequence of events flowing from B to C is illustrated
+ here:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="475" contentdepth="450" fileref="../refman-common/images/published/rpl-circular-upgrade-2.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en"><quote>Marker</quote> event created
+ on server B in the flow of events from B to C</phrase>
+ </textobject>
+ </mediaobject>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Take server C offline</title>
+
+ <para>
+ Ensure that no further actions capable of updating the
+ binary log can be taken on C:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Redirect any clients using C to A or B. This is best
+ handled in application code. Additionally, you may
+ wish to use the <literal role="stmt">SHOW
+ PROCESSLIST</literal> and
+ <literal role="stmt">KILL</literal> statements to
+ terminate any remaining client processes other than
+ the one you are using to perform tasks on C relating
+ to the software upgrade.
+ </para>
+
+ <para>
+ You can prevent any application clients from
+ reconnecting to C by executing the following
+ statement:
+
+<programlisting>
+SET @@GLOBAL.MAX_CONNECTIONS = 0;
+</programlisting>
+
+ Once this has been done, only a single client,
+ having the <literal role="priv">SUPER</literal>
+ privilege, may connect to C.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Force all tables to be read-only by executing the
+ following statement:
+
+<programlisting>
+SET @@GLOBAL.READ_ONLY = ON;
+</programlisting>
+
+ As an alternative, you can use the following
+ statement, which is equivalent to the previous one:
+
+<programlisting>
+SET @@GLOBAL.READ_ONLY = 1;
+ </programlisting>
+
+ This places the server into <quote>read-only</quote>
+ mode, which prevents any accidental changes to
+ tables on C.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Stop the MySQL Event Scheduler on server C by
+ executing the following statement:
+
+<programlisting>
+SET @@GLOBAL.EVENT_SCHEDULER = OFF;
+</programlisting>
+
+ This is necessary since the Event Scheduler can
+ perform actions that result in writes to the binary
+ log, which could cause the binary log on C to
+ diverge from the binary logs on the other servers in
+ unexpected ways.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Find the end of the last binary log on C</title>
+
+ <para>
+ This can be accomplished by executing
+ <literal role="stmt">SHOW MASTER STATUS</literal> on C and
+ noting the values shown in the <literal>File</literal> and
+ <literal>Position</literal> columns of the output, which
+ we show as <replaceable>fileC</replaceable> and
+ <replaceable>posC</replaceable>, respectively, in the next
+ step.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Stop and synchronize slave A</title>
+
+ <para>
+ Execute <literal role="stmt">STOP SLAVE</literal> on A.
+ Then perform the following statements:
+
+<programlisting>
+START SLAVE UNTIL
+ MASTER_LOG_FILE=<replaceable>fileC</replaceable>,
+ MASTER_LOG_POS=<replaceable>posC</replaceable>;
+
+SELECT MASTER_POS_WAIT(<replaceable>fileC</replaceable>, <replaceable>posC</replaceable>);
+</programlisting>
+
+ This causes any remaining unprocessed events up the marker
+ event on C to be executed on A, and causes A to stop once
+ this has been done. The propagation of the marker from
+ server C to server A is shown here:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="475" contentdepth="475" fileref="../refman-common/images/published/rpl-circular-upgrade-3.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Marker event propagates from server
+ C to server A</phrase>
+ </textobject>
+ </mediaobject>
+
+ This is not the same marker as the previous one — in
+ fact, the best <quote>marker</quote> to use here is the
+ end of C's binary log.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Start replication from B to A</title>
+
+ <para>
+ You can cause A to replicate from B instead of from C by
+ issuing the following 2 statements on server A:
+
+<programlisting>
+CHANGE MASTER TO
+ MASTER_HOST=<replaceable>hostB</replaceable>,
+ MASTER_LOG_FILE=<replaceable>fileB</replaceable>,
+ MASTER_LOG_POS=<replaceable>posB</replaceable>;
+
+START SLAVE;
+</programlisting>
+
+ In the first of these statements,
+ <replaceable>hostB</replaceable> represents the hostname
+ or IP address for server B;
+ <replaceable>fileB</replaceable> and
+ <replaceable>posB</replaceable> are the same as determined
+ for these values earlier
+ </para>
+
+ </formalpara>
+
+ <para>
+ C is now isolated from the other two servers, which are now
+ replicating to each other, as shown here:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="500" contentdepth="575" fileref="../refman-common/images/published/rpl-circular-upgrade-4.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Servers A and B in mutual replication;
+ server C isolated</phrase>
+ </textobject>
+ </mediaobject>
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Upgrade C to C'</title>
+
+ <para>
+ Shut down C, and upgrade the MySQL software on C from
+ version X to version Y:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="450" contentdepth="575" fileref="../refman-common/images/published/rpl-circular-upgrade-5.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Upgrading Server C running MySQL
+ version X to C', running MySQL version Y</phrase>
+ </textobject>
+ </mediaobject>
+
+ We refer to the upgraded server C as
+ <emphasis>C'</emphasis>.
+ </para>
+
+ </formalpara>
+
+ <para>
+ For general information about performing upgrades, see the
+ <citetitle>Upgrading MySQL</citetitle> section of the
+ <citetitle>MySQL Manual</citetitle> corresponding to the
+ versions from which and to which you are upgrading.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Start C' in offline mode</title>
+
+ <para>
+ Start server C', insuring that all its tables are in
+ read-only mode, and that no MySQL clients (with the
+ exception of a single connection from a superuser account)
+ can connect to it. You can do this by starting
+ <command>mysqld</command> with the options
+ <option>--read_only --max_connections=0</option>. (For
+ more information about these options, see
+ <xref linkend="server-system-variables"/>.)
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Stop replicating from B to A</title>
+
+ <para>
+ Stop sending events from B to A, and ensure that A has
+ executed all events sent to it from B:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Issue a <literal role="stmt">STOP SLAVE</literal> on
+ A
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Issue a marker statement on B, such as this one:
+
+<programlisting>
+CREATE TABLE test.marker2 (col INT);
+</programlisting>
+
+ As with the previous marker statement, the type and
+ any other aspects of the statement are completely
+ arbitrary; the only requirement is that the
+ statement must be uniquely identifiable.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Use <literal role="stmt">SHOW BINLOG
+ EVENTS</literal> on B to find the binary log file
+ and position where the marker event was recorded, as
+ described previously. We use
+ <replaceable>fileB'</replaceable> and
+ <replaceable>posB'</replaceable> to denote
+ these in the next item.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Start server A and synchronize it with B by issuing
+ the following statements on A:
+
+<programlisting>
+START SLAVE UNTIL
+ MASTER_LOG_FILE=<replaceable>fileB'</replaceable>,
+ MASTER_LOG_POS=<replaceable>posB'</replaceable>;
+
+SELECT MASTER_POS_WAIT(<replaceable>fileB'</replaceable>, <replaceable>posB'</replaceable>);
+</programlisting>
+
+ Once A has executed all events up to and including
+ the second marker event, it stops, as shown here:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="450" contentdepth="575" fileref="../refman-common/images/published/rpl-circular-upgrade-6.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Second marker event propagates
+ from server B to server A</phrase>
+ </textobject>
+ </mediaobject>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Start replicating from B to C'</title>
+
+ <para>
+ Start sending events from B to C' and executing them
+ on C' (indicated by the dotted line in the next
+ diagram), ensuring that the first event not sent to A is
+ the first event sent to C'. You can do this by
+ issuing the following statements on C':
+
+<programlisting>
+SET @@GLOBAL.READ_ONLY = OFF;
+
+CHANGE MASTER TO
+ MASTER_HOST=<replaceable>hostB</replaceable>,
+ MASTER_LOG_FILE=<replaceable>fileB'</replaceable>,
+ MASTER_LOG_POS=<replaceable>posB'</replaceable>;
+
+START SLAVE;
+</programlisting>
+
+ Replication now occurs as shown here:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="400" contentdepth="400" fileref="../refman-common/images/published/rpl-circular-upgrade-7.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Server B now replicates to server
+ C'</phrase>
+ </textobject>
+ </mediaobject>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Start replicating from C' to A</title>
+
+ <para>
+ This can be done as follows:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Locate the file and position of the second marker
+ event in the binary log on server C'. This can
+ be found by issuing <literal role="stmt">SHOW BINLOG
+ EVENTS</literal> on C' as previously described.
+ </para>
+
+ <para>
+ We denote the file and position within this file as
+ <replaceable>fileC'</replaceable> and
+ <replaceable>posC'</replaceable>, respectively.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Start replication on A from this point by issuing
+ the following statements, where
+ <replaceable>hostC'</replaceable> represents
+ the hostname or IP address of server C', and
+ <replaceable>fileC'</replaceable> and
+ <replaceable>posC'</replaceable> are defined as
+ stated in the previous item:
+
+<programlisting>
+CHANGE MASTER TO
+ MASTER_HOST=<replaceable>hostC'</replaceable>,
+ MASTER_LOG_FILE=<replaceable>fileC'</replaceable>,
+ MASTER_LOG_POS=<replaceable>posC'</replaceable>;
+
+START SLAVE;
+</programlisting>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Return server C to online status</title>
+
+ <para>
+ This can be done by setting
+ <literal>@@GLOBAL.MAX_CONNECTIONS</literal> to an
+ appropriate value, thereby permitting regular clients not
+ having the <literal role="priv">SUPER</literal> privilege
+ once again to connect.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </orderedlist>
+ </para>
+
+ <para>
+ At this point, the original replication topology has been
+ restored, and all is as before, except that server C running MySQL
+ version X has been upgrade to C' running MySQL version Y, as
+ shown here:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata contentwidth="375" contentdepth="375" fileref="../refman-common/images/published/rpl-circular-upgrade-8.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">The circular replication topology is now
+ restored, with server A replicating to server B, server B
+ replicating to server C', and server C' replicating
+ to server A</phrase>
+ </textobject>
+ </mediaobject>
+
+ You can now complete the software upgrade process by repeating the
+ steps shown previously for servers A and B, each in turn.
+ </para>
+
+ </section>
+
<section id="replication-solutions-switch">
<title>Switching Masters During Failover</title>
Modified: trunk/topic-guides/topics-6.0/Makefile.depends
===================================================================
--- trunk/topic-guides/topics-6.0/Makefile.depends 2008-11-11 15:58:13 UTC (rev 12410)
+++ trunk/topic-guides/topics-6.0/Makefile.depends 2008-11-11 16:17:58 UTC (rev 12411)
Changed blocks: 3, Lines Added: 23, Lines Deleted: 1; 7812 bytes
@@ -277,7 +277,18 @@
../../refman-6.0/../refman-common/images/published/multi-db.png \
../../refman-6.0/../refman-common/images/published/redundancy-after.png \
../../refman-6.0/../refman-common/images/published/redundancy-before.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-1.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-2.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-3.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-4.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-5.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-6.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-7.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-8.png \
../../refman-6.0/../refman-common/images/published/rpl-create-select-failure-rbr.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-multi-master-linear-1.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-multi-master-linear-2.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-multi-master-linear-3.png \
../../refman-6.0/../refman-common/images/published/scaleout.png \
../../refman-6.0/../refman-common/images/published/submaster-performance.png \
../../refman-6.0/replication-configuration-core.xml \
@@ -297,7 +308,18 @@
../../refman-6.0/../refman-common/images/published/multi-db.png \
../../refman-6.0/../refman-common/images/published/redundancy-after.png \
../../refman-6.0/../refman-common/images/published/redundancy-before.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-1.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-2.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-3.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-4.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-5.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-6.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-7.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-8.png \
../../refman-6.0/../refman-common/images/published/rpl-create-select-failure-rbr.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-multi-master-linear-1.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-multi-master-linear-2.png \
+ ../../refman-6.0/../refman-common/images/published/rpl-multi-master-linear-3.png \
../../refman-6.0/../refman-common/images/published/scaleout.png \
../../refman-6.0/../refman-common/images/published/submaster-performance.png
mysql_replication_excerpt_SOURCES = mysql-replication-excerpt.xml $(mysql_replication_excerpt_INCLUDES)
@@ -575,7 +597,7 @@
$(RM) mysql-solaris-excerpt.xml mysql-solaris-excerpt-arbitrary.xml
$(MAKE) mysql-solaris-excerpt.xml
-mysql-replication-excerpt-aspec.xml.replication-configuration.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-implementation.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-notes.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-solutions.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication.all.preface.xml: ../../common/fixedchars.ent ../../common/phrases.ent ../../dynamic-docs/command-optvars/mysqld.xml ../../dynamic-docs/metadata-titles.en.xml ../../refman-6.0/replication-configuration-core.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication-implementation.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/../refman-common/images/published/rpl-create-select-failure-rbr.png ../../refman-6.0/replication-notes!
.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/../refman-common/images/published/multi-db.png ../../refman-6.0/../refman-common/images/published/redundancy-after.png ../../refman-6.0/../refman-common/images/published/redundancy-before.png ../../refman-6.0/../refman-common/images/published/scaleout.png ../../refman-6.0/../refman-common/images/published/submaster-performance.png ../../refman-6.0/replication-solutions.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent
+mysql-replication-excerpt-aspec.xml.replication-configuration.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-implementation.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-notes.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-solutions.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication.all.preface.xml: ../../common/fixedchars.ent ../../common/phrases.ent ../../dynamic-docs/command-optvars/mysqld.xml ../../dynamic-docs/metadata-titles.en.xml ../../refman-6.0/replication-configuration-core.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication-implementation.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/../refman-common/images/published/rpl-create-select-failure-rbr.png ../../refman-6.0/replication-notes!
.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/../refman-common/images/published/multi-db.png ../../refman-6.0/../refman-common/images/published/redundancy-after.png ../../refman-6.0/../refman-common/images/published/redundancy-before.png ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-1.png ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-2.png ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-3.png ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-4.png ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-5.png ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-6.png ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-7.png ../../refman-6.0/../refman-common/images/published/rpl-circular-upgrade-8.png ../../refman-6.0/../r!
efman-common/images/published/rpl-multi-master-linear-1.png ..!
/../refm
an-6.0/../refman-common/images/published/rpl-multi-master-linear-2.png ../../refman-6.0/../refman-common/images/published/rpl-multi-master-linear-3.png ../../refman-6.0/../refman-common/images/published/scaleout.png ../../refman-6.0/../refman-common/images/published/submaster-performance.png ../../refman-6.0/replication-solutions.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent
$(RM) mysql-replication-excerpt.xml mysql-replication-excerpt-arbitrary.xml
$(MAKE) mysql-replication-excerpt.xml
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12411 - in trunk: refman-6.0 topic-guides/topics-6.0 | jon | 11 Nov |
