Below is the list of changes that have just been committed into a local
mysqldoc repository of guilhem. When guilhem does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.2430 04/12/06 23:31:53 guilhem@stripped +1 -0
Various edits inspired by customer, hum, feedback:
- more prominent pointing to "replication known bugs" from the binary log section
- more known bugs of binary log
- known limitation of column Seconds_Behind_Master
Changelog entries. Small random fixes (adding @code{} etc).
Docs/manual.texi
1.2283 04/12/06 23:31:50 guilhem@stripped +107 -13
Various edits inspired by customer, hum, feedback:
- more prominent pointing to "replication known bugs" from the binary log section
- more known bugs of binary log
- known limitation of column Seconds_Behind_Master
Changelog entries. Small random fixes (adding @code{} etc).
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: guilhem
# Host: gbichot2.local
# Root: /home/mysql_src/mysqldoc
--- 1.2282/Docs/manual.texi 2004-12-06 12:25:01 +01:00
+++ 1.2283/Docs/manual.texi 2004-12-06 23:31:50 +01:00
@@ -28333,6 +28333,16 @@
or only some of them with @code{PURGE MASTER LOGS}.
See @ref{RESET, , @code{RESET}} and @ref{Replication Master SQL}.
+The binary log format has some known limitations which can affect recovery from
+backups, especially in old versions. These caveats which also affect
+replication are listed at @ref{Replication Features}. One caveat which does not
+affect replication but only recovery with @code{mysqlbinlog}: before MySQL 4.1,
+@command{mysqlbinlog} could not prepare output suitable for @command{mysql} if
+the binary log contained interlaced statements originating from different
+clients that used temporary tables of the same name. This is fixed in MySQL
+4.1. However, the problem still existed for @code{LOAD DATA INFILE} statements
+until it was fixed in MySQL 4.1.8.
+
You can use the following options to @command{mysqld} to affect what is logged
to the binary log. See also the discussion that follows this option list.
@@ -28533,10 +28543,6 @@
than its expected size"). In this case, this binary log is not correct,
replication should be restarted from a fresh master's data snapshot.
-The binary log format has some limitations which apply when the client sessions
-change their character set and collation variables. @xref{Replication
-Features}.
-
@node Slow query log, Log file maintenance, Binary log, Log Files
@subsection The Slow Query Log
@@ -30661,11 +30667,19 @@
possible for the data on the master and slave to become different if a
query is designed in such a way that the data modification is
non-deterministic; that is, left to the will of the query optimizer. (That
-generally is not a good practice anyway, even outside of replication!)
+generally is not a good practice anyway, even outside of replication!).
For a detailed explanation of this issue, see
@ref{Open bugs}.
@item
+If on master a @code{LOAD DATA INFILE} is interrupted in the middle (integrity
+constraint violation, killed connection...), the slave will skip this
+@code{LOAD DATA INFILE} entirely. It means that if this command permanently
+inserted/updated some table records before being interrupted, these
+modifications won't be replicated to the slave. This will be fixed when MySQL
+features a record-level binary log format, in development.
+
+@item
Before MySQL 4.1.1, @code{FLUSH}, @code{ANALYZE TABLE}, @code{OPTIMIZE
TABLE}, and @code{REPAIR TABLE} statements are not written to the binary
log and thus are not replicated to the slaves. This is not normally
@@ -39130,9 +39144,10 @@
INFILE} statements have been executed.
Before MySQL 4.1, @command{mysqlbinlog} could not prepare output suitable for
-@command{mysql} if the binary log contained intertwined statements originating
-from different clients that used temporary tables of the same name. This is
-fixed in MySQL 4.1.
+@command{mysql} if the binary log contained interlaced statements originating
+from different clients that used temporary tables of the same name. This is
+fixed in MySQL 4.1. However, the problem still existed for @code{LOAD DATA
+INFILE} statements until it was fixed in MySQL 4.1.8.
@node mysqlcc, Using mysqlcheck, mysqlbinlog, Client-Side Scripts
@@ -61929,7 +61944,14 @@
when no event has been executed yet, or after @code{CHANGE MASTER} and
@code{RESET SLAVE}. This field can be used to know how ``late'' your slave
is. It will work even though your master and slave don't have identical
-clocks.
+clocks. But it has one limitation. Indeed the timestamp is preserved through
+replication, which means that if your master M1 is itself a slave of M0, any
+event from M1's binlog which has its origin in replication of an event of M0's
+binlog, has the timestamp of that last event. This enables MySQL to replicate
+@code{TIMESTAMP} successfully. But the drawback for
+@code{Seconds_Behind_Master} is that if M1 also receives direct updates from
+clients, then the value will randomly go up and down, because sometimes the
+last M1's event will be from M0 and sometimes it will be from a direct update.
This field is present beginning with MySQL 4.1.1.
@@ -93403,6 +93425,9 @@
Functionality added or changed:
@itemize @bullet
+@item
+@code{FLUSH TABLES WITH READ LOCK} is now killable while it's waiting for
+running @code{COMMIT}s to finish.
@end itemize
Bugs fixed:
@@ -93417,6 +93442,16 @@
Changed semantics of @code{CREATE/ALTER/DROP DATABASE} statements so
that replication of @code{CREATE DATABASE} is possible when using
@code{--binlog-do-db} and @code{--binlog-ignore-db}. (Bug #6391)
+@item
+A sequence of @code{BEGIN} (or @code{SET AUTOCOMMIT=0}), @code{FLUSH TABLES
+WITH READ LOCK}, transactional update, @code{COMMIT}, @code{FLUSH
+TABLES WITH READ LOCK} could hang the connection forever and possibly the MySQL
+server itself. (Bug #6732)
+@item
+@code{mysqlbinlog} did not print @code{SET PSEUDO_THREAD_ID} statements in
+front of @code{LOAD DATA INFILE} statements inserting into temporary tables,
+thus causing potential problems when rolling forward these statements after
+restoring a backup. (Bug #6671)
@end itemize
@node News-5.0.2, News-5.0.1, News-5.0.3, News-5.0.x
@@ -93526,6 +93561,13 @@
in @file{my.cnf}, InnoDB in an @code{UPDATE} or a @code{DELETE} only
locks the rows that it updates or deletes. This greatly reduces the
probability of deadlocks.
+@item
+A connection doing a rollback will now display "Rolling back" in the
+@code{State} column of @code{SHOW PROCESSLIST}.
+@item
+@code{mysqlbinlog} now prints an informative commented line (thread id,
+timestamp, server id, etc) before each @code{LOAD DATA INFILE}, like it already
+does for other queries; unless @code{--short-form} is used.
@end itemize
Bugs fixed:
@@ -93586,8 +93628,17 @@
would cause replication slaves to stop (complaining about error 1223). Bug
surfaced when using the InnoDB @code{innobackup} script. (Bug #5949)
@item
-OPTIMIZE TABLE, REPAIR TABLE, and ANALYZE TABLE are now replicated
+@code{OPTIMIZE TABLE}, @code{REPAIR TABLE}, and @code{ANALYZE TABLE} are now replicated
without any error code in the binary log. (Bug #5551)
+@item
+If a connection had an open transaction but had done no updates to
+transactional tables (for example if had just done a @code{SELECT FOR UPDATE}
+then executed a non-transactional update, that update automatically committed
+the transaction (thus releasing InnoDB's row-level locks etc). (Bug #5714)
+@item
+If a connection was interrupted by a network error and did a rollback, the
+network error code got stored into the @code{BEGIN} and @code{ROLLBACK} binary
+log events; that caused superfluous slave stops. (Bug #6522)
@end itemize
@node News-5.0.1, News-5.0.0, News-5.0.2, News-5.0.x
@@ -94057,6 +94108,13 @@
@item
Added @code{[mysql_cluster]} section to @file{my.cnf} file for configuration
settings specific to MySQL Cluster. @code{ndb-connectstring} variable moved here.
+@item
+A connection doing a rollback will now display "Rolling back" in the
+@code{State} column of @code{SHOW PROCESSLIST}.
+@item
+@code{mysqlbinlog} now prints an informative commented line (thread id,
+timestamp, server id, etc) before each @code{LOAD DATA INFILE}, like it already
+does for other queries; unless @code{--short-form} is used.
@end itemize
Bugs fixed:
@@ -94121,7 +94179,6 @@
record matched completely to search tuple. This unnecessary
next-key locking is now removed when @code{innodb_locks_unsafe_for_binlog}
option is used.
-
@item
If @code{STMT_ATTR_UPDATE_MAX_LENGTH} is set for a prepared statement,
@code{mysql_stmt_store_result()} will update @code{field->max_length}
@@ -94151,10 +94208,10 @@
Improved performance of identifier comparisons
(if many tables or columns are specified).
@item
-OPTIMIZE TABLE, REPAIR TABLE, and ANALYZE TABLE are now replicated
+@code{OPTIMIZE TABLE}, @code{REPAIR TABLE}, and @code{ANALYZE TABLE} are now replicated
without any error code in the binary log. (Bug #5551)
@item
-LOAD DATA INFILE now works with option replicate-rewrite-db.
+@code{LOAD DATA INFILE} now works with option replicate-rewrite-db.
(Bug #6353)
@item
Fixed a bug which caused a crash when only the slave I/O thread was
@@ -94163,6 +94220,25 @@
Changed semantics of @code{CREATE/ALTER/DROP DATABASE} statements so
that replication of @code{CREATE DATABASE} is possible when using
@code{--binlog-do-db} and @code{--binlog-ignore-db}. (Bug #6391)
+@item
+If a connection had an open transaction but had done no updates to
+transactional tables (for example if had just done a @code{SELECT FOR UPDATE}
+then executed a non-transactional update, that update automatically committed
+the transaction (thus releasing InnoDB's row-level locks etc). (Bug #5714)
+@item
+If a connection was interrupted by a network error and did a rollback, the
+network error code got stored into the @code{BEGIN} and @code{ROLLBACK} binary
+log events; that caused superfluous slave stops. (Bug #6522)
+@item
+A sequence of @code{BEGIN} (or @code{SET AUTOCOMMIT=0}), @code{FLUSH TABLES
+WITH READ LOCK}, transactional update, @code{COMMIT}, @code{FLUSH
+TABLES WITH READ LOCK} could hang the connection forever and possibly the MySQL
+server itself. (Bug #6732)
+@item
+@code{mysqlbinlog} did not print @code{SET PSEUDO_THREAD_ID} statements in
+front of @code{LOAD DATA INFILE} statements inserting into temporary tables,
+thus causing potential problems when rolling forward these statements after
+restoring a backup. (Bug #6671)
@end itemize
@node News-4.1.7, News-4.1.6, News-4.1.8, News-4.1.x
@@ -96130,6 +96206,10 @@
InnoDB: Fixed a bug in @code{LOAD DATA INFILE@dots{}REPLACE}
printing duplicate key error when executing the same
load query several times. (Bug #5835)
+@item
+@code{mysqlbinlog} now prints an informative commented line (thread id,
+timestamp, server id, etc) before each @code{LOAD DATA INFILE}, like it already
+does for other queries; unless @code{--short-form} is used.
@end itemize
Bugs fixed:
@@ -96152,6 +96232,20 @@
@item
Fixed a bug which caused a crash when only the slave I/O thread was
stopped and restarted. (Bug #6148)
+@item
+If a connection had an open transaction but had done no updates to
+transactional tables (for example if had just done a @code{SELECT FOR UPDATE}
+then executed a non-transactional update, that update automatically committed
+the transaction (thus releasing InnoDB's row-level locks etc). (Bug #5714)
+@item
+If a connection was interrupted by a network error and did a rollback, the
+network error code got stored into the @code{BEGIN} and @code{ROLLBACK} binary
+log events; that caused superfluous slave stops. (Bug #6522)
+@item
+A sequence of @code{BEGIN} (or @code{SET AUTOCOMMIT=0}), @code{FLUSH TABLES
+WITH READ LOCK}, transactional update, @code{COMMIT}, @code{FLUSH
+TABLES WITH READ LOCK} could hang the connection forever and possibly the MySQL
+server itself. (Bug #6732)
@end itemize
@node News-4.0.22, News-4.0.21, News-4.0.23, News-4.0.x
| Thread |
|---|
| • bk commit - mysqldoc tree (guilhem:1.2430) | guilhem | 6 Dec |
