MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:paul.dubois Date:November 14 2008 12:29am
Subject:svn commit - mysqldoc@docsrva: r12467 - in trunk: . refman-6.0
View as plain text  
Author: paul
Date: 2008-11-14 01:29:07 +0100 (Fri, 14 Nov 2008)
New Revision: 12467

Log:
 r35700@frost:  paul | 2008-11-13 18:29:04 -0500
 Add preliminary documentation for semisynchronous replication


Added:
   trunk/refman-6.0/semisync-repl-tmp.xml
Modified:
   trunk/refman-6.0/replication-solutions.xml

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:35693
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34365
   + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:35700
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34365


Modified: trunk/refman-6.0/replication-solutions.xml
===================================================================
--- trunk/refman-6.0/replication-solutions.xml	2008-11-14 00:15:10 UTC (rev 12466)
+++ trunk/refman-6.0/replication-solutions.xml	2008-11-14 00:29:07 UTC (rev 12467)
Changed blocks: 3, Lines Added: 12, Lines Deleted: 46; 4010 bytes

@@ -1559,41 +1559,6 @@
                     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 as MySQL <literal>root</literal> (or
-                    another user having the
-                    <literal role="priv">SUPER</literal> privilege):
-
-<programlisting>
-SET @@GLOBAL.MAX_CONNECTIONS = 1;
-</programlisting>
-                  </para>
-
-                  <para>
-                    Once this has been done, only a single client,
-                    having the <literal role="priv">SUPER</literal>
-                    privilege, may connect to C. This works because
-                    <literal>max_connections + 1</literal> clients are
-                    allowed to connect to the server, with one of these
-                    connections being reserved for a client having the
-                    <literal role="priv">SUPER</literal> privilege.
-                    Therefore, when <literal>max_connections</literal>
-                    is equal to 1, and no other clients are connected, a
-                    maximum of 1 client <emphasis>not</emphasis> having
-                    <literal role="priv">SUPER</literal> may connect.
-                    However, a client not having the
-                    <literal>SUPER</literal> privilege cannot use the
-                    extra connection. This means that, when
-                    <literal>max_connections</literal> is
-                    <literal>1</literal> and a client having
-                    <literal role="priv">SUPER</literal> is already
-                    connected, no
-                    non-<literal role="priv">SUPER</literal> clients may
-                    connect connect to the server.
-                  </para>
                 </listitem>
 
                 <listitem>

@@ -1783,12 +1748,13 @@
 
             <para>
               Start server C&apos;, 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=1</option>. (For
-              more information about these options, see
+              read-only mode. You can do this by starting
+              <command>mysqld</command> with the
+              <option>--read_only</option> option. Using this option
+              allows only slave threads or clients having the
+              <literal role="priv">SUPER</literal> privilege to perform
+              any updates on the server. (For more information about
+              this option, see
               <xref linkend="server-system-variables"/>.)
             </para>
 

@@ -1972,11 +1938,11 @@
 
             <para>
               This can be done by setting
-              <literal>@@GLOBAL.MAX_CONNECTIONS</literal> to an
-              appropriate value greater than <literal>1</literal>,
-              thereby once again permitting regular clients not having
-              the <literal role="priv">SUPER</literal> privilege to
-              connect.
+              <literal>@@GLOBAL.READ_ONLY</literal> to
+              <literal>0</literal> or <literal>OFF</literal>, thereby
+              permitting regular clients other than those having the
+              <literal role="priv">SUPER</literal> privilege once again
+              to connect.
             </para>
 
           </formalpara>


Added: trunk/refman-6.0/semisync-repl-tmp.xml
===================================================================
--- trunk/refman-6.0/semisync-repl-tmp.xml	                        (rev 0)
+++ trunk/refman-6.0/semisync-repl-tmp.xml	2008-11-14 00:29:07 UTC (rev 12467)
Changed blocks: 1, Lines Added: 558, Lines Deleted: 0; 18418 bytes

@@ -0,0 +1,558 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY % all.entities SYSTEM "all-entities.ent">
+  %all.entities;
+]>
+<section id="replication-semisync">
+
+  <title>Semisynchronous Replication</title>
+
+  <indexterm>
+    <primary>semisynchronous replication</primary>
+  </indexterm>
+
+  <indexterm>
+    <primary>replication</primary>
+    <secondary>semisynchronous</secondary>
+  </indexterm>
+
+  <para>
+    MySQL 6.0.x and up supports semisynchronous replication in addition
+    to asynchronous replication. This section discusses what
+    semisynchronous replication is and how it works. The following
+    sections cover the adminstrative interface to semisynchronous
+    replication and how to install, configure, and monitor it.
+  </para>
+
+  <para>
+    MySQL replication by default is asynchronous. The master writes
+    events to its binary log but does not know whether or when a slave
+    has retrieved and processed them. With asynchronous replication, if
+    the master crashes, transactions that it has committed might not
+    have been transmitted to any slave. Consequently, failover from
+    master to slave in this case may result in failover to a server that
+    is missing transactions relative to the master.
+  </para>
+
+  <para>
+    As of MySQL 6.0.x, semisynchronous replication can be used instead:
+  </para>
+
+  <itemizedlist>
+
+    <listitem>
+      <para>
+        A slave indicates whether it is semisynchronous-capable when it
+        connects to the master.
+      </para>
+    </listitem>
+
+    <listitem>
+      <para>
+        When semisynchronous replication is enabled on the master side
+        and there is at least one semisynchronous slave, a thread that
+        performs a transaction commit on the master blocks after the
+        commit is done and waits until at least one semisynchronous
+        slave acknowledges that it has received all events for the
+        transaction, or until a timeout occurs.
+      </para>
+    </listitem>
+
+    <listitem>
+      <para>
+        The slave acknowledges receipt of a transaction's events only
+        after the events have been written to the relay log and flushed
+        to disk.
+      </para>
+    </listitem>
+
+    <listitem>
+      <para>
+        If a timeout occurs without any slave having acknowledged the
+        transaction, the master reverts to asynchronous replication.
+        When at least one semisynchronous slave catches up, the master
+        returns to semisynchronous replication.
+      </para>
+    </listitem>
+
+    <listitem>
+      <para>
+        Semisynchronous replication must be enabled on both the master
+        and slave sides. If semisynchronous replication is disabled on
+        the master, or enabled on the master but on no slaves, the
+        master uses asynchronous replication.
+      </para>
+    </listitem>
+
+  </itemizedlist>
+
+  <para>
+    While the master is blocking (waiting for acknowledgment from a
+    slave after having performed a commit), it does not return to the
+    session that performed the transaction. When the block ends, the
+    master returns to the session, which then can proceed to execute
+    other statements. At this point, the transaction has committed on
+    the master side, and receipt of its events has been acknowledged by
+    at least one slave.
+  </para>
+
+  <para>
+    Blocking also occurs after rollbacks that are written to the binary
+    log, which occurs when a transaction that modifies non-transactional
+    tables is rolled back. The rolled-back transaction is logged because
+    it modifies the non-transactional tables even though it has no
+    effect for transactional tables.
+  </para>
+
+  <para>
+    For statements that do not occur in transactional context (that is,
+    when no transaction has been started with
+    <literal role="stmt" condition="commit">START TRANSACTION</literal>
+    or <literal>SET AUTOCOMMIT = 0</literal>), autocommit is enabled and
+    each statement commits implicitly. With semisynchronous replication,
+    the master blocks for each such statement, just as it does for
+    explicit transaction commits.
+  </para>
+
+  <para>
+    To understand what the <quote>semi</quote> in <quote>semisynchronous
+    replication</quote> means, compare it with asynchronous and fully
+    synchronous replication:
+  </para>
+
+  <itemizedlist>
+
+    <listitem>
+      <para>
+        With asynchronous replication, the master writes events to its
+        binary log and slaves request them when they are ready. There is
+        no guarantee that any event will ever reach any slave.
+      </para>
+    </listitem>
+
+    <listitem>
+      <para>
+        With fully synchronous replication, when a master commits a
+        transaction, all slaves also will have committed the transaction
+        before the master returns to the session that performed the
+        transaction. The drawback of this is that there can be a lot of
+        delay to complete a transaction.
+      </para>
+    </listitem>
+
+    <listitem>
+      <para>
+        Semisynchronous replication falls between asynchronous and fully
+        synchronous replication. The master waits only until at least
+        one slave has received and logged the events. It does not wait
+        for all slaves to acknowledge receipt, and it requires only
+        receipt, not that the events have been processed and committed
+        on the slave side.
+      </para>
+    </listitem>
+
+  </itemizedlist>
+
+  <para>
+    Compared to asynchronous replication, semisynchronous replication
+    provides improved data integrity. When a commit returns, it is known
+    that the data exists in at least two places. If the master crashes
+    after having committed a transaction, at least one slave is
+    guaranteed to have received it.
+  </para>
+
+  <para>
+    Semisynchronous replication does have some performance impact
+    because commits are slower due to the need to wait for slaves. This
+    is the tradeoff for increased data integrity. The amount of slowdown
+    is at least the TCP/IP roundtrip time to send the commit to the
+    slave and wait for the acknowledgment of receipt by the slave. This
+    means that semisynchronous replication works best for close servers
+    communicating over fast networks, and worst for distant servers
+    communicating over slow networks.
+  </para>
+
+  <section id="replication-semisync-interface">
+
+    <title>Semisynchronous Replication Administrative Interface</title>
+
+    <indexterm>
+      <primary>semisynchronous replication</primary>
+      <secondary>administrative interface</secondary>
+    </indexterm>
+
+    <para>
+      The administrative interface to semisynchronous replication has
+      several components:
+    </para>
+
+    <para>
+      Two plugins implement semisynchronous capability. There is one
+      plugin for the master side and one for the slave side.
+    </para>
+
+    <para>
+      System variables control plugin behavior:
+    </para>
+
+    <itemizedlist>
+
+      <listitem>
+        <para>
+          <literal>rpl_semi_sync_master_enabled</literal>
+        </para>
+
+        <para>
+          Controls whether semisynchronous replication is enabled on the
+          master. To enable or disable the plugin, set this variable to
+          1 or 0, respectively. The default is 0.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>rpl_semi_sync_slave_enabled</literal>
+        </para>
+
+        <para>
+          Similar, but controls the slave plugin.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>rpl_semi_sync_master_timeout</literal>
+        </para>
+
+        <para>
+          A value in seconds that controls how long the master waits on
+          a commit for acknowledgment from a slave before timing out and
+          reverting to asynchronous replication. The default value is 10
+          seconds.
+        </para>
+      </listitem>
+
+    </itemizedlist>
+
+    <para>
+      Status variables enable semisynchronous replication monitoring:
+    </para>
+
+    <itemizedlist>
+
+      <listitem>
+        <para>
+          <literal>Rpl_semi_sync_master_clients</literal>
+        </para>
+
+        <para>
+          The number of semisynchronous slaves.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>Rpl_semi_sync_master_status</literal>
+        </para>
+
+        <para>
+          Whether semisynchronous replication currently is operational
+          on the master. This is 1 if the plugin has been enabled and a
+          commit acknowledgment has not occurred. It is 0 if the plugin
+          is not enabled or the master has falled back to asynchronous
+          replication due to commit acknowledgment timeout.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>Rpl_semi_sync_master_no_tx</literal>
+        </para>
+
+        <para>
+          The number of commits that were not acknowledged successfully.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>Rpl_semi_sync_master_yes_tx</literal>
+        </para>
+
+        <para>
+          The number of commits that were acknowledged successfully.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>Rpl_semi_sync_slave_status</literal>
+        </para>
+
+        <para>
+          Whether semisynchronous replication currently is operational
+          on the slave. This is 1 if the plugin has been enabled and the
+          slave I/O thread is running, 0 otherwise.
+        </para>
+      </listitem>
+
+    </itemizedlist>
+
+    <para>
+      The system and status variables are unavailable unless the
+      appropriate master or slave plugin has been installed with
+      <literal role="stmt">INSTALL PLUGIN</literal>.
+    </para>
+
+  </section>
+
+  <section id="replication-semisync-installation">
+
+    <title>Semisynchronous Replication Installation, Configuration, and Monitoring</title>
+
+    <indexterm>
+      <primary>semisynchronous replication</primary>
+      <secondary>installation</secondary>
+    </indexterm>
+
+    <indexterm>
+      <primary>semisynchronous replication</primary>
+      <secondary>configuration</secondary>
+    </indexterm>
+
+    <indexterm>
+      <primary>semisynchronous replication</primary>
+      <secondary>monitoring</secondary>
+    </indexterm>
+
+    <para>
+      Semisynchronous replication is implemented using plugins, so the
+      plugins must be installed into the server to make them available.
+      After a plugin has been installed, you control it by means of the
+      system variables associated with it. (These system variables are
+      not available until the associated plugin has been installed.)
+    </para>
+
+    <para>
+      Semisynchronous replication is available beginning with MySQL
+      6.0.x. The plugins are included in MySQL binary distributions. If
+      you build MySQL from source, the plugins will be compiled and
+      installed along with the rest of the distribution; no special
+      configuration options are required.
+    </para>
+
+    <para>
+      Currently, the plugins are available only on Unix. Windows is not
+      yet supported.
+    </para>
+
+    <para>
+      To set up semisynchronous replication, use the following
+      procedure. These instructions assume that you already have a
+      working replication set up. If you do not, see
+      <xref linkend="replication-howto"/>, for information on setting up
+      a master/slave relationship.
+    </para>
+
+    <para>
+      The <literal role="stmt">INSTALL PLUGIN</literal>,
+      <literal role="stmt" condition="set-option">SET GLOBAL</literal>,
+      <literal role="stmt">STOP SLAVE</literal>, and
+      <literal role="stmt">START SLAVE</literal> statements mentioned in
+      these instructions require the
+      <literal role="priv">SUPER</literal> privilege.
+    </para>
+
+    <para>
+      To load the plugins, use <literal role="stmt">INSTALL
+      PLUGIN</literal> on the master and on each slave that is to be
+      semisynchronous.
+    </para>
+
+    <para>
+      On the master:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>INSTALL PLUGIN rpl_semi_sync_master SONAME 'libsemisync_master.so';</userinput>
+</programlisting>
+
+    <para>
+      On each slave:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>INSTALL PLUGIN rpl_semi_sync_slave SONAME 'libsemisync_slave.so';</userinput>
+</programlisting>
+
+    <para>
+      The preceding commands use a plugin filename suffix of
+      <filename>.so</filename>. A different suffix might apply on your
+      system. If you are not sure about the plugin filename, look for
+      the plugins in the directory named by the server's
+      <literal>plugin_dir</literal> system variable.
+    </para>
+
+    <para>
+      To see which plugins are installed, use the
+      <literal role="stmt">SHOW PLUGINS</literal> statement, or query
+      the <literal role="is">INFORMATION_SCHEMA.PLUGINS</literal> table.
+    </para>
+
+    <para>
+      [At this point, system/status variables become visible]
+    </para>
+
+    <para>
+      After a plugin has been installed, you can enable it. This must be
+      done both on the master side and the slave side to enable
+      semisynchronous replication. If semisynchronous replication is
+      enabled only on one side, replication will be asynchronous.
+    </para>
+
+    <para>
+      [I found that simply installing the plugin enabled it, at least on
+      the master side]
+    </para>
+
+    <para>
+      To control an installed plugin, set the appropriate system
+      variables. You can set these variables at runtime using
+      <literal role="stmt" condition="set-option">SET GLOBAL</literal>,
+      or at server startup on the command line or in an option file.
+    </para>
+
+    <para>
+      At runtime, these master-side system variables are available:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>SET GLOBAL rpl_semi_sync_master_enabled = {0|1};</userinput>
+mysql&gt; <userinput>SET GLOBAL rpl_semi_sync_master_timeout = <replaceable>N</replaceable>;</userinput>
+</programlisting>
+
+    <para>
+      On the slave side, this system variable is available:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>SET GLOBAL rpl_semi_sync_slave_enabled = {0|1};</userinput>
+</programlisting>
+
+    <para>
+      For <literal>rpl_semi_sync_master_enabled</literal> or
+      <literal>rpl_semi_sync_slave_enabled</literal>, the value should
+      be 1 to enable semisynchronous replication or 0 to disable it. By
+      default, these variables are set to 0.
+    </para>
+
+    <para>
+      For <literal>rpl_semi_sync_master_timeout</literal>, the value
+      <replaceable>N</replaceable> is given in seconds. The default
+      value is 10.
+    </para>
+
+    <para>
+      If you enable semisynchronous replication on a slave at runtime,
+      you must also start the slave I/O thread (stopping it first if it
+      is already running) to cause the slave to connect to the master
+      and register as a semisynchronous slave:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;</userinput>
+</programlisting>
+
+    <para>
+      If the I/O thread is already running and you do not restart it,
+      the slave continues to use asynchronous replication.
+    </para>
+
+    <para>
+      At server startup, the variables that control semisynchronous
+      replication can be set as command-line options or in an option
+      file. A setting listed in an option file takes effect each time
+      the server starts. For example, you can set the variables in
+      my.cnf files on the master and slave sides like this:
+    </para>
+
+    <para>
+      On the master:
+    </para>
+
+<programlisting>
+[mysqld]
+rpl_semi_sync_master_enabled=1
+rpl_semi_sync_master_timeout=10
+</programlisting>
+
+    <para>
+      On each slave:
+    </para>
+
+<programlisting>
+[mysqld]
+rpl_semi_sync_slave_enabled=1
+</programlisting>
+
+    <para>
+      To check the values of the semisynchronous replication system
+      variables (regardless of whether you set them at startup or at
+      runtime), use <literal role="stmt">SHOW VARIABLES</literal>:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>SHOW VARIABLES LIKE 'rpl_semi_sync%';</userinput>
+</programlisting>
+
+    <para>
+      The plugins expose several status variables that enable you to
+      monitor the operation of semisynchronous replication.
+    </para>
+
+    <para>
+      When the master switches between asynchronous or semisynchronous
+      replication due to commit-blocking timeout or a slave catching up,
+      it sets the value of the
+      <literal>Rpl_semi_sync_master_status</literal> status variable
+      appropriately. Automatic fallback from semisynchronous to
+      asynchronous replication on the master means that it is possible
+      for the <literal>rpl_semi_sync_master_enabled</literal> system
+      variable to have a value of 1 on the master side even when
+      semisynchronous replication is in fact not operational at the
+      moment. You can monitor the
+      <literal>Rpl_semi_sync_master_status</literal> status variable to
+      determine whether the master currently is using asynchronous or
+      semisynchronous replication.
+    </para>
+
+    <para>
+      To see how many semisynchronous slaves are connected, check
+      <literal>Rpl_semi_sync_master_clients</literal>.
+    </para>
+
+    <para>
+      The number of commits that have been acknowledged successfully or
+      unsucessfully by slaves are indicated by the
+      <literal>Rpl_semi_sync_master_yes_tx</literal> and
+      <literal>Rpl_semi_sync_master_no_tx</literal> variables.
+    </para>
+
+    <para>
+      On the slave side, <literal>Rpl_semi_sync_slave_status</literal>
+      indicates whether semisynchronous replication currently is
+      operational.
+    </para>
+
+    <para>
+      To check the values of the semisynchronous replication status
+      variables, use <literal role="stmt">SHOW STATUS</literal>:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>SHOW STATUS LIKE 'Rpl_semi_sync%';</userinput>
+</programlisting>
+
+  </section>
+
+</section>


Thread
svn commit - mysqldoc@docsrva: r12467 - in trunk: . refman-6.0paul.dubois14 Nov