The output from ndb_config --xml --configinfo now includes the restart type required for resetting each configuration parameter. (Bug#47366)

Under certain conditions, accounting of the number of free scan records in the local query handler could be incorrect, so that during node recovery or a local checkpoint operations, the LQH could find itself lacking a scan record that is expected to find, causing the node to crash. (Bug#48697)

See also Bug#48564.

The creation of an ordered index on a table undergoing DDL operations could cause a data node crash under certain timing-dependent conditions. (Bug#48604)

During an LCP master takeover, when the newly elected master did not receive a COPY_GCI LCP protocol message but other nodes participating in the local checkpoint had received one, the new master could use an uninitialized variable, which caused it to crash. (Bug#48584)

When running many parallel scans, a local checkpoint (which performs a scan internally) could find itself not getting a scan record, which led to a data node crash. Now an extra scan record is reserved for this purpose, and a problem with obtaining the scan record returns an appropriate error (error code 489, Too many active scans). (Bug#48564)

During a node restart, logging was enabled on a per-fragment basis as the copying of each fragment was completed but local checkpoints were not enabled until all fragments were copied, making it possible to run out of redo log file space (NDB error code 410) before the restart was complete. Now logging is enabled only after all fragments has been copied, just prior to enabling local checkpoints. (Bug#48474)

When using very large transactions containing many inserts, ndbmtd could fail with Signal 11 without an easily detectable reason, due to an internal variable being unitialized in the event that the LongMessageBuffer was overloaded. Now, the variable is initialized in such cases, avoiding the crash, and an appropriate error message is generated. (Bug#48441)

See also Bug#46914.

A data node crashing while restarting, followed by a system restart could lead to incorrect handling of redo log metadata, causing the system restart to fail with Error while reading REDO log. (Bug#48436)

The configuration check that each management server runs to verify that all connected ndb_mgmd processes have the same configuration could fail when a configuration change took place while this check was in progress. Now in such cases, the configuration check is rescheduled for a later time, after the change is complete. (Bug#48143)

ndb_config --xml --configinfo now indicates that parameters belonging in the [SCI], [SCI DEFAULT], [SHM], and [SHM DEFAULT] sections of the config.ini file are deprecated or experimental, as appropriate. (Bug#47365)

Deprecation and usage information obtained from ndb_config --configinfo regarding the PortNumber and ServerPort configuration parameters was improved. (Bug#24584)

Disk Data: NDBCLUSTER failed to provide a valid error message it failed to commit schema transactions during an initial start if the cluster was configured using the InitialLogFileGroup parameter. (Bug#48517)

Disk Data: In certain limited cases, it was possible when the cluster contained Disk Data tables for ndbmtd to crash during a system restart. (Bug#48498)

See also Bug#47832.

The mysql_real_connect() C API function only attempted to connect to the first IP address returned for a hostname. This could be a problem if a hostname mapped to multiple IP address and the server was not bound to the first one returned. Now mysql_real_connect() attempts to connect to all IPv4 or IPv6 addresses that a domain name maps to. (Bug#45017)

See also Bug#47757.

Using a large number of small fragment log files could cause NDBCLUSTER to crash while trying to read them during a restart. This issue was first observed with 1024 fragment log files of 16 MB each. (Bug#48651)

When the combined length of all names of tables using the NDB storage engine was greater than or equal to 1024 bytes, issuing the START BACKUP command in the ndb_mgm client caused the cluster to crash. (Bug#48531)

Performance: Significant improvements in redo log handling and other filesystem operations can yield a considerable reduction in the time required for restarts. While actual restart times observed in a production setting will naturally vary according to database size, hardware, and other conditions, our own preliminary testing shows that these optimizations can yield startup times that are faster than those typical of previous MySQL Cluster releases by a factor of 50 or more.

Important Change: The --with-ndb-port-base option for configure did not function correctly, and has been deprecated. Attempting to use this option produces the warning Ignoring deprecated option --with-ndb-port-base.

Beginning with MySQL Cluster NDB 7.1.0, the deprecation warning itself is removed, and the --with-ndb-port-base option is simply handled as an unknown and invalid option if you try to use it. (Bug#47941)

See also Bug#38502.

After upgrading a MySQL Cluster containing tables having unique indexes from an NDB 6.3 release to an NDB 7.0 release, attempts to create new unique indexes failed with inconsistent trigger errors (error code 293).

For more information (including a workaround for previous MySQL Cluster NDB 7.0 releases), see Section 17.2.6.2, “MySQL Cluster 5.1 and MySQL Cluster NDB 6.x/7.x Upgrade and Downgrade Compatibility”. (Bug#48416)

When a data node failed to start due to inability to recreate or drop objects during schema restoration (for example: insufficient memory was available to the data node process on account of issues not directly related to MySQL Cluster on the host machine), the reason for the failure was not provided. Now is such cases, a more informative error message is logged. (Bug#48232)

A table that was created following an upgrade from a MySQL Cluster NDB 6.3 release to MySQL Cluster NDB 7.0 (starting with version 6.4.0) or later was dropped by a system restart. This was due to a change in the format of NDB schema files and the fact that the upgrade of the format of existing NDB 6.3 schema files to the NDB 7.0 format failed to change the version number contained in the file; this meant that a system restart re-ran the upgrade routine, which interpreted the newly-created table as an uncommitted table (which by definition ought not to be saved). Now the version number of upgraded NDB 6.3 schema files is set correctly during the upgrade process. (Bug#48227)

In certain cases, performing very large inserts on NDB tables when using ndbmtd caused the memory allocations for ordered or unique indexes (or both) to be exceeded. This could cause aborted transactions and possibly lead to data node failures. (Bug#48037)

See also Bug#48113.

For UPDATE IGNORE statements, batching of updates is now disabled. This is because such statements failed when batching of updates was employed if any updates violated a unique constraint, to the fact a unique constraint violation could not be handled without aborting the transaction. (Bug#48036)

Starting a data node with a very large amount of DataMemory (approximately 90G or more) could lead to crash of the node due to job buffer congestion. (Bug#47984)

In some cases, ndbmtd could allocate more space for the undo buffer than was actually available, leading to a failure in the LGMAN kernel block and subsequent failure of the data node. (Bug#47966)

When an UPDATE statement was issued against an NDB table where an index was used to identify rows but no data was actually changed, the NDB storage returned zero found rows.

For example, consider the table created and populated using these statements:

CREATE TABLE t1 
(
    c1 INT NOT NULL, 
    c2 INT NOT NULL,
    PRIMARY KEY(c1), 
    KEY(c2)
) 
ENGINE = NDB;

INSERT INTO t1 VALUES(1, 1);

The following UPDATE statements, even though they did not change any rows, each still matched a row, but this was reported incorrectly in both cases, as shown here:

mysql> UPDATE t1 SET c2 = 1 WHERE c1 = 1;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> UPDATE t1 SET c1 = 1 WHERE c2 = 1;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

Now in such cases, the number of rows matched is correct. (In the case of each of the example UPDATE statements just shown, this is displayed as Rows matched: 1, as it should be.)

This issue could affect UPDATE statements involving any indexed columns in NDB tables, regardless of the type of index (including KEY, UNIQUE KEY, and PRIMARY KEY) or the number of columns covered by the index. (Bug#47955)

On Solaris, shutting down a management node failed when issuing the command to do so from a client connected to a different management node. (Bug#47948)

After changing the value of DiskSyncSize to 4294967039 (the maximum) in the config.ini file and reloading the cluster configuration, the new value was displayed in the update information written into the cluster log as a signed number instead of unsigned. (Bug#47944)

See also Bug#47932.

On Solaris 10 for SPARC, ndb_mgmd failed to parse the config.ini file when the DiskSyncSize configuration parameter, whose permitted range of values is 32768 to 4294967039, was set equal to 4294967040 (which is also the value of the internal constant MAX_INT_RNIL), nor could DiskSyncSize be set successfully any higher than the minimum value. (Bug#47932)

See also Bug#47944.

Setting FragmentLogFileSize to a value greater than 256 MB led to errors when trying to read the redo log file. (Bug#47908)

SHOW CREATE TABLE did not display the AUTO_INCREMENT value for NDB tables having AUTO_INCREMENT columns. (Bug#47865)

An optimization in MySQL Cluster NDB 7.0 causes the DBDICT kernel block to copy several tables at a time when synchronizing the data dictionary to a newly-started node; previously, this was done one table at a time. However, when NDB tables were sufficiently large and numerous, the internal buffer for storing them could fill up, causing a data node crash.

In testing, it was found that having 100 NDB tables with 128 columns each was enough to trigger this issue. (Bug#47859)

Under some circumstances, when a scan encountered an error early in processing by the DBTC kernel block (see The DBTC Block), a node could crash as a result. Such errors could be caused by applications sending incorrect data, or, more rarely, by a DROP TABLE operation executed in parallel with a scan. (Bug#47831)

When starting a node and synchronizing tables, memory pages were allocated even for empty fragments. In certain situations, this could lead to insufficient memory. (Bug#47782)

During an upgrade, newer nodes (NDB kernel block DBTUP) could in some cases try to use the long signal format for communication with older nodes (DBUTIL kernel block) that did not understand the newer format, causing older data nodes to fail after restarting. (Bug#47740)

A very small race-condition between NODE_FAILREP and LQH_TRANSREQ signals when handling node failure could lead to operations (locks) not being taken over when they should have been, and subsequently becoming stale. This could lead to node restart failures, and applications getting into endless lock-conflicts with operations that were not released until the node was restarted. (Bug#47715)

See also Bug#41297.

In some cases, the MySQL Server tried to use an error status whose value had never been set. The problem in the code that caused this, in hostname.cc, manifested when using debug builds of mysqld in MySQL Cluster replication.

This fix brings MySQL Cluster's error handling in hostname.cc in line with what is implemented in MySQL 5.4. (Bug#47548)

configure failed to honor the --with-zlib-dir option when trying to build MySQL Cluster from source. (Bug#47223)

Performing a system restart of the cluster after having performed a table reorganization which added partitions caused the cluster to become inconsistent, possibly leading to a forced shutdown, in either of the following cases:

Now, DBDIH is forced in such cases to use the version of the table definition held by the DBDICT kernel block, which was (already) correct and up to date. (Bug#46585)

ndbd was not built correctly when compiled using gcc 4.4.0. (The ndbd binary was built, but could not be started.) (Bug#46113)

ndb_mgmd failed to close client connections that had timed out. After running for some time, a race condition could develop in the management server, due to ndb_mgmd having exhausted all of its file descriptors in this fashion. (Bug#45497)

See also Bug#47712.

If a node failed while sending a fragmented long signal, the receiving node did not free long signal assembly resources that it had allocated for the fragments of the long signal that had already been received. (Bug#44607)

Numeric configuration parameters set in my.cnf were interpreted as signed rather than unsigned values. The effect of this was that values of 2G or more were truncated with the warning [MgmSrvr] Warning: option 'opt_name': signed value opt_value adjusted to 2147483647. Now such parameter values are treated as unsigned, so that this truncation does not take place.

This issue did not effect parameters set in config.ini. (Bug#44448)

When starting a cluster with a great many tables, it was possible for MySQL client connections as well as the slave SQL thread to issue DML statements against MySQL Cluster tables before mysqld had finished connecting to the cluster and making all tables writeable. This resulted in Table ... is read only errors for clients and the Slave SQL thread.

This issue is fixed by introducing the --ndb-wait-setup option for the MySQL server. This provides a configurable maximum amount of time that mysqld waits for all NDB tables to become writeable, before allowing MySQL clients or the slave SQL thread to connect. (Bug#40679)

See also Bug#46955.

When building MySQL Cluster, it was possible to configure the build using --with-ndb-port without supplying a port number. Now in such cases, configure fails with an error. (Bug#38502)

See also Bug#47941.

When the MySQL server SQL mode included STRICT_TRANS_TABLES, storage engine warnings and error codes specific to NDB were returned when errors occurred, instead of the MySQL server errors and error codes expected by some programming APIs (such as Connector/J) and applications. (Bug#35990)

When a copying operation exhausted the available space on a data node while copying large BLOB columns, this could lead to failure of the data node and a Table is full error on the SQL node which was executing the operation. Examples of such operations could include an ALTER TABLE that changed an INT column to a BLOB column, or a bulk insert of BLOB data that failed due to running out of space or to a duplicate key error. (Bug#34583, Bug#48040)

See also Bug#41674, Bug#45768.

Replication: When mysqlbinlog --verbose was used to read a binary log that had been recorded using the row-based format, the output for events that updated some but not all columns of tables was not correct. (Bug#47323)

Disk Data: A local checkpoint of an empty fragment could cause a crash during a system restart which was based on that LCP. (Bug#47832)

See also Bug#41915.

Disk Data: Multi-threaded data nodes could in some cases attempt to access the same memory structure in parallel, in a non-safe manner. This could result in data node failure when running ndbmtd while using Disk Data tables. (Bug#44195)

See also Bug#46507.

Cluster Replication: When using multiple active replication channels, it was sometimes possible that a node group would fail on the slave cluster, causing the slave cluster to shut down. (Bug#47935)

Cluster Replication: When recording a binary log using the --ndb-log-update-as-write and --ndb-log-updated-only options (both enabled by default) and later attempting to apply that binary log with mysqlbinlog, any operations that were played back from the log but which updated only some (but not all) columns caused any columns that were not updated to be reset to their default values. (Bug#47674)

See also Bug#47323, Bug#46662.

Cluster Replication: mysqlbinlog failed to apply correctly a binary log that had been recorded using --ndb-log-update-as-write=1. (Bug#46662)

See also Bug#47323, Bug#47674.

Cluster API: If an NDB API program reads the same column more than once, it is possible exceed the maximum allowable message size, in which case the operation should be aborted due to NDB error 880 Tried to read too much - too many getValue calls, however due to a change introduced in MySQL Cluster NDB 6.3.18, the check for this was not done correctly, which instead caused a data node crash. (Bug#48266)

Cluster API: The NDB API methods Dictionary::listEvents(), Dictionary::listIndexes(), Dictionary::listObjects(), and NdbOperation::getErrorLine() formerly had both const and non-const variants. The non-const versions of these methods have been removed. In addition, the NdbOperation::getBlobHandle() method has been re-implemented in order to provide consistent internal semantics. (Bug#47798)

Cluster API: A duplicate read of a column caused NDB API applications to crash. (Bug#45282)

Cluster API: The error handling shown in the example file ndbapi_scan.cpp included with the MySQL Cluster distribution was incorrect. (Bug#39573)

Installation of MySQL on Windows would fail to set the correct location for the character set files, which could lead to mysqld and mysql failing to initialize properly. (Bug#17270)

The disconnection of an API or SQL node having a node ID greater than 49 caused a forced shutdown of the cluster. (Bug#47844)

The error message text for NDB error code 410 (REDO log files overloaded...) was truncated. (Bug#23662)

A new option --log-name is added for ndb_mgmd. This option can be used to provide a name for the current node and then to identify it in messages written to the cluster log. For more information, see Section 17.4.4, “ndb_mgmd — The MySQL Cluster Management Server Daemon”. (Bug#47643)

--config-dir is now accepted by ndb_mgmd as an alias for the --configdir option. (Bug#42013)

Disk Data: Two new columns have been added to the output of ndb_desc to make it possible to determine how much of the disk space allocated to a given table or fragment remains free. (This information is not available from the INFORMATION_SCHEMA.FILES table, since the FILES table applies only to Disk Data files.) For more information, see Section 17.4.9, “ndb_desc — Describe NDB Tables”. (Bug#47131)

Important Change: Previously, the MySQL Cluster management node and data node programs, when run on Windows platforms, required the --nodaemon option in order to produce console output. Now, these programs run in the foreground when invoked from the command line on Windows, which is the same behavior that mysqld.exe displays on Windows. (Bug#45588)

Cluster Replication: Important Change: In a MySQL Cluster acting as a replication slave and having multiple SQL nodes, only the SQL node receiving events directly from the master recorded DDL statements in its binary logs unless this SQL node also had binary logging enabled; otherwise, other SQL nodes in the slave cluster failed to log DDL statements, regardless of their individual --log-bin settings.

The fix for this issue aligns binary logging of DDL statements with that of DML statements. In particular, you should take note of the following:

Affect on upgrades.  When upgrading from a previous MySQL CLuster release, you should perform either one of the following:

(Bug#45756)

The following issues with error logs generated by ndbmtd were addressed:

(Bug#47629)

mysqld allocated an excessively large buffer for handling BLOB values due to overestimating their size. (For each row, enough space was allocated to accommodate every BLOB or TEXT column value in the result set.) This could adversely affect performance when using tables containing BLOB or TEXT columns; in a few extreme cases, this issue could also cause the host system to run out of memory unexpectedly. (Bug#47574)

See also Bug#47572, Bug#47573.

NDBCLUSTER uses a dynamically-allocated buffer to store BLOB or TEXT column data that is read from rows in MySQL Cluster tables.

When an instance of the NDBCLUSTER table handler was recycled (this can happen due to table definition cache pressure or to operations such as FLUSH TABLES or ALTER TABLE), if the last row read contained blobs of zero length, the buffer was not freed, even though the reference to it was lost. This resulted in a memory leak.

For example, consider the table defined and populated as shown here:

CREATE TABLE t (a INT PRIMARY KEY, b LONGTEXT) ENGINE=NDB;

INSERT INTO t VALUES (1, REPEAT('F', 20000));
INSERT INTO t VALUES (2, '');

Now execute repeatedly a SELECT on this table, such that the zero-length LONGTEXT row is last, followed by a FLUSH TABLES statement (which forces the handler object to be re-used), as shown here:

      
SELECT a, length(b) FROM bl ORDER BY a;
FLUSH TABLES;

Prior to the fix, this resulted in a memory leak proportional to the size of the stored LONGTEXT value each time these two statements were executed. (Bug#47573)

See also Bug#47572, Bug#47574.

Large transactions involving joins between tables containing BLOB columns used excessive memory. (Bug#47572)

See also Bug#47573, Bug#47574.

After an NDB table had an ALTER ONLINE TABLE operation performed on it in a MySQL Cluster running a MySQL Cluster NDB 6.3.x release, it could not be upgraded online to a MySQL Cluster NDB 7.0.x release. This issue was detected using MySQL Cluster NDB 6.3.20, but is likely to effect any MySQL Cluster NDB 6.3.x release supporting online DDL operations. (Bug#47542)

When using multi-threade data nodes (ndbmtd) with NoOfReplicas set to a value greater than 2, attempting to restart any of the data nodes caused a forced shutdown of the entire cluster. (Bug#47530)

A variable was left uninitialized while a data node copied data from its peers as part of its startup routine; if the starting node died during this phase, this could lead a crash of the cluster when the node was later restarted. (Bug#47505)

Handling of LQH_TRANS_REQ signals was done incorrectly in DBLQH when the transaction coordinator failed during a LQH_TRANS_REQ session. This led to incorrect handling of multiple node failures, particularly when using ndbmtd. (Bug#47476)

The NDB kernel's parser (in ndb/src/common/util/Parser.cpp) did not interpret the backslash (“\”) character correctly. (Bug#47426)

During an online alter table operation, the new table definition was made available for users during the prepare-phase when it should only be exposed during and after a commit. This issue could affect NDB API applications, mysqld processes, or data node processes. (Bug#47375)

Aborting an online add column operation (for example, due to resource problems on a single data node, but not others) could lead to a forced node shutdown. (Bug#47364)

Clients attempting to connect to the cluster during shutdown could sometimes cause the management server to crash. (Bug#47325)

The size of the table descriptor pool used in the DBTUP kernel block was incorrect. This could lead to a data node crash when an LQH sent a CREATE_TAB_REF signal. (Bug#47215)

See also Bug#44908.

When a data node restarts, it first runs the redo log until reaching the latest restorable global checkpoint; after this it scans the remainder of the redo log file, searching for entries that should be invalidated so they are not used in any subsequent restarts. (It is possible, for example, if restoring GCI number 25, that there might be entries belonging to GCI 26 in the redo log.) However, under certain rare conditions, during the invalidation process, the redo log files themselves were not always closed while scanning ahead in the redo log. In rare cases, this could lead to MaxNoOfOpenFiles being exceeded, causing a the data node to crash. (Bug#47171)

For very large values of MaxNoOfTables + MaxNoOfAttributes, the calculation for StringMemory could overflow when creating large numbers of tables, leading to NDB error 773 (Out of string memory, please modify StringMemory config parameter), even when StringMemory was set to 100 (100 percent). (Bug#47170)

The default value for the StringMemory configuration parameter, unlike other MySQL Cluster configuration parameters, was not set in ndb/src/mgmsrv/ConfigInfo.cpp. (Bug#47166)

Signals from a failed API node could be received after an API_FAILREQ signal (see Operations and Signals) has been received from that node, which could result in invalid states for processing subsequent signals. Now, all pending signals from a failing API node are processed before any API_FAILREQ signal is received. (Bug#47039)

See also Bug#44607.

When reloading the management server configuration, only the last changed parameter was logged. (Bug#47036)

When using ndbmtd, a parallel DROP TABLE operation could cause data nodes to have different views of which tables should be included in local checkpoints; this discrepancy could lead to a node failure during an LCP. (Bug#46873)

Using triggers on NDB tables caused ndb_autoincrement_prefetch_sz to be treated as having the NDB kernel's internal default value (32) and the value for this variable as set on the cluster's SQL nodes to be ignored. (Bug#46712)

Now, when started with --initial --reload, ndb_mgmd tries to copy the configuration of an existing ndb_mgmd process with a confirmed configuration. This works only if the configuration files used by both management nodes are exactly the same. (Bug#45495, Bug#46488)

See also Bug#42015.

On Windows, ndbd --initial could hang in an endless loop while attempting to remove directories. (Bug#45402)

For multi-threaded data nodes, insufficient fragment records were allocated in the DBDIH NDB kernel block, which could lead to error 306 when creating many tables; the number of fragment records allocated did not take into account the number of LQH instances. (Bug#44908)

Running an ALTER TABLE statement while an NDB backup was in progress caused mysqld to crash. (Bug#44695)

When performing auto-discovery of tables on individual SQL nodes, NDBCLUSTER attempted to overwrite existing MyISAM .frm files and corrupted them.

Workaround.  In the mysql client, create a new table (t2) with same definition as the corrupted table (t1). Use your system shell or file manager to rename the old .MYD file to the new file name (for example, mv t1.MYD t2.MYD). In the mysql client, repair the new table, drop the old one, and rename the new table using the old file name (for example, RENAME TABLE t2 TO t1).

(Bug#42614)

When started with the --initial and --reload options, if ndb_mgmd could not find a configuration file or connect to another management server, it appeared to hang. Now, when trying to fetch its configuration from another management node, ndb_mgmd checks and signals (Trying to get configuration from other mgmd(s)) each 30 seconds that it has not yet done so. (Bug#42015)

See also Bug#45495.

Running ndb_restore with the --print or --print_log option could cause it to crash. (Bug#40428, Bug#33040)

An insert on an NDB table was not always flushed properly before performing a scan. One way in which this issue could manifest was that LAST_INSERT_ID() sometimes failed to return correct values when using a trigger on an NDB table. (Bug#38034)

When a data node received a TAKE_OVERTCCONF signal from the master before that node had received a NODE_FAILREP, a race condition could in theory result. (Bug#37688)

See also Bug#25364, Bug#28717.

Some joins on large NDB tables having TEXT or BLOB columns could cause mysqld processes to leak memory. The joins did not need to reference the TEXT or BLOB columns directly for this issue to occur. (Bug#36701)

On Mac OS X 10.5, commands entered in the management client failed and sometimes caused the client to hang, although management client commands invoked using the --execute (or -e) option from the system shell worked normally.

For example, the following command failed with an error and hung until killed manually, as shown here:

ndb_mgm> SHOW      
Warning, event thread startup failed, degraded printouts as result, errno=36
^C

However, the same management client command, invoked from the system shell as shown here, worked correctly:

shell> ndb_mgm -e "SHOW"

(Bug#35751)

See also Bug#34438.

Replication: In some cases, a STOP SLAVE statement could cause the replication slave to crash. This issue was specific to MySQL on Windows or Macintosh platforms. (Bug#45238, Bug#45242, Bug#45243, Bug#46013, Bug#46014, Bug#46030)

See also Bug#40796.

Disk Data: Calculation of free space for Disk Data table fragments was sometimes done incorrectly. This could lead to unnecessary allocation of new extents even when sufficient space was available in existing ones for inserted data. In some cases, this might also lead to crashes when restarting data nodes.

(Bug#47072)

Cluster API: In some circumstances, if an API node encountered a data node failure between the creation of a transaction and the start of a scan using that transaction, then any subsequent calls to startTransaction() and closeTransaction() could cause the same transaction to be started and closed repeatedly. (Bug#47329)

Cluster API: Performing multiple operations using the same primary key within the same NdbTransaction::execute() call could lead to a data node crash.

(Bug#44065)

See also Bug#44015.

API: The fix for Bug#24507 could lead in some cases to client application failures due to a race condition. Now the server waits for the “dummy” thread to return before exiting, thus making sure that only one thread can initialize the POSIX threads library. (Bug#42850)

Important Change: The default value of the DiskIOThreadPool data node configuration parameter has changed from 8 to 2.

On Solaris platforms, the MySQL Cluster management server and NDB API applications now use CLOCK_REALTIME as the default clock. (Bug#46183)

Formerly, node IDs were represented in the cluster log using a complex hexadecimal/binary encoding scheme. Now, node IDs are reported in the cluster log using numbers in standard decimal notation. (Bug#44248)

A new option --exclude-missing-columns has been added for the ndb_restore program. In the event that any tables in the database or databases being restored to have fewer columns than the same-named tables in the backup, the extra columns in the backup's version of the tables are ignored. For more information, see Section 17.4.17, “ndb_restore — Restore a MySQL Cluster Backup”. (Bug#43139)

(Bug#25984)

Previously, it was possible to disable arbitration only by setting ArbitrationRank to 0 on all management and API nodes. A new data node configuration parameter Arbitration simplifies this task; to disable arbitration, you can now use Arbitration = Disabled in the [ndbd default] section of the config.ini file.

It is now also possible to configure arbitration in such a way that the cluster waits until the time determined by ArbitrationTimeout passes for an external manager to perform arbitration instead of handling it internally. This can be done by setting Arbitration = WaitExternal in the [ndbd default] section of the config.ini file.

The default value for the Arbitration parameter is Default, which allows arbitration to proceed normally, as determined by the ArbitrationRank settings for the management and API nodes.

For more information, see Section 17.3.2.6, “Defining MySQL Cluster Data Nodes”.

Packaging: The pkg installer for MySQL Cluster on Solaris did not perform a complete installation due to an invalid directory reference in the post-install script. (Bug#41998)

The output from ndb_config --configinfo --xml contained quote characters (") within quoted XML attributes, causing it to be not well-formed. (Bug#46891)

When using multi-threaded data node processes (ndbmtd), it was possible for LQH threads to continue running even after all NDB tables had been dropped. This meant that dropping the last remaining NDB table during a local checkpoint could cause multi-threaded data nodes to fail. (Bug#46890)

During a global checkpoint, LQH threads could run unevenly, causing a circular buffer oveflow by the Subscription Manager, which led to data node failure. (Bug#46782)

See also Bug#46123, Bug#46723, Bug#45612.

Restarting the cluster following a local checkpoint and an online ALTER TABLE on a non-empty table caused data nodes to crash. (Bug#46651)

A combination of index creation and drop operations (or creating and dropping tables having indexes) with node and system restarts could lead to a crash. (Bug#46552)

Following an upgrade from MySQL Cluster NDB 6.3.x to MySQL Cluster NDB 7.0.6, DDL and backup operations failed. (Bug#46494, Bug#46563)

Full table scans failed to execute when the cluster contained more than 21 table fragments.

(Bug#46490)

Killing MySQL Cluster nodes immediately following a local checkpoint could lead to a crash of the cluster when later attempting to perform a system restart.

The exact sequence of events causing this issue was as follows:

(Bug#46412)

Creating an index when the cluster had run out of table records could cause data nodes to crash. (Bug#46295)

Ending a line in the config.ini file with an extra semicolon character (;) caused reading the file to fail with a parsing error. (Bug#46242)

When combining an index scan and a delete with a primary key delete, the index scan and delete failed to initialize a flag properly. This could in rare circumstances cause a data node to crash. (Bug#46069)

OPTIMIZE TABLE on an NDB table could in some cases cause SQL and data nodes to crash. This issue was observed with both ndbd and ndbmtd. (Bug#45971)

The AutoReconnect configuration parameter for API nodes (including SQL nodes) has been added. This is intended to prevent API nodes from re-using allocated node IDs during cluster restarts. For more information, see Section 17.3.2.7, “Defining SQL and Other API Nodes in a MySQL Cluster”.

This fix also introduces two new methods of the Ndb_cluster_connection class in the NDB API. For more information, see Ndb_cluster_connection::set_auto_reconnect(), and Ndb_cluster_connection::get_auto_reconnect(). (Bug#45921)

DML statements run during an upgrade from MySQL Cluster NDB 6.3 to NDB 7.0 were not handled correctly. (Bug#45917)

On Windows, the internal basestring_vsprintf() function did not return a POSIX-compliant value as expected, causing the management server to crash when trying to start a MySQL Cluster with more than 4 data nodes. (Bug#45733)

The signals used by ndb_restore to send progress information about backups to the cluster log accessed the cluster transporter without using any locks. Because of this, it was theoretically possible that these signals could be interefered with by heartbeat signals if both were sent at the same time, causing the ndb_restore messages to be corrupted. (Bug#45646)

Due to changes in the way that NDBCLUSTER handles schema changes (implementation of schema transactions) in MySQL Cluster NDB 7.0, it was not possible to create MySQL Cluster tables having more than 16 indexes using a single CREATE TABLE statement.

This issue occurs only in MySQL Cluster NDB 7.0 releases prior to 7.0.7 (including releases numbered NDB 6.4.x).

If you are not yet able to upgrade from an earlier MySQL Cluster NDB 7.0 release, you can work around this problem by creating the table without any indexes, then adding the indexes using a separate CREATE INDEX statement for each index. (Bug#45525)

storage/ndb/src/common/util/CMakeLists.txt did not build the BaseString-t test program for Windows as the equivalent storage/ndb/src/common/util/Makefile.am does when building MySQL Cluster on Unix platforms. (Bug#45099)

Problems could arise when using VARCHAR columns whose size was greater than 341 characters and which used the utf8_unicode_ci collation. In some cases, this combination of conditions could cause certain queries and OPTIMIZE TABLE statements to crash mysqld. (Bug#45053)

The warning message Possible bug in Dbdih::execBLOCK_COMMIT_ORD ... could sometimes appear in the cluster log. This warning is obsolete, and has been removed. (Bug#44563)

Debugging code causing ndbd to use file compression on NTFS filesystems failed with an error. (The code was removed.) This issue affected debug builds of MySQL Cluster on Windows platforms only. (Bug#44418)

ALTER TABLE REORGANIZE PARTITION could fail with Error 741 (Unsupported alter table) if the appropriate hash-map was not present. This could occur when adding nodes online; for example, when going from 2 data nodes to 3 data nodes with NoOfReplicas=1, or from 4 data nodes to 6 data nodes with NoOfReplicas=2. (Bug#44301)

Previously, a GCP STOP event was written to the cluster log as an INFO event. Now it is logged as a WARNING event instead. (Bug#43853)

In some cases, OPTIMIZE TABLE on an NDB table did not free any DataMemory. (Bug#43683)

If the cluster crashed during the execution of a CREATE LOGFILE GROUP statement, the cluster could not be restarted afterwards. (Bug#36702)

See also Bug#34102.

Disk Data: Partitioning: An NDBCLUSTER table created with a very large value for the MAX_ROWS option could — if this table was dropped and a new table with fewer partitions, but having the same table ID, was created — cause ndbd to crash when performing a system restart. This was because the server attempted to examine each partition whether or not it actually existed. (Bug#45154)

Disk Data: If the value set in the config.ini file for FileSystemPathDD, FileSystemPathDataFiles, or FileSystemPathUndoFiles was identical to the value set for FileSystemPath, that parameter was ignored when starting the data node with --initial option. As a result, the Disk Data files in the corresponding directory were not removed when performing an initial start of the affected data node or data nodes. (Bug#46243)

For an IPv6-enabled MySQL server, privileges specified using standard IPv4 addresses for hosts were not matched (only IPv4-mapped addresses were handled correctly).

As part of the fix for this bug, a new build option --disable-ipv6 has been introduced. Compiling MySQL with this option causes all IPv6-specific code in the server to be ignored.

(Bug#45606)

See also Bug#38247, Bug#43006, Bug#45283, Bug#45584.

The hostname cache failed to work correctly. (Bug#45584)

See also Bug#38247, Bug#43006, Bug#45283, Bug#45606.

The number of connection errors from a given host as counted by the server was periodically reset, with the result that max_connect_errors was never reached and invalid hosts were never blocked from trying to connect. (Bug#45283)

See also Bug#38247, Bug#43006, Bug#45584, Bug#45606.

The IPv6 loopback address ::1 was interpeted as a hostname rather than a numeric IP address.

In addition, the IPv6-enabled server on Windows interpeted the hostname localhost as ::1 only, which failed to match the default root@127.0.0.1 entry in the mysql.user privilege table. (Bug#43006)

See also Bug#38247, Bug#45283, Bug#45584, Bug#45606.

An IPv6-enabled MySQL server did not resolve the IP addresses of incoming connections correctly, with the result that a connection that attempted to match any privilege table entries using fully-qualified domain names for hostnames or hostnames using wildcards were dropped. (Bug#38247)

See also Bug#43006, Bug#45283, Bug#45584, Bug#45606.

The ndb_config utility program can now provide an offline dump of all MySQL Cluster configuration parameters including information such as default and permitted values, brief description, and applicable section of the config.ini file. A dump in text format is produced when running ndb_config with the new --configinfo option, and in XML format when the options --configinfo --xml are used together. For more information and examples, see Section 17.4.6, “ndb_config — Extract MySQL Cluster Configuration Information”.

Important Change: Partitioning: User-defined partitioning of an NDBCLUSTER table without any primary key sometimes failed, and could cause mysqld to crash.

Now, if you wish to create an NDBCLUSTER table with user-defined partitioning, the table must have an explicit primary key, and all columns listed in the partitioning expression must be part of the primary key. The hidden primary key used by the NDBCLUSTER storage engine is not sufficient for this purpose. However, if the list of columns is empty (that is, the table is defined using PARTITION BY [LINEAR] KEY()), then no explicit primary key is required.

This change does not effect the partitioning of tables using any storage engine other than NDBCLUSTER. (Bug#40709)

Important Change: Previously, the configuration parameter NoOfReplicas had no default value. Now the default for NoOfReplicas is 2, which is the recommended value in most settings. (Bug#44746)

Important Note: It was not possible to perform an online upgrade from any MySQL Cluster NDB 6.x release to MySQL Cluster NDB 7.0.5 or any to earlier MySQL Cluster NDB 7.0 release.

With this fix, it is possible in MySQL Cluster NDB 7.0.6 and later to perform online upgrades from MySQL Cluster NDB 6.3.8 and later MySQL Cluster NDB 6.3 releases, or from MySQL Cluster NDB 7.0.5 or later MySQL Cluster NDB 7.0 releases. Online upgrades to MySQL Cluster NDB 7.0 releases previous to MySQL Cluster NDB 7.0.6 from earlier MySQL Cluster releases remain unsupported; online upgrades from MySQL Cluster NDB 7.0 releases previous to MySQL Cluster NDB 7.0.5 (including NDB 6.4.x beta releases) to later MySQL Cluster NDB 7.0 releases also remain unsupported. (Bug#44294)

An internal NDB API buffer was not properly initialized. (Bug#44977)

When a data node had written its GCI marker to the first page of a megabyte, and that node was later killed during restart after having processed that page (marker) but before completing a LCP, the data node could fail with filesystem errors. (Bug#44952)

See also Bug#42564, Bug#44291.

When restarting a data nodes, management and API nodes reconnecting to it failed to re-use existing ports that had already been dynamically allocated for communications with that data node. (Bug#44866)

When ndb_config could not find the file referenced by the --config-file option, it tried to read my.cnf instead, then failed with a misleading error message. (Bug#44846)

When a data node was down so long that its most recent local checkpoint depended on a global checkpoint that was no longer restorable, it was possible for it to be unable to use optimized node recovery when being restarted later. (Bug#44844)

See also Bug#26913.

Online upgrades to MySQL Cluster NDB 7.0 from a MySQL Cluster NDB 6.3 release could fail due to changes in the handling of key lengths and unique indexes during node recovery. (Bug#44827)

ndb_config --xml did not output any entries for the HostName parameter. In addition, the default listed for MaxNoOfFiles was outside the allowed range of values. (Bug#44749)

See also Bug#44685, Bug#44746.

The output of ndb_config --xml did not provide information about all sections of the configuration file. (Bug#44685)

See also Bug#44746, Bug#44749.

Use of __builtin_expect() had the side effect that compiler warnings about misuse of = (assignment) instead of == in comparisons were lost when building in debug mode. This is no longer employed when configuring the build with the --with-debug option. (Bug#44570)

See also Bug#44567.

Inspection of the code revealed that several assignment operators (=) were used in place of comparison operators (==) in DbdihMain.cpp. (Bug#44567)

See also Bug#44570.

When using large numbers of configuration parameters, the management server took an excessive amount of time (several minutes or more) to load these from the configuration cache when starting. This problem occurred when there were more than 32 configuration parameters specified, and became progressively worse with each additional multiple of 32 configuration parameters. (Bug#44488)

Building the MySQL Cluster NDB 7.0 tree failed when using the icc compiler. (Bug#44310)

SSL connections to SQL nodes failed on big-endian platforms. (Bug#44295)

Signals providing node state information (NODE_STATE_REP and CHANGE_NODE_STATE_REQ) were not propagated to all blocks of ndbmtd. This could cause the following problems:

(Bug#44291)

See also Bug#42564.

An NDB internal timing function did not work correctly on Windows and could cause mysqld to fail on some AMD processors, or when running inside a virtual machine. (Bug#44276)

It was possible for NDB API applications to insert corrupt data into the database, which could subquently lead to data node crashes. Now, stricter checking is enforced on input data for inserts and updates. (Bug#44132)

ndb_restore failed when trying to restore data on a big-endian machine from a backup file created on a little-endian machine. (Bug#44069)

Repeated starting and stopping of data nodes could cause ndb_mgmd to fail. This issue was observed on Solaris/SPARC. (Bug#43974)

A number of incorrectly formatted output strings in the source code caused compiler warnings. (Bug#43878)

When trying to use a data node with an older version of the management server, the data node crashed on startup. (Bug#43699)

In some cases, data node restarts during a system restart could fail due to insufficient redo log space. (Bug#43156)

NDBCLUSTER did not build correctly on Solaris 9 platforms. (Bug#39080)

See also Bug#39036, Bug#39038.

The output of ndbd --help did not provide clear information about the program's --initial and --initial-start options. (Bug#28905)

It was theoretically possible for the value of a nonexistent column to be read as NULL, rather than causing an error. (Bug#27843)

Disk Data: During a checkpoint, restore points are created for both the on-disk and in-memory parts of a Disk Data table. Under certain rare conditions, the in-memory restore point could include or exclude a row that should have been in the snapshot. This would later later lead to a crash during or following recovery.

This issue was somewhat more likely to be encountered when using ndbmtd. (Bug#41915)

See also Bug#47832.

Disk Data: This fix supercedes and improves on an earlier fix made for this bug in MySQL 5.1.18. (Bug#24521)

Cluster Replication: A failure when setting up replication events could lead to subsequent data node failures. (Bug#44915)

Two new server status variables Ndb_scan_count and Ndb_pruned_scan_count have been introduced. Ndb_scan_count gives the number of scans executed since the cluster was last started. Ndb_pruned_scan_count gives the number of scans for which NDBCLUSTER was able to use partition pruning. Together, these variables can be used to help determine in the MySQL server whether table scans are pruned by NDBCLUSTER. (Bug#44153)

Important Note: Due to problem discovered after the code freeze for this release, it is not possible to perform an online upgrade from any MySQL Cluster NDB 6.x release to MySQL Cluster NDB 7.0.5 or any earlier MySQL Cluster NDB 7.0 release.

This issue is fixed in MySQL Cluster NDB 7.0.6 and later for upgrades from MySQL Cluster NDB 6.3.8 and later MySQL Cluster NDB 6.3 releases, or from MySQL Cluster NDB 7.0.5. (Bug#44294)

Cluster Replication: If data node failed during an event creation operation, there was a slight risk that a surviving data node could send an invalid table reference back to NDB, causing the operation to fail with a false Error 723 (No such table). This could take place when a data node failed as a mysqld process was setting up MySQL Cluster Replication. (Bug#43754)

Cluster API: The following issues occurred when performing an online (rolling) upgrade of a cluster to a version of MySQL Cluster that supports configuration caching from a version that does not:

(Bug#43641)

If the number of fragments per table rises above a certain threshold, the DBDIH kernel block's on-disk table-definition grows large enough to occupy 2 pages. However, in MySQL Cluster NDB 7.0 (including MySQL Cluster NDB 6.4 releases), only 1 page was actually written, causing table definitions stored on disk to be incomplete.

This issue was not observed in MySQL Cluster release series prior to MySQL Cluster NDB 7.0. (Bug#44135)

TransactionDeadlockDetectionTimeout values less than 100 were treated as 100. This could cause scans to time out unexpectedly. (Bug#44099)

The file ndberror.c contained a C++-style comment, which caused builds to fail with some C compilers. (Bug#44036)

A race condition could occur when a data node failed to restart just before being included in the next global checkpoint. This could cause other data nodes to fail. (Bug#43888)

The setting for ndb_use_transactions was ignored. This issue was only known to occur in MySQL Cluster NDB 6.4.3 and MySQL Cluster NDB 7.0.4. (Bug#43236)

When a data node process had been killed after allocating a node ID, but before making contact with any other data node processes, it was not possible to restart it due to a node ID allocation failure.

This issue could effect either ndbd or ndbmtd processes. (Bug#43224)

This regression was introduced by Bug#42973.

ndb_restore crashed when trying to restore a backup made to a MySQL Cluster running on a platform having different endianness from that on which the original backup was taken. (Bug#39540)

PID files for the data and management node daemons were not removed following a normal shutdown. (Bug#37225)

ndb_restore --print_data did not handle DECIMAL columns correctly. (Bug#37171)

Invoking the management client START BACKUP command from the system shell (for example, as ndb_mgm -e "START BACKUP") did not work correctly, unless the backup ID was included when the command was invoked.

Now, the backup ID is no longer required in such cases, and the backup ID that is automatically generated is printed to stdout, similar to how this is done when invoking START BACKUP within the management client. (Bug#31754)

When aborting an operation involving both an insert and a delete, the insert and delete were aborted separately. This was because the transaction coordinator did not know that the operations affected on same row, and, in the case of a committed-read (tuple or index) scan, the abort of the insert was performed first, then the row was examined after the insert was aborted but before the delete was aborted. In some cases, this would leave the row in a inconsistent state. This could occur when a local checkpoint was performed during a backup. This issue did not affect primary ley operations or scans that used locks (these are serialized).

After this fix, for ordered indexes, all operations that follow the operation to be aborted are now also aborted.

Disk Data: When using multi-threaded data nodes, DROP TABLE statements on Disk Data tables could hang. (Bug#43825)

Disk Data: This fix completes one that was made for this issue in MySQL Cluster NDB-7.0.4, which did not rectify the problem in all cases. (Bug#43632)

Cluster Replication: When creating or altering a table an NdbEventOperation is created by the mysqld process to monitor the table for subsequent logging in the binlog. If this happened during a node restart there was a chance that the reference count on this event operation object could be incorrect, which could lead to an assert in debug MySQL Cluster builds. (Bug#43752)

Cluster API: If the largest offset of a RecordSpecification used for an NdbRecord object was for the NULL bits (and thus not a column), this offset was not taken into account when calculating the size used for the RecordSpecification. This meant that the space for the NULL bits could be overwritten by key or other information. (Bug#43891)

Cluster API: BIT columns created using the native NDB API format that were not created as nullable could still sometimes be overwritten, or cause other columns to be overwritten.

This issue did not effect tables having BIT columns created using the mysqld format (always used by MySQL Cluster SQL nodes). (Bug#43802)

Important Change: The default values for a number of MySQL Cluster configuration parameters relating to memory usage and buffering have changed. These parameters include RedoBuffer, LongMessageBuffer, BackupMemory, BackupDataBufferSize, BackupLogBufferSize, BackupWriteSize, BackupMaxWriteSize, SendBufferMemory (when applied to TCP transporters), and ReceiveBufferMemory.

For more information, see Section 17.3, “MySQL Cluster Configuration”.

When restoring from backup, ndb_restore now reports the last global checkpoint reached when the backup was taken. (Bug#37384)

Cluster API: Partition pruning did not work correctly for queries involving multiple range scans.

As part of the fix for this issue, several improvements have been made in the NDB API, including the addition of a new NdbScanOperation::getPruned() method, a new variant of NdbIndexScanOperation::setBound(), and a new Ndb::PartitionSpec data structure. For more information about these changes, see NdbScanOperation::getPruned(), NdbIndexScanOperation::setBound, and The PartitionSpec Structure. (Bug#37934)

TimeBetweenLocalCheckpoints was measured from the end of one local checkpoint to the beginning of the next, rather than from the beginning of one LCP to the beginning of the next. This meant that the time spent performing the LCP was not taken into account when determining the TimeBetweenLocalCheckpoints interval, so that LCPs were not started often enough, possibly causing data nodes to run out of redo log space prematurely. (Bug#43567)

The management server failed to start correctly in daemon mode. (Bug#43559)

Following a DROP NODEGROUP command, the output of SHOW in the ndb_mgm cliently was not updated to reflect the fact that the data nodes affected by this command were no longer part of a node group. (Bug#43413)

Using indexes containing variable-sized columns could lead to internal errors when the indexes were being built. (Bug#43226)

When using ndbmtd, multiple data node failures caused the remaining data nodes to fail as well. (Bug#43109)

It was not possible to add new data nodes to the cluster online using multi-threaded data node processes (ndbmtd). (Bug#43108)

Some queries using combinations of logical and comparison operators on an indexed column in the WHERE clause could fail with the error Got error 4541 'IndexBound has no bound information' from NDBCLUSTER. (Bug#42857)

Disk Data: When using multi-threaded data nodes, dropping a Disk Data table followed by a data node restart led to a crash. (Bug#43632)

Disk Data: When using ndbmtd, repeated high-volume inserts (on the order of 10000 rows inserted at a time) on a Disk Data table would eventually lead to a data node crash. (Bug#41398)

Disk Data: When a log file group had an undo log file whose size was too small, restarting data nodes failed with Read underflow errors.

As a result of this fix, the minimum allowed INTIAL_SIZE for an undo log file is now 1M (1 megabyte). (Bug#29574)

Cluster API: The default NdbRecord structures created by NdbDictionary could have overlapping null bits and data fields. (Bug#43590)

Cluster API: When performing insert or write operations, NdbRecord allows key columns to be specified in both the key record and in the attribute record. Only one key column value for each key column should be sent to the NDB kernel, but this was not guaranteed. This is now ensured as follows: For insert and write operations, key column values are taken from the key record; for scan takeover update operations, key column values are taken from the attribute record. (Bug#42238)

Cluster API: Ordered index scans using NdbRecord formerly expressed a BoundEQ range as separate lower and upper bounds, resulting in 2 copies of the column values being sent to the NDB kernel.

Now, when a range is specified by NdbScanOperation::setBound(), the passed pointers, key lengths, and inclusive bits are compared, and only one copy of the equal key columns is sent to the kernel. This makes such operations more efficient, as half the amount of KeyInfo is now sent for a BoundEQ range as before. (Bug#38793)

Important Change: Replication: RESET MASTER and RESET SLAVE now reset the values shown for Last_IO_Error, Last_IO_Errno, Last_SQL_Error, and Last_SQL_Errno in the output of SHOW SLAVE STATUS. (Bug#34654)

See also Bug#44270.

A new data node configuration parameter MaxLCPStartDelay has been introduced to facilitate parallel node recovery by causing a local checkpoint to be delayed while recovering nodes are synchronizing data dictionaries and other meta-information. For more information about this parameter, see Section 17.3.2.6, “Defining MySQL Cluster Data Nodes”. (Bug#43053)

New options are introduced for ndb_restore for determining which tables or databases should be restored:

For more information about these options, see Section 17.4.17, “ndb_restore — Restore a MySQL Cluster Backup”. (Bug#40429)

Disk Data: It is now possible to specify default locations for Disk Data data files and undo log files, either together or separately, using the data node configuration parameters FileSystemPathDD, FileSystemPathDataFiles, and FileSystemPathUndoFiles. For information about these configuration parameters, see Disk Data filesystem parameters.

It is also now possible to specify a log file group, tablespace, or both, that is created when the cluster is started, using the InitialLogFileGroup and InitialTablespace data node configuration parameters. For information about these configuration parameters, see Disk Data object creation parameters.

Performance: Updates of the SYSTAB_0 system table to obtain a unique identifier did not use transaction hints for tables having no primary key. In such cases the NDB kernel used a cache size of 1. This meant that each insert into a table not having a primary key required an update of the corresponding SYSTAB_0 entry, creating a potential performance bottleneck.

With this fix, inserts on NDB tables without primary keys can be under some conditions be performed up to 100% faster than previously. (Bug#39268)

Important Note: It is not possible in this release to install the InnoDB plugin if InnoDB support has been compiled into mysqld. (Bug#42610)

This regression was introduced by Bug#29263.

Packaging: Packages for MySQL Cluster were missing the libndbclient.so and libndbclient.a files. (Bug#42278)

Partitioning: Executing ALTER TABLE ... REORGANIZE PARTITION on an NDBCLUSTER table having only one partition caused mysqld to crash. (Bug#41945)

See also Bug#40389.

Backup IDs greater than 2³¹ were not handled correctly, causing negative values to be used in backup directory names and printouts. (Bug#43042)

When using ndbmtd, NDB kernel threads could hang while trying to start the data nodes with LockPagesInMainMemory set to 1. (Bug#43021)

When using multiple management servers and starting several API nodes (possibly including one or more SQL nodes) whose connectstrings listed the management servers in different order, it was possible for 2 API nodes to be assigned the same node ID. When this happened it was possible for an API node not to get fully connected, consequently producing a number of errors whose cause was not easily recognizable. (Bug#42973)

When using multi-threaded data nodes, IndexMemory, MaxNoOfLocalOperations, and MaxNoOfLocalScans were effectively multiplied by the number of local query handlers in use by each ndbmtd instance. (Bug#42765)

See also Bug#42215.

ndb_error_reporter worked correctly only with GNU tar. (With other versions of tar, it produced empty archives.) (Bug#42753)

Triggers on NDBCLUSTER tables caused such tables to become locked. (Bug#42751)

See also Bug#16229, Bug#18135.

When performing more than 32 index or tuple scans on a single fragment, the scans could be left hanging. This caused unnecessary timeouts, and in addition could possibly lead to a hang of an LCP. (Bug#42559)

A data node failure that occurred between calls to NdbIndexScanOperation::readTuples(SF_OrderBy) and NdbTransaction::Execute() was not correctly handled; a subsequent call to nextResult() caused a null pointer to be deferenced, leading to a segfault in mysqld. (Bug#42545)

If the cluster configuration cache file was larger than 32K, the management server would not start. (Bug#42543)

Issuing SHOW GLOBAL STATUS LIKE 'NDB%' before mysqld had connected to the cluster caused a segmentation fault. (Bug#42458)

When using ndbmtd for all data nodes, repeated failures of one data node during DML operations caused other data nodes to fail. (Bug#42450)

Data node failures that occurred before all data nodes had connected to the cluster were not handled correctly, leading to additional data node failures. (Bug#42422)

When using multi-threaded data nodes, their DataMemory and IndexMemory usage as reported was multiplied by the number of local query handlers (worker threads), making it appear that much more memory was being used than was actually the case. (Bug#42215)

See also Bug#42765.

Given a MySQL Cluster containing no data (that is, whose data nodes had all been started using --initial, and into which no data had yet been imported) and having an empty backup directory, executing START BACKUP with a user-specified backup ID caused the data nodes to crash. (Bug#41031)

In some cases, NDB did not check correctly whether tables had changed before trying to use the query cache. This could result in a crash of the debug MySQL server. (Bug#40464)

Disk Data: It was not possible to add an in-memory column online to a table that used a table-level or column-level STORAGE DISK option. The same issue prevented ALTER ONLINE TABLE ... REORGANIZE PARTITION from working on Disk Data tables. (Bug#42549)

Disk Data: Repeated insert and delete operations on disk-based tables could lead to failures in the NDB Tablespace Manager (TSMAN kernel block). (Bug#40344)

Disk Data: Creating a Disk Data tablespace with a very large extent size caused the data nodes to fail. The issue was observed when using extent sizes of 100 MB and larger. (Bug#39096)

Disk Data: Trying to execute a CREATE LOGFILE GROUP statement using a value greater than 150M for UNDO_BUFFER_SIZE caused data nodes to crash.

As a result of this fix, the upper limit for UNDO_BUFFER_SIZE is now 600M; attempting to set a higher value now fails gracefully with an error. (Bug#34102)

See also Bug#36702.

Disk Data: When attempting to create a tablespace that already existed, the error message returned was Table or index with given name already exists. (Bug#32662)

Disk Data: Using a path or filename longer than 128 characters for Disk Data undo log files and tablespace data files caused a number of issues, including failures of CREATE LOGFILE GROUP, ALTER LOGFILE GROUP, CREATE TABLESPACE, and ALTER TABLESPACE statements, as well as crashes of management nodes and data nodes.

With this fix, the maximum length for path and file names used for Disk Data undo log files and tablespace data files is now the same as the maximum for the operating system. (Bug#31769, Bug#31770, Bug#31772)

Disk Data: Attempting to perform a system restart of the cluster where there existed a logfile group without and undo log files caused the data nodes to crash.

(Bug#17614)

Cluster Replication: Being disconnected from the cluster while setting up the binary log caused mysqld to hang or crash. (Bug#43045)

Cluster Replication: Primary key updates on MyISAM and InnoDB tables failed to replicate to NDBCLUSTER tables. (Bug#42921)

Cluster API: Some error messages from ndb_mgmd contained newline (\n) characters. This could break the MGM API protocol, which uses the newline as a line separator. (Bug#43104)

Cluster API: When using an ordered index scan without putting all key columns in the read mask, this invalid use of the NDB API went undetected, which resulted in the use of uninitialized memory. (Bug#42591)

Connections using IPv6 were not handled correctly by mysqld. (Bug#42413)

See also Bug#42412, Bug#38247.

When a cluster backup failed with Error 1304 (Node node_id1: Backup request from node_id2 failed to start), no clear reason for the failure was provided.

As part of this fix, MySQL Cluster now retries backups in the event of sequence errors. (Bug#42354)

See also Bug#22698.

Issuing SHOW ENGINE NDBCLUSTER STATUS on an SQL node before the management server had connected to the cluster caused mysqld to crash. (Bug#42264)

When using ndbmtd, setting MaxNoOfThreads to a value higher than the actual number of cores available and with insufficient SharedGlobalMemory caused the data nodes to crash.

The fix for this issue changes the behavior of ndbmtd such that its internal job buffers no longer rely on SharedGlobalMemory. (Bug#42254)

Important Change: Formerly, when the management server failed to create a transporter for a data node connection, net_write_timeout seconds elapsed before the data node was actually allowed to disconnect. Now in such cases the disconnection occurs immediately. (Bug#41965)

See also Bug#41713.

Formerly, when using MySQL Cluster Replication, records for “empty” epochs — that is, epochs in which no changes to NDBCLUSTER data or tables took place — were inserted into the ndb_apply_status and ndb_binlog_index tables on the slave even when --log-slave-updates was disabled. Beginning with MySQL Cluster NDB 6.2.16 and MySQL Cluster NDB 6.3.13 this was changed so that these “empty” eopchs were no longer logged. However, it is now possible to re-enable the older behavior (and cause “empty” epochs to be logged) by using the --ndb-log-empty-epochs option. For more information, see Section 16.1.3.3, “Replication Slave Options and Variables”.

See also Bug#37472.

Cluster Replication: IPv6 networking is now supported between MySQL Cluster SQL nodes. This means that it is now possible to replicate between instances of MySQL Cluster using IPv6 addresses.

A maximum of 11 TUP scans were allowed in parallel. (Bug#42084)

The management server could hang after attempting to halt it with the STOP command in the management client. (Bug#42056)

See also Bug#40922.

When using ndbmtd, one thread could flood another thread, which would cause the system to stop with a job buffer full condition (currently implemented as an abort). This could be caused by committing or aborting a large transaction (50000 rows or more) on a single data node running ndbmtd. To prevent this from happening, the number of signals that can be accepted by the system threads is calculated before excuting them, and only executing them if sufficient space is found. (Bug#42052)

MySQL Cluster would not compile when using libwrap. This issue was known to occur only in MySQL Cluster NDB 6.4.0. (Bug#41918)

Trying to execute an ALTER ONLINE TABLE ... ADD COLUMN statement while inserting rows into the table caused mysqld to crash. (Bug#41905)

When a data node connects to the management server, the node sends its node ID and transporter type; the management server then verifies that there is a transporter set up for that node and that it is in the correct state, and then sends back an acknowledgement to the connecting node. If the transporter was not in the correct state, no reply was sent back to the connecting node, which would then hang until a read timeout occurred (60 seconds). Now, if the transporter is not in the correct state, the management server acknowledges this promptly, and the node immediately disconnects. (Bug#41713)

See also Bug#41965.

Issuing EXIT in the management client sometimes caused the client to hang. (Bug#40922)

In the event that a MySQL Cluster backup failed due to file permissions issues, conflicting reports were issued in the management client. (Bug#34526)

If all data nodes were shut down, MySQL clients were unable to access NDBCLUSTER tables and data even after the data nodes were restarted, unless the MySQL clients themselves were restarted. (Bug#33626)

Important Change: MySQL Cluster now caches its configuration data. This means that, by default, the management server only reads the global configuration file (usually named config.ini) the first time that it is started, and does not automatically re-read the this file when restarted. This behavior can be controlled using new management server options (--config-dir, --initial, and --reload) that have been added for this purpose. For more information, see Section 17.3.2, “MySQL Cluster Configuration Files”, and Section 17.4.4, “ndb_mgmd — The MySQL Cluster Management Server Daemon”.

It is now possible while in Single User Mode to restart all data nodes using ALL RESTART in the management client. Restarting of individual nodes while in Single User Mode remains disallowed. (Bug#31056)

It is now possible to add data nodes to a MySQL Cluster online — that is, to a running MySQL Cluster without shutting it down.

For information about the procedure for adding data nodes online, see Section 17.5.10, “Adding MySQL Cluster Data Nodes Online”.

A multi-threaded version of the MySQL Cluster data node daemon is now available. The multi-threaded ndbmtd binary is similar to ndbd and functions in much the same way, but is intended for use on machines with multiple CPU cores.

For more information, see Section 17.4.3, “ndbmtd — The MySQL Cluster Data Node Daemon (Multi-Threaded)”.

It is now possible when performing a cluster backup to determine whether the backup matches the state of the data when the backup began or when it ended, using the new START BACKUP options SNAPSHOTSTART and SNAPSHOTEND in the management client. See Section 17.5.3.2, “Using The MySQL Cluster Management Client to Create a Backup”, for more information.

API nodes disconnected too agressively from cluster when data nodes were being restarted. This could sometimes lead to the API node being unable to access the cluster at all during a rolling restart. (Bug#41462)

When long signal buffer exhaustion in the ndbd process resulted in a signal being dropped, the usual handling mechanism did not take fragmented signals into account. This could result in a crash of the data node because the fragmented signal handling mechanism was not able to work with the missing fragments. (Bug#39235)

The failure of a master node during a DDL operation caused the cluster to be unavailable for further DDL operations until it was restarted; failures of nonmaster nodes during DLL operations caused the cluster to become completely inaccessible. (Bug#36718)

Status messages shown in the management client when restarting a management node were inappropriate and misleading. Now, when restarting a management node, the messages displayed are as follows, where node_id is the management node's node ID:

ndb_mgm> node_id RESTART
Shutting down MGM node node_id for restart
Node node_id is being restarted

ndb_mgm>

(Bug#29275)

A data node failure when NoOfReplicas was greater than 2 caused all cluster SQL nodes to crash. (Bug#18621)

Partitioning: A query on a user-partitioned table caused MySQL to crash, where the query had the following characteristics:

Two examples of such a query are given here, where a represents an indexed column used in the table's partitioning key:

(Bug#40954)

This regression was introduced by Bug#30573, Bug#33257, Bug#33555.