Author: jstephens
Date: 2009-05-28 17:05:46 +0200 (Thu, 28 May 2009)
New Revision: 15096
Log:
Documented Replication bugfixes:
Bug #41725, Bug #42415,
Bug #43949, Bug #44442
Modified:
trunk/dynamic-docs/changelog/mysqld-1.xml
trunk/refman-5.1/dba-log-files.xml
trunk/refman-5.1/replication-notes.xml
Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml 2009-05-28 15:01:11 UTC (rev 15095)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml 2009-05-28 15:05:46 UTC (rev 15096)
Changed blocks: 2, Lines Added: 149, Lines Deleted: 1; 4546 bytes
@@ -6,9 +6,157 @@
]>
<changelog>
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="replication"/>
+ <highlight type="importantchange"/>
+ <manual type="binary log"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="44442"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.36"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Previously, incident log events were represented as comments in
+ the output from mysqlbinlog, making them effectively silent when
+ playing back the binlog.
+ </para>
+
+ <para>
+ (An incident log event represents an incident that could cause
+ the contents of the database to change without that event being
+ recorded in the binary log.)
+ </para>
+
+ <para>
+ This meant that, if the SQL were applied to a server, it could
+ potentially lead to the master and the slave having different
+ data. To make it possible to handle incident log events without
+ breaking applications that expect the previous behavior, the
+ nonsense statement RELOAD DATABASE is added to the SQL output
+ for that incident log event, which causes an error.
+ </para>
+
+ <para>
+ To use this functionality currently requires hand editing of the
+ dump file and handling of each case on an individual basis by a
+ database administrator before applying the output to a server.
+ </para>
+
+ </message>
+
+ </logentry>
+
<logentry entrytype="bug">
<tags>
+ <highlight type="replication"/>
+ <manual type="binary log"/>
+ <manual type="warnings"/>
+ <manual type="safe"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="42415"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.36"/>
+ </versions>
+
+ <message>
+
+ <para>
+ The warning <errortext>Statement is not safe to log in statement
+ format</errortext>, issued in situations when it cannot be
+ determined that a statement or other database event can be
+ written reliably to the binary log using the statement-based
+ format, has been changed to <errortext>Statement may not be safe
+ to log in statement format</errortext>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="SBR"/>
+ <manual type="temporary tables"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="41725"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.83"/>
+ <version ver="5.1.36"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When stopping and restarting the slave while it was replicating
+ temporary tables, the slave server could crash or raise an
+ assertion failure. This was due to the fact that, although
+ temporary tables were saved between slave thread restarts, the
+ reference to the thread being used
+ (<literal>table->in_use</literal>) was not being properly
+ updated when restarting, continuing to reference the old thread
+ instead of the new one. This issue affected statement-based
+ replication only.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
+ <highlight type="replication"/>
+ <manual type="binlog"/>
+ <manual type="RBR"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="42749"/>
+ <seealsobug bugid="44548"/>
+ <seealsobug bugid="44672"/>
+ <seealsobug bugid="44752"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.1.36"/>
+ </versions>
+
+ <message>
+
+ <para>
+ When using row-based logging, the length of an event for which
+ the field metadata exceeded 255 bytes in size was incorrectly
+ calculated. This could lead to corruption of the binary log, or
+ cause the server to hang.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <tags>
<manual type="DDL"/>
<manual type="CREATE TABLESPACE"/>
<manual type="ALTER TABLESPACE"/>
@@ -32,7 +180,7 @@
<para>
The following statements generated an incorrect and confusing
- error message when used with ENGINE=MyISAM:
+ error message when used with <literal>ENGINE=MyISAM</literal>:
</para>
<itemizedlist>
Modified: trunk/refman-5.1/dba-log-files.xml
===================================================================
--- trunk/refman-5.1/dba-log-files.xml 2009-05-28 15:01:11 UTC (rev 15095)
+++ trunk/refman-5.1/dba-log-files.xml 2009-05-28 15:05:46 UTC (rev 15096)
Changed blocks: 1, Lines Added: 24, Lines Deleted: 0; 1284 bytes
@@ -1417,6 +1417,30 @@
</itemizedlist>
+ <para>
+ With MySQL's classic statement-based replication, there may
+ be issues with replicating non-deterministic statements. In
+ deciding whether or not a given statement is safe for
+ statement-based replication, MySQL determines whether it can
+ guarantee that the statement can be replicated using the
+ statement-based format. If MySQL cannot make this guarantee, it
+ marks the statement as potentially unreliable and issues the
+ warning, <errortext>Statement may not be safe to log in
+ statement format</errortext>.
+ </para>
+
+ <para>
+ Prior to MySQL 5.1.36, this warning read, <errortext>Statement
+ is not safe to log in statement format</errortext>. (Bug #42415)
+ </para>
+
+ <para>
+ You can avoid these issues by using MySQL's row-based
+ replication instead.
+ </para>
+
+ <para></para>
+
</section>
<section id="binary-log-setting">
Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml 2009-05-28 15:01:11 UTC (rev 15095)
+++ trunk/refman-5.1/replication-notes.xml 2009-05-28 15:05:46 UTC (rev 15096)
Changed blocks: 2, Lines Added: 16, Lines Deleted: 13; 2511 bytes
@@ -81,13 +81,14 @@
</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
+ 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 more information
- about row-based replication, see
- <xref linkend="replication-formats"/>.
+ about row-based replication and row-based logging, see
+ <xref linkend="replication-formats"/>, and
+ <xref linkend="binary-log-formats"/>.
</para>
<para>
@@ -1184,14 +1185,16 @@
<para>
Attempting to replicate invoked features using
statement-based replication produces the warning
+ <errortext>Statement may not be safe to log in statement
+ format</errortext>. (Prior to MySQL 5.1.36, this was
<errortext>Statement is not safe to log in statement
- format</errortext>. For example, trying to replicate a
- UDF with statement-based replication generates this
- warning because it currently cannot be determined by the
- MySQL server whether the UDF is deterministic. If you
- are absolutely certain that the invoked feature's
- effects are deterministic, you can safely disregard such
- warnings.
+ format</errortext> — see Bug #42415.) For example,
+ trying to replicate a UDF with statement-based
+ replication generates this warning because it currently
+ cannot be determined by the MySQL server whether the UDF
+ is deterministic. If you are absolutely certain that the
+ invoked feature's effects are deterministic, you
+ can safely disregard such warnings.
</para>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r15096 - in trunk: dynamic-docs/changelog refman-5.1 | jon.stephens | 28 May |
