From: jon Date: December 7 2007 8:20pm Subject: svn commit - mysqldoc@docsrva: r9202 - in trunk: dynamic-docs/command-optvars refman-5.1 refman-6.0 List-Archive: http://lists.mysql.com/commits/39570 Message-Id: <200712072020.lB7KKH4C019686@docsrva.mysql.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Author: jstephens Date: 2007-12-07 21:20:17 +0100 (Fri, 07 Dec 2007) New Revision: 9202 Log: Fixes to mysql-cluster-replication-conflict-resolution Added missing mysqld options to optvars file (Thanks, Oli!) Modified: trunk/dynamic-docs/command-optvars/mysqld.xml trunk/refman-5.1/mysql-cluster-cge-building-tmp.xml trunk/refman-5.1/mysql-cluster-replication.xml trunk/refman-6.0/mysql-cluster-replication.xml Modified: trunk/dynamic-docs/command-optvars/mysqld.xml =================================================================== --- trunk/dynamic-docs/command-optvars/mysqld.xml 2007-12-07 19:59:29 UTC (rev 9201) +++ trunk/dynamic-docs/command-optvars/mysqld.xml 2007-12-07 20:20:17 UTC (rev 9202) Changed blocks: 14, Lines Added: 149, Lines Deleted: 93; 10132 bytes @@ -10666,74 +10666,73 @@ - + - + - + max_prepared_STATEMENT_count - + - This variable limits the total number of prepared statements in the server + This variable limits the total number of prepared statements in + the server - + - - + - + - + - + - + max_prepared_STATEMENT_count - + The current number of prepared statements - + - - + - + - + - + - + local_infile - + Whether LOCAL is supported for LOAD DATA INFILE statements - + - + - + @@ -10768,10 +10767,10 @@ - - - - + + - @@ -10820,29 +10818,28 @@ - + - + - + log_bin - + Whether the binary log is enabled - + - - + - + @@ -11028,7 +11025,7 @@ log-output - The destination for general query log and slow query log output. + The destination for general query log and slow query log output. Syntax: log-output[=value[,value...]], where "value" could be TABLE, FILE, or NONE @@ -12622,28 +12619,28 @@ - + - + - + locked_in_memory - + Whether mysqld is locked in memory - + - + - + @@ -12688,7 +12685,7 @@ - + @@ -12761,26 +12758,26 @@ + - + myisam_recover_options - + The value of the --myisam-recover option - - + - + @@ -13303,28 +13300,28 @@ - + - + ndb-connectstring - + - Indicates the management server that distributes the cluster configuration + Indicates the management server that distributes the cluster + configuration - + - - - - + + + - + @@ -13419,6 +13416,67 @@ + + + + + ndb_log_updated_only + + + Log complete rows (ON) or updates only (OFF) + + + + + + + + + + + + + + + + + + + + + + + + + + + ndb_log_update_as_write + + + Toggles logging of updates on the master between updates (OFF) and + writes (ON) + + + + + + + + + + + + + + + + + + + + + + @@ -16087,28 +16145,27 @@ - + - + - + slow_query_log - + Whether the slow query log is enabled - + - - + - + @@ -18917,7 +18974,6 @@ - @@ -18928,30 +18984,30 @@ - + - + - + named_pipe - + - Enable support for named pipes. + Enable support for named pipes. - + - + - + - + @@ -21312,50 +21368,50 @@ - + - + - + skip-ndbcluster - + Disable the NDB Cluster storage engine - + - + - + - + - + - + one-thread - + Only use one thread (for debugging under Linux) - + - + - + Modified: trunk/refman-5.1/mysql-cluster-cge-building-tmp.xml =================================================================== --- trunk/refman-5.1/mysql-cluster-cge-building-tmp.xml 2007-12-07 19:59:29 UTC (rev 9201) +++ trunk/refman-5.1/mysql-cluster-cge-building-tmp.xml 2007-12-07 20:20:17 UTC (rev 9202) Changed blocks: 14, Lines Added: 101, Lines Deleted: 41; 9921 bytes @@ -9,9 +9,10 @@ This section provides instructions on building &mccge-series; using - the source code that can be obtained from the MySQL FTP site and the + the source code that can be obtained from the MySQL FTP site or + and the build_mccge.sh script that can be found in the - source code's BUILD directory. + source code BUILD directory.
@@ -20,40 +21,39 @@ The build_mccge.sh script is intended to - provide an easy way to build &mccge-series; binaries on the - principal supported platforms for this product: + provide an easy way to build 32-bit or 64-bit &mccge-series; + binaries on the principal supported platforms for this product: - Linux/x86 32-bit or 64-bit, using the gcc - compiler. + Linux/x86, using gcc or Intel's + icc compiler. - Linux/x86 32-bit or 64-bit, using Intel's - icc compiler. + Solaris/x86, using gcc. - Solaris/x86, also using gcc. + Solaris/SPARC, using the Forte compiler. - Solaris/Sparc, using the Forte compiler. + MacOS X on x86, using gcc. - MacOS X, using gcc. + FreeBSD/x86, using gcc. @@ -61,21 +61,32 @@ These instructions are not intended to cover obtaining and installing the compiler and other tools needed to - build the &mccge-series; (often abbreviated as - MCCGE or CGE) software. For help - with doing so, please see the documentation provided for your - operating platform. + build the &mccge-series; software (sometimes abbreviated as + MCCGE). For help with this, see the documentation + provided for your operating platform. For information on what + tools are required and recommended, see + , and + . The script automatically detects the CPU type and operating system of the machine on which it is used; in most cases this also - determines which compiler to use, the exception being Linux/x86 - where you can choose between gcc (the default) - and icc. To build on any of these platforms - (using gcc on Linux), it is often sufficient to - invoke the script without any extra options, like this: + determines which compiler to use. + + + For Linux running on x86 processors, gcc is + the default, but you can also choose the + icc compiler if it is available on your + system. + + + + To build on any of these platforms (using gcc + on Linux), it is often sufficient to invoke the script without any + extra options, like this: + shell> cd mccge-root shell> BUILD/build_mccge.sh @@ -127,13 +138,52 @@ Using the option with build_mccge.sh, it is possible to build a - number of different packages. These include a - Classic version of MySQL having only the - MyISAM storage engine, a Pro - package including all storage engines and other features except - for MySQL Cluster, and a Max package including all - of these features plus MySQL Cluster (this is the default package - when the option is used). + number of different packages, listed here: + + + + + + + Classic + + + This package includes only the MyISAM + and CSV storage engines. + + + + + + + + + Pro + + + This packages includes all storage engines and other + features except for MySQL Cluster. + + + + + + + + + Extended + + + This package includes all of the features found in the Pro + package with the addition of MySQL Cluster. This is the + default package when the + option is used. + + + + + + @@ -158,7 +208,7 @@ - + ARCHIVE, BLACKHOLE, CSV, EXAMPLE, FEDERATED, MYISAM, @@ -168,7 +218,7 @@ -cge - + ARCHIVE, BLACKHOLE, CSV, EXAMPLE, FEDERATED, INNODB, @@ -208,6 +258,14 @@ options). + + + Because the &mccge-series; sources are currently based on MySQL + 5.1, there is no support in &mccge-series; for the + Falcon storage engine at this time. + + + Additional package options @@ -256,7 +314,7 @@ This option changes a number of things to make the version built more appropriate to developers' debugging and testing needs. It changes the default package to - Max. It also changes the default warning mode from + Extended. It also changes the default warning mode from none to normal, which allows an extensive list of warnings to be generated. @@ -271,7 +329,7 @@ <option>--error-inject</option> - This option is used only when the + This option is honored only when the option is also used, and enables error injection in both the MySQL Server and on MySQL Cluster data nodes. @@ -375,9 +433,9 @@ MyISAM support is always built - into the MySQL Server. The server cannot be built - without the MyISAM storage - engine. + into the MySQL Server. The server + cannot be built without the + MyISAM storage engine. @@ -440,9 +498,9 @@ - The MySQL Cluster Carrier Grade Edition builds (built using - or ) - add the following options: + The &mccge-series; builds (built using + or + ) add the following options: @@ -495,7 +553,7 @@ <option>--with-innodb</option> - Included in the Pro and Max packages only. + Included in the Pro and Extended packages only. @@ -519,11 +577,11 @@ - <option/> + <option>--with-server-suffix</option> - --with-server-suffix Sets the server suffix on the MySQL - version, by package, as described in + Sets the server suffix on the MySQL version, by package, + as described in . @@ -535,6 +593,8 @@ + + Other options Modified: trunk/refman-5.1/mysql-cluster-replication.xml =================================================================== --- trunk/refman-5.1/mysql-cluster-replication.xml 2007-12-07 19:59:29 UTC (rev 9201) +++ trunk/refman-5.1/mysql-cluster-replication.xml 2007-12-07 20:20:17 UTC (rev 9202) Changed blocks: 6, Lines Added: 11, Lines Deleted: 12; 3258 bytes @@ -2336,7 +2336,7 @@ Logging full or partial rows (<option>--ndb-log-updated-only</option> option) - + For purposes of conflict resolution, there are two basic methods of logging rows, as determined by the setting of the option for @@ -2360,11 +2360,10 @@ - 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 to - 1 or ON. + It more efficient to log updated columns only; however, if you + need to log full rows, you can do so by setting + to 0 + or OFF. @@ -2374,15 +2373,15 @@ Logging changed data as updates (<option>--ndb-log-update-as-write</option> option) - + Either of these logging methods can be configured to be done with or without the before image as determined by the setting of another MySQL Server 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 + updates and not writes. This option is turned on by default; to + turn it off, start the server with or . @@ -2758,7 +2757,7 @@ The following examples assume that you have already a working - replication setup, as described in + MySQL Cluster replication setup, as described in , and . @@ -2783,7 +2782,7 @@ Make sure that you have started the master mysqld with - . + . @@ -2825,7 +2824,7 @@ columns mycol INT UNSIGNED, columns -); +) ENGINE=NDB; Now, when updates are done on this table, conflict Modified: trunk/refman-6.0/mysql-cluster-replication.xml =================================================================== --- trunk/refman-6.0/mysql-cluster-replication.xml 2007-12-07 19:59:29 UTC (rev 9201) +++ trunk/refman-6.0/mysql-cluster-replication.xml 2007-12-07 20:20:17 UTC (rev 9202) Changed blocks: 7, Lines Added: 450, Lines Deleted: 363; 37931 bytes @@ -2190,52 +2190,56 @@ 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. There are two ways in which - this column can be used, as explained in the next two paragraphs. + master should be applied on the slave. - In the first method, if the timestamp 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 timestamps + on the slave when conflicts occur, as explained later in this + section; the method used can be set on a per-table basis. - - In the second method for conflict resolution, the update is - applied only if the timestamp column is the same on - both the master and the slave. This ensures that updates are not - applied from the wrong master. - + - - This replication scheme, also known as changed parameter - only replication, is configurable on a per-table basis. + Requirements - + + Preparations for conflict resolution must be made on both the + master and the slave: - - - On the master, it must be determined which columns to send - (all columns or only those that have been updated). - - + - - - On the slave, it must be determined which type of conflict - resolution to apply (latest timestamp wins, - same timestamp wins, or none). - - + + + 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 mysqld startup + option + (described later in this section) or on a per-table basis + by entries in the mysql.ndb_replication + table. + + - + + + On the slave, you must determine which type of conflict + resolution to apply (latest timestamp wins, + same timestamp wins, or none). This is done + using the mysql.ndb_replication system + table, on a per-table basis. + + - If only some but not all columns are sent, then the master and - slave can diverge. - + + If only some but not all columns are sent, then the master and + slave can diverge. + + + + We refer to the column used for determining updates as a @@ -2250,150 +2254,141 @@ --ndb-log-update-as-write (mysqld option) - - We can see update operations in terms of before and - after 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 before - 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 - startup option for - mysqld, as described later in this section. - + - - 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 mysqld, - or start a new mysqld instance with different - logging options. - + Master column control - - For purposes of conflict resolution, there are two basic methods - of logging rows: + + We can see update operations in terms of before + and after 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 before + 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 startup + option for mysqld, as described later in this + section. - - - + - 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 + mysqld, or start a new + mysqld instance with different logging + options. - + + - - - 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. - - + - + + conflict resolution + mysqld startup options + - Either of the above logging methods can be configured to be done - with or without the before image. - - - <command>mysqld</command> startup options + Logging full or partial rows (<option>--ndb-log-updated-only</option> + option) - - conflict resolution - mysqld startup options - + + For purposes of conflict resolution, there are two basic methods + of logging rows, as determined by the setting of the + option for + mysqld: - - The following mysqld startup options are - available to control conflict resolution: - - - - <option>--ndb-log-update-as-write</option> - - - --ndb-log-update-as-write (mysqld 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 or - . - - - + + Log complete rows + - + + 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. + + - <option>--ndb-log-updated-only</option> + - - --ndb-log-updated-only (mysqld option) - + It more efficient to log updated columns only; however, if you + need to log full rows, you can do so by setting + to 0 + or OFF. + - - 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 - to - 1 or ON. - + - - + - + Logging changed data as updates + (<option>--ndb-log-update-as-write</option> option) + + + Either of these logging methods can be configured to be done + with or without the before image as determined by + the setting of another MySQL Server 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. This option is turned on by default; to + turn it off, start the server with + or + . - - The 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. 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. - - conflict resolution enabling - - To enable conflict resolution, it is necessary to create an - ndb_replication table in the - mysql 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 - mysql.ndb_replication corresponding to a given - table specifies how to log and resolve conflicts for that table. - The definition of this table is shown here: + + Conflict resolution control + + + Conflict resolution is usually enabled on the server where + conflicts can occur. Like logging method selection, it is + enabled by entries in the + mysql.ndb_replication table. + + + + + + + The <literal>ndb_replication</literal> system table + + + To enable conflict resolution, it is necessary to create an + ndb_replication table in the + mysql 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. + ndb_replication 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 + mysql.ndb_replication 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 + mysql.ndb_replication table is shown here: + CREATE TABLE mysql.ndb_replication ( db VARBINARY(63), @@ -2406,172 +2401,216 @@ PARTITION BY KEY(db,table_name); - The columns in this table are described in the following list: + The columns in this table are described in the following list: - + - - + + - <literal>db</literal> + <literal>db</literal> - - The name of the database containing the table to be - replicated. - + + The name of the database containing the table to be + replicated. + - - + + - - + + - <literal>table_name</literal> + <literal>table_name</literal> - - The name of the table to be replicated. - + + The name of the table to be replicated. + - - + + - - + + - <literal>server_id</literal> + <literal>server_id</literal> - - The unique server ID of the MySQL instance (SQL node) - where the table resides. - + + The unique server ID of the MySQL instance (SQL node) + where the table resides. + - - + + - - + + - <literal>binlog_type</literal> + <literal>binlog_type</literal> - - The type of binary logging to be employed. This is - determined as shown in the following table: + + The type of binary logging to be employed. This is + determined as shown in the following table: - - - - - - - - Value - Internal Value - Description - - - - - 0 - NBT_DEFAULT - Use server default - - - 1 - NBT_NO_LOGGING - Do not log this table in the binary log - - - 2 - NBT_UPDATED_ONLY - Only updated attributes are logged - - - 3 - NBT_FULL - Log full row, even if not updated (MySQL server default behavior) - - - 4 - NBT_USE_UPDATE - (For generating NBT_UPDATED_ONLY_USE_UPDATE and - NBT_FULL_USE_UPDATE values - only — not intended for separate use) - - - 5 - [Not used] - --- - - - 6 - NBT_UPDATED_ONLY_USE_UPDATE (= - NBT_UPDATED_ONLY | - NBT_USE_UPDATE) - Use updated attributes, even if values are unchanged - - - 7 - NBT_FULL_USE_UPDATE(= NBT_FULL | - NBT_USE_UPDATE) - Use full row, even if values are unchanged - - - - - + + + + + + + + Value + Internal Value + Description + + + + + 0 + NBT_DEFAULT + Use server default + + + 1 + NBT_NO_LOGGING + Do not log this table in the binary log + + + 2 + NBT_UPDATED_ONLY + Only updated attributes are logged + + + 3 + NBT_FULL + Log full row, even if not updated (MySQL server default behavior) + + + 4 + NBT_USE_UPDATE + (For generating NBT_UPDATED_ONLY_USE_UPDATE and + NBT_FULL_USE_UPDATE values + only — not intended for separate use) + + + 5 + [Not used] + --- + + + 6 + NBT_UPDATED_ONLY_USE_UPDATE (= + NBT_UPDATED_ONLY | + NBT_USE_UPDATE) + Use updated attributes, even if values are unchanged + + + 7 + NBT_FULL_USE_UPDATE(= NBT_FULL | + NBT_USE_UPDATE) + Use full row, even if values are unchanged + + + + + - - + + - - + + - <literal>conflict_fn</literal> + <literal>conflict_fn</literal> - - The conflict resolution function to be applied. This - function must be specified as one of the following: + + The conflict resolution function to be applied. This + function must be specified as one of the following: - + - - - NDB$MAX(column_name: - Indicates that greatest timestamp - wins conflict resolution is to be used. - - + + - - - NDB$OLD(column_name: - An update is applied only if the value of - column_name is the same - on both the master and the slave. - - + <literal>NDB$MAX(<replaceable>column_name</replaceable></literal>) - - - NULL: Indicates that conflict - resolution is not to be used for the corresponding - table - - + + Indicates that greatest timestamp + wins conflict resolution is to be used + — that is, if the timestamp + 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. + - + + - . - + + - - + <literal>NDB$OLD(<replaceable>column_name</replaceable></literal>) - - + + Indicates that an update is applied only if the + value of column_name + is the same on both the master and the slave. + This ensures that updates are not applied from + the wrong master. + + + + + + + NULL: Indicates that conflict + resolution is not to be used for the corresponding + table + + + + + + . + + + + + + + + + + + Status information + + + The Ndb_conflict_fn_max server status + variable 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. + + + + + + Additional requirements for <quote>Same timestamp wins</quote> conflict resolution @@ -2640,11 +2679,11 @@ The mysql.ndb_replication 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 mysql.ndb_replication - before creation of the table to be - replicated takes place. + before the table to be replicated is + created. @@ -2660,78 +2699,115 @@ - <literal>NDB$MAX()</literal> example + Examples - Suppose you wish to enable greatest timestamp - wins conflict resolution on table - test.t1, using column - mycol as the timestamp. This - can be done using the following two steps: + The following examples assume that you have already a working + MySQL Cluster replication setup, as described in + , and + . - - On the master, perform this INSERT - statement: + + <literal>NDB$MAX()</literal> example + + + Suppose you wish to enable greatest timestamp + wins conflict resolution on table + test.t1, using column + mycol as the + timestamp. This can be done using the + following steps: + + + + + + Make sure that you have started the master + mysqld with + . + + + + + + On the master, perform this + INSERT statement: + INSERT INTO mysql.ndb_replication VALUES ('test', 't1', 0, NULL, 'NDB$MAX(mycol)'); - + - - Inserting a 0 into the server_id - indicates that all SQL nodes accessing this table should - use conflict resolution. If you want to use conflict - resolution on a specific mysqld only, - use the actual server ID. - + + Inserting a 0 into the + server_id indicates that all + SQL nodes accessing this table should use conflict + resolution. If you want to use conflict resolution + on a specific mysqld only, use + the actual server ID. + - - Inserting NULL into the - binlog_type column has the same effect - as inserting 0 (NBT_DEFAULT); the - server default is used. - - + + Inserting NULL into the + binlog_type column has the same + effect as inserting 0 + (NBT_DEFAULT); the server + default is used. + + - - - Create the test.t1 table: + + + Create the test.t1 table: CREATE TABLE test.t1 ( columns mycol INT UNSIGNED, columns -); +) ENGINE=NDB; - Now, when updates are done on this table, conflict - resolution will be applied, and the version of the row - having the greatest value for mycol - will be written to the slave. - - + Now, when updates are done on this table, conflict + resolution will be applied, and the version of the + row having the greatest value for + mycol will be written to the + slave. + + - - + + - + - + + + Other binlog_type options — + such as NBT_UPDATED_ONLY_USE_UPDATE + should be used in order to control logging on the master + via the ndb_replication table rather + than by using command line options. + + + - <literal>NDB$OLD()</literal> example + + - - Suppose an NDB table such as the one defined - here is being replicated, and you wish to enable same - timestamp wins conflict resolution for updates to this - table: + <literal>NDB$OLD()</literal> example + + Suppose an NDB table such as the one + defined here is being replicated, and you wish to enable + same timestamp wins conflict resolution + for updates to this table: + CREATE TABLE test.t2 ( a INT UNSIGNED NOT NULL, @@ -2743,36 +2819,40 @@ ) ENGINE=NDB; - The following steps are required, in the order shown: + The following steps are required, in the order shown: - + - - - First — and prior to creating - test.t2 — you must insert a row - into the mysql.ndb_replication table, - as shown here: + + + First — and prior to + creating test.t2 — you + must insert a row into the + mysql.ndb_replication table, as + shown here: INSERT INTO mysql.ndb_replication VALUES ('test', 't2', 0, NULL, 'NDB$OLD(mycol)'); - Possible values for the binlog_type - column are shown earlier in this section. The value - 'NDB$OLD(mycol)' should be inserted - into the conflict_fn column. - - + Possible values for the + binlog_type column are shown + earlier in this section. The value + 'NDB$OLD(mycol)' should be + inserted into the conflict_fn + column. + + - - - Create an appropriate exceptions table for - test.t2. 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. + + + Create an appropriate exceptions table for + test.t2. 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. CREATE TABLE test.t2$EX ( @@ -2786,24 +2866,31 @@ PRIMARY KEY(server_id, master_server_id, master_epoch, count) ) ENGINE=NDB; - - + + - - - Create the table test.t2 as shown - previously. - + + + Create the table test.t2 as + shown previously. + + + + + + These steps must be followed for every table for which + you wish to perform conflict resolution using + NDB$OLD(). For each such table, there + must be a corresponding row in + mysql.ndb_replication, and there must + be an exceptions table in the same database as the table + being replicated. + + + - - - These steps must be followed for every table for which you wish - to perform conflict resolution using - NDB$OLD(). For each such table, there must be - a corresponding row in mysql.ndb_replication, - and there must be an exceptions table in the same database as - the table being replicated. +