List:Commits« Previous MessageNext Message »
From:jon.stephens Date:May 28 2009 3:05pm
Subject:svn commit - mysqldoc@docsrva: r15096 - in trunk: dynamic-docs/changelog refman-5.1
View as plain text  
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-&gt;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&apos;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&apos;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&apos;s classic statement-based replication, there may
+      be issues with replicating stored routines or triggers. You can
+      avoid these issues by using MySQL&apos;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&apos;s
-                effects are deterministic, you can safely disregard such
-                warnings.
+                format</errortext> &mdash; 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&apos;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.1jon.stephens28 May