Author: jstephens
Date: 2007-10-26 22:38:00 +0200 (Fri, 26 Oct 2007)
New Revision: 8349
Log:
Rewrite of Conflict Resolution section
(It's Bernie's fault... No, really!)
Modified:
trunk/refman-5.1/mysql-cluster-replication.xml
Modified: trunk/refman-5.1/mysql-cluster-replication.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-replication.xml 2007-10-26 19:48:38 UTC (rev 8348)
+++ trunk/refman-5.1/mysql-cluster-replication.xml 2007-10-26 20:38:00 UTC (rev 8349)
Changed blocks: 9, Lines Added: 467, Lines Deleted: 371; 39261 bytes
@@ -2231,49 +2231,52 @@
</para>
<para>
- In &mccge-series; releases beginning with MySQL 5.1.19-ndb-6.3.0,
- if the <quote>timestamp</quote> for a given row coming from the
- master is higher than that on the slave, it is applied; otherwise
- it is not applied on the slave. This ensures that, in the event of
- a conflict, the version of the row that was most recently updated
- is the version that persists.
+ Different methods can be used to compare <quote>timestamps</quote>
+ on the slave when conflicts occur, as explained later in this
+ section; the method used can be set on a per-table basis.
</para>
- <para>
- Beginning with MySQL 5.1.22-ndb-6.3.4, a second method of
- resolution is available: with this method, the update is applied
- only if the <quote>timestamp</quote> column is the same on both
- the master and the slave. This ensures that updates are not
- applied from the wrong master.
- </para>
+ <formalpara>
- <para>
- This replication scheme, also known as <quote>changed parameter
- only replication</quote>, is configurable on a per-table basis.
+ <title>Requirements</title>
- <itemizedlist>
+ <para>
+ Preparations for conflict resolution must be made on both the
+ master and the slave:
- <listitem>
- <para>
- On the master, it must be determined which columns to send
- (all columns or only those that have been updated).
- </para>
- </listitem>
+ <itemizedlist>
- <listitem>
- <para>
- On the slave, it must be determined which type of conflict
- resolution to apply (<quote>latest timestamp wins</quote>,
- <quote>same timestamp wins</quote>, or none).
- </para>
- </listitem>
+ <listitem>
+ <para>
+ On the master writing the binlogs, you must determine
+ which columns are sent (all columns or only those that
+ have been updated). This is done for the MySQL Server as a
+ while by applying the <command>mysqld</command> startup
+ option <option>-–ndb-log-updated-only</option>
+ (described later in this section) or on a per-table basis
+ by entries in the <literal>mysql.ndb_replication</literal>
+ table.
+ </para>
+ </listitem>
- </itemizedlist>
+ <listitem>
+ <para>
+ On the slave, you must determine which type of conflict
+ resolution to apply (<quote>latest timestamp wins</quote>,
+ <quote>same timestamp wins</quote>, or none). This is done
+ using the <literal>mysql.ndb_replication</literal> system
+ table, on a per-table basis.
+ </para>
+ </listitem>
- If only some but not all columns are sent, then the master and
- slave can diverge.
- </para>
+ </itemizedlist>
+ If only some but not all columns are sent, then the master and
+ slave can diverge.
+ </para>
+
+ </formalpara>
+
<note>
<para>
We refer to the column used for determining updates as a
@@ -2288,151 +2291,142 @@
<primary>--ndb-log-update-as-write (mysqld option)</primary>
</indexterm>
- <para>
- We can see update operations in terms of <quote>before</quote> and
- <quote>after</quote> images — that is, the states of the
- table before and after the update is applied. Normally, when
- updating a table with a primary key, the <quote>before</quote>
- image is not of great interest; however, when we need to determine
- on a per-update basis whether or not to use the updated values on
- a replication slave, we need to make sure that both images are
- written to the master's binary log. This is done with the
- <option>--ndb-log-update-as-write</option> startup option for
- <command>mysqld</command>, as described later in this section.
- </para>
+ <formalpara>
- <para>
- Whether logging of complete rows or of updated columns only is
- done is decided when the MySQL server is started, and cannot be
- changed online; you must either restart <command>mysqld</command>,
- or start a new <command>mysqld</command> instance with different
- logging options.
- </para>
+ <title>Master column control</title>
- <para>
- For purposes of conflict resolution, there are two basic methods
- of logging rows:
+ <para>
+ We can see update operations in terms of <quote>before</quote>
+ and <quote>after</quote> images — that is, the states of
+ the table before and after the update is applied. Normally, when
+ updating a table with a primary key, the <quote>before</quote>
+ image is not of great interest; however, when we need to
+ determine on a per-update basis whether or not to use the
+ updated values on a replication slave, we need to make sure that
+ both images are written to the master's binary log. This is done
+ with the <option>--ndb-log-update-as-write</option> startup
+ option for <command>mysqld</command>, as described later in this
+ section.
- <itemizedlist>
-
- <listitem>
+ <important>
<para>
- Log complete rows
+ Whether logging of complete rows or of updated columns only
+ is done is decided when the MySQL server is started, and
+ cannot be changed online; you must either restart
+ <command>mysqld</command>, or start a new
+ <command>mysqld</command> instance with different logging
+ options.
</para>
- </listitem>
+ </important>
+ </para>
- <listitem>
- <para>
- Log only column data that has been updated — that is,
- column data whose value has been set, regardless of whether
- or not this value was actually changed.
- </para>
- </listitem>
+ </formalpara>
- </itemizedlist>
+ <indexterm>
+ <primary>conflict resolution</primary>
+ <secondary>mysqld startup options</secondary>
+ </indexterm>
- Either of the above logging methods can be configured to be done
- with or without the <quote>before</quote> image.
- </para>
-
<formalpara>
- <title><command>mysqld</command> startup options</title>
+ <title>Logging full or partial rows (<option>--ndb-log-updated-only</option>
+ option)</title>
- <indexterm>
- <primary>conflict resolution</primary>
- <secondary>mysqld startup options</secondary>
- </indexterm>
-
<para>
- The following <command>mysqld</command> startup options are
- available to control conflict resolution:
+ For purposes of conflict resolution, there are two basic methods
+ of logging rows, as determined by the setting of the
+ <option>--ndb-log-updated-only</option> option for
+ <command>mysqld</command>:
<itemizedlist>
<listitem>
- <formalpara>
-
- <title><option>--ndb-log-update-as-write</option></title>
-
- <indexterm>
- <primary>--ndb-log-update-as-write (mysqld option)</primary>
- </indexterm>
-
- <para>
- Because conflict resolution is done in the MySQL
- Server's update handler, it is necessary to control
- logging on the master such that updates are updates and
- not writes as in in mainline MySQL 5.1. This option is
- turned on by default; to turn it off, start the server
- with <option>--ndb-log-update-as-write=0</option> or
- <option>--ndb-log-update-as-write=OFF</option>.
- </para>
-
- </formalpara>
+ <para>
+ Log complete rows
+ </para>
</listitem>
<listitem>
- <formalpara>
+ <para>
+ Log only column data that has been updated — that
+ is, column data whose value has been set, regardless of
+ whether or not this value was actually changed.
+ </para>
+ </listitem>
- <title><option>--ndb-log-updated-only</option></title>
+ </itemizedlist>
- <indexterm>
- <primary>--ndb-log-updated-only (mysqld option)</primary>
- </indexterm>
+ In general it is preferable to log full rows. However, depending
+ on the application, it may be sufficient to log only the
+ updates, and can be more efficient to do so. This can be done by
+ setting <option>--ndb-log-updated-only</option> to
+ <literal>1</literal> or <literal>ON</literal>.
+ </para>
- <para>
- In general it is preferable to log full rows. However,
- depending on the application, it may be sufficient to
- log only the updates, and can be more efficient to do
- so. This can be done by setting
- <option>--ndb-log-updated-only</option> to
- <literal>1</literal> or <literal>ON</literal>.
- </para>
+ </formalpara>
- </formalpara>
- </listitem>
+ <formalpara>
- </itemizedlist>
+ <title>Logging changed data as updates
+ (<option>--ndb-log-update-as-write</option> option)</title>
+
+ <para>
+ Either of these logging methods can be configured to be done
+ with or without the <quote>before</quote> image as determined by
+ the setting of another MySQL Server option
+ <option>--ndb-log-update-as-write</option>. Because conflict
+ resolution is done in the MySQL Server's update handler, it is
+ necessary to control logging on the master such that updates are
+ updates and not writes as in in mainline MySQL 5.1. This option
+ is turned on by default; to turn it off, start the server with
+ <option>--ndb-log-update-as-write=0</option> or
+ <option>--ndb-log-update-as-write=OFF</option>.
</para>
</formalpara>
- <para>
- Beginning with MySQL 5.1.22-ndb-6.3.3, a server status variable
- <literal>Ndb_conflict_fn_max</literal> provides a count of the
- number of times that a row was not applied on the current SQL node
- due to <quote>greatest timestamp wins</quote> conflict resolution
- since the last time that <command>mysqld</command> was started.
- Beginning with MySQL-5.1.22-ndb-6.3.4, the number of times that a
- row was not applied as the result of <quote>same timestamp
- wins</quote> conflict resolution on a given
- <command>mysqld</command> since the last time it was restarted is
- given by the global status variable
- <literal>Ndb_conflict_fn_old</literal>. In addition to
- incrementing <literal>Ndb_conflict_fn_old</literal>, the primary
- key of the row that was not used is inserted into an
- <firstterm>exceptions table</firstterm>, as explained later in
- this section.
- </para>
-
<indexterm>
<primary>conflict resolution</primary>
<secondary>enabling</secondary>
</indexterm>
- <para>
- To enable conflict resolution, it is necessary to create an
- <literal>ndb_replication</literal> table in the
- <literal>mysql</literal> system database on the master, the slave,
- or both, depending on the conflict resolution type and method to
- be employed. This table is used in order to control logging and
- conflict resolution function on a per-table basis, and has one row
- per table invokved in replication. Each row in
- <literal>mysql.ndb_replication</literal> corresponding to a given
- table specifies how to log and resolve conflicts for that table.
- The definition of this table is shown here:
+ <formalpara>
+ <title>Conflict resolution control</title>
+
+ <para>
+ Conflict resolution is usually enabled on the server where
+ conflicts can occur. Like logging method selection, it is
+ enabled by entries in the
+ <literal>mysql.ndb_replication</literal> table.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>The <literal>ndb_replication</literal> system table</title>
+
+ <para>
+ To enable conflict resolution, it is necessary to create an
+ <literal>ndb_replication</literal> table in the
+ <literal>mysql</literal> system database on the master, the
+ slave, or both, depending on the conflict resolution type and
+ method to be employed. This table is used to control logging and
+ conflict resolution functions on a per-table basis, and has one
+ row per table invoved in replication.
+ <literal>ndb_replication</literal> is created and filled with
+ control information on the server where the conflict is to be
+ resolved. In a simple master-slave setup where data can also be
+ changed locally on the slave this will typically be the slave.
+ In a more complex master-master (2-way) replication schema this
+ will usually be all of the masters involved. Each row in
+ <literal>mysql.ndb_replication</literal> corresponds to a table
+ being replicated, and specifies how to log and resolve conflicts
+ (that is, which conflict resolution function, if any, to use)
+ for that table. The definition of the
+ <literal>mysql.ndb_replication</literal> table is shown here:
+
<programlisting>
CREATE TABLE mysql.ndb_replication (
db VARBINARY(63),
@@ -2445,177 +2439,229 @@
PARTITION BY KEY(db,table_name);
</programlisting>
- The columns in this table are described in the following list:
+ The columns in this table are described in the following list:
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <formalpara>
+ <listitem>
+ <formalpara>
- <title><literal>db</literal></title>
+ <title><literal>db</literal></title>
- <para>
- The name of the database containing the table to be
- replicated.
- </para>
+ <para>
+ The name of the database containing the table to be
+ replicated.
+ </para>
- </formalpara>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <formalpara>
+ <listitem>
+ <formalpara>
- <title><literal>table_name</literal></title>
+ <title><literal>table_name</literal></title>
- <para>
- The name of the table to be replicated.
- </para>
+ <para>
+ The name of the table to be replicated.
+ </para>
- </formalpara>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <formalpara>
+ <listitem>
+ <formalpara>
- <title><literal>server_id</literal></title>
+ <title><literal>server_id</literal></title>
- <para>
- The unique server ID of the MySQL instance (SQL node)
- where the table resides.
- </para>
+ <para>
+ The unique server ID of the MySQL instance (SQL node)
+ where the table resides.
+ </para>
- </formalpara>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <formalpara>
+ <listitem>
+ <formalpara>
- <title><literal>binlog_type</literal></title>
+ <title><literal>binlog_type</literal></title>
- <para>
- The type of binary logging to be employed. This is
- determined as shown in the following table:
+ <para>
+ The type of binary logging to be employed. This is
+ determined as shown in the following table:
- <informaltable>
- <tgroup cols="3">
- <colspec colwidth="15*"/>
- <colspec colwidth="30*"/>
- <colspec colwidth="55*"/>
- <thead>
- <row>
- <entry>Value</entry>
- <entry>Internal Value</entry>
- <entry>Description</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>0</entry>
- <entry><literal>NBT_DEFAULT</literal></entry>
- <entry>Use server default</entry>
- </row>
- <row>
- <entry>1</entry>
- <entry><literal>NBT_NO_LOGGING</literal></entry>
- <entry>Do not log this table in the binary log</entry>
- </row>
- <row>
- <entry>2</entry>
- <entry><literal>NBT_UPDATED_ONLY</literal></entry>
- <entry>Only updated attributes are logged</entry>
- </row>
- <row>
- <entry>3</entry>
- <entry><literal>NBT_FULL</literal></entry>
- <entry>Log full row, even if not updated (MySQL server default behavior)</entry>
- </row>
- <row>
- <entry>4</entry>
- <entry><literal>NBT_USE_UPDATE</literal></entry>
- <entry>(For generating <literal>NBT_UPDATED_ONLY_USE_UPDATE</literal> and
- <literal>NBT_FULL_USE_UPDATE</literal> values
- only — not intended for separate use)</entry>
- </row>
- <row>
- <entry>5</entry>
- <entry>[<emphasis>Not used</emphasis>]</entry>
- <entry>---</entry>
- </row>
- <row>
- <entry>6</entry>
- <entry><literal>NBT_UPDATED_ONLY_USE_UPDATE</literal> (=
- <literal>NBT_UPDATED_ONLY |
- NBT_USE_UPDATE</literal>)</entry>
- <entry>Use updated attributes, even if values are unchanged</entry>
- </row>
- <row>
- <entry>7</entry>
- <entry><literal>NBT_FULL_USE_UPDATE</literal>(= <literal>NBT_FULL |
- NBT_USE_UPDATE</literal>)</entry>
- <entry>Use full row, even if values are unchanged</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </para>
+ <informaltable>
+ <tgroup cols="3">
+ <colspec colwidth="15*"/>
+ <colspec colwidth="30*"/>
+ <colspec colwidth="55*"/>
+ <thead>
+ <row>
+ <entry>Value</entry>
+ <entry>Internal Value</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>0</entry>
+ <entry><literal>NBT_DEFAULT</literal></entry>
+ <entry>Use server default</entry>
+ </row>
+ <row>
+ <entry>1</entry>
+ <entry><literal>NBT_NO_LOGGING</literal></entry>
+ <entry>Do not log this table in the binary log</entry>
+ </row>
+ <row>
+ <entry>2</entry>
+ <entry><literal>NBT_UPDATED_ONLY</literal></entry>
+ <entry>Only updated attributes are logged</entry>
+ </row>
+ <row>
+ <entry>3</entry>
+ <entry><literal>NBT_FULL</literal></entry>
+ <entry>Log full row, even if not updated (MySQL server default behavior)</entry>
+ </row>
+ <row>
+ <entry>4</entry>
+ <entry><literal>NBT_USE_UPDATE</literal></entry>
+ <entry>(For generating <literal>NBT_UPDATED_ONLY_USE_UPDATE</literal> and
+ <literal>NBT_FULL_USE_UPDATE</literal> values
+ only — not intended for separate use)</entry>
+ </row>
+ <row>
+ <entry>5</entry>
+ <entry>[<emphasis>Not used</emphasis>]</entry>
+ <entry>---</entry>
+ </row>
+ <row>
+ <entry>6</entry>
+ <entry><literal>NBT_UPDATED_ONLY_USE_UPDATE</literal> (=
+ <literal>NBT_UPDATED_ONLY |
+ NBT_USE_UPDATE</literal>)</entry>
+ <entry>Use updated attributes, even if values are unchanged</entry>
+ </row>
+ <row>
+ <entry>7</entry>
+ <entry><literal>NBT_FULL_USE_UPDATE</literal>(= <literal>NBT_FULL |
+ NBT_USE_UPDATE</literal>)</entry>
+ <entry>Use full row, even if values are unchanged</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
- </formalpara>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <formalpara>
+ <listitem>
+ <formalpara>
- <title><literal>conflict_fn</literal></title>
+ <title><literal>conflict_fn</literal></title>
- <para>
- The conflict resolution function to be applied. This
- function must be specified as one of the following:
+ <para>
+ The conflict resolution function to be applied. This
+ function must be specified as one of the following:
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <literal>NDB$MAX(<replaceable>column_name</replaceable></literal>:
- Indicates that <quote>greatest timestamp
- wins</quote> conflict resolution is to be used.
- </para>
- </listitem>
+ <listitem>
+ <formalpara>
- <listitem>
- <para>
- <literal>NDB$OLD(<replaceable>column_name</replaceable></literal>:
- An update is applied only if the value of
- <replaceable>column_name</replaceable> is the same
- on both the master and the slave.
- </para>
+ <title><literal>NDB$MAX(<replaceable>column_name</replaceable></literal>)</title>
- <para>
- This function is available beginning with MySQL
- 5.1.22-ndb-6.3.4.
- </para>
- </listitem>
+ <para>
+ Indicates that <quote>greatest timestamp
+ wins</quote> conflict resolution is to be used
+ — that is, if the <quote>timestamp</quote>
+ for a given row coming from the master is higher
+ than that on the slave, it is applied; otherwise
+ it is not applied on the slave. This ensures
+ that, in the event of a conflict, the version of
+ the row that was most recently updated is the
+ version that persists.
+ </para>
- <listitem>
- <para>
- <literal>NULL</literal>: Indicates that conflict
- resolution is not to be used for the corresponding
- table
- </para>
- </listitem>
+ </formalpara>
- </itemizedlist>
+ <para>
+ This conflict resolution function is available in
+ &mccge-series; releases beginning with MySQL
+ 5.1.19-ndb-6.3.0.
+ </para>
+ </listitem>
- .
- </para>
+ <listitem>
+ <formalpara>
- </formalpara>
- </listitem>
+ <title><literal>NDB$OLD(<replaceable>column_name</replaceable></literal>)</title>
- </itemizedlist>
- </para>
+ <para>
+ Indicates that an update is applied only if the
+ value of <replaceable>column_name</replaceable>
+ is the same on both the master and the slave.
+ This ensures that updates are not applied from
+ the wrong master.
+ </para>
+ </formalpara>
+
+ <para>
+ This conflict resolution function is available in
+ &mccge-series; releases beginning with MySQL
+ 5.1.22-ndb-6.3.4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>NULL</literal>: Indicates that conflict
+ resolution is not to be used for the corresponding
+ table
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ .
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+
<formalpara>
+ <title>Status information</title>
+
+ <para>
+ Beginning with MySQL 5.1.22-ndb-6.3.3, a server status variable
+ <literal>Ndb_conflict_fn_max</literal> provides a count of the
+ number of times that a row was not applied on the current SQL
+ node due to <quote>greatest timestamp wins</quote> conflict
+ resolution since the last time that <command>mysqld</command>
+ was started. Beginning with MySQL-5.1.22-ndb-6.3.4, the number
+ of times that a row was not applied as the result of <quote>same
+ timestamp wins</quote> conflict resolution on a given
+ <command>mysqld</command> since the last time it was restarted
+ is given by the global status variable
+ <literal>Ndb_conflict_fn_old</literal>. In addition to
+ incrementing <literal>Ndb_conflict_fn_old</literal>, the primary
+ key of the row that was not used is inserted into an
+ <firstterm>exceptions table</firstterm>, as explained later in
+ this section.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
<title>Additional requirements for <quote>Same timestamp wins</quote> conflict
resolution</title>
@@ -2664,13 +2710,15 @@
</para>
<para>
- The first four columns should be some variety of
+ The first three columns should be some variety of
<literal>INT UNSIGNED</literal>. We suggest the types shown,
or larger ones, in order to ensure that they are large
- enough to accommodate likely values. The data types for the
- columns duplicating the primary key columns of the original
- table should be the same as for (or larger than) the
- original columns.
+ enough to accommodate likely values. The
+ <literal>count</literal> columns must be <literal>BIGINT
+ UNSIGNED</literal>. The data types for the columns
+ duplicating the primary key columns of the original table
+ should be the same as for (or larger than) the original
+ columns.
</para>
</note>
@@ -2687,11 +2735,11 @@
<important>
<para>
The <literal>mysql.ndb_replication</literal> table is read when
- the table is set up for replication, so the row corresponding to
- a table to be replicated must be inserted into
+ a data table is set up for replication, so the row corresponding
+ to a table to be replicated must be inserted into
<literal>mysql.ndb_replication</literal>
- <emphasis>before</emphasis> creation of the table to be
- replicated takes place.
+ <emphasis>before</emphasis> the table to be replicated is
+ created.
</para>
</important>
@@ -2707,47 +2755,71 @@
<formalpara>
- <title><literal>NDB$MAX()</literal> example</title>
+ <title>Examples</title>
<para>
- Suppose you wish to enable <quote>greatest timestamp
- wins</quote> conflict resolution on table
- <literal>test.t1</literal>, using column
- <literal>mycol</literal> as the <quote>timestamp</quote>. This
- can be done using the following two steps:
+ The following examples assume that you have already a working
+ replication setup, as described in
+ <xref linkend="mysql-cluster-replication-preparation"/>, and
+ <xref linkend="mysql-cluster-replication-starting"/>.
<itemizedlist>
<listitem>
- <para>
- On the master, perform this <literal>INSERT</literal>
- statement:
+ <formalpara>
+ <title><literal>NDB$MAX()</literal> example</title>
+
+ <para>
+ Suppose you wish to enable <quote>greatest timestamp
+ wins</quote> conflict resolution on table
+ <literal>test.t1</literal>, using column
+ <literal>mycol</literal> as the
+ <quote>timestamp</quote>. This can be done using the
+ following steps:
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Make sure that you have started the master
+ <command>mysqld</command> with
+ <option>-–ndb-log-updates-as-writes=OFF</option>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ On the master, perform this
+ <literal>INSERT</literal> statement:
+
<programlisting>
INSERT INTO mysql.ndb_replication
VALUES ('test', 't1', 0, NULL, 'NDB$MAX(mycol)');
</programlisting>
- </para>
+ </para>
- <para>
- Inserting a 0 into the <literal>server_id</literal>
- indicates that all SQL nodes accessing this table should
- use conflict resolution. If you want to use conflict
- resolution on a specific <command>mysqld</command> only,
- use the actual server ID.
- </para>
+ <para>
+ Inserting a 0 into the
+ <literal>server_id</literal> indicates that all
+ SQL nodes accessing this table should use conflict
+ resolution. If you want to use conflict resolution
+ on a specific <command>mysqld</command> only, use
+ the actual server ID.
+ </para>
- <para>
- Inserting <literal>NULL</literal> into the
- <literal>binlog_type</literal> column has the same effect
- as inserting 0 (<literal>NBT_DEFAULT</literal>); the
- server default is used.
- </para>
- </listitem>
+ <para>
+ Inserting <literal>NULL</literal> into the
+ <literal>binlog_type</literal> column has the same
+ effect as inserting 0
+ (<literal>NBT_DEFAULT</literal>); the server
+ default is used.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Create the <literal>test.t1</literal> table:
+ <listitem>
+ <para>
+ Create the <literal>test.t1</literal> table:
<programlisting>
CREATE TABLE test.t1 (
@@ -2757,28 +2829,41 @@
);
</programlisting>
- Now, when updates are done on this table, conflict
- resolution will be applied, and the version of the row
- having the greatest value for <literal>mycol</literal>
- will be written to the slave.
- </para>
- </listitem>
+ Now, when updates are done on this table, conflict
+ resolution will be applied, and the version of the
+ row having the greatest value for
+ <literal>mycol</literal> will be written to the
+ slave.
+ </para>
+ </listitem>
- </itemizedlist>
- </para>
+ </orderedlist>
+ </para>
- </formalpara>
+ </formalpara>
- <formalpara>
+ <note>
+ <para>
+ Other <literal>binlog_type</literal> options —
+ such as <literal>NBT_UPDATED_ONLY_USE_UPDATE</literal>
+ should be used in order to control logging on the master
+ via the <literal>ndb_replication</literal> table rather
+ than by using command line options.
+ </para>
+ </note>
+ </listitem>
- <title><literal>NDB$OLD()</literal> example</title>
+ <listitem>
+ <formalpara>
- <para>
- Suppose an <literal>NDB</literal> table such as the one defined
- here is being replicated, and you wish to enable <quote>same
- timestamp wins</quote> conflict resolution for updates to this
- table:
+ <title><literal>NDB$OLD()</literal> example</title>
+ <para>
+ Suppose an <literal>NDB</literal> table such as the one
+ defined here is being replicated, and you wish to enable
+ <quote>same timestamp wins</quote> conflict resolution
+ for updates to this table:
+
<programlisting>
CREATE TABLE test.t2 (
a INT UNSIGNED NOT NULL,
@@ -2790,36 +2875,40 @@
) ENGINE=NDB;
</programlisting>
- The following steps are required, in the order shown:
+ The following steps are required, in the order shown:
- <orderedlist>
+ <orderedlist>
- <listitem>
- <para>
- First — and <emphasis>prior</emphasis> to creating
- <literal>test.t2</literal> — you must insert a row
- into the <literal>mysql.ndb_replication</literal> table,
- as shown here:
+ <listitem>
+ <para>
+ First — and <emphasis>prior</emphasis> to
+ creating <literal>test.t2</literal> — you
+ must insert a row into the
+ <literal>mysql.ndb_replication</literal> table, as
+ shown here:
<programlisting>
INSERT INTO mysql.ndb_replication
VALUES ('test', 't2', 0, NULL, 'NDB$OLD(mycol)');
</programlisting>
- Possible values for the <literal>binlog_type</literal>
- column are shown earlier in this section. The value
- <literal>'NDB$OLD(mycol)'</literal> should be inserted
- into the <literal>conflict_fn</literal> column.
- </para>
- </listitem>
+ Possible values for the
+ <literal>binlog_type</literal> column are shown
+ earlier in this section. The value
+ <literal>'NDB$OLD(mycol)'</literal> should be
+ inserted into the <literal>conflict_fn</literal>
+ column.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Create an appropriate exceptions table for
- <literal>test.t2</literal>. The table creation statement
- shown here includes all required columns; any additional
- columns must be declared following these columns, and
- before the definition of the table's primary key.
+ <listitem>
+ <para>
+ Create an appropriate exceptions table for
+ <literal>test.t2</literal>. The table creation
+ statement shown here includes all required
+ columns; any additional columns must be declared
+ following these columns, and before the definition
+ of the table's primary key.
<programlisting>
CREATE TABLE test.t2$EX (
@@ -2833,24 +2922,31 @@
PRIMARY KEY(server_id, master_server_id, master_epoch, count)
) ENGINE=NDB;
</programlisting>
- </para>
- </listitem>
+ </para>
+ </listitem>
- <listitem>
- <para>
- Create the table <literal>test.t2</literal> as shown
- previously.
- </para>
+ <listitem>
+ <para>
+ Create the table <literal>test.t2</literal> as
+ shown previously.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ These steps must be followed for every table for which
+ you wish to perform conflict resolution using
+ <literal>NDB$OLD()</literal>. For each such table, there
+ must be a corresponding row in
+ <literal>mysql.ndb_replication</literal>, and there must
+ be an exceptions table in the same database as the table
+ being replicated.
+ </para>
+
+ </formalpara>
</listitem>
- </orderedlist>
-
- These steps must be followed for every table for which you wish
- to perform conflict resolution using
- <literal>NDB$OLD()</literal>. For each such table, there must be
- a corresponding row in <literal>mysql.ndb_replication</literal>,
- and there must be an exceptions table in the same database as
- the table being replicated.
+ </itemizedlist>
</para>
</formalpara>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r8349 - trunk/refman-5.1 | jon | 26 Oct |
