Changes in MySQL Cluster NDB 6.2.14 (5.1.23-ndb-6.2.14) (2008-03-05)

MySQL Cluster NDB 6.2 no longer in development.
MySQL Cluster NDB 6.2 is no longer being developed or
maintained; if you are using a MySQL Cluster NDB 6.2 release,
you should upgrade to the latest version of MySQL Cluster,
which is available from
http://dev.mysql.com/downloads/cluster/ .

This release incorporates all bugfixes and changes made in
previous MySQL Cluster releases, as well as all bugfixes and
feature changes which were added in mainline MySQL 5.1 through
MySQL 5.1.23 (see Changes in MySQL 5.1.23 (2008-01-29)).

Note

Please refer to our bug database at
http://bugs.mysql.com/ for more details about
the individual bugs fixed in this version.

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.

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 permitted
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 Data Type Default Values, and
Bug #39265.
(Bug #33699)

References: See also: Bug #39265.

Incompatible Change:
Previously, the parser accepted the ODBC { OJ ... LEFT
OUTER JOIN ...} syntax for writing left outer joins.
The parser now permits { 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.

A consequence of this change is that the parser no longer
permits nested { OJ ... } constructs (which
are not legal ODBC syntax, anyway). Queries that use such
constructs should be rewritten. For example, this query is now
produces an error:

SELECT * FROM
{OJ
{OJ a LEFT OUTER JOIN b ON a.a1=b.a1}
LEFT OUTER JOIN c ON b.b1 = c.b1};

That can be replaced by any of the following rewrites:

SELECT * FROM
{OJ a LEFT OUTER JOIN b
LEFT OUTER JOIN c ON b.b1 = c.b1 ON a.a1=b.a1};
SELECT * FROM
{OJ a LEFT OUTER JOIN b ON a.a1=b.a1
LEFT OUTER JOIN c ON b.b1 = c.b1};
SELECT * FROM
a LEFT OUTER JOIN b ON a.a1=b.a1 LEFT OUTER JOIN c ON b.b1 = c.b1;

The first two are legal according to ODBC, and you nest the
joins inside a single { OJ ...} clause. The
third is standard SQL syntax, without ODBC decoration. It can be
used with parentheses to emphasize the evaluation order:

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 binary log as starting with a
BEGIN and
ending with a COMMIT or
ROLLBACK.

Note

The current fix does not cause
nontransactional changes to be wrapped in
BEGIN ...
COMMIT or
BEGIN ...
ROLLBACK
when written to the binary log. For this purpose, any
statements affecting tables using a nontransactional storage
engine such as MyISAM are
regarded as nontransactional, even when
autocommit is enabled.

(Bug #26395)

References: See also: Bug #29288, Bug #49522.

Important Note; Replication:
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: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)

References: This issue is a regression of: 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 binary log; previously,
either of these occurrences could cause the slave to fail.
(Bug #33862)

References: 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 binary log event was not written to the binary log
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)

References: This issue is a regression of: 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:
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)

References: This issue is a regression of: Bug #22583.

Cluster Replication:
Using --ndb-wait-connected 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:
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)

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(X,D)
or
TRUNCATE(X,D)
for nonconstant values of 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)

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)

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)