MySQL Cluster NDB 7.1.2 is a new beta release of MySQL Cluster,
incorporating new features in the
NDBCLUSTER
storage engine and
fixing recently discovered bugs in MySQL Cluster NDB 7.1.1 and
previous MySQL Cluster releases.
This release also incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.1, 6.2, 6.3, and 7.0 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.41 (see Section C.1.7, “Changes in MySQL 5.1.41 (05 November 2009)”).
Functionality added or changed:
Cluster API:
It is now possible to determine, using the
ndb_desc utility or the NDB API, which data
nodes contain replicas of which partitions. For
ndb_desc, a new
--extra-node-info
option is
added to cause this information to be included in its output. A
new method
NdbDictionary::Object::Table::getFragmentNodes()
is added to the NDB API for obtaining this information
programmatically.
(Bug#51184)
Numeric codes used in management server status update messages in the cluster logs have been replaced with text descriptions. (Bug#49627)
See also Bug#44248.
A new configuration parameter
HeartbeatThreadPriority
makes it possible to
select between a first-in, first-out or round-round scheduling
policy for management node and API node heartbeat threads, as
well as to set the priority of these threads. See
Section 17.3.2.5, “Defining a MySQL Cluster Management Server”, or
Section 17.3.2.7, “Defining SQL and Other API Nodes in a MySQL Cluster”, for more
information.
(Bug#49617)
Start phases are now written to the data node logs. (Bug#49158)
Formerly, the REPORT
and
DUMP
commands returned output to all
ndb_mgm clients connected to the same MySQL
Cluster. Now, these commands return their output only to the
ndb_mgm client that actually issued the
command.
(Bug#40865)
Disk Data:
The ndb_desc utility can now show the extent
space and free extent space for subordinate
BLOB
and
TEXT
columns (stored in hidden
BLOB
tables by NDB). A
--blob-info
option has been
added for this program that causes ndb_desc
to generate a report for each subordinate
BLOB table. For more information, see
Section 17.4.9, “ndb_desc — Describe NDB Tables”.
(Bug#50599)
Bugs fixed:
Important Change:
The DATA_MEMORY
column of the
ndbinfo.memoryusage
table was renamed to
memory_type
.
(Bug#50926)
When deciding how to divide the REDO log, the
DBDIH
kernel block saved more than was needed
to restore the previous local checkpoint, which could cause REDO
log space to be exhausted prematurely (NDB
error 410).
(Bug#51547)
DML operations can fail with NDB
error 1220
(REDO log files overloaded...) if the
opening and closing of REDO log files takes too much time. If
this occurred as a GCI marker was being written in the REDO log
while REDO log file 0 was being opened or closed, the error
could persist until a GCP stop was encountered. This issue could
be triggered when there was insufficient REDO log space (for
example, with configuration parameter settings
NoOfFragmentLogFiles = 6
and
FragmentLogFileSize = 6M
) with a load
including a very high number of updates.
(Bug#51512)
See also Bug#20904.
An attempted online upgrade from a MySQL Cluster NDB 6.3 or 7.0 release to a MySQL Cluster NDB 7.1 release failed, as the first upgraded data node rejected the remaining data nodes as using incompatible versions. (Bug#51429)
A side effect of the ndb_restore
--disable-indexes
and
--rebuild-indexes
options is
to change the schema versions of indexes. When a
mysqld later tried to drop a table that had
been restored from backup using one or both of these options,
the server failed to detect these changed indexes. This caused
the table to be dropped, but the indexes to be left behind,
leading to problems with subsequent backup and restore
operations.
(Bug#51374)
The output of the ndb_mgm client
REPORT BACKUPSTATUS
command could sometimes
contain errors due to uninitialized data.
(Bug#51316)
Setting IndexMemory
greater than 2GB could
cause data nodes to crash while starting.
(Bug#51256)
ndb_restore crashed while trying to restore a corrupted backup, due to missing error handling. (Bug#51223)
The ndb_restore message Successfully
created index `PRIMARY`...
was directed to
stderr
instead of stdout
.
(Bug#51037)
An initial restart of a data node configured with a large amount of memory could fail with a Pointer too large error. (Bug#51027)
This regression was introduced by Bug#47818.
When using NoOfReplicas
equal to 1 or 2, if
data nodes from one node group were restarted 256 times and
applications were running traffic such that it would encounter
NDB
error 1204
(Temporary failure, distribution
changed), the live node in the node group would
crash, causing the cluster to crash as well. The crash occurred
only when the error was encountered on the 256th restart; having
the error on any previous or subsequent restart did not cause
any problems.
(Bug#50930)
A GROUP BY
query against
NDB
tables sometimes did not use
any indexes unless the query included a FORCE
INDEX
option. With this fix, indexes are used by such
queries (where otherwise possible) even when FORCE
INDEX
is not specified.
(Bug#50736)
ndbmtd started on a single-core machine could
sometimes fail with a Job Buffer Full
error when MaxNoOfExecutionThreads
was set
greater than LockExecuteThreadToCPU
. Now a
warning is logged when this occurs.
(Bug#50582)
The following issues were fixed in the
ndb_mgm client REPORT
MEMORYUSAGE
command:
The client sometimes inserted extra
ndb_mgm>
prompts within the output.
For data nodes running ndbmtd,
IndexMemory
was reported before
DataMemory
.
Also for data nodes running ndbmtd, there
were multiple IndexMemory
entries listed
in the output.
Issuing a command in the ndb_mgm client after it had lost its connection to the management server could cause the client to crash. (Bug#49219)
Replication of a MySQL Cluster using multi-threaded data nodes
could fail with forced shutdown of some data nodes due to the
fact that ndbmtd exhausted
LongMessageBuffer
much more quickly than
ndbd. After this fix, passing of replication
data between the DBTUP
and
SUMA
NDB kernel blocks is done using
DataMemory
rather than
LongMessageBuffer
.
Until you can upgrade, you may be able to work around this issue
by increasing the LongMessageBuffer
setting;
doubling the default should be sufficient in most cases.
(Bug#46914)
Information about several management client commands was missing
from (that is, truncated in) the output of the
HELP
command.
(Bug#46114)
A SELECT
requiring a sort could
fail with the error Can't find record in
'table
' when run
concurrently with a DELETE
from
the same table.
(Bug#45687)
When the MemReportFrequency
configuration
parameter was set in config.ini
, the
ndb_mgm client REPORT
MEMORYUSAGE
command printed its output multiple times.
(Bug#37632)
ndb_mgm -e "... REPORT ..." did not write any
output to stdout
.
The fix for this issue also prevents the cluster log from being
flooded with INFO
messages when
DataMemory
usage reaches 100%, and insures
that when when the usage is decreased, an appropriate message is
written to the cluster log.
(Bug#31542, Bug#44183, Bug#49782)
Disk Data:
The error message returned after atttempting to execute
ALTER LOGFILE GROUP
on an
nonexistent logfile group did not indicate the reason for the
failure.
(Bug#51111)
Cluster API: An issue internal to ndb_mgm could cause problems when trying to start a large number of data nodes at the same time. (Bug#51273)
Cluster API:
When reading blob data with lock mode
LM_SimpleRead
, the lock was not upgraded as
expected.
(Bug#51034)
User Comments
Add your own comment.