Author: jstephens
Date: 2008-04-30 17:25:25 +0200 (Wed, 30 Apr 2008)
New Revision: 10633
Log:
Updated mysql-cluster-conflict-resolution (Tomas, Bodgan, Frazer)
Modified:
trunk/it/refman-5.1/mysql-cluster-replication.xml
trunk/pt/refman-5.1/mysql-cluster-replication.xml
trunk/refman-5.1/mysql-cluster-replication.xml
Modified: trunk/it/refman-5.1/mysql-cluster-replication.xml
===================================================================
--- trunk/it/refman-5.1/mysql-cluster-replication.xml 2008-04-30 14:30:40 UTC (rev 10632)
+++ trunk/it/refman-5.1/mysql-cluster-replication.xml 2008-04-30 15:25:25 UTC (rev 10633)
Changed blocks: 4, Lines Added: 42, Lines Deleted: 25; 5098 bytes
@@ -605,7 +605,7 @@
<para>
This can be accomplished by setting
- <literal>SQL_BIN_LOG = 0</literal>.
+ <literal>SQL_LOG_BIN = 0</literal>.
</para>
</formalpara>
@@ -2294,21 +2294,32 @@
&mccge-warning-section;
<para>
- When using a replication setup involving multiple masters, it is
- possible that different masters may try to update the same row on
- the slave with different data. Conflict resolution in MySQL
- Cluster Replication provides a means of resolving such conflicts
- by allowing a user defined <quote>timestamp</quote> column to be
- used to determine whether or not an update to the row on a given
- master should be applied on the slave.
- </para>
-
- <para>
- Different methods can be used to compare <quote>timestamps</quote>
+ When using a replication setup involving multiple masters
+ (including circular replication), it is possible that different
+ masters may try to update the same row on the slave with different
+ data. Conflict resolution in MySQL Cluster Replication provides a
+ means of resolving such conflicts by allowing a user defined
+ resolution column to be used to determine whether or not an update
+ to the row on a given master should be applied on the slave. (This
+ column is sometimes referred to as a <quote>timestamp</quote>
+ column, even though this column' type cannot be
+ <literal>TIMESTAMP</literal>, as explained later in this section.)
+ Different methods can be used to compare resolution column values
on the slave when conflicts occur, as explained later in this
section; the method used can be set on a per-table basis.
</para>
+ <important>
+ <para>
+ Conflict resolution as described in this section is always
+ applied on a row-by-row basis rather than a transactional basis.
+ In addition, it is the application's responsibility to
+ ensure that the resolution column is correctly populated with
+ relevant values, so that the resolution function can make the
+ appropriate choice when determining whether to apply an update.
+ </para>
+ </important>
+
<formalpara>
<title>Requirements</title>
@@ -2355,8 +2366,10 @@
We refer to the column used for determining updates as a
<quote>timestamp</quote> column, but the data type of this
column is never <literal>TIMESTAMP</literal>; rather, its data
- type should be an integer type. This column can be either signed
- or unsigned.
+ type should be <literal>INT</literal>
+ (<literal>INTEGER</literal>) or <literal>BIGINT</literal>. This
+ column should be <literal>UNSIGNED</literal> and <literal>NOT
+ NULL</literal>.
</para>
</note>
@@ -2714,26 +2727,30 @@
<title>Status information</title>
- <para>
+ <para id="option_mysqld_Ndb_conflict_fn_max">
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.
+ was started.
</para>
</formalpara>
+ <para id="option_mysqld_Ndb_conflict_fn_old">
+ 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>
<title>Additional requirements for <quote>Same timestamp wins</quote> conflict
Modified: trunk/pt/refman-5.1/mysql-cluster-replication.xml
===================================================================
--- trunk/pt/refman-5.1/mysql-cluster-replication.xml 2008-04-30 14:30:40 UTC (rev 10632)
+++ trunk/pt/refman-5.1/mysql-cluster-replication.xml 2008-04-30 15:25:25 UTC (rev 10633)
Changed blocks: 4, Lines Added: 42, Lines Deleted: 25; 5098 bytes
@@ -605,7 +605,7 @@
<para>
This can be accomplished by setting
- <literal>SQL_BIN_LOG = 0</literal>.
+ <literal>SQL_LOG_BIN = 0</literal>.
</para>
</formalpara>
@@ -2294,21 +2294,32 @@
&mccge-warning-section;
<para>
- When using a replication setup involving multiple masters, it is
- possible that different masters may try to update the same row on
- the slave with different data. Conflict resolution in MySQL
- Cluster Replication provides a means of resolving such conflicts
- by allowing a user defined <quote>timestamp</quote> column to be
- used to determine whether or not an update to the row on a given
- master should be applied on the slave.
- </para>
-
- <para>
- Different methods can be used to compare <quote>timestamps</quote>
+ When using a replication setup involving multiple masters
+ (including circular replication), it is possible that different
+ masters may try to update the same row on the slave with different
+ data. Conflict resolution in MySQL Cluster Replication provides a
+ means of resolving such conflicts by allowing a user defined
+ resolution column to be used to determine whether or not an update
+ to the row on a given master should be applied on the slave. (This
+ column is sometimes referred to as a <quote>timestamp</quote>
+ column, even though this column' type cannot be
+ <literal>TIMESTAMP</literal>, as explained later in this section.)
+ Different methods can be used to compare resolution column values
on the slave when conflicts occur, as explained later in this
section; the method used can be set on a per-table basis.
</para>
+ <important>
+ <para>
+ Conflict resolution as described in this section is always
+ applied on a row-by-row basis rather than a transactional basis.
+ In addition, it is the application's responsibility to
+ ensure that the resolution column is correctly populated with
+ relevant values, so that the resolution function can make the
+ appropriate choice when determining whether to apply an update.
+ </para>
+ </important>
+
<formalpara>
<title>Requirements</title>
@@ -2355,8 +2366,10 @@
We refer to the column used for determining updates as a
<quote>timestamp</quote> column, but the data type of this
column is never <literal>TIMESTAMP</literal>; rather, its data
- type should be an integer type. This column can be either signed
- or unsigned.
+ type should be <literal>INT</literal>
+ (<literal>INTEGER</literal>) or <literal>BIGINT</literal>. This
+ column should be <literal>UNSIGNED</literal> and <literal>NOT
+ NULL</literal>.
</para>
</note>
@@ -2714,26 +2727,30 @@
<title>Status information</title>
- <para>
+ <para id="option_mysqld_Ndb_conflict_fn_max">
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.
+ was started.
</para>
</formalpara>
+ <para id="option_mysqld_Ndb_conflict_fn_old">
+ 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>
<title>Additional requirements for <quote>Same timestamp wins</quote> conflict
Modified: trunk/refman-5.1/mysql-cluster-replication.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-replication.xml 2008-04-30 14:30:40 UTC (rev 10632)
+++ trunk/refman-5.1/mysql-cluster-replication.xml 2008-04-30 15:25:25 UTC (rev 10633)
Changed blocks: 2, Lines Added: 26, Lines Deleted: 13; 2922 bytes
@@ -2294,21 +2294,32 @@
&mccge-warning-section;
<para>
- When using a replication setup involving multiple masters, it is
- possible that different masters may try to update the same row on
- the slave with different data. Conflict resolution in MySQL
- Cluster Replication provides a means of resolving such conflicts
- by allowing a user defined <quote>timestamp</quote> column to be
- used to determine whether or not an update to the row on a given
- master should be applied on the slave.
- </para>
-
- <para>
- Different methods can be used to compare <quote>timestamps</quote>
+ When using a replication setup involving multiple masters
+ (including circular replication), it is possible that different
+ masters may try to update the same row on the slave with different
+ data. Conflict resolution in MySQL Cluster Replication provides a
+ means of resolving such conflicts by allowing a user defined
+ resolution column to be used to determine whether or not an update
+ to the row on a given master should be applied on the slave. (This
+ column is sometimes referred to as a <quote>timestamp</quote>
+ column, even though this column' type cannot be
+ <literal>TIMESTAMP</literal>, as explained later in this section.)
+ Different methods can be used to compare resolution column values
on the slave when conflicts occur, as explained later in this
section; the method used can be set on a per-table basis.
</para>
+ <important>
+ <para>
+ Conflict resolution as described in this section is always
+ applied on a row-by-row basis rather than a transactional basis.
+ In addition, it is the application's responsibility to
+ ensure that the resolution column is correctly populated with
+ relevant values, so that the resolution function can make the
+ appropriate choice when determining whether to apply an update.
+ </para>
+ </important>
+
<formalpara>
<title>Requirements</title>
@@ -2355,8 +2366,10 @@
We refer to the column used for determining updates as a
<quote>timestamp</quote> column, but the data type of this
column is never <literal>TIMESTAMP</literal>; rather, its data
- type should be an integer type. This column can be either signed
- or unsigned.
+ type should be <literal>INT</literal>
+ (<literal>INTEGER</literal>) or <literal>BIGINT</literal>. This
+ column should be <literal>UNSIGNED</literal> and <literal>NOT
+ NULL</literal>.
</para>
</note>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r10633 - in trunk: it/refman-5.1 pt/refman-5.1 refman-5.1 | jon | 30 Apr |
