This is a bugfix release, fixing recently discovered bugs in the previous MySQL Cluster NDB 6.2 release.
Obtaining MySQL Cluster NDB 6.2. You can download the latest MySQL Cluster NDB 6.2 source code and binaries for supported platforms from http://dev.mysql.com/downloads/select.php?id=14.
This release incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.2 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.23 (see Section C.1.29, “Changes in MySQL 5.1.23 (29 January 2008)”).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Functionality added or changed:
Added the MaxBufferedEpochs
data node
configuration parameter, which controls the maximum number of
unprocessed epochs by which a subscribing node can lag.
Subscribers which exceed this number are disconnected and forced
to reconnect.
See Section 17.3.2.6, “Defining MySQL Cluster Data Nodes”, for more information.
Replication:
Introduced the slave_exec_mode
system variable to control whether idempotent or strict mode is
used for replication conflict resolution. Idempotent mode
suppresses duplicate-key, no-key-found, and some other errors,
and is needed for circular replication, multi-master
replication, and some other complex replication setups when
using MySQL Cluster, where idempotent mode is the default.
However, strict mode is the default for storage engines other
than NDB
.
(Bug#31609)
Cluster Replication:
RESET MASTER
now uses
TRUNCATE TABLE
rather than
DELETE
to clear the
mysql.ndb_binlog_index
table. This improves
the performance of the statement and is less likely to leave the
table in a fragmented state.
(Bug#34356)
Formerly, when the MySQL server crashed, the generated stack dump was numeric and required external tools to properly resolve the names of functions. This is not very helpful to users having a limited knowledge of debugging techniques. In addition, the generated stack trace contained only the names of functions and was formatted differently for each platform due to different stack layouts.
Now it is possible to take advantage of newer versions of the GNU C Library provide a set of functions to obtain and manipulate stack traces from within the program. On systems that use the ELF binary format, the stack trace contains important information such as the shared object where the call was generated, an offset into the function, and the actual return address. Having the function name also makes possible the name demangling of C++ functions.
The library generates meaningful stack traces on the following platforms: i386, x86_64, PowerPC, IA64, Alpha, and S390. On other platforms, a numeric stack trace is still produced, and the use of the resolve_stack_dump utility is still required. (Bug#31891)
mysqltest now has mkdir
and rmdir
commands for creating and removing
directories.
(Bug#31004)
Added the
Uptime_since_flush_status
status variable, which indicates the number of seconds since the
most recent FLUSH STATUS
statement.
(Community contribution by Jeremy Cole)
(Bug#24822)
Bugs fixed:
Performance:
InnoDB
exhibited thread thrashing with more
than 50 concurrent connections under an update-intensive
workload.
(Bug#22868)
Incompatible Change:
The UPDATE
statement allowed
NULL
to be assigned to NOT
NULL
columns (the implicit default value for the
column data type was assigned). This was changed so that on
error occurs.
This change was reverted, because the original report was
determined not to be a bug: Assigning NULL
to
a NOT NULL
column in an
UPDATE
statement should produce
an error only in strict SQL mode and set the column to the
implicit default with a warning otherwise, which was the
original behavior. See Section 10.1.4, “Data Type Default Values”, and
Bug#39265.
(Bug#33699)
Important Change: Replication:
When the master crashed during an update on a transactional
table while in autocommit
mode,
the slave failed. This fix causes every transaction (including
autocommit
transactions) to be
recorded in the binlog as starting with a
BEGIN
and
ending with a COMMIT
or
ROLLBACK
.
(Bug#26395)
Replication: Important Note: Network timeouts between the master and the slave could result in corruption of the relay log. This fix rectifies a long-standing replication issue when using unreliable networks, including replication over wide area networks such as the Internet. If you experience reliability issues and see many You have an error in your SQL syntax errors on replication slaves, we strongly recommend that you upgrade to a MySQL version which includes this fix. (Bug#26489)
Replication:
When the Windows version of mysqlbinlog read
4.1 binlogs containing
LOAD DATA
INFILE
statements, it output backslashes as path
separators, causing problems for client programs expecting
forward slashes. In such cases, it now converts
\\
to /
in directory
paths.
(Bug#34355)
Replication:
SHOW SLAVE STATUS
failed when
slave I/O was about to terminate.
(Bug#34305)
Replication:
mysqlbinlog from a 5.1 or later MySQL
distribution could not read binary logs generated by a 4.1
server when the logs contained
LOAD DATA
INFILE
statements.
(Bug#34141)
This regression was introduced by Bug#32407.
Replication:
A CREATE USER
,
DROP USER
, or
RENAME USER
statement that fails
on the master, or that is a duplicate of any of these
statements, is no longer written to the binlog; previously,
either of these occurrences could cause the slave to fail.
(Bug#33862)
See also Bug#29749.
Replication: mysqlbinlog failed to release all of its memory after terminating abnormally. (Bug#33247)
Replication: The error message generated due to lack of a default value for an extra column was not sufficiently informative. (Bug#32971)
Replication:
When a user variable was used inside an
INSERT
statement, the
corresponding binlog event was not written to the binlog
correctly.
(Bug#32580)
Replication: When using row-based replication, deletes from a table with a foreign key constraint failed on the slave. (Bug#32468)
Replication:
SQL statements containing comments using --
syntax were not replayable by mysqlbinlog,
even though such statements replicated correctly.
(Bug#32205)
Replication: When using row-based replication from a master running MySQL 5.1.21 or earlier to a slave running 5.1.22 or later, updates of integer columns failed on the slave with Error in Unknown event: row application failed. (Bug#31583)
This regression was introduced by Bug#21842.
Replication: Replicating write, update, or delete events from a master running MySQL 5.1.15 or earlier to a slave running 5.1.16 or later caused the slave to crash. (Bug#31581)
Replication: When using row-based replication, the slave stopped when attempting to delete nonexistent rows from a slave table without a primary key. In addition, no error was reported when this occurred. (Bug#31552)
Replication:
Issuing a DROP VIEW
statement
caused replication to fail if the view did not actually exist.
(Bug#30998)
Replication:
Replication of LOAD
DATA INFILE
could fail when
read_buffer_size
was larger
than max_allowed_packet
.
(Bug#30435)
Replication:
Replication crashed with the NDB
storage engine when mysqld was started with
--character-set-server=ucs2
.
(Bug#29562)
Replication:
Setting server_id
did not
update its value for the current session.
(Bug#28908)
Replication: Some older servers wrote events to the binary log using different numbering from what is currently used, even though the file format number in the file is the same. Slaves running MySQL 5.1.18 and later could not read these binary logs properly. Binary logs from these older versions now are recognized and event numbers are mapped to the current numbering so that they can be interpreted properly. (Bug#27779, Bug#32434)
This regression was introduced by Bug#22583.
Cluster Replication:
Enabling the ndb_wait_connected
system variable caused the server to wait for a partial
connection plus an additional 3 seconds for a complete
connection to the cluster. This could lead to issues with
setting up the binary log.
(Bug#34757)
Cluster API: Closing a scan before it was executed caused the application to segfault. (Bug#36375)
Cluster API:
Using NDB API applications from older MySQL Cluster versions
with libndbclient
from newer ones caused the
cluster to fail.
(Bug#36124)
Cluster API: Scans having no bounds set were handled incorrectly. (Bug#35876)
Use of stored functions in the WHERE
clause
for SHOW OPEN TABLES
caused a
server crash.
(Bug#34166)
Large unsigned integers were improperly handled for prepared statements, resulting in truncation or conversion to negative numbers. (Bug#33798)
The server crashed when executing a query that had a subquery
containing an equality X=Y where Y referred to a named select
list expression from the parent select. The server crashed when
trying to use the X=Y equality for
ref
-based access.
(Bug#33794)
ORDER BY ... DESC
sorts could produce
misordered results.
(Bug#33697)
The server could crash when
REPEAT
or another control instruction was used in conjunction with
labels and a
LEAVE
instruction.
(Bug#33618)
SET GLOBAL myisam_max_sort_file_size=DEFAULT
set myisam_max_sort_file_size
to an incorrect value.
(Bug#33382)
See also Bug#31177.
Granting the UPDATE
privilege on
one column of a view caused the server to crash.
(Bug#33201)
For DECIMAL
columns used with the
ROUND(
or
X
,D
)TRUNCATE(
function with a nonconstant value of
X
,D
)D
, adding an ORDER
BY
for the function result produced misordered output.
(Bug#33143)
The SHOW ENGINE
INNODB STATUS
and
SHOW ENGINE INNODB
MUTEX
statements incorrectly required the
SUPER
privilege rather than the
PROCESS
privilege.
(Bug#32710)
Tables in the mysql
database that stored the
current sql_mode
value as part
of stored program definitions were not updated with newer mode
values
(NO_ENGINE_SUBSTITUTION
,
PAD_CHAR_TO_FULL_LENGTH
). This
causes various problems defining stored programs if those modes
were included in the current
sql_mode
value.
(Bug#32633)
ROUND(
or
X
,D
)TRUNCATE(
for nonconstant values of X
,D
)D
could
crash the server if these functions were used in an
ORDER BY
that was resolved using
filesort
.
(Bug#30889)
Resetting the query cache by issuing a SET GLOBAL
query_cache_size=0
statement caused the server to
crash if it concurrently was saving a new result set to the
query cache.
(Bug#30887)
The Table_locks_waited
waited
variable was not incremented in the cases that a lock had to be
waited for but the waiting thread was killed or the request was
aborted.
(Bug#30331)
The Com_create_function
status variable was
not incremented properly.
(Bug#30252)
mysqld displayed the
--enable-pstack
option in its
help message even if MySQL was configured without
--with-pstack
.
(Bug#29836)
Views were treated as insertable even if some base table columns with no default value were omitted from the view definition. (This is contrary to the condition for insertability that a view must contain all columns in the base table that do not have a default value.) (Bug#29477)
Previously, the parser accepted the ODBC { OJ ... LEFT
OUTER JOIN ...}
syntax for writing left outer joins.
The parser now allows { OJ ... }
to be used
to write other types of joins, such as INNER
JOIN
or RIGHT OUTER JOIN
. This
helps with compatibility with some third-party applications, but
is not official ODBC syntax.
(Bug#28317)
The parser rules for the SHOW
PROFILE
statement were revised to work with older
versions of bison.
(Bug#27433)
resolveip failed to produce correct results for host names that begin with a digit. (Bug#27427)
mysqlcheck -A -r did not correctly identify all tables that needed repairing. (Bug#25347)
Warnings for deprecated syntax constructs used in stored routines make sense to report only when the routine is being created, but they were also being reported when the routine was parsed for loading into the execution cache. Now they are reported only at routine creation time. (Bug#21801)
CREATE ... SELECT
did not always set
DEFAULT
column values in the new table.
(Bug#21380)
If a SELECT
calls a stored
function in a transaction, and a statement within the function
fails, that statement should roll back. Furthermore, if
ROLLBACK
is
executed after that, the entire transaction should be rolled
back. Before this fix, the failed statement did not roll back
when it failed (even though it might ultimately get rolled back
by a ROLLBACK
later that rolls back the entire transaction).
(Bug#12713)
See also Bug#34655.
User Comments
Add your own comment.