| List: | Commits | « Previous MessageNext Message » | |
| From: | jon | Date: | October 26 2008 2:33am |
| Subject: | svn commit - mysqldoc@docsrva: r12155 - in trunk: refman-5.0 refman-5.1 refman-5.1-maria refman-6.0 refman-common/images/published refman-common/image... | ||
| View as plain text | |||
Author: jstephens Date: 2008-10-26 02:33:16 +0100 (Sun, 26 Oct 2008) New Revision: 12155 Log: Overhauled replication-features Completes fix of Docs Bug #40023 Added: trunk/refman-common/images/published/rpl-create-select-failure-rbr.png trunk/refman-common/images/source/rpl-create-select-failure-rbr.html Modified: trunk/refman-5.0/Makefile.depends trunk/refman-5.0/renamed-nodes.txt trunk/refman-5.0/replication-notes.xml trunk/refman-5.1-maria/Makefile.depends trunk/refman-5.1/Makefile.depends trunk/refman-5.1/replication-notes.xml trunk/refman-6.0/Makefile.depends trunk/refman-6.0/replication-notes.xml trunk/topic-guides/topics-5.0/Makefile.depends trunk/topic-guides/topics-5.1/Makefile.depends trunk/topic-guides/topics-6.0/Makefile.depends Property changes on: trunk/refman-common/images/published/rpl-create-select-failure-rbr.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Modified: trunk/refman-5.0/Makefile.depends =================================================================== --- trunk/refman-5.0/Makefile.depends 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/refman-5.0/Makefile.depends 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1173 bytes @@ -2879,7 +2879,7 @@ ../refman-5.0/metadata/se-memory.idmap \ ../refman-5.0/metadata/sql-syntax-data-definition.idmap \ ../refman-5.0/metadata/sql-syntax-server-administration.idmap \ - ../refman-5.0/metadata/stored-programs-views.idmap \ + ../refman-5.0/metadata/sql-syntax-transactions.idmap \ ../refman-5.1/metadata/replication-configuration.idmap \ ../refman-common/metadata/bug-reports.idmap replication-notes.validpure: $(replication_notes_SOURCES) @@ -2962,7 +2962,7 @@ ../refman-5.0/metadata/sql-syntax-data-definition.idmap \ ../refman-5.0/metadata/sql-syntax-replication.idmap \ ../refman-5.0/metadata/sql-syntax-server-administration.idmap \ - ../refman-5.0/metadata/stored-programs-views.idmap \ + ../refman-5.0/metadata/sql-syntax-transactions.idmap \ ../refman-5.1/metadata/replication-configuration.idmap \ ../refman-common/metadata/bug-reports.idmap replication.validpure: $(replication_SOURCES) Modified: trunk/refman-5.0/renamed-nodes.txt =================================================================== --- trunk/refman-5.0/renamed-nodes.txt 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/refman-5.0/renamed-nodes.txt 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 1, Lines Added: 4, Lines Deleted: 0; 973 bytes @@ -681,6 +681,10 @@ releasenotes-cs-5-0-29 releasenotes-es-5-0-30 remote-connection connector-odbc-examples-walkthrough replication-auto-increment replication-features-auto-increment 2009-08-01 +replication-features-differing-tables ../../5.1/en/replication-features-differing-tables 2009-10-25 +replication-features-different-data-types ../../5.1/en/replication-features-different-data-types 2009-10-25 +replication-features-more-columns ../../5.1/en/replication-features-more-columns 2009-10-25 +replication-features-timeouts replication-features-timeout 2009-10-25 replication-drbd ha-drbd 2009-03-01 replication-drbd-install ha-drbd-install 2009-03-01 replication-drbd-install-drbd ha-drbd-install-drbd 2009-03-01 Modified: trunk/refman-5.0/replication-notes.xml =================================================================== --- trunk/refman-5.0/replication-notes.xml 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/refman-5.0/replication-notes.xml 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 17, Lines Added: 259, Lines Deleted: 111; 21671 bytes @@ -39,41 +39,53 @@ </indexterm> <para> - In general, replication compatibility at the SQL level requires - that any features used be supported by both the master and the - slave servers. If you use a feature on a master server that is - available only as of a given version of MySQL, you cannot - replicate to a slave that is older than that version. Such - incompatibilities are likely to occur between series, so that, for - example, you cannot replicate from MySQL ¤t-series; to - &previous-series;. However, these incompatibilities also can occur - for within-series replication. For example, the - <function role="sql">SLEEP()</function> function is available in - MySQL 5.0.12 and up. If you use this function on the master - server, you cannot replicate to a slave server that is older than - MySQL 5.0.12. + The following sections provide information about what is supported + and what is not in MySQL replication, and about specific issues + and situations that may occur when replicating certain statements. </para> <para> - If you are planning to use replication between ¤t-series; - and a previous version of MySQL you should consult the edition of - the MySQL Reference Manual corresponding to the earlier release - series for information regarding the replication characteristics - of that series. + Statement-based replication depends on compatibility at the SQL + level between the master and slave. In others, successful SBR + requires that any SQL features used be supported by both the + master and the slave servers. For example, if you use a feature on + the master server that is available only in MySQL ¤t-series; + (or later), you cannot replicate to a slave that uses MySQL + &previous-series; (or earlier). </para> <para> - The following sections provide details about what is supported and - what is not. Additional information specific to - <literal>InnoDB</literal> and replication is given in - <xref linkend="innodb-and-mysql-replication"/>. + Such incompatibilities also can occur within a release series when + using pre-production releases of MySQL. For example, the + <function role="sql">SLEEP()</function> function is available + beginning with MySQL 5.0.12. If you use this function on the + master, you cannot replicate to a slave that uses MySQL 5.0.11 or + earlier. </para> <para> - Replication issues with regard to stored routines and triggers is - described in <xref linkend="stored-programs-logging"/>. + For this reason, we recommend that you use Generally Available + (GA) releases of MySQL for statement-based replication in a + production setting, since we do not introduce new SQL statements + or change their behavior within a given release series once that + series reaches GA release status. </para> + <para> + If you are planning to use replication between MySQL + ¤t-series; and a previous MySQL release series, it is also a + good idea to consult the edition of the <citetitle>MySQL Reference + Manual</citetitle> corresponding to the earlier release series for + information regarding the replication characteristics of that + series. + </para> + + <para> + For additional information specific to replication and + <literal>InnoDB</literal>, see + <xref linkend="innodb-and-mysql-replication"/>. + </para> + <section id="replication-features-auto-increment"> <title>Replication and <literal>AUTO_INCREMENT</literal></title> @@ -93,7 +105,8 @@ VALUES(LAST_INSERT_ID())</literal> inserts a different value on the master and the slave. (Bug #20819) This is fixed in MySQL &next-series; when using row-based or mixed-format - binary logging. + binary logging. For more information, see + <xref linkend="refman-5.1:replication-formats"/>. </para> </listitem> @@ -267,9 +280,9 @@ <literal>character_set_server</literal> value, you should design your <literal>CREATE TABLE</literal> statements so that tables in those databases do not implicitly rely on the - database default character set (see Bug #2326). A good - workaround is to state the character set and collation - explicitly in <literal>CREATE TABLE</literal> statements. + database default character set. A good workaround is to + state the character set and collation explicitly in + <literal>CREATE TABLE</literal> statements. </para> </listitem> @@ -277,9 +290,88 @@ </section> + <section id="replication-features-create-select"> + + <title>Replication of <literal>CREATE TABLE ... SELECT</literal> Statements</title> + + <para> + This section discusses the rules that are applied when a + <literal>CREATE TABLE ... SELECT</literal> statement is + replicated. + </para> + + <note> + <para> + <literal>CREATE TABLE ... SELECT</literal> always performs an + implicit commit (<xref linkend="implicit-commit"/>). + </para> + </note> + + <formalpara> + + <title>Statement succeeds</title> + + <para> + If the <literal>CREATE TABLE ... SELECT</literal> statement + succeeds on the master, then the <literal>CREATE TABLE ... + SELECT</literal> statement is itself replicated. + </para> + + </formalpara> + + <formalpara> + + <title>Statement fails</title> + + <para> + The failure of a <literal>CREATE TABLE ... SELECT</literal> is + handled according to the following criteria: + + <itemizedlist> + + <listitem> + <formalpara> + + <title>No <literal>IF NOT EXISTS</literal> option</title> + + <para> + If the <literal>CREATE TABLE ... SELECT</literal> does + not contain an <literal>IF NOT EXISTS</literal> + option, then the statement has no effect. However, the + implicit commit caused by the statement is logged. + This is true regardless of the storage engine used and + the reason for which the statement failed. + </para> + + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title>Statement uses <literal>IF NOT EXISTS</literal></title> + + <para> + If the <literal>CREATE TABLE ... SELECT</literal> + statement includes the <literal>IF NOT + EXISTS</literal> option and fails, the <literal>CREATE + TABLE IF NOT EXISTS ... SELECT</literal> is logged + with an error. + </para> + + </formalpara> + </listitem> + + </itemizedlist> + </para> + + </formalpara> + + </section> + <section id="replication-features-directory"> - <title>Replication <literal>DIRECTORY</literal> Statements</title> + <title>Replication and <literal>DIRECTORY</literal> Statements</title> <para> If a <literal>DATA DIRECTORY</literal> or <literal>INDEX @@ -287,16 +379,20 @@ TABLE</literal> statement on the master server, the table option is also used on the slave. This can cause problems if no corresponding directory exists in the slave host filesystem or - if it exists but is not accessible to the slave server. MySQL - supports an <literal>sql_mode</literal> option called - <literal>NO_DIR_IN_CREATE</literal>. If the slave server is run - with this SQL mode enabled, it ignores the <literal>DATA - DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> table - options when replicating <literal>CREATE TABLE</literal> - statements. The result is that <literal>MyISAM</literal> data - and index files are created in the table's database directory. + if it exists but is not accessible to the slave server. This can + be overridden by using the <literal>NO_DIR_IN_CREATE</literal> + server SQL mode on the slave, which causes the slave to ignore + the <literal>DATA DIRECTORY</literal> and <literal>INDEX + DIRECTORY</literal> table options when replicating + <literal>CREATE TABLE</literal> statements. The result is that + <literal>MyISAM</literal> data and index files are created in + the table's database directory. </para> + <para> + For more information, see <xref linkend="server-sql-mode"/>. + </para> + </section> <section id="replication-features-floatvalues"> @@ -304,14 +400,16 @@ <title>Replication with Floating-Point Values</title> <para> - Floating-point values are approximate, so comparisons involving - them are inexact. This is true for operations that use - floating-point values explicitly, or values that are converted - to floating-point implicitly. Comparisons of floating-point - values might yield different results on master and slave servers - due to differences in computer architecture, the compiler used - to build MySQL, and so forth. See - <xref linkend="type-conversion"/>, and + With statement-based replication, values are converted from + decimal to binary. Because conversions between decimal and + binary representations of them may be approximate, comparisons + involving floating-point values are inexact. This is true for + operations that use floating-point values explicitly, or that + use values that are converted to floating-point implicitly. + Comparisons of floating-point values might yield different + results on master and slave servers due to differences in + computer architecture, the compiler used to build MySQL, and so + forth. See <xref linkend="type-conversion"/>, and <xref linkend="problems-with-float"/>. </para> @@ -344,17 +442,21 @@ <literal>OPTIMIZE TABLE</literal>, and <literal>REPAIR TABLE</literal> statements are written to the binary log and thus replicated to slaves. This is not normally a problem - because these statements do not modify table data. However, this - can cause difficulties under certain circumstances. If you - replicate the privilege tables in the <literal>mysql</literal> - database and update those tables directly without using - <literal>GRANT</literal>, you must issue a <literal>FLUSH - PRIVILEGES</literal> on the slaves to put the new privileges - into effect. In addition, if you use <literal>FLUSH - TABLES</literal> when renaming a <literal>MyISAM</literal> table - that is part of a <literal>MERGE</literal> table, you must issue - <literal>FLUSH TABLES</literal> manually on the slaves. These - statements are written to the binary log unless you specify + because these statements do not modify table data. + </para> + + <para> + However, this behavior can cause difficulties under certain + circumstances. If you replicate the privilege tables in the + <literal>mysql</literal> database and update those tables + directly without using <literal>GRANT</literal>, you must issue + a <literal>FLUSH PRIVILEGES</literal> on the slaves to put the + new privileges into effect. In addition, if you use + <literal>FLUSH TABLES</literal> when renaming a + <literal>MyISAM</literal> table that is part of a + <literal>MERGE</literal> table, you must issue <literal>FLUSH + TABLES</literal> manually on the slaves. These statements are + written to the binary log unless you specify <literal>NO_WRITE_TO_BINLOG</literal> or its alias <literal>LOCAL</literal>. </para> @@ -363,7 +465,7 @@ <section id="replication-features-functions"> - <title>Replication and Functions</title> + <title>Replication and System Functions</title> <para> Certain functions do not replicate well under some conditions: @@ -627,6 +729,22 @@ </section> + <section id="replication-features-mysqldb"> + + <title>Replication of the System <literal>mysql</literal> Database</title> + + <para> + User privileges are replicated only if the + <literal>mysql</literal> database is replicated. That is, the + <literal>GRANT</literal>, <literal>REVOKE</literal>, + <literal>SET PASSWORD</literal>, <literal>CREATE USER</literal>, + and <literal>DROP USER</literal> statements take effect on the + slave only if the replication setup includes the + <literal>mysql</literal> database. + </para> + + </section> + <section id="replication-features-optimizer"> <title>Replication and the Query Optimizer</title> @@ -698,7 +816,7 @@ For listings of reserved words by MySQL version, see <ulink url="http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-optvar.html">Reserved - Words</ulink>,.in the <citetitle>MySQL Server Version + Words</ulink>, in the <citetitle>MySQL Server Version Reference</citetitle>. </para> @@ -752,17 +870,23 @@ <title>Replication and Temporary Tables</title> - <para> - Temporary tables are replicated except in the case where you - shut down the slave server (not just the slave threads) and you - have replicated temporary tables that are used in updates that - have not yet been executed on the slave. If you shut down the - slave server, the temporary tables needed by those updates are - no longer available when the slave is restarted. To avoid this - problem, do not shut down the slave while it has temporary - tables open. Instead, use the following procedure: - </para> + <formalpara> + <title>Safe shutdown of slaves when using temporary tables</title> + + <para> + Temporary tables are replicated except in the case where you + shut down the slave server (not just the slave threads) and + you have replicated temporary tables that are used in updates + that have not yet been executed on the slave. If you shut down + the slave server, the temporary tables needed by those updates + are no longer available when the slave is restarted. To avoid + this problem, do not shut down the slave while it has + temporary tables open. Instead, use the following procedure: + </para> + + </formalpara> + <orderedlist> <listitem> @@ -802,9 +926,39 @@ </orderedlist> + <formalpara> + + <title>Temporary tables and replication options</title> + + <para> + By default, all temporary tables are replicated; this happens + whether or not there are any matching + <option>--replicate-do-db</option>, + <option>--replicate-do-table</option>, or + <option>--replicate-wild-do-table</option> options in effect. + However, the <option>--replicate-ignore-table</option> and + <option>--replicate-wild-ignore-table</option> options are + honored for temporary tables. + </para> + + </formalpara> + + <para> + A recommended practice when using replication is to designate a + prefix for exclusive use in naming temporary tables that you do + not want replicated, then employ a matching + <option>--replicate-wild-ignore-table</option> option. For + example, you might give all such tables names beginning with + <literal>norep_</literal> (such as + <literal>norep_tablea</literal>, + <literal>norep_tableb</literal>, and so on), then use + <option>--replicate-wild-ignore-table=norep_</option> to prevent + the replication of these tables. + </para> + </section> - <section id="replication-features-timeouts"> + <section id="replication-features-timeout"> <title>Replication Retries and Timeouts</title> @@ -850,11 +1004,9 @@ </para> <para> - <function role="sql">CONVERT_TZ(...,...,@@global.time_zone)</function> - is not properly replicated. - <function>CONVERT_TZ(...,...,@@session.time_zone)</function> is - properly replicated only if the master and slave are from MySQL - 5.0.4 or newer. + <function role="sql">CONVERT_TZ(...,...,@@session.time_zone)</function> + is properly replicated only if both master and slave are running + MySQL 5.0.4 or newer. </para> </section> @@ -867,39 +1019,26 @@ It is possible to replicate transactional tables on the master using non-transactional tables on the slave. For example, you can replicate an <literal>InnoDB</literal> master table as a - <literal>MyISAM</literal> slave table. However, there are issues - that you should consider before you do this: + <literal>MyISAM</literal> slave table. However, if you do this, + there are problems if the slave is stopped in the middle of a + <literal>BEGIN</literal>/<literal>COMMIT</literal> block because + the slave restarts at the beginning of the + <literal>BEGIN</literal> block. </para> - <itemizedlist> + <para> + In situations where transactions mix updates to transactional + and non-transactional tables, the order of statements in the + binary log is correct, and all needed statements are written to + the binary log even in case of a <literal>ROLLBACK</literal>. + However, when a second connection updates the non-transactional + table before the first connection's transaction is complete, + statements can be logged out of order, because the second + connection's update is written immediately after it is + performed, regardless of the state of the transaction being + performed by the first connection. + </para> - <listitem> - <para> - There are problems if the slave is stopped in the middle of - a <literal>BEGIN</literal>/<literal>COMMIT</literal> block - because the slave restarts at the beginning of the - <literal>BEGIN</literal> block. - </para> - </listitem> - - <listitem> - <para> - When the storage engine type of the slave is - non-transactional, transactions on the master that mix - updates of transactional and non-transactional tables should - be avoided because they can cause inconsistency of the data - between the master's transactional table and the slave's - non-transactional table. That is, such transactions can lead - to master storage engine-specific behavior with the possible - effect of replication going out of synchrony. MySQL does not - issue a warning about this currently, so extra care should - be taken when replicating transactional tables from the - master to non-transactional ones on the slaves. - </para> - </listitem> - - </itemizedlist> - <para> Due to the non-transactional nature of <literal>MyISAM</literal> tables, it is possible to have a statement that only partially @@ -944,6 +1083,20 @@ </para> </caution> + <para> + When the storage engine type of the slave is non-transactional, + transactions on the master that mix updates of transactional and + non-transactional tables should be avoided because they can + cause inconsistency of the data between the master's + transactional table and the slave's non-transactional table. + That is, such transactions can lead to master storage + engine-specific behavior with the possible effect of replication + going out of synchrony. MySQL does not issue a warning about + this currently, so extra care should be taken when replicating + transactional tables from the master to non-transactional ones + on the slaves. + </para> + </section> <section id="replication-features-triggers"> @@ -1001,8 +1154,8 @@ that affect user privileges to be replicated, set up the slave to not replicate the <literal>mysql</literal> database, using the <option>--replicate-wild-ignore-table=mysql.%</option> - option. The slave will recognize that issuing privilege-related - SQL statements won't have an effect, and thus not execute those + option. The slave recognizes that issuing privilege-related SQL + statements have no effect, and thus it does not execute those statements. </para> @@ -1446,11 +1599,6 @@ <xref linkend="replication-implementation-details"/>. </para> - <remark role="todo"> - Check following in light of changes to TIMESTAMP in recent - versions. /JS - </remark> - <para> When the slave SQL thread executes an event read from the master, it modifies its own time to the event timestamp. Modified: trunk/refman-5.1/Makefile.depends =================================================================== --- trunk/refman-5.1/Makefile.depends 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/refman-5.1/Makefile.depends 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 7, Lines Added: 9, Lines Deleted: 1; 3245 bytes @@ -1581,6 +1581,7 @@ ../refman-common/images/published/replicas-groups-1-1.png \ ../refman-common/images/published/replicas-groups-1-2.png \ ../refman-common/images/published/rolling-restarts.png \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/images/published/scaleout.png \ ../refman-common/images/published/se-federated-structure.png \ ../refman-common/images/published/stdlb.png \ @@ -1785,6 +1786,7 @@ ../refman-common/images/published/replicas-groups-1-1.png \ ../refman-common/images/published/replicas-groups-1-2.png \ ../refman-common/images/published/rolling-restarts.png \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/images/published/scaleout.png \ ../refman-common/images/published/se-federated-structure.png \ ../refman-common/images/published/stdlb.png \ @@ -2877,10 +2879,12 @@ replication_notes_INCLUDES = \ ../common/fixedchars.ent \ ../common/phrases.ent \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/urls.ent \ all-entities.ent \ versions.ent -replication_notes_IMAGES = +replication_notes_IMAGES = \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png replication_notes_SOURCES = replication-notes.xml $(replication_notes_INCLUDES) replication_notes_IDMAPS = \ ../refman-5.1/metadata/data-types.idmap \ @@ -2896,6 +2900,7 @@ ../refman-5.1/metadata/se-innodb-core.idmap \ ../refman-5.1/metadata/se-memory.idmap \ ../refman-5.1/metadata/sql-syntax-server-administration.idmap \ + ../refman-5.1/metadata/sql-syntax-transactions.idmap \ ../refman-5.1/metadata/stored-programs-views.idmap \ ../refman-common/metadata/bug-reports.idmap replication-notes.validpure: $(replication_notes_SOURCES) @@ -2946,6 +2951,7 @@ ../refman-common/images/published/multi-db.png \ ../refman-common/images/published/redundancy-after.png \ ../refman-common/images/published/redundancy-before.png \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/images/published/scaleout.png \ ../refman-common/images/published/submaster-performance.png \ ../refman-common/urls.ent \ @@ -2959,6 +2965,7 @@ ../refman-common/images/published/multi-db.png \ ../refman-common/images/published/redundancy-after.png \ ../refman-common/images/published/redundancy-before.png \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/images/published/scaleout.png \ ../refman-common/images/published/submaster-performance.png replication_SOURCES = replication.xml $(replication_INCLUDES) @@ -2982,6 +2989,7 @@ ../refman-5.1/metadata/se-memory.idmap \ ../refman-5.1/metadata/sql-syntax-replication.idmap \ ../refman-5.1/metadata/sql-syntax-server-administration.idmap \ + ../refman-5.1/metadata/sql-syntax-transactions.idmap \ ../refman-5.1/metadata/stored-programs-views.idmap \ ../refman-common/metadata/bug-reports.idmap replication.validpure: $(replication_SOURCES) Modified: trunk/refman-5.1/replication-notes.xml =================================================================== --- trunk/refman-5.1/replication-notes.xml 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/refman-5.1/replication-notes.xml 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 13, Lines Added: 701, Lines Deleted: 743; 66478 bytes @@ -39,145 +39,179 @@ </indexterm> <para> - In general, replication compatibility at the SQL level requires - that any features used be supported by both the master and the - slave servers. If you use a feature on a master server that is - available only as of a given version of MySQL, you cannot - replicate to a slave that is older than that version. Such - incompatibilities are likely to occur between series, so that, for - example, you cannot replicate from MySQL ¤t-series; to - &previous-series;. However, these incompatibilities also can occur - for within-series replication. For example, the - <function role="sql">SLEEP()</function> function is available in - MySQL 5.0.12 and up. If you use this function on the master - server, you cannot replicate to a slave server that is older than - MySQL 5.0.12. + The following sections provide information about what is supported + and what is not in MySQL replication, and about specific issues + and situations that may occur when replicating certain statements. </para> <para> - If you are planning to use replication between ¤t-series; - and a previous version of MySQL you should consult the edition of - the MySQL Reference Manual corresponding to the earlier release - series for information regarding the replication characteristics - of that series. + Statement-based replication depends on compatibility at the SQL + level between the master and slave. In others, successful SBR + requires that any SQL features used be supported by both the + master and the slave servers. For example, if you use a feature on + the master server that is available only in MySQL ¤t-series; + (or later), you cannot replicate to a slave that uses MySQL + &previous-series; (or earlier). </para> <para> - The following sections provide details about what is supported and - what is not, and about specific issues and situations that may - occur when replicating certain statements. Additional information - specific to <literal>InnoDB</literal> and replication is given in - <xref linkend="innodb-and-mysql-replication"/>. For information - relating to replication with MySQL Cluster, see - <xref linkend="mysql-cluster-replication"/>. + Such incompatibilities also can occur within a release series when + using pre-production releases of MySQL. For example, the + <function role="sql">SLEEP()</function> function is available + beginning with MySQL 5.0.12. If you use this function on the + master, you cannot replicate to a slave that uses MySQL 5.0.11 or + earlier. </para> <para> + For this reason, we recommend that you use Generally Available + (GA) releases of MySQL for statement-based replication in a + production setting, since we do not introduce new SQL statements + or change their behavior within a given release series once that + series reaches GA release status. + </para> + + <para> + If you are planning to use statement-based replication between + MySQL ¤t-series; and a previous MySQL release series, it is + also a good idea to consult the edition of the <citetitle>MySQL + Reference Manual</citetitle> corresponding to the earlier release + series for information regarding the replication characteristics + of that series. + </para> + + <para> With MySQL's classic statement-based replication, there may be issues with replicating stored routines or triggers. You can avoid these issues by using MySQL's row-based replication instead. For a detailed list of issues, see - <xref linkend="stored-programs-logging"/>. For a description of - row-based replication, see <xref linkend="replication-formats"/>. + <xref linkend="stored-programs-logging"/>. For more information + about row-based replication, see + <xref linkend="replication-formats"/>. </para> + <para> + For additional information specific to replication and + <literal>InnoDB</literal>, see + <xref linkend="innodb-and-mysql-replication"/>. For information + relating to replication with MySQL Cluster, see + <xref linkend="mysql-cluster-replication"/>. + </para> + <section id="replication-features-auto-increment"> <title>Replication and <literal>AUTO_INCREMENT</literal></title> <para> - Replication of <literal>AUTO_INCREMENT</literal>, + Statement-based replication of + <literal>AUTO_INCREMENT</literal>, <function role="sql">LAST_INSERT_ID()</function>, and <literal>TIMESTAMP</literal> values is done correctly, subject - to the following exceptions. + to the following exceptions: </para> - <para> - A stored procedure that uses - <function role="sql">LAST_INSERT_ID()</function> does not - replicate properly using statement-based binary logging. This - limitation is lifted in MySQL 5.1.12. - </para> + <itemizedlist> - <para> - Prior to MySQL 5.1.12, when a stored routine or trigger caused - an <literal>INSERT</literal> into an - <literal>AUTO_INCREMENT</literal> column, the generated - <literal>AUTO_INCREMENT</literal> value was not written into the - binary log, so a different value could in some cases be inserted - on the slave. - </para> + <listitem> + <para> + A stored procedure that uses + <function role="sql">LAST_INSERT_ID()</function> does not + replicate properly using statement-based binary logging. + This limitation is lifted in MySQL 5.1.12. + </para> + </listitem> - <para> - An insert into an <literal>AUTO_INCREMENT</literal> column - caused by a stored routine or trigger running on a master that - uses MySQL 5.0.60 or earlier does not replicate correctly to a - slave running MySQL 5.1.12 through 5.1.23 (inclusive). (Bug - #33029) - </para> + <listitem> + <para> + Prior to MySQL 5.1.12, when a stored routine or trigger + caused an <literal>INSERT</literal> into an + <literal>AUTO_INCREMENT</literal> column, the generated + <literal>AUTO_INCREMENT</literal> value was not written into + the binary log, so a different value could in some cases be + inserted on the slave. + </para> + </listitem> - <para> - Adding an <literal>AUTO_INCREMENT</literal> column to a table - with <literal>ALTER TABLE</literal> might not produce the same - ordering of the rows on the slave and the master. This occurs - because the order in which the rows are numbered depends on the - specific storage engine used for the table and the order in - which the rows were inserted. If it is important to have the - same order on the master and slave, the rows must be ordered - before assigning an <literal>AUTO_INCREMENT</literal> number. - Assuming that you want to add an - <literal>AUTO_INCREMENT</literal> column to the table - <literal>t1</literal>, the following statements produce a new - table <literal>t2</literal> identical to <literal>t1</literal> - but with an <literal>AUTO_INCREMENT</literal> column: - </para> + <listitem> + <para> + An insert into an <literal>AUTO_INCREMENT</literal> column + caused by a stored routine or trigger running on a master + that uses MySQL 5.0.60 or earlier does not replicate + correctly to a slave running MySQL 5.1.12 through 5.1.23 + (inclusive). (Bug #33029) + </para> + </listitem> + <listitem> + <para> + Adding an <literal>AUTO_INCREMENT</literal> column to a + table with <literal>ALTER TABLE</literal> might not produce + the same ordering of the rows on the slave and the master. + This occurs because the order in which the rows are numbered + depends on the specific storage engine used for the table + and the order in which the rows were inserted. If it is + important to have the same order on the master and slave, + the rows must be ordered before assigning an + <literal>AUTO_INCREMENT</literal> number. Assuming that you + want to add an <literal>AUTO_INCREMENT</literal> column to + the table <literal>t1</literal>, the following statements + produce a new table <literal>t2</literal> identical to + <literal>t1</literal> but with an + <literal>AUTO_INCREMENT</literal> column: + </para> + <programlisting> CREATE TABLE t2 LIKE t1; ALTER TABLE t2 ADD id INT AUTO_INCREMENT PRIMARY KEY; INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2; </programlisting> - <para> - This assumes that the table <literal>t1</literal> has columns - <literal>col1</literal> and <literal>col2</literal>. - </para> + <para> + This assumes that the table <literal>t1</literal> has + columns <literal>col1</literal> and <literal>col2</literal>. + </para> - <important> - <para> - To guarantee the same ordering on both master and slave, - <emphasis>all</emphasis> columns of <literal>t1</literal> must - be referenced in the <literal>ORDER BY</literal> clause. - </para> - </important> + <important> + <para> + To guarantee the same ordering on both master and slave, + <emphasis>all</emphasis> columns of <literal>t1</literal> + must be referenced in the <literal>ORDER BY</literal> + clause. + </para> + </important> - <para> - The instructions just given are subject to the limitations of - <literal>CREATE TABLE ... LIKE</literal>: Foreign key - definitions are ignored, as are the <literal>DATA - DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> table - options. If a table definition includes any of those - characteristics, create <literal>t2</literal> using a - <literal>CREATE TABLE</literal> statement that is identical to - the one used to create <literal>t1</literal>, but with the - addition of the <literal>AUTO_INCREMENT</literal> column. - </para> + <para> + The instructions just given are subject to the limitations + of <literal>CREATE TABLE ... LIKE</literal>: Foreign key + definitions are ignored, as are the <literal>DATA + DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> + table options. If a table definition includes any of those + characteristics, create <literal>t2</literal> using a + <literal>CREATE TABLE</literal> statement that is identical + to the one used to create <literal>t1</literal>, but with + the addition of the <literal>AUTO_INCREMENT</literal> + column. + </para> - <para> - Regardless of the method used to create and populate the copy - having the <literal>AUTO_INCREMENT</literal> column, the final - step is to drop the original table and then rename the copy: - </para> + <para> + Regardless of the method used to create and populate the + copy having the <literal>AUTO_INCREMENT</literal> column, + the final step is to drop the original table and then rename + the copy: + </para> <programlisting> DROP t1; ALTER TABLE t2 RENAME t1; </programlisting> - <para> - See also <xref linkend="alter-table-problems"/>. - </para> + <para> + See also <xref linkend="alter-table-problems"/>. + </para> + </listitem> + </itemizedlist> + </section> <section id="replication-features-charset"> @@ -253,243 +287,596 @@ <title>Replication of <literal>CREATE TABLE ... SELECT</literal> Statements</title> <para> - The following rules and decisions are applied when a + This section discusses the rules that are applied when a <literal>CREATE TABLE ... SELECT</literal> statement is - replicated: + replicated. </para> - <itemizedlist> + <note> + <para> + <literal>CREATE TABLE ... SELECT</literal> always performs an + implicit commit (<xref linkend="implicit-commit"/>). + </para> + </note> - <listitem> - <para> - All <literal>CREATE TABLE ... SELECT</literal> statements do - implicit commit. - </para> - </listitem> + <formalpara> - <listitem> - <para> - If there are no failures, then all <literal>CREATE TABLE ... - SELECT</literal> statements are replicated as follows: - </para> + <title>Statement succeeds</title> + <para> + If the <literal>CREATE TABLE ... SELECT</literal> statement + succeeds on the master, then it is replicated as follows: + <itemizedlist> <listitem> - <para> - For <literal>STATEMENT</literal> and - <literal>MIXED</literal> format, as the <literal>CREATE - TABLE ... SELECT</literal> statement itself. - </para> + <formalpara> + + <title><literal>STATEMENT</literal> or <literal>MIXED</literal> format</title> + + <para> + The <literal>CREATE TABLE ... SELECT</literal> + statement is itself replicated. + </para> + + </formalpara> </listitem> <listitem> - <para> - For <literal>ROW</literal> format, as a <literal>CREATE - TABLE</literal> statement followed by binwrite events. - </para> + <formalpara> + + <title><literal>ROW</literal> format</title> + + <para> + The statement is replicated as a <literal>CREATE + TABLE</literal> statement followed by a series of + <literal>binwrite</literal> events (that is, binary + inserts). + </para> + + </formalpara> </listitem> </itemizedlist> - </listitem> + </para> - <listitem> - <para> - Requirements for <literal>CREATE TABLE t2 SELECT - ...</literal> using both transactional and non-transactional - tables: - </para> + </formalpara> + <formalpara> + + <title>Statement fails</title> + + <para> + The failure of a <literal>CREATE TABLE ... SELECT</literal> is + handled according to the following criteria: + <itemizedlist> <listitem> - <para> - For <literal>STATEMENT</literal>, - <literal>MIXED</literal>, and <literal>ROW</literal> - formats: - </para> + <formalpara> - <itemizedlist> + <title>No <literal>IF NOT EXISTS</literal> option</title> - <listitem> - <para> - If the table already exists, then the statement does - nothing on the master, and only the implicit commit - is logged. - </para> - </listitem> + <para> + If the <literal>CREATE TABLE ... SELECT</literal> does + not contain an <literal>IF NOT EXISTS</literal> + option, then the statement has no effect. However, the + implicit commit caused by the statement is logged. + This is true regardless of the replication format, + storage engine used, and the reason for which the + statement failed. + </para> - <listitem> - <para> - If other execution failure (and thus - <literal>t2</literal> did not exist), then the table - is never created on master and only the implicit - commit is logged. - </para> - </listitem> + </formalpara> + </listitem> - </itemizedlist> + <listitem> + <formalpara> + + <title>Statement uses <literal>IF NOT EXISTS</literal></title> + + <para> + If the <literal>CREATE TABLE ... SELECT</literal> + statement includes the <literal>IF NOT + EXISTS</literal> option and fails, the failure is + handled according to the replication format. If the + row-based format is in use, the action taken depends + additionally on whether or not the table to be created + uses a transactional or non-transactional storage + engine, and on the reason for the failure: + + <itemizedlist> + + <listitem> + <formalpara> + + <title><literal>STATEMENT</literal> or <literal>MIXED</literal> format</title> + + <para> + When using statement-based or mixed-format + replication, the <literal>CREATE TABLE IF NOT + EXISTS ... SELECT</literal> is logged with an + error. + </para> + + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title><literal>ROW</literal> format</title> + + <para> + When row-based replication is used, failure of + a <literal>CREATE TABLE ... SELECT</literal> + that includes <literal>IF NOT EXISTS</literal> + is handled differently depending on the reason + for the failure, as shown in the following + diagram: + + <mediaobject> + <imageobject> + <imagedata contentwidth="514" contentdepth="241" fileref="../refman-common/images/published/rpl-create-select-failure-rbr.png" format="PNG"/> + </imageobject> + <textobject> + <phrase lang="en"><literal>CREATE TABLE IF + NOT EXISTS ... SELECT</literal> Failure + Handling (RBR)</phrase> + </textobject> + </mediaobject> + </para> + + </formalpara> + </listitem> + + </itemizedlist> + </para> + + </formalpara> </listitem> </itemizedlist> - </listitem> + </para> - <listitem> - <para> - Requirements for <literal>CREATE TABLE IF NOT EXISTS t2 - SELECT ...</literal> - </para> + </formalpara> + </section> + + <section id="replication-features-differing-tables"> + + <title>Replication with Differing Tables on Master and Slave</title> + + <para> + Starting with MySQL 5.1.21, source and target tables for + replication do not have to be identical. A table on the master + can have more or fewer columns than the slave's copy of the + table. In addition — subject to certain conditions — + corresponding table columns on the master and the slave can use + different data types. + </para> + + <para> + In all cases where the source and target tables do not have + identical definitions, the following must be true in order for + replication to work: + + <itemizedlist> + + <listitem> + <para> + You must be using row-based replication. (Using + <literal>MIXED</literal> for the binary logging format + does not work.) + </para> + </listitem> + + <listitem> + <para> + The database and table names must be the same on both the + master and the slave. + </para> + </listitem> + + </itemizedlist> + + Additional conditions are discussed (and examples provided) in + the following two sections. + </para> + + <section id="replication-features-more-columns"> + + <title>Replication with More Columns on Master or Slave</title> + + <para> + Starting with MySQL 5.1.21, you can replicate a table from the + master to the slave such that the master's copy of the + table and the slave's copy of the table do not have the + same number of columns, subject to the following conditions: + <itemizedlist> <listitem> <para> - For <literal>STATEMENT</literal> and - <literal>MIXED</literal> format: + Each <quote>extra</quote> column in the version of the + table having more columns must have a default value. </para> + <note> + <para> + A column's default value is determined by a + number of factors, including its type, whether it is + defined with a <literal>DEFAULT</literal> option, + whether it is declared as <literal>NULL</literal>, and + the server SQL mode in effect at the time of its + creation; see <xref linkend="data-type-defaults"/>), + for more information. + </para> + </note> + </listitem> + + <listitem> <para> - If execution failure, then statement is logged with - error code. + Matching columns must be defined in the same order on + both the master and the slave. </para> </listitem> <listitem> <para> - For <literal>ROW</literal> format when t2 is - transactional: + Any additional columns must be defined following the + matching columns. </para> + </listitem> - <itemizedlist> + </itemizedlist> - <listitem> - <para> - If table already exists, then - </para> + In addition, when the slave's copy of the table has more + columns than the master's copy, then each matching column + must use the same data type. + </para> - <itemizedlist> + <formalpara> - <listitem> - <para> - The <literal>CREATE TABLE</literal> part of the - statement is not logged. - </para> - </listitem> + <title>Examples</title> - <listitem> - <para> - All applied rows are logged. - </para> - </listitem> + <para> + The following examples illustrate some valid and invalid + table definitions: - <listitem> - <para> - The implicit commit is logged. - </para> - </listitem> + <itemizedlist> - </itemizedlist> - </listitem> + <listitem> + <formalpara> - <listitem> + <title>More columns on the master</title> + <para> - If other failure in creating table, then only the - implicit commit is logged. + The following table definitions are valid: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +</programlisting> + + The following table definitions would raise Error + 1532 + (<errorname>ER_BINLOG_ROW_RBR_TO_SBR</errorname>) + because the definitions of the columns common to + both versions of the table are in a different order + on the slave than they are on the master: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c2 INT, c1 INT);</userinput> +</programlisting> + + The following table definitions would also raise + Error 1532, because the definition of the extra + column on the master appears before the definitions + of the columns common to both versions of the table: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +</programlisting> </para> - </listitem> - <listitem> + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title>More columns on the slave</title> + <para> - If failure in selecting or inserting (but create - succeeded), then the table is dropped on master and - only the implicit commit is logged. + The following definitions replicate correctly: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> + </programlisting> + + The following definitions raise Error 1532 because + the columns common to both versions of the table are + not defined in the same order on both the master and + the slave: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c2 INT, c1 INT, c3 INT);</userinput> +</programlisting> + + The following table definitions also raise Error + 1532 because the definition for the extra column in + the slave's version of the table appears before + the definitions for the columns which are common to + both versions of the table: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput> +</programlisting> + + The following table definitions fail, because the + slave's version of the table has additional + columns compared to the master's version, and + the two versions of the table define column + <literal>c2</literal> as a different data type. + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 BIGINT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> +</programlisting> </para> - </listitem> - </itemizedlist> + </formalpara> + </listitem> + + </itemizedlist> + </para> + + </formalpara> + + </section> + + <section id="replication-features-different-data-types"> + + <title>Replication of Columns Having Different Data Types</title> + + <para> + Corresponding columns on the master's and the + slave's copies of the same table ideally should have the + same data type. However, beginning with MySQL 5.1.21, this is + not always strictly enforced, as long as certain conditions + are met. These conditions are listed here: + + <itemizedlist> + + <listitem> + <para> + The slave's copy of the table cannot contain more + columns than the master's copy. + </para> </listitem> <listitem> <para> - For <literal>ROW</literal> format when t2 is - non-transactional: + <indexterm> + <primary>attribute promotion</primary> + <secondary>replication</secondary> + </indexterm> + + <indexterm> + <primary>replication</primary> + <secondary>attribute promotion</secondary> + </indexterm> + + For columns holding numeric data types, the sizes may + differ, as long as the size of the slave's version + of the column is equal or greater to the size of the + master's version of the column. This is sometimes + referred to as <firstterm>attribute + promotion</firstterm>, because the data type of the + master's version of the column is promoted to a + type that is the same size or larger on the slave. </para> - <itemizedlist> + <para> + Data type conversions currently supported by attribute + promotion are shown in the following table, in which + <replaceable>X</replaceable> and + <replaceable>N</replaceable> both represent positive + integers: - <listitem> - <para> - If table already exists, then: - </para> + <informaltable> + <tgroup cols="2"> + <colspec colwidth="50*"/> + <colspec colwidth="50*"/> + <thead> + <row> + <entry>Original Data Type</entry> + <entry>Promoted Data Type(s)</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>CHAR(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>CHAR(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>VARCHAR(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>VARCHAR(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>CHAR(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>VARCHAR(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>BINARY(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>BINARY(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>VARBINARY(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>VARBINARY(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>BINARY(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>VARBINARY(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>BIT(<replaceable>X</replaceable>) </literal></entry> + <entry><literal>BIT(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>TINYINT</literal></entry> + <entry><literal>SMALLINT</literal>, <literal>MEDIUMINT</literal>, + <literal>INT</literal>, or + <literal>BIGINT</literal></entry> + </row> + <row> + <entry><literal>SMALLINT</literal></entry> + <entry><literal>MEDIUMINT</literal>, <literal>INT</literal>, or + <literal>BIGINT</literal></entry> + </row> + <row> + <entry><literal>MEDIUMINT</literal></entry> + <entry><literal>INT</literal> or <literal>BIGINT</literal></entry> + </row> + <row> + <entry><literal>INT</literal></entry> + <entry><literal>BIGINT</literal></entry> + </row> + </tbody> + </tgroup> + </informaltable> - <itemizedlist> + Unsigned integer columns can be promoted to larger + unsigned types; for example, a column declared as + <literal>TINYINT UNSIGNED</literal> can be restored to a + column declared as <literal>SMALLINT UNSIGNED</literal>, + <literal>MEDIUMINT UNSIGNED</literal>, <literal>INT + UNSIGNED</literal>, or <literal>BIGINT + UNSIGNED</literal>. You cannot promote a signed column + to an unsigned type, or an unsigned column to a signed + type. + </para> - <listitem> - <para> - the <literal>CREATE TABLE</literal> part of the - statement is not logged. - </para> - </listitem> + <para> + For columns holding numeric data types the sizes may + differ, as long as the size of the slave's version + of the column is equal or greater to the size of the + master's version of the column. For example, the + following table definitions are allowed: - <listitem> - <para> - All applied rows are logged. - </para> - </listitem> +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 TINYINT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +</programlisting> - <listitem> - <para> - The implicit commit is logged. - </para> - </listitem> + The slave's versions of both columns + <literal>c1</literal> and <literal>c2</literal> are the + same size as or larger than the master's versions + of these columns. However, the following definitions + would fail: - </itemizedlist> - </listitem> +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(8,3));</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(7,3));</userinput> +</programlisting> - <listitem> - <para> - If other failure in creating table, then only the - implicit commit is logged. - </para> - </listitem> + In this case, Error 1532 would be raised because the + master's copy of column <literal>c2</literal> is + larger than its counterpart on the slave — that + is, the master's copy of <literal>c2</literal> on + the master can hold more digits than the slave's + copy of the column. + </para> + </listitem> - <listitem> - <para> - If failure in selecting or inserting (but create - succeeded), then: - </para> + <listitem> + <para> + There is no conversion between integer + (<literal>TINYINT</literal>, + <literal>SMALLINT</literal>, + <literal>MEDIUMINT</literal>, and so on) and non-integer + (<literal>FLOAT</literal>, <literal>DOUBLE</literal>, + <literal>DECIMAL</literal>, and so on) numeric data + types, and so the following definitions would fail with + Error 1532: - <itemizedlist> +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(8,3));</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 BIGINT);</userinput> +</programlisting> - <listitem> - <para> - The <literal>CREATE TABLE</literal> part of the - statement is logged. - </para> - </listitem> + A column using a non-integer numeric data type must + always have the same definition on both the master and + the slave. + </para> + </listitem> - <listitem> - <para> - All applied rows are logged. - </para> - </listitem> + <listitem> + <para> + For columns storing <literal>CHAR</literal> and + <literal>BINARY</literal> data, the size of the + slave's copy of the column must be equal to or + greater than the size of the master's copy. For + example, the following table definitions would replicate + successfully: - <listitem> - <para> - The implicit commit is logged. - </para> - </listitem> +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(30));</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(50));</userinput> +</programlisting> - </itemizedlist> - </listitem> + If the size of the master's version of the column + is greater than that of the slave's version of the + column, replication fails with Error 1532. + </para> + </listitem> - </itemizedlist> + <listitem> + <para> + The replication process can convert freely between + <literal>BINARY</literal>, <literal>VARBINARY</literal>, + <literal>CHAR</literal> and <literal>VARCHAR</literal> + columns, as long as the slave's version of the + column is the same size as or larger than the + master's version. For example, the following table + definitions can be used successfully: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 VARBINARY(30));</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(30));</userinput> +</programlisting> + </para> + + <note> + <para> + Since replication is currently not supported between + different character sets, it is sufficient when + comparing sizes of columns containing character data + to count the number of characters rather than the + number of bytes. + </para> + </note> </listitem> + <listitem> + <para> + Attribute promotion can be used with both + statement-based and row-based replication, and is not + dependent on the storage engine used by either the + master or the slave. + </para> + </listitem> + </itemizedlist> - </listitem> + </para> - </itemizedlist> + </section> </section> @@ -503,16 +890,20 @@ TABLE</literal> statement on the master server, the table option is also used on the slave. This can cause problems if no corresponding directory exists in the slave host filesystem or - if it exists but is not accessible to the slave server. MySQL - supports an <literal>sql_mode</literal> option called - <literal>NO_DIR_IN_CREATE</literal>. If the slave server is run - with this SQL mode enabled, it ignores the <literal>DATA - DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> table - options when replicating <literal>CREATE TABLE</literal> - statements. The result is that <literal>MyISAM</literal> data - and index files are created in the table's database directory. + if it exists but is not accessible to the slave server. This can + be overridden by using the <literal>NO_DIR_IN_CREATE</literal> + server SQL mode on the slave, which causes the slave to ignore + the <literal>DATA DIRECTORY</literal> and <literal>INDEX + DIRECTORY</literal> table options when replicating + <literal>CREATE TABLE</literal> statements. The result is that + <literal>MyISAM</literal> data and index files are created in + the table's database directory. </para> + <para> + For more information, see <xref linkend="server-sql-mode"/>. + </para> + </section> <section id="replication-features-invoked"> @@ -766,14 +1157,16 @@ <title>Replication with Floating-Point Values</title> <para> - Floating-point values are approximate, so comparisons involving - them are inexact. This is true for operations that use - floating-point values explicitly, or values that are converted - to floating-point implicitly. Comparisons of floating-point - values might yield different results on master and slave servers - due to differences in computer architecture, the compiler used - to build MySQL, and so forth. See - <xref linkend="type-conversion"/>, and + With statement-based replication, values are converted from + decimal to binary. Because conversions between decimal and + binary representations of them may be approximate, comparisons + involving floating-point values are inexact. This is true for + operations that use floating-point values explicitly, or that + use values that are converted to floating-point implicitly. + Comparisons of floating-point values might yield different + results on master and slave servers due to differences in + computer architecture, the compiler used to build MySQL, and so + forth. See <xref linkend="type-conversion"/>, and <xref linkend="problems-with-float"/>. </para> @@ -794,17 +1187,21 @@ <literal>OPTIMIZE TABLE</literal>, and <literal>REPAIR TABLE</literal> statements are written to the binary log and thus replicated to slaves. This is not normally a problem - because these statements do not modify table data. However, this - can cause difficulties under certain circumstances. If you - replicate the privilege tables in the <literal>mysql</literal> - database and update those tables directly without using - <literal>GRANT</literal>, you must issue a <literal>FLUSH - PRIVILEGES</literal> on the slaves to put the new privileges - into effect. In addition, if you use <literal>FLUSH - TABLES</literal> when renaming a <literal>MyISAM</literal> table - that is part of a <literal>MERGE</literal> table, you must issue - <literal>FLUSH TABLES</literal> manually on the slaves. These - statements are written to the binary log unless you specify + because these statements do not modify table data. + </para> + + <para> + However, this behavior can cause difficulties under certain + circumstances. If you replicate the privilege tables in the + <literal>mysql</literal> database and update those tables + directly without using <literal>GRANT</literal>, you must issue + a <literal>FLUSH PRIVILEGES</literal> on the slaves to put the + new privileges into effect. In addition, if you use + <literal>FLUSH TABLES</literal> when renaming a + <literal>MyISAM</literal> table that is part of a + <literal>MERGE</literal> table, you must issue <literal>FLUSH + TABLES</literal> manually on the slaves. These statements are + written to the binary log unless you specify <literal>NO_WRITE_TO_BINLOG</literal> or its alias <literal>LOCAL</literal>. </para> @@ -1222,7 +1619,7 @@ For listings of reserved words by MySQL version, see <ulink url="http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-optvar.html">Reserved - Words</ulink>,.in the <citetitle>MySQL Server Version + Words</ulink>, in the <citetitle>MySQL Server Version Reference</citetitle>. </para> @@ -1242,19 +1639,6 @@ <literal>START SLAVE</literal>. </para> - <formalpara role="mnmas"> - - <title>MySQL Enterprise</title> - - <para> - For instant notification when a slave thread terminates - subscribe to the MySQL Enterprise Monitor. For more - information see - <ulink url="&base-url-enterprise;advisors.html"/>. - </para> - - </formalpara> - </section> <section id="replication-features-slaveshutdown"> @@ -1494,440 +1878,6 @@ </section> - <section id="replication-features-differing-tables"> - - <title>Replication with Differing Tables on Master and Slave</title> - - <para> - Starting with MySQL 5.1.21, source and target tables for - replication do not have to be identical. A table on the master - can have more or fewer columns than the slave's copy of the - table. In addition — subject to certain conditions — - corresponding table columns on the master and the slave can use - different data types. - </para> - - <para> - In all cases where the source and target tables do not have - identical definitions, the following must be true in order for - replication to work: - - <itemizedlist> - - <listitem> - <para> - You must be using row-based replication. (Using - <literal>MIXED</literal> for the binary logging format - does not work.) - </para> - </listitem> - - <listitem> - <para> - The database and table names must be the same on both the - master and the slave. - </para> - </listitem> - - </itemizedlist> - - Additional conditions are discussed (and examples provided) in - the following two sections. - </para> - - <section id="replication-features-more-columns"> - - <title>Replication with More Columns on Master or Slave</title> - - <para> - Starting with MySQL 5.1.21, you can replicate a table from the - master to the slave such that the master's copy of the - table and the slave's copy of the table do not have the - same number of columns, subject to the following conditions: - - <itemizedlist> - - <listitem> - <para> - Each <quote>extra</quote> column in the version of the - table having more columns must have a default value. - </para> - - <note> - <para> - A column's default value is determined by a - number of factors, including its type, whether it is - defined with a <literal>DEFAULT</literal> option, - whether it is declared as <literal>NULL</literal>, and - the server SQL mode in effect at the time of its - creation; see <xref linkend="data-type-defaults"/>), - for more information. - </para> - </note> - </listitem> - - <listitem> - <para> - Matching columns must be defined in the same order on - both the master and the slave. - </para> - </listitem> - - <listitem> - <para> - Any additional columns must be defined following the - matching columns. - </para> - </listitem> - - </itemizedlist> - - In addition, when the slave's copy of the table has more - columns than the master's copy, then each matching column - must use the same data type. - </para> - - <formalpara> - - <title>Examples</title> - - <para> - The following examples illustrate some valid and invalid - table definitions: - - <itemizedlist> - - <listitem> - <formalpara> - - <title>More columns on the master</title> - - <para> - The following table definitions are valid: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -</programlisting> - - The following table definitions would raise Error - 1532 - (<errorname>ER_BINLOG_ROW_RBR_TO_SBR</errorname>) - because the definitions of the columns common to - both versions of the table are in a different order - on the slave than they are on the master: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c2 INT, c1 INT);</userinput> -</programlisting> - - The following table definitions would also raise - Error 1532, because the definition of the extra - column on the master appears before the definitions - of the columns common to both versions of the table: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -</programlisting> - </para> - - </formalpara> - </listitem> - - <listitem> - <formalpara> - - <title>More columns on the slave</title> - - <para> - The following definitions replicate correctly: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> - </programlisting> - - The following definitions raise Error 1532 because - the columns common to both versions of the table are - not defined in the same order on both the master and - the slave: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c2 INT, c1 INT, c3 INT);</userinput> -</programlisting> - - The following table definitions also raise Error - 1532 because the definition for the extra column in - the slave's version of the table appears before - the definitions for the columns which are common to - both versions of the table: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput> -</programlisting> - - The following table definitions fail, because the - slave's version of the table has additional - columns compared to the master's version, and - the two versions of the table define column - <literal>c2</literal> as a different data type. - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 BIGINT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> -</programlisting> - </para> - - </formalpara> - </listitem> - - </itemizedlist> - </para> - - </formalpara> - - </section> - - <section id="replication-features-different-data-types"> - - <title>Replication of Columns Having Different Data Types</title> - - <para> - Corresponding columns on the master's and the - slave's copies of the same table ideally should have the - same data type. However, beginning with MySQL 5.1.21, this is - not always strictly enforced, as long as certain conditions - are met. These conditions are listed here: - - <itemizedlist> - - <listitem> - <para> - The slave's copy of the table cannot contain more - columns than the master's copy. - </para> - </listitem> - - <listitem> - <para> - <indexterm> - <primary>attribute promotion</primary> - <secondary>replication</secondary> - </indexterm> - - <indexterm> - <primary>replication</primary> - <secondary>attribute promotion</secondary> - </indexterm> - - For columns holding numeric data types, the sizes may - differ, as long as the size of the slave's version - of the column is equal or greater to the size of the - master's version of the column. This is sometimes - referred to as <firstterm>attribute - promotion</firstterm>, because the data type of the - master's version of the column is promoted to a - type that is the same size or larger on the slave. - </para> - - <para> - Data type conversions currently supported by attribute - promotion are shown in the following table, in which - <replaceable>X</replaceable> and - <replaceable>N</replaceable> both represent positive - integers: - - <informaltable> - <tgroup cols="2"> - <colspec colwidth="50*"/> - <colspec colwidth="50*"/> - <thead> - <row> - <entry>Original Data Type</entry> - <entry>Promoted Data Type(s)</entry> - </row> - </thead> - <tbody> - <row> - <entry><literal>CHAR(<replaceable>X</replaceable>)</literal></entry> - <entry><literal>CHAR(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> - </row> - <row> - <entry><literal>VARCHAR(<replaceable>X</replaceable>)</literal></entry> - <entry><literal>VARCHAR(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> - </row> - <row> - <entry><literal>CHAR(<replaceable>X</replaceable>)</literal></entry> - <entry><literal>VARCHAR(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> - </row> - <row> - <entry><literal>BINARY(<replaceable>X</replaceable>)</literal></entry> - <entry><literal>BINARY(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> - </row> - <row> - <entry><literal>VARBINARY(<replaceable>X</replaceable>)</literal></entry> - <entry><literal>VARBINARY(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> - </row> - <row> - <entry><literal>BINARY(<replaceable>X</replaceable>)</literal></entry> - <entry><literal>VARBINARY(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> - </row> - <row> - <entry><literal>BIT(<replaceable>X</replaceable>) </literal></entry> - <entry><literal>BIT(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> - </row> - <row> - <entry><literal>TINYINT</literal></entry> - <entry><literal>SMALLINT</literal>, <literal>MEDIUMINT</literal>, - <literal>INT</literal>, or - <literal>BIGINT</literal></entry> - </row> - <row> - <entry><literal>SMALLINT</literal></entry> - <entry><literal>MEDIUMINT</literal>, <literal>INT</literal>, or - <literal>BIGINT</literal></entry> - </row> - <row> - <entry><literal>MEDIUMINT</literal></entry> - <entry><literal>INT</literal> or <literal>BIGINT</literal></entry> - </row> - <row> - <entry><literal>INT</literal></entry> - <entry><literal>BIGINT</literal></entry> - </row> - </tbody> - </tgroup> - </informaltable> - - Unsigned integer columns can be promoted to larger - unsigned types; for example, a column declared as - <literal>TINYINT UNSIGNED</literal> can be restored to a - column declared as <literal>SMALLINT UNSIGNED</literal>, - <literal>MEDIUMINT UNSIGNED</literal>, <literal>INT - UNSIGNED</literal>, or <literal>BIGINT - UNSIGNED</literal>. You cannot promote a signed column - to an unsigned type, or an unsigned column to a signed - type. - </para> - - <para> - For example, the following table definitions are - allowed: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 TINYINT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -</programlisting> - - The slave's versions of both columns - <literal>c1</literal> and <literal>c2</literal> are the - same size as or larger than the master's versions - of these columns. However, the following definitions - would fail: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(8,3));</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(7,3));</userinput> -</programlisting> - - In this case, Error 1532 would be raised because the - master's copy of column <literal>c2</literal> is - larger than its counterpart on the slave — that - is, the master's copy of <literal>c2</literal> on - the master can hold more digits than the slave's - copy of the column. - </para> - </listitem> - - <listitem> - <para> - There is no conversion between integer - (<literal>TINYINT</literal>, - <literal>SMALLINT</literal>, - <literal>MEDIUMINT</literal>, and so on) and non-integer - (<literal>FLOAT</literal>, <literal>DOUBLE</literal>, - <literal>DECIMAL</literal>, and so on) numeric data - types, and so the following definitions would fail with - Error 1532: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(8,3));</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 BIGINT);</userinput> -</programlisting> - - A column using a non-integer numeric data type must - always have the same definition on both the master and - the slave. - </para> - </listitem> - - <listitem> - <para> - For columns storing <literal>CHAR</literal> and - <literal>BINARY</literal> data, the size of the - slave's copy of the column must be equal to or - greater than the size of the master's copy. For - example, the following table definitions would replicate - successfully: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(30));</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(50));</userinput> -</programlisting> - - If the size of the master's version of the column - is greater than that of the slave's version of the - column, replication fails with Error 1532. - </para> - </listitem> - - <listitem> - <para> - The replication process can convert freely between - <literal>BINARY</literal>, <literal>VARBINARY</literal>, - <literal>CHAR</literal> and <literal>VARCHAR</literal> - columns, as long as the slave's version of the - column is the same size as or larger than the - master's version. For example, the following table - definitions can be used successfully: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 VARBINARY(30));</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(30));</userinput> -</programlisting> - </para> - - <note> - <para> - Since replication is currently not supported between - different character sets, it is sufficient when - comparing sizes of columns containing character data - to count the number of characters rather than the - number of bytes. - </para> - </note> - </listitem> - - <listitem> - <para> - Attribute promotion can be used with both - statement-based and row-based replication, and is not - dependent on the storage engine used by either the - master or the slave. - </para> - </listitem> - - </itemizedlist> - </para> - - </section> - - </section> - <section id="replication-features-variables"> <title>Replication and Variables</title> @@ -2074,6 +2024,11 @@ </para> </formalpara> + + <para> + For more information about row-based replication, see + <xref linkend="replication-formats"/>. + </para> </listitem> <listitem> @@ -2089,6 +2044,15 @@ </para> </formalpara> + + <para> + However, if both the master and the slave support row-based + replication, and there are no data definition statements to be + replicated that depend on SQL features found on the master but + not on the slave, then you can use row-based replication to + replicate the effects of data modification statements even if + the DDL run on the master is not supported on the slave. + </para> </listitem> </itemizedlist> @@ -2164,18 +2128,6 @@ <title>Replication FAQ</title> - <formalpara role="mnmas"> - - <title>MySQL Enterprise</title> - - <para> - For expert advice on replication subscribe to the MySQL - Enterprise Monitor. For more information, see - <ulink url="&base-url-enterprise;advisors.html"/>. - </para> - - </formalpara> - <qandaset> <qandaentry> @@ -2689,8 +2641,13 @@ </programlisting> <para> - The value will be either <literal>STATEMENT</literal> or - <literal>ROW</literal>. + The value shown is one of <literal>STATEMENT</literal>, + <literal>ROW</literal>, or <literal>MIXED</literal>. When + <literal>MIXED</literal> mode is in use, row-based + replication is preferred but replication switches + automatically to statement-based format under certain + conditions; see <xref linkend="binary-log-mixed"/>, for + information about when this may occur. </para> </answer> @@ -2722,8 +2679,9 @@ <question> <para> - How do I prevent GRANT and REVOKE statements from - replicating to slave machines? + How do I prevent <literal>GRANT</literal> and + <literal>REVOKE</literal> statements from replicating to + slave machines? </para> </question> Modified: trunk/refman-5.1-maria/Makefile.depends =================================================================== --- trunk/refman-5.1-maria/Makefile.depends 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/refman-5.1-maria/Makefile.depends 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 2, Lines Added: 2, Lines Deleted: 0; 1364 bytes @@ -368,6 +368,7 @@ ../refman-5.1/../refman-common/images/published/mysql-vstudioplugin-4.png \ ../refman-5.1/../refman-common/images/published/redundancy-after.png \ ../refman-5.1/../refman-common/images/published/redundancy-before.png \ + ../refman-5.1/../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-5.1/../refman-common/images/published/scaleout.png \ ../refman-5.1/../refman-common/images/published/se-federated-structure.png \ ../refman-5.1/../refman-common/images/published/submaster-performance.png \ @@ -556,6 +557,7 @@ ../refman-5.1/../refman-common/images/published/mysql-vstudioplugin-4.png \ ../refman-5.1/../refman-common/images/published/redundancy-after.png \ ../refman-5.1/../refman-common/images/published/redundancy-before.png \ + ../refman-5.1/../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-5.1/../refman-common/images/published/scaleout.png \ ../refman-5.1/../refman-common/images/published/se-federated-structure.png \ ../refman-5.1/../refman-common/images/published/submaster-performance.png \ Modified: trunk/refman-6.0/Makefile.depends =================================================================== --- trunk/refman-6.0/Makefile.depends 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/refman-6.0/Makefile.depends 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 8, Lines Added: 12, Lines Deleted: 1; 3978 bytes @@ -1350,6 +1350,7 @@ ../refman-common/images/published/mysql-vstudioplugin-4.png \ ../refman-common/images/published/redundancy-after.png \ ../refman-common/images/published/redundancy-before.png \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/images/published/scaleout.png \ ../refman-common/images/published/se-federated-structure.png \ ../refman-common/images/published/stdlb.png \ @@ -1523,6 +1524,7 @@ ../refman-common/images/published/mysql-vstudioplugin-4.png \ ../refman-common/images/published/redundancy-after.png \ ../refman-common/images/published/redundancy-before.png \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/images/published/scaleout.png \ ../refman-common/images/published/se-federated-structure.png \ ../refman-common/images/published/stdlb.png \ @@ -1534,6 +1536,7 @@ ../query-browser/metadata/query-browser.idmap \ ../quick-guides/metadata/reservedwords-core.idmap \ ../refman-5.1/metadata/faqs.idmap \ + ../refman-5.1/metadata/mysql-cluster-replication.idmap \ ../refman-5.1/metadata/mysql-cluster-roadmap.idmap \ ../refman-5.1/metadata/mysql-cluster.idmap \ ../refman-5.1/metadata/programs-admin-util-core.idmap \ @@ -2042,12 +2045,15 @@ replication_notes_INCLUDES = \ ../common/fixedchars.ent \ ../common/phrases.ent \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/urls.ent \ all-entities.ent \ versions.ent -replication_notes_IMAGES = +replication_notes_IMAGES = \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png replication_notes_SOURCES = replication-notes.xml $(replication_notes_INCLUDES) replication_notes_IDMAPS = \ + ../refman-5.1/metadata/mysql-cluster-replication.idmap \ ../refman-6.0/metadata/data-types.idmap \ ../refman-6.0/metadata/dba-core.idmap \ ../refman-6.0/metadata/errors-problems.idmap \ @@ -2060,6 +2066,7 @@ ../refman-6.0/metadata/se-innodb-core.idmap \ ../refman-6.0/metadata/se-memory.idmap \ ../refman-6.0/metadata/sql-syntax-server-administration.idmap \ + ../refman-6.0/metadata/sql-syntax-transactions.idmap \ ../refman-6.0/metadata/stored-programs-views.idmap \ ../refman-common/metadata/bug-reports.idmap replication-notes.validpure: $(replication_notes_SOURCES) @@ -2110,6 +2117,7 @@ ../refman-common/images/published/multi-db.png \ ../refman-common/images/published/redundancy-after.png \ ../refman-common/images/published/redundancy-before.png \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/images/published/scaleout.png \ ../refman-common/images/published/submaster-performance.png \ ../refman-common/urls.ent \ @@ -2123,10 +2131,12 @@ ../refman-common/images/published/multi-db.png \ ../refman-common/images/published/redundancy-after.png \ ../refman-common/images/published/redundancy-before.png \ + ../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../refman-common/images/published/scaleout.png \ ../refman-common/images/published/submaster-performance.png replication_SOURCES = replication.xml $(replication_INCLUDES) replication_IDMAPS = \ + ../refman-5.1/metadata/mysql-cluster-replication.idmap \ ../refman-5.1/metadata/mysql-cluster.idmap \ ../refman-6.0/metadata/backup.idmap \ ../refman-6.0/metadata/data-types.idmap \ @@ -2145,6 +2155,7 @@ ../refman-6.0/metadata/se-memory.idmap \ ../refman-6.0/metadata/sql-syntax-replication.idmap \ ../refman-6.0/metadata/sql-syntax-server-administration.idmap \ + ../refman-6.0/metadata/sql-syntax-transactions.idmap \ ../refman-6.0/metadata/stored-programs-views.idmap \ ../refman-common/metadata/bug-reports.idmap replication.validpure: $(replication_SOURCES) Modified: trunk/refman-6.0/replication-notes.xml =================================================================== --- trunk/refman-6.0/replication-notes.xml 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/refman-6.0/replication-notes.xml 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 10, Lines Added: 685, Lines Deleted: 584; 58662 bytes @@ -39,126 +39,179 @@ </indexterm> <para> - In general, replication compatibility at the SQL level requires - that any features used be supported by both the master and the - slave servers. If you use a feature on a master server that is - available only as of a given version of MySQL, you cannot - replicate to a slave that is older than that version. Such - incompatibilities are likely to occur between series, so that, for - example, you cannot replicate from MySQL ¤t-series; to - &previous-series;. However, these incompatibilities also can occur - for within-series replication. For example, the - <function role="sql">SLEEP()</function> function is available in - MySQL 5.0.12 and up. If you use this function on the master - server, you cannot replicate to a slave server that is older than - MySQL 5.0.12. + The following sections provide information about what is supported + and what is not in MySQL replication, and about specific issues + and situations that may occur when replicating certain statements. </para> <para> - If you are planning to use replication between ¤t-series; - and a previous version of MySQL you should consult the edition of - the MySQL Reference Manual corresponding to the earlier release - series for information regarding the replication characteristics - of that series. + Statement-based replication depends on compatibility at the SQL + level between the master and slave. In others, successful SBR + requires that any SQL features used be supported by both the + master and the slave servers. For example, if you use a feature on + the master server that is available only in MySQL ¤t-series; + (or later), you cannot replicate to a slave that uses MySQL + &previous-series; (or earlier). </para> <para> - The following sections provide details about what is supported and - what is not, and about specific issues and situations that may - occur when replicating certain statements. Additional information - specific to <literal>InnoDB</literal> and replication is given in - <xref linkend="innodb-and-mysql-replication"/>. + Such incompatibilities also can occur within a release series when + using pre-production releases of MySQL. For example, the + <function role="sql">SLEEP()</function> function is available + beginning with MySQL 5.0.12. If you use this function on the + master, you cannot replicate to a slave that uses MySQL 5.0.11 or + earlier. </para> <para> + For this reason, we recommend that you use Generally Available + (GA) releases of MySQL for statement-based replication in a + production setting, since we do not introduce new SQL statements + or change their behavior within a given release series once that + series reaches GA release status. + </para> + + <para> + If you are planning to use statement-based replication between + MySQL ¤t-series; and a previous MySQL release series, it is + also a good idea to consult the edition of the <citetitle>MySQL + Reference Manual</citetitle> corresponding to the earlier release + series for information regarding the replication characteristics + of that series. + </para> + + <para> With MySQL's classic statement-based replication, there may be issues with replicating stored routines or triggers. You can avoid these issues by using MySQL's row-based replication instead. For a detailed list of issues, see - <xref linkend="stored-programs-logging"/>. For a description of - row-based replication, see <xref linkend="replication-formats"/>. + <xref linkend="stored-programs-logging"/>. For more information + about row-based replication, see + <xref linkend="replication-formats"/>. </para> + <para> + For additional information specific to replication and + <literal>InnoDB</literal>, see + <xref linkend="innodb-and-mysql-replication"/>. For information + relating to replication with MySQL Cluster, see + <xref linkend="mysql-cluster-replication"/>. + </para> + <section id="replication-features-auto-increment"> <title>Replication and <literal>AUTO_INCREMENT</literal></title> <para> - Replication of <literal>AUTO_INCREMENT</literal>, + Statement-based replication of + <literal>AUTO_INCREMENT</literal>, <function role="sql">LAST_INSERT_ID()</function>, and <literal>TIMESTAMP</literal> values is done correctly, subject - to the following exceptions. + to the following exceptions: </para> - <para> - An insert into an <literal>AUTO_INCREMENT</literal> column - caused by a stored routine or trigger running on a master that - uses MySQL 5.0.60 or earlier does not replicate correctly to a - slave running MySQL 6.0 prior to 6.0.5. (Bug #33029) - </para> + <itemizedlist> - <para> - Adding an <literal>AUTO_INCREMENT</literal> column to a table - with <literal>ALTER TABLE</literal> might not produce the same - ordering of the rows on the slave and the master. This occurs - because the order in which the rows are numbered depends on the - specific storage engine used for the table and the order in - which the rows were inserted. If it is important to have the - same order on the master and slave, the rows must be ordered - before assigning an <literal>AUTO_INCREMENT</literal> number. - Assuming that you want to add an - <literal>AUTO_INCREMENT</literal> column to the table - <literal>t1</literal>, the following statements produce a new - table <literal>t2</literal> identical to <literal>t1</literal> - but with an <literal>AUTO_INCREMENT</literal> column: - </para> + <listitem> + <para> + A stored procedure that uses + <function role="sql">LAST_INSERT_ID()</function> does not + replicate properly using statement-based binary logging. + This limitation is lifted in MySQL 5.1.12. + </para> + </listitem> + <listitem> + <para> + Prior to MySQL 5.1.12, when a stored routine or trigger + caused an <literal>INSERT</literal> into an + <literal>AUTO_INCREMENT</literal> column, the generated + <literal>AUTO_INCREMENT</literal> value was not written into + the binary log, so a different value could in some cases be + inserted on the slave. + </para> + </listitem> + + <listitem> + <para> + An insert into an <literal>AUTO_INCREMENT</literal> column + caused by a stored routine or trigger running on a master + that uses MySQL 5.0.60 or earlier does not replicate + correctly to a slave running MySQL 5.1.12 through 5.1.23 + (inclusive). (Bug #33029) + </para> + </listitem> + + <listitem> + <para> + Adding an <literal>AUTO_INCREMENT</literal> column to a + table with <literal>ALTER TABLE</literal> might not produce + the same ordering of the rows on the slave and the master. + This occurs because the order in which the rows are numbered + depends on the specific storage engine used for the table + and the order in which the rows were inserted. If it is + important to have the same order on the master and slave, + the rows must be ordered before assigning an + <literal>AUTO_INCREMENT</literal> number. Assuming that you + want to add an <literal>AUTO_INCREMENT</literal> column to + the table <literal>t1</literal>, the following statements + produce a new table <literal>t2</literal> identical to + <literal>t1</literal> but with an + <literal>AUTO_INCREMENT</literal> column: + </para> + <programlisting> CREATE TABLE t2 LIKE t1; ALTER TABLE t2 ADD id INT AUTO_INCREMENT PRIMARY KEY; INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2; </programlisting> - <para> - This assumes that the table <literal>t1</literal> has columns - <literal>col1</literal> and <literal>col2</literal>. - </para> + <para> + This assumes that the table <literal>t1</literal> has + columns <literal>col1</literal> and <literal>col2</literal>. + </para> - <important> - <para> - To guarantee the same ordering on both master and slave, - <emphasis>all</emphasis> columns of <literal>t1</literal> must - be referenced in the <literal>ORDER BY</literal> clause. - </para> - </important> + <important> + <para> + To guarantee the same ordering on both master and slave, + <emphasis>all</emphasis> columns of <literal>t1</literal> + must be referenced in the <literal>ORDER BY</literal> + clause. + </para> + </important> - <para> - The instructions just given are subject to the limitations of - <literal>CREATE TABLE ... LIKE</literal>: Foreign key - definitions are ignored, as are the <literal>DATA - DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> table - options. If a table definition includes any of those - characteristics, create <literal>t2</literal> using a - <literal>CREATE TABLE</literal> statement that is identical to - the one used to create <literal>t1</literal>, but with the - addition of the <literal>AUTO_INCREMENT</literal> column. - </para> + <para> + The instructions just given are subject to the limitations + of <literal>CREATE TABLE ... LIKE</literal>: Foreign key + definitions are ignored, as are the <literal>DATA + DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> + table options. If a table definition includes any of those + characteristics, create <literal>t2</literal> using a + <literal>CREATE TABLE</literal> statement that is identical + to the one used to create <literal>t1</literal>, but with + the addition of the <literal>AUTO_INCREMENT</literal> + column. + </para> - <para> - Regardless of the method used to create and populate the copy - having the <literal>AUTO_INCREMENT</literal> column, the final - step is to drop the original table and then rename the copy: - </para> + <para> + Regardless of the method used to create and populate the + copy having the <literal>AUTO_INCREMENT</literal> column, + the final step is to drop the original table and then rename + the copy: + </para> <programlisting> DROP t1; ALTER TABLE t2 RENAME t1; </programlisting> - <para> - See also <xref linkend="alter-table-problems"/>. - </para> + <para> + See also <xref linkend="alter-table-problems"/>. + </para> + </listitem> + </itemizedlist> + </section> <section id="replication-features-charset"> @@ -234,243 +287,596 @@ <title>Replication of <literal>CREATE TABLE ... SELECT</literal> Statements</title> <para> - The following rules and decisions are applied when a + This section discusses the rules that are applied when a <literal>CREATE TABLE ... SELECT</literal> statement is - replicated: + replicated. </para> - <itemizedlist> + <note> + <para> + <literal>CREATE TABLE ... SELECT</literal> always performs an + implicit commit (<xref linkend="implicit-commit"/>). + </para> + </note> - <listitem> - <para> - All <literal>CREATE TABLE ... SELECT</literal> statements do - implicit commit. - </para> - </listitem> + <formalpara> - <listitem> - <para> - If there are no failures, then all <literal>CREATE TABLE ... - SELECT</literal> statements are replicated as follows: - </para> + <title>Statement succeeds</title> + <para> + If the <literal>CREATE TABLE ... SELECT</literal> statement + succeeds on the master, then it is replicated as follows: + <itemizedlist> <listitem> - <para> - For <literal>STATEMENT</literal> and - <literal>MIXED</literal> format, as the <literal>CREATE - TABLE ... SELECT</literal> statement itself. - </para> + <formalpara> + + <title><literal>STATEMENT</literal> or <literal>MIXED</literal> format</title> + + <para> + The <literal>CREATE TABLE ... SELECT</literal> + statement is itself replicated. + </para> + + </formalpara> </listitem> <listitem> - <para> - For <literal>ROW</literal> format, as a <literal>CREATE - TABLE</literal> statement followed by binwrite events. - </para> + <formalpara> + + <title><literal>ROW</literal> format</title> + + <para> + The statement is replicated as a <literal>CREATE + TABLE</literal> statement followed by a series of + <literal>binwrite</literal> events (that is, binary + inserts). + </para> + + </formalpara> </listitem> </itemizedlist> - </listitem> + </para> - <listitem> - <para> - Requirements for <literal>CREATE TABLE t2 SELECT - ...</literal> using both transactional and non-transactional - tables: - </para> + </formalpara> + <formalpara> + + <title>Statement fails</title> + + <para> + The failure of a <literal>CREATE TABLE ... SELECT</literal> is + handled according to the following criteria: + <itemizedlist> <listitem> - <para> - For <literal>STATEMENT</literal>, - <literal>MIXED</literal>, and <literal>ROW</literal> - formats: - </para> + <formalpara> - <itemizedlist> + <title>No <literal>IF NOT EXISTS</literal> option</title> - <listitem> - <para> - If the table already exists, then the statement does - nothing on the master, and only the implicit commit - is logged. - </para> - </listitem> + <para> + If the <literal>CREATE TABLE ... SELECT</literal> does + not contain an <literal>IF NOT EXISTS</literal> + option, then the statement has no effect. However, the + implicit commit caused by the statement is logged. + This is true regardless of the replication format, + storage engine used, and the reason for which the + statement failed. + </para> - <listitem> - <para> - If other execution failure (and thus - <literal>t2</literal> did not exist), then the table - is never created on master and only the implicit - commit is logged. - </para> - </listitem> + </formalpara> + </listitem> - </itemizedlist> + <listitem> + <formalpara> + + <title>Statement uses <literal>IF NOT EXISTS</literal></title> + + <para> + If the <literal>CREATE TABLE ... SELECT</literal> + statement includes the <literal>IF NOT + EXISTS</literal> option and fails, the failure is + handled according to the replication format. If the + row-based format is in use, the action taken depends + additionally on whether or not the table to be created + uses a transactional or non-transactional storage + engine, and on the reason for the failure: + + <itemizedlist> + + <listitem> + <formalpara> + + <title><literal>STATEMENT</literal> or <literal>MIXED</literal> format</title> + + <para> + When using statement-based or mixed-format + replication, the <literal>CREATE TABLE IF NOT + EXISTS ... SELECT</literal> is logged with an + error. + </para> + + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title><literal>ROW</literal> format</title> + + <para> + When row-based replication is used, failure of + a <literal>CREATE TABLE ... SELECT</literal> + that includes <literal>IF NOT EXISTS</literal> + is handled differently depending on the reason + for the failure, as shown in the following + diagram: + + <mediaobject> + <imageobject> + <imagedata contentwidth="514" contentdepth="241" fileref="../refman-common/images/published/rpl-create-select-failure-rbr.png" format="PNG"/> + </imageobject> + <textobject> + <phrase lang="en"><literal>CREATE TABLE IF + NOT EXISTS ... SELECT</literal> Failure + Handling (RBR)</phrase> + </textobject> + </mediaobject> + </para> + + </formalpara> + </listitem> + + </itemizedlist> + </para> + + </formalpara> </listitem> </itemizedlist> - </listitem> + </para> - <listitem> - <para> - Requirements for <literal>CREATE TABLE IF NOT EXISTS t2 - SELECT ...</literal> - </para> + </formalpara> + </section> + + <section id="replication-features-differing-tables"> + + <title>Replication with Differing Tables on Master and Slave</title> + + <para> + Source and target tables for replication do not have to be + identical. A table on the master can have more or fewer columns + than the slave's copy of the table. In addition — + subject to certain conditions — corresponding table + columns on the master and the slave can use different data + types. + </para> + + <para> + In all cases where the source and target tables do not have + identical definitions, the following must be true in order for + replication to work: + + <itemizedlist> + + <listitem> + <para> + You must be using row-based replication. (Using + <literal>MIXED</literal> for the binary logging format + does not work.) + </para> + </listitem> + + <listitem> + <para> + The database and table names must be the same on both the + master and the slave. + </para> + </listitem> + + </itemizedlist> + + Additional conditions are discussed (and examples provided) in + the following two sections. + </para> + + <section id="replication-features-more-columns"> + + <title>Replication with More Columns on Master or Slave</title> + + <para> + You can replicate a table from the master to the slave such + that the master's copy of the table and the slave's + copy of the table do not have the same number of columns, + subject to the following conditions: + <itemizedlist> <listitem> <para> - For <literal>STATEMENT</literal> and - <literal>MIXED</literal> format: + Each <quote>extra</quote> column in the version of the + table having more columns must have a default value. </para> + <note> + <para> + A column's default value is determined by a + number of factors, including its type, whether it is + defined with a <literal>DEFAULT</literal> option, + whether it is declared as <literal>NULL</literal>, and + the server SQL mode in effect at the time of its + creation; see <xref linkend="data-type-defaults"/>), + for more information. + </para> + </note> + </listitem> + + <listitem> <para> - If execution failure, then statement is logged with - error code. + Matching columns must be defined in the same order on + both the master and the slave. </para> </listitem> <listitem> <para> - For <literal>ROW</literal> format when t2 is - transactional: + Any additional columns must be defined following the + matching columns. </para> + </listitem> - <itemizedlist> + </itemizedlist> - <listitem> - <para> - If table already exists, then - </para> + In addition, when the slave's copy of the table has more + columns than the master's copy, then each matching column + must use the same data type. + </para> - <itemizedlist> + <formalpara> - <listitem> - <para> - The <literal>CREATE TABLE</literal> part of the - statement is not logged. - </para> - </listitem> + <title>Examples</title> - <listitem> - <para> - All applied rows are logged. - </para> - </listitem> + <para> + The following examples illustrate some valid and invalid + table definitions: - <listitem> - <para> - The implicit commit is logged. - </para> - </listitem> + <itemizedlist> - </itemizedlist> - </listitem> + <listitem> + <formalpara> - <listitem> + <title>More columns on the master</title> + <para> - If other failure in creating table, then only the - implicit commit is logged. + The following table definitions are valid: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +</programlisting> + + The following table definitions would raise Error + 1532 + (<errorname>ER_BINLOG_ROW_RBR_TO_SBR</errorname>) + because the definitions of the columns common to + both versions of the table are in a different order + on the slave than they are on the master: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c2 INT, c1 INT);</userinput> +</programlisting> + + The following table definitions would also raise + Error 1532, because the definition of the extra + column on the master appears before the definitions + of the columns common to both versions of the table: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +</programlisting> </para> - </listitem> - <listitem> + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title>More columns on the slave</title> + <para> - If failure in selecting or inserting (but create - succeeded), then the table is dropped on master and - only the implicit commit is logged. + The following definitions replicate correctly: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> + </programlisting> + + The following definitions raise Error 1532 because + the columns common to both versions of the table are + not defined in the same order on both the master and + the slave: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c2 INT, c1 INT, c3 INT);</userinput> +</programlisting> + + The following table definitions also raise Error + 1532 because the definition for the extra column in + the slave's version of the table appears before + the definitions for the columns which are common to + both versions of the table: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput> +</programlisting> + + The following table definitions fail, because the + slave's version of the table has additional + columns compared to the master's version, and + the two versions of the table define column + <literal>c2</literal> as a different data type. + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 BIGINT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> +</programlisting> </para> - </listitem> - </itemizedlist> + </formalpara> + </listitem> + + </itemizedlist> + </para> + + </formalpara> + + </section> + + <section id="replication-features-different-data-types"> + + <title>Replication of Columns Having Different Data Types</title> + + <para> + Corresponding columns on the master's and the + slave's copies of the same table should have the same + type. However, this is not always strictly enforced, as long + as certain conditions are met. These conditions are listed + here: + + <itemizedlist> + + <listitem> + <para> + The slave's copy of the table cannot contain more + columns than the master's copy. + </para> </listitem> <listitem> <para> - For <literal>ROW</literal> format when t2 is - non-transactional: + <indexterm> + <primary>attribute promotion</primary> + <secondary>replication</secondary> + </indexterm> + + <indexterm> + <primary>replication</primary> + <secondary>attribute promotion</secondary> + </indexterm> + + For columns holding numeric data types, the sizes may + differ, as long as the size of the slave's version + of the column is equal or greater to the size of the + master's version of the column. This is sometimes + referred to as <firstterm>attribute + promotion</firstterm>, because the data type of the + master's version of the column is promoted to a + type that is the same size or larger on the slave. </para> - <itemizedlist> + <para> + Data type conversions currently supported by attribute + promotion are shown in the following table, in which + <replaceable>X</replaceable> and + <replaceable>N</replaceable> both represent positive + integers: - <listitem> - <para> - If table already exists, then: - </para> + <informaltable> + <tgroup cols="2"> + <colspec colwidth="50*"/> + <colspec colwidth="50*"/> + <thead> + <row> + <entry>Original Data Type</entry> + <entry>Promoted Data Type(s)</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>CHAR(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>CHAR(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>VARCHAR(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>VARCHAR(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>CHAR(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>VARCHAR(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>BINARY(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>BINARY(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>VARBINARY(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>VARBINARY(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>BINARY(<replaceable>X</replaceable>)</literal></entry> + <entry><literal>VARBINARY(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>BIT(<replaceable>X</replaceable>) </literal></entry> + <entry><literal>BIT(<replaceable>X</replaceable>+<replaceable>N</replaceable>)</literal></entry> + </row> + <row> + <entry><literal>TINYINT</literal></entry> + <entry><literal>SMALLINT</literal>, <literal>MEDIUMINT</literal>, + <literal>INT</literal>, or + <literal>BIGINT</literal></entry> + </row> + <row> + <entry><literal>SMALLINT</literal></entry> + <entry><literal>MEDIUMINT</literal>, <literal>INT</literal>, or + <literal>BIGINT</literal></entry> + </row> + <row> + <entry><literal>MEDIUMINT</literal></entry> + <entry><literal>INT</literal> or <literal>BIGINT</literal></entry> + </row> + <row> + <entry><literal>INT</literal></entry> + <entry><literal>BIGINT</literal></entry> + </row> + </tbody> + </tgroup> + </informaltable> - <itemizedlist> + Unsigned integer columns can be promoted to larger + unsigned types; for example, a column declared as + <literal>TINYINT UNSIGNED</literal> can be restored to a + column declared as <literal>SMALLINT UNSIGNED</literal>, + <literal>MEDIUMINT UNSIGNED</literal>, <literal>INT + UNSIGNED</literal>, or <literal>BIGINT + UNSIGNED</literal>. You cannot promote a signed column + to an unsigned type, or an unsigned column to a signed + type. + </para> - <listitem> - <para> - the <literal>CREATE TABLE</literal> part of the - statement is not logged. - </para> - </listitem> + <para> + For columns holding numeric data types the sizes may + differ, as long as the size of the slave's version + of the column is equal or greater to the size of the + master's version of the column. For example, the + following table definitions are allowed: - <listitem> - <para> - All applied rows are logged. - </para> - </listitem> +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 TINYINT, c2 INT);</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> +</programlisting> - <listitem> - <para> - The implicit commit is logged. - </para> - </listitem> + The slave's versions of both columns + <literal>c1</literal> and <literal>c2</literal> are the + same size as or larger than the master's versions + of these columns. However, the following definitions + would fail: - </itemizedlist> - </listitem> +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(8,3));</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(7,3));</userinput> +</programlisting> - <listitem> - <para> - If other failure in creating table, then only the - implicit commit is logged. - </para> - </listitem> + In this case, Error 1532 would be raised because the + master's copy of column <literal>c2</literal> is + larger than its counterpart on the slave — that + is, the master's copy of <literal>c2</literal> on + the master can hold more digits than the slave's + copy of the column. + </para> + </listitem> - <listitem> - <para> - If failure in selecting or inserting (but create - succeeded), then: - </para> + <listitem> + <para> + There is no conversion between integer + (<literal>TINYINT</literal>, + <literal>SMALLINT</literal>, + <literal>MEDIUMINT</literal>, and so on) and non-integer + (<literal>FLOAT</literal>, <literal>DOUBLE</literal>, + <literal>DECIMAL</literal>, and so on) numeric data + types, and so the following definitions would fail with + Error 1532: - <itemizedlist> +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(8,3));</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 BIGINT);</userinput> +</programlisting> - <listitem> - <para> - The <literal>CREATE TABLE</literal> part of the - statement is logged. - </para> - </listitem> + A column using a non-integer numeric data type must + always have the same definition on both the master and + the slave. + </para> + </listitem> - <listitem> - <para> - All applied rows are logged. - </para> - </listitem> + <listitem> + <para> + For columns storing <literal>CHAR</literal> and + <literal>BINARY</literal> data, the size of the + slave's copy of the column must be equal to or + greater than the size of the master's copy. For + example, the following table definitions would replicate + successfully: - <listitem> - <para> - The implicit commit is logged. - </para> - </listitem> +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(30));</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(50));</userinput> +</programlisting> - </itemizedlist> - </listitem> + If the size of the master's version of the column + is greater than that of the slave's version of the + column, replication fails with Error 1532. + </para> + </listitem> - </itemizedlist> + <listitem> + <para> + The replication process can convert freely between + <literal>BINARY</literal>, <literal>VARBINARY</literal>, + <literal>CHAR</literal> and <literal>VARCHAR</literal> + columns, as long as the slave's version of the + column is the same size as or larger than the + master's version. For example, the following table + definitions can be used successfully: + +<programlisting> +master> <userinput>CREATE TABLE t1 (c1 INT, c2 VARBINARY(30));</userinput> +slave> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(30));</userinput> +</programlisting> + </para> + + <note> + <para> + Since replication is currently not supported between + different character sets, it is sufficient when + comparing sizes of columns containing character data + to count the number of characters rather than the + number of bytes. + </para> + </note> </listitem> + <listitem> + <para> + Attribute promotion can be used with both + statement-based and row-based replication, and is not + dependent on the storage engine used by either the + master or the slave. + </para> + </listitem> + </itemizedlist> - </listitem> + </para> - </itemizedlist> + </section> </section> @@ -484,16 +890,20 @@ TABLE</literal> statement on the master server, the table option is also used on the slave. This can cause problems if no corresponding directory exists in the slave host filesystem or - if it exists but is not accessible to the slave server. MySQL - supports an <literal>sql_mode</literal> option called - <literal>NO_DIR_IN_CREATE</literal>. If the slave server is run - with this SQL mode enabled, it ignores the <literal>DATA - DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> table - options when replicating <literal>CREATE TABLE</literal> - statements. The result is that <literal>MyISAM</literal> data - and index files are created in the table's database directory. + if it exists but is not accessible to the slave server. This can + be overridden by using the <literal>NO_DIR_IN_CREATE</literal> + server SQL mode on the slave, which causes the slave to ignore + the <literal>DATA DIRECTORY</literal> and <literal>INDEX + DIRECTORY</literal> table options when replicating + <literal>CREATE TABLE</literal> statements. The result is that + <literal>MyISAM</literal> data and index files are created in + the table's database directory. </para> + <para> + For more information, see <xref linkend="server-sql-mode"/>. + </para> + </section> <section id="replication-features-invoked"> @@ -745,14 +1155,16 @@ <title>Replication with Floating-Point Values</title> <para> - Floating-point values are approximate, so comparisons involving - them are inexact. This is true for operations that use - floating-point values explicitly, or values that are converted - to floating-point implicitly. Comparisons of floating-point - values might yield different results on master and slave servers - due to differences in computer architecture, the compiler used - to build MySQL, and so forth. See - <xref linkend="type-conversion"/>, and + With statement-based replication, values are converted from + decimal to binary. Because conversions between decimal and + binary representations of them may be approximate, comparisons + involving floating-point values are inexact. This is true for + operations that use floating-point values explicitly, or that + use values that are converted to floating-point implicitly. + Comparisons of floating-point values might yield different + results on master and slave servers due to differences in + computer architecture, the compiler used to build MySQL, and so + forth. See <xref linkend="type-conversion"/>, and <xref linkend="problems-with-float"/>. </para> @@ -773,17 +1185,21 @@ <literal>OPTIMIZE TABLE</literal>, and <literal>REPAIR TABLE</literal> statements are written to the binary log and thus replicated to slaves. This is not normally a problem - because these statements do not modify table data. However, this - can cause difficulties under certain circumstances. If you - replicate the privilege tables in the <literal>mysql</literal> - database and update those tables directly without using - <literal>GRANT</literal>, you must issue a <literal>FLUSH - PRIVILEGES</literal> on the slaves to put the new privileges - into effect. In addition, if you use <literal>FLUSH - TABLES</literal> when renaming a <literal>MyISAM</literal> table - that is part of a <literal>MERGE</literal> table, you must issue - <literal>FLUSH TABLES</literal> manually on the slaves. These - statements are written to the binary log unless you specify + because these statements do not modify table data. + </para> + + <para> + However, this behavior can cause difficulties under certain + circumstances. If you replicate the privilege tables in the + <literal>mysql</literal> database and update those tables + directly without using <literal>GRANT</literal>, you must issue + a <literal>FLUSH PRIVILEGES</literal> on the slaves to put the + new privileges into effect. In addition, if you use + <literal>FLUSH TABLES</literal> when renaming a + <literal>MyISAM</literal> table that is part of a + <literal>MERGE</literal> table, you must issue <literal>FLUSH + TABLES</literal> manually on the slaves. These statements are + written to the binary log unless you specify <literal>NO_WRITE_TO_BINLOG</literal> or its alias <literal>LOCAL</literal>. </para> @@ -1062,10 +1478,10 @@ When a slave loses its connection to the master, the slave tries to reconnect immediately and retries periodically if that fails. The default is to retry every 60 seconds. This may be changed - with <literal>CHANGE MASTER TO</literal> statement. A slave also - is able to deal with network connectivity outages. However, the - slave notices the network outage only after receiving no data - from the master for <literal>slave_net_timeout</literal> + with the <literal>CHANGE MASTER TO</literal> statement. A slave + also is able to deal with network connectivity outages. However, + the slave notices the network outage only after receiving no + data from the master for <literal>slave_net_timeout</literal> seconds. If your outages are short, you may want to decrease <literal>slave_net_timeout</literal>. See <xref linkend="server-system-variables"/>. @@ -1166,7 +1582,7 @@ For listings of reserved words by MySQL version, see <ulink url="http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-optvar.html">Reserved - Words</ulink>,.in the <citetitle>MySQL Server Version + Words</ulink>, in the <citetitle>MySQL Server Version Reference</citetitle>. </para> @@ -1435,321 +1851,6 @@ </section> - <section id="replication-features-differing-tables"> - - <title>Replication with Differing Tables on Master and Slave</title> - - <para> - Source and target tables for replication do not have to be - identical. A table on the master can have more or fewer columns - than the slave's copy of the table. In addition — - subject to certain conditions — corresponding table - columns on the master and the slave can use different data - types. - </para> - - <para> - In all cases where the source and target tables do not have - identical definitions, the following must be true in order for - replication to work: - - <itemizedlist> - - <listitem> - <para> - You must be using row-based replication. (Using - <literal>MIXED</literal> for the binary logging format - does not work.) - </para> - </listitem> - - <listitem> - <para> - The database and table names must be the same on both the - master and the slave. - </para> - </listitem> - - </itemizedlist> - - Additional conditions are discussed (and examples provided) in - the following two sections. - </para> - - <section id="replication-features-more-columns"> - - <title>Replication with More Columns on Master or Slave</title> - - <para> - You can replicate a table from the master to the slave such - that the master's copy of the table and the slave's - copy of the table do not have the same number of columns, - subject to the following conditions: - - <itemizedlist> - - <listitem> - <para> - Each <quote>extra</quote> column in the version of the - table having more columns must have a default value. - </para> - - <note> - <para> - A column's default value is determined by a - number of factors, including its type, whether it is - defined with a <literal>DEFAULT</literal> option, - whether it is declared as <literal>NULL</literal>, and - the server SQL mode in effect at the time of its - creation; see <xref linkend="data-type-defaults"/>), - for more information. - </para> - </note> - </listitem> - - <listitem> - <para> - Matching columns must be defined in the same order on - both the master and the slave. - </para> - </listitem> - - <listitem> - <para> - Any additional columns must be defined following the - matching columns. - </para> - </listitem> - - </itemizedlist> - - In addition, when the slave's copy of the table has more - columns than the master's copy, then each matching column - must use the same data type. - </para> - - <formalpara> - - <title>Examples</title> - - <para> - The following examples illustrate some valid and invalid - table definitions: - - <itemizedlist> - - <listitem> - <formalpara> - - <title>More columns on the master</title> - - <para> - The following table definitions are valid: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -</programlisting> - - The following table definitions would raise Error - 1532 - (<errorname>ER_BINLOG_ROW_RBR_TO_SBR</errorname>) - because the definitions of the columns common to - both versions of the table are in a different order - on the slave than they are on the master: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c2 INT, c1 INT);</userinput> -</programlisting> - - The following table definitions would also raise - Error 1532, because the definition of the extra - column on the master appears before the definitions - of the columns common to both versions of the table: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -</programlisting> - </para> - - </formalpara> - </listitem> - - <listitem> - <formalpara> - - <title>More columns on the slave</title> - - <para> - The following definitions replicate correctly: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> - </programlisting> - - The following definitions raise Error 1532 because - the columns common to both versions of the table are - not defined in the same order on both the master and - the slave: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c2 INT, c1 INT, c3 INT);</userinput> -</programlisting> - - The following table definitions also raise Error - 1532 because the definition for the extra column in - the slave's version of the table appears before - the definitions for the columns which are common to - both versions of the table: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput> - </programlisting> - - The following table definitions fail, because the - slave's version of the table has additional - columns compared to the master's version, and - the two versions of the table define column - <literal>c2</literal> as a different data type. - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 BIGINT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);</userinput> - </programlisting> - </para> - - </formalpara> - </listitem> - - </itemizedlist> - </para> - - </formalpara> - - </section> - - <section id="replication-features-different-data-types"> - - <title>Replication of Columns Having Different Data Types</title> - - <para> - Corresponding columns on the master's and the - slave's copies of the same table should have the same - type. However, this is not always strictly enforced, as long - as certain conditions are met. These conditions are listed - here: - - <itemizedlist> - - <listitem> - <para> - The slave's copy of the table cannot contain more - columns than the master's copy. - </para> - </listitem> - - <listitem> - <para> - For columns holding numeric data types the sizes may - differ, as long as the size of the slave's version - of the column is equal or greater to the size of the - master's version of the column. For example, the - following table definitions are allowed: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 TINYINT, c2 INT);</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 INT);</userinput> -</programlisting> - - The slave's versions of both columns - <literal>c1</literal> and <literal>c2</literal> are the - same size as or larger than the master's versions - of these columns. However, the following definitions - would fail: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(8,3));</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(7,3));</userinput> -</programlisting> - - In this case, Error 1532 would be raised because the - master's copy of column <literal>c2</literal> is - larger than its counterpart on the slave — that - is, the master's copy of <literal>c2</literal> on - the master can hold more digits than the slave's - copy of the column. - </para> - </listitem> - - <listitem> - <para> - There is no conversion between numeric data types, and - so the following definitions would fail with Error 1532: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 FLOAT(8,3));</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 BIGINT);</userinput> -</programlisting> - </para> - </listitem> - - <listitem> - <para> - For columns storing <literal>CHAR</literal> and - <literal>BINARY</literal> data, the size of the - slave's copy of the column must be equal to or - greater than the size of the master's copy. For - example, the following table definitions would replicate - successfully: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(30));</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(50));</userinput> -</programlisting> - - If the size of the master's version of the column - is greater than that of the slave's version of the - column, replication fails with Error 1532. - </para> - </listitem> - - <listitem> - <para> - The replication process can convert freely between - <literal>BINARY</literal>, <literal>VARBINARY</literal>, - <literal>CHAR</literal> and <literal>VARCHAR</literal> - columns. For example, the following table definitions - can be used successfully: - -<programlisting> -master> <userinput>CREATE TABLE t1 (c1 INT, c2 VARBINARY(30));</userinput> -slave> <userinput>CREATE TABLE t1 (c1 INT, c2 CHAR(30));</userinput> -</programlisting> - </para> - - <note> - <para> - Since replication is currently not supported between - different character sets, it is sufficient when - comparing sizes of columns containing character data - to count the number of characters rather than the - number of bytes. - </para> - </note> - </listitem> - - </itemizedlist> - </para> - - </section> - - </section> - <section id="replication-features-variables"> <title>Replication and Variables</title> @@ -1989,7 +2090,7 @@ <para> Downgrading a replication setup to a previous version cannot be - done once you've switched from statement-based to row-based + done once you have switched from statement-based to row-based replication, and after the first row-based statement has been written to the binlog. See <xref linkend="replication-formats"/>. </para> @@ -2525,7 +2626,7 @@ </programlisting> <para> - The value will be one of <literal>STATEMENT</literal>, + The value shown is one of <literal>STATEMENT</literal>, <literal>ROW</literal>, or <literal>MIXED</literal>. When <literal>MIXED</literal> mode is in use, row-based replication is preferred but replication switches Added: trunk/refman-common/images/published/rpl-create-select-failure-rbr.png =================================================================== Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 371 bytes Added: trunk/refman-common/images/source/rpl-create-select-failure-rbr.html =================================================================== --- trunk/refman-common/images/source/rpl-create-select-failure-rbr.html (rev 0) +++ trunk/refman-common/images/source/rpl-create-select-failure-rbr.html 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 1, Lines Added: 43, Lines Deleted: 0; 2011 bytes @@ -0,0 +1,43 @@ +<!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> + <head><title>Gahhhh</title></head> + <body style="font-family:Arial;"> + <table frame="box" rules="all" cellpadding="2"> + <tbody> + <tr> + <th rowspan="2">Transactional Table?</th> + <th colspan="3">Reason for Failure</th> + </tr> + <tr> + <th><code>CREATE</code> Succeeded; <code>SELECT</code> or Inserts Failed</th> + <th><code>CREATE</code> Failed<br/>(Table Already Exists)</th> + <th><code>CREATE</code> Failed (Other Reason)</th> + </tr> + <tr> + <th>YES</th> + <td><ol style="padding-right:15px;"> + <li>Table is dropped</li> + <li>Implicit commit is logged</li> + </ol> + </td> + <td rowspan="2"><ol style="padding-right:15px;"> + <li><code>CREATE TABLE</code> statement is not logged</li> + <li>Applied rows are logged</li> + <li>Implicit commit is logged</li> + </ol> + </td> + <td rowspan="2"><p style="padding-left:5px;">Only implicit commit is logged</p></td> + </tr> + <tr> + <th>NO</th> + <td><ol style="padding-right:15px;"> + <li><code>CREATE TABLE</code> statement is logged</li> + <li>Applied rows are logged</li> + <li>Implicit commit is logged</li> + </ol></td> + </tr> + </tbody> + + </table> + </body> +</html> \ No newline at end of file Modified: trunk/topic-guides/topics-5.0/Makefile.depends =================================================================== --- trunk/topic-guides/topics-5.0/Makefile.depends 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/topic-guides/topics-5.0/Makefile.depends 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 806 bytes @@ -305,7 +305,7 @@ ../../refman-5.0/metadata/sql-syntax-data-definition.idmap \ ../../refman-5.0/metadata/sql-syntax-replication.idmap \ ../../refman-5.0/metadata/sql-syntax-server-administration.idmap \ - ../../refman-5.0/metadata/stored-programs-views.idmap \ + ../../refman-5.0/metadata/sql-syntax-transactions.idmap \ ../../refman-5.1/metadata/replication-configuration.idmap \ ../../refman-common/metadata/bug-reports.idmap mysql-replication-excerpt.validpure: $(mysql_replication_excerpt_SOURCES) Modified: trunk/topic-guides/topics-5.1/Makefile.depends =================================================================== --- trunk/topic-guides/topics-5.1/Makefile.depends 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/topic-guides/topics-5.1/Makefile.depends 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 4, Lines Added: 4, Lines Deleted: 1; 5300 bytes @@ -377,6 +377,7 @@ ../../refman-5.1/../refman-common/images/published/multi-db.png \ ../../refman-5.1/../refman-common/images/published/redundancy-after.png \ ../../refman-5.1/../refman-common/images/published/redundancy-before.png \ + ../../refman-5.1/../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../../refman-5.1/../refman-common/images/published/scaleout.png \ ../../refman-5.1/../refman-common/images/published/submaster-performance.png \ ../../refman-5.1/replication-configuration.xml \ @@ -396,6 +397,7 @@ ../../refman-5.1/../refman-common/images/published/multi-db.png \ ../../refman-5.1/../refman-common/images/published/redundancy-after.png \ ../../refman-5.1/../refman-common/images/published/redundancy-before.png \ + ../../refman-5.1/../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../../refman-5.1/../refman-common/images/published/scaleout.png \ ../../refman-5.1/../refman-common/images/published/submaster-performance.png mysql_replication_excerpt_SOURCES = mysql-replication-excerpt.xml $(mysql_replication_excerpt_INCLUDES) @@ -419,6 +421,7 @@ ../../refman-5.1/metadata/se-memory.idmap \ ../../refman-5.1/metadata/sql-syntax-replication.idmap \ ../../refman-5.1/metadata/sql-syntax-server-administration.idmap \ + ../../refman-5.1/metadata/sql-syntax-transactions.idmap \ ../../refman-5.1/metadata/stored-programs-views.idmap \ ../../refman-common/metadata/bug-reports.idmap mysql-replication-excerpt.validpure: $(mysql_replication_excerpt_SOURCES) @@ -675,7 +678,7 @@ $(RM) mysql-cluster-excerpt.xml mysql-cluster-excerpt-arbitrary.xml $(MAKE) mysql-cluster-excerpt.xml -mysql-replication-excerpt-aspec.xml.replication-configuration.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-implementation.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-notes.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-solutions.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication.all.preface.xml: ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-5.1/replication-configuration.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-5.1/replication-implementation.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-5.1/replication-notes.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-5.1/../refman-common/images/pub! lished/multi-db.png ../../refman-5.1/../refman-common/images/published/redundancy-after.png ../../refman-5.1/../refman-common/images/published/redundancy-before.png ../../refman-5.1/../refman-common/images/published/scaleout.png ../../refman-5.1/../refman-common/images/published/submaster-performance.png ../../refman-5.1/replication-solutions.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-5.1/replication.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent +mysql-replication-excerpt-aspec.xml.replication-configuration.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-implementation.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-notes.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-solutions.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication.all.preface.xml: ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-5.1/replication-configuration.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-5.1/replication-implementation.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-5.1/../refman-common/images/published/rpl-create-select-failure-rbr.png ../../refman-5.1/replication-notes.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common! /fixedchars.ent ../../common/phrases.ent ../../refman-5.1/../refman-common/images/published/multi-db.png ../../refman-5.1/../refman-common/images/published/redundancy-after.png ../../refman-5.1/../refman-common/images/published/redundancy-before.png ../../refman-5.1/../refman-common/images/published/scaleout.png ../../refman-5.1/../refman-common/images/published/submaster-performance.png ../../refman-5.1/replication-solutions.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-5.1/replication.xml ../../refman-5.1/versions.ent ../../refman-common/urls.ent all-entities.ent $(RM) mysql-replication-excerpt.xml mysql-replication-excerpt-arbitrary.xml $(MAKE) mysql-replication-excerpt.xml Modified: trunk/topic-guides/topics-6.0/Makefile.depends =================================================================== --- trunk/topic-guides/topics-6.0/Makefile.depends 2008-10-26 01:09:57 UTC (rev 12154) +++ trunk/topic-guides/topics-6.0/Makefile.depends 2008-10-26 01:33:16 UTC (rev 12155) Changed blocks: 4, Lines Added: 5, Lines Deleted: 1; 5410 bytes @@ -275,6 +275,7 @@ ../../refman-6.0/../refman-common/images/published/multi-db.png \ ../../refman-6.0/../refman-common/images/published/redundancy-after.png \ ../../refman-6.0/../refman-common/images/published/redundancy-before.png \ + ../../refman-6.0/../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../../refman-6.0/../refman-common/images/published/scaleout.png \ ../../refman-6.0/../refman-common/images/published/submaster-performance.png \ ../../refman-6.0/replication-configuration.xml \ @@ -294,6 +295,7 @@ ../../refman-6.0/../refman-common/images/published/multi-db.png \ ../../refman-6.0/../refman-common/images/published/redundancy-after.png \ ../../refman-6.0/../refman-common/images/published/redundancy-before.png \ + ../../refman-6.0/../refman-common/images/published/rpl-create-select-failure-rbr.png \ ../../refman-6.0/../refman-common/images/published/scaleout.png \ ../../refman-6.0/../refman-common/images/published/submaster-performance.png mysql_replication_excerpt_SOURCES = mysql-replication-excerpt.xml $(mysql_replication_excerpt_INCLUDES) @@ -315,7 +317,9 @@ ../../refman-6.0/metadata/se-memory.idmap \ ../../refman-6.0/metadata/sql-syntax-replication.idmap \ ../../refman-6.0/metadata/sql-syntax-server-administration.idmap \ + ../../refman-6.0/metadata/sql-syntax-transactions.idmap \ ../../refman-6.0/metadata/stored-programs-views.idmap \ + ../../refman-5.1/metadata/mysql-cluster-replication.idmap \ ../../refman-5.1/metadata/mysql-cluster.idmap \ ../../refman-common/metadata/bug-reports.idmap mysql-replication-excerpt.validpure: $(mysql_replication_excerpt_SOURCES) @@ -569,7 +573,7 @@ $(RM) mysql-solaris-excerpt.xml mysql-solaris-excerpt-arbitrary.xml $(MAKE) mysql-solaris-excerpt.xml -mysql-replication-excerpt-aspec.xml.replication-configuration.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-implementation.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-notes.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-solutions.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication.all.preface.xml: ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication-configuration.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication-implementation.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication-notes.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/../refman-common/images/pub! lished/multi-db.png ../../refman-6.0/../refman-common/images/published/redundancy-after.png ../../refman-6.0/../refman-common/images/published/redundancy-before.png ../../refman-6.0/../refman-common/images/published/scaleout.png ../../refman-6.0/../refman-common/images/published/submaster-performance.png ../../refman-6.0/replication-solutions.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent +mysql-replication-excerpt-aspec.xml.replication-configuration.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-implementation.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-notes.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication-solutions.none.chapter.xml mysql-replication-excerpt-aspec.xml.replication.all.preface.xml: ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication-configuration.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication-implementation.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/../refman-common/images/published/rpl-create-select-failure-rbr.png ../../refman-6.0/replication-notes.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common! /fixedchars.ent ../../common/phrases.ent ../../refman-6.0/../refman-common/images/published/multi-db.png ../../refman-6.0/../refman-common/images/published/redundancy-after.png ../../refman-6.0/../refman-common/images/published/redundancy-before.png ../../refman-6.0/../refman-common/images/published/scaleout.png ../../refman-6.0/../refman-common/images/published/submaster-performance.png ../../refman-6.0/replication-solutions.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent ../../common/fixedchars.ent ../../common/phrases.ent ../../refman-6.0/replication.xml ../../refman-6.0/versions.ent ../../refman-common/urls.ent all-entities.ent $(RM) mysql-replication-excerpt.xml mysql-replication-excerpt-arbitrary.xml $(MAKE) mysql-replication-excerpt.xml
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r12155 - in trunk: refman-5.0 refman-5.1 refman-5.1-maria refman-6.0 refman-common/images/published refman-common/image... | jon | 26 Oct |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 1.682 sec. using MySQL 5.1.14-beta-log