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.