From: jon Date: April 30 2008 3:25pm Subject: svn commit - mysqldoc@docsrva: r10633 - in trunk: it/refman-5.1 pt/refman-5.1 refman-5.1 List-Archive: http://lists.mysql.com/commits/46234 Message-Id: <200804301525.m3UFPPjg012186@docsrva.mysql.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 @@ This can be accomplished by setting - SQL_BIN_LOG = 0. + SQL_LOG_BIN = 0. @@ -2294,21 +2294,32 @@ &mccge-warning-section; - 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 timestamp column to be - used to determine whether or not an update to the row on a given - master should be applied on the slave. - - - - Different methods can be used to compare timestamps + 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 timestamp + column, even though this column' type cannot be + TIMESTAMP, 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. + + + 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. + + + Requirements @@ -2355,8 +2366,10 @@ We refer to the column used for determining updates as a timestamp column, but the data type of this column is never TIMESTAMP; rather, its data - type should be an integer type. This column can be either signed - or unsigned. + type should be INT + (INTEGER) or BIGINT. This + column should be UNSIGNED and NOT + NULL. @@ -2714,26 +2727,30 @@ Status information - + Beginning with MySQL 5.1.22-ndb-6.3.3, a server status variable Ndb_conflict_fn_max provides a count of the number of times that a row was not applied on the current SQL node due to greatest timestamp wins conflict resolution since the last time that mysqld - 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 same - timestamp wins conflict resolution on a given - mysqld since the last time it was restarted - is given by the global status variable - Ndb_conflict_fn_old. In addition to - incrementing Ndb_conflict_fn_old, the primary - key of the row that was not used is inserted into an - exceptions table, as explained later in - this section. + 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 same timestamp + wins conflict resolution on a given + mysqld since the last time it was restarted is + given by the global status variable + Ndb_conflict_fn_old. In addition to + incrementing Ndb_conflict_fn_old, the primary + key of the row that was not used is inserted into an + exceptions table, as explained later in + this section. + + 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 @@ -2355,8 +2366,10 @@ We refer to the column used for determining updates as a timestamp column, but the data type of this column is never TIMESTAMP; rather, its data - type should be an integer type. This column can be either signed - or unsigned. + type should be INT + (INTEGER) or BIGINT. This + column should be UNSIGNED and NOT + NULL. @@ -2714,26 +2727,30 @@ Status information - + Beginning with MySQL 5.1.22-ndb-6.3.3, a server status variable Ndb_conflict_fn_max provides a count of the number of times that a row was not applied on the current SQL node due to greatest timestamp wins conflict resolution since the last time that mysqld - 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 same - timestamp wins conflict resolution on a given - mysqld since the last time it was restarted - is given by the global status variable - Ndb_conflict_fn_old. In addition to - incrementing Ndb_conflict_fn_old, the primary - key of the row that was not used is inserted into an - exceptions table, as explained later in - this section. + 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 same timestamp + wins conflict resolution on a given + mysqld since the last time it was restarted is + given by the global status variable + Ndb_conflict_fn_old. In addition to + incrementing Ndb_conflict_fn_old, the primary + key of the row that was not used is inserted into an + exceptions table, as explained later in + this section. + + 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 @@ -2355,8 +2366,10 @@ We refer to the column used for determining updates as a timestamp column, but the data type of this column is never TIMESTAMP; rather, its data - type should be an integer type. This column can be either signed - or unsigned. + type should be INT + (INTEGER) or BIGINT. This + column should be UNSIGNED and NOT + NULL.