From: jon.stephens Date: May 28 2009 3:05pm Subject: svn commit - mysqldoc@docsrva: r15096 - in trunk: dynamic-docs/changelog refman-5.1 List-Archive: http://lists.mysql.com/commits/75164 Message-Id: <200905281505.n4SF5lHo009972@docsrva.mysql.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 @@ ]> + + + + + + + + + + + + + + + + + + + + Previously, incident log events were represented as comments in + the output from mysqlbinlog, making them effectively silent when + playing back the binlog. + + + + (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.) + + + + 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. + + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + The warning Statement is not safe to log in statement + format, 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 Statement may not be safe + to log in statement format. + + + + + + + + + + + + + + + + + + + + + + + + + + + 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 + (table->in_use) 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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. + + + + + + + + + @@ -32,7 +180,7 @@ The following statements generated an incorrect and confusing - error message when used with ENGINE=MyISAM: + error message when used with ENGINE=MyISAM: 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 @@ + + 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, Statement may not be safe to log in + statement format. + + + + Prior to MySQL 5.1.36, this warning read, Statement + is not safe to log in statement format. (Bug #42415) + + + + You can avoid these issues by using MySQL's row-based + replication instead. + + + +
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 @@ - 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 . For more information - about row-based replication, see - . + about row-based replication and row-based logging, see + , and + . @@ -1184,14 +1185,16 @@ Attempting to replicate invoked features using statement-based replication produces the warning + Statement may not be safe to log in statement + format. (Prior to MySQL 5.1.36, this was Statement is not safe to log in statement - format. 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 — 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.