Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

- In-Memory storage - Real-time performance
- Transparent Auto-Sharding - Read & write scalability
- Active-Active/Multi-Master geographic replication
- 99.999% High Availability with no single point of failure
and on-line maintenance
- NoSQL and SQL APIs (including C++, Java, http, Memcached
and JavaScript/Node.js)

MySQL Cluster 7.4 makes significant advances in performance;
operational efficiency (such as enhanced reporting and faster restarts
and upgrades) and conflict detection and resolution for active-active
replication between MySQL Clusters.

MySQL Cluster 7.4.16 has been released and can be downloaded from

http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/7.4/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

http://www.mysql.com/products/cluster/

Enjoy !

==============================================================================

Changes in MySQL NDB Cluster 7.4.16 (5.6.37-ndb-7.4.16) (2017-07-18)

MySQL NDB Cluster 7.4.16 is a new release of MySQL NDB
Cluster 7.4, based on MySQL Server 5.6 and including features
in version 7.4 of the NDB storage engine, as well as fixing
recently discovered bugs in previous NDB Cluster releases.

Obtaining MySQL NDB Cluster 7.4. MySQL NDB Cluster 7.4
source code and binaries can be obtained from
http://dev.mysql.com/downloads/cluster/.

For an overview of changes made in MySQL NDB Cluster 7.4, see
What is New in NDB Cluster 7.4
(http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what-is-new-7-4.html).


This release also incorporates all bugfixes and changes made
in previous NDB Cluster releases, as well as all bugfixes and
feature changes which were added in mainline MySQL 5.6
through MySQL 5.6.37 (see Changes in MySQL 5.6.37 (Not yet
released, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-37.html)).

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* NDB Replication: Added the --ndb-log-update-minimal
option for logging by mysqld. This option causes only
primary key values to be written in the before image, and
only changed columns in the after image. (Bug #24438868)

* Added the --diff-default option for ndb_config. This
option causes the program to print only those parameters
having values that differ from their defaults. (Bug
#85831, Bug #25844166)

* Added the --query-all option to ndb_config. This option
acts much like the --query option except that --query-all
(short form: -a) dumps configuration information for all
attributes at one time. (Bug #60095, Bug #11766869)

Bugs Fixed

* NDB Replication: Added a check to stop an NDB replication
slave when configuration as a multi-threaded slave is
detected (for example, if slave_parallel_workers is set
to a nonzero value). (Bug #21074209)

* NDB Cluster APIs: The implementation method
NdbDictionary::NdbTableImpl::getColumn(), used from many
places in the NDB API where a column is referenced by
name, has been made more efficient. This method used a
linear search of an array of columns to find the correct
column object, which could be inefficient for tables with
many columns, and was detected as a significant use of
CPU in customer applications. (Ideally, users should
perform name-to-column object mapping, and then use
column IDs or objects in method calls, but in practice
this is not always done.) A less costly hash index
implementation, used previously for the name lookup, is
reinstated for tables having relatively many columns. (A
linear search continues to be used for tables having
fewer columns, where the difference in performance is
neglible.) (Bug #24829435)

* MySQL NDB ClusterJ: The JTie and NDB JTie tests were
skipped when the unit tests for ClusterJ were being run.
(Bug #26088583)

* Backup .log files contained log entries for one or more
extra fragments, due to an issue with filtering out
changes logged by other nodes in the same node group.
This resulted in a larger .log file and thus use of more
resources than necessary; it could also cause problems
when restoring, since backups from different nodes could
interfere with one another while the log was being
applied. (Bug #25891014)

* When making the final write to a redo log file, it is
expected that the next log file is already opened for
writes, but this was not always the case with a slow
disk, leading to node failure. Now in such cases NDB
waits for the next file to be opened properly before
attempting to write to it. (Bug #25806659)

* Data node threads can be bound to a single CPU or a set
of CPUs, a set of CPUs being represented internally by
NDB as a SparseBitmask. When attempting to lock to a set
of CPUs, CPU usage was excessive due to the fact that the
routine performing the locks used the
mt_thr_config.cpp::do_bind() method, which looks for bits
that are set over the entire theoretical range of the
SparseBitmask (2^32-2, or 4294967294). This is fixed by
using SparseBitmask::getBitNo(), which can be used to
iterate over only those bits that are actually set,
instead. (Bug #25799506)

* A bulk update is executed by reading records and
executing a transaction on the set of records, which is
started while reading them. When transaction
initialization failed, the transaction executor function
was subsequently unaware that this had occurred, leading
to SQL node failures. This issue is fixed by providing
appropriate error handling when attempting to initialize
the transaction. (Bug #25476474)
References: See also: Bug #20092754.

* Setting NoOfFragmentLogParts such that there were more
than 4 redo log parts per local data manager led to
resource exhaustion and subsequent multiple data node
failures. Since this is an invalid configuration, a check
has been added to detect a configuration with more than 4
redo log parts per LDM, and reject it as invalid. (Bug
#25333414)

* Execution of an online ALTER TABLE ... REORGANIZE
PARTITION statement on an NDB table having a primary key
whose length was greater than 80 bytes led to restarting
of data nodes, causing the reorganization to fail. (Bug
#25152165)

* Error 240 is raised when there is a mismatch between
foreign key trigger columns and the values supplied to
them during trigger execution, but had no error message
indicating the source of the problem. (Bug #23141739)
References: See also: Bug #23068914, Bug #85857.

* If the number of LDM blocks was not evenly divisible by
the number of TC/SPJ blocks, SPJ requests were not
equally distributed over the available SPJ instances. Now
a round-robin distribution is used to distribute SPJ
requests across all available SPJ instances more
effectively.
As part of this work, a number of unused member variables
have been removed from the class Dbtc. (Bug #22627519)

* ALTER TABLE .. MAX_ROWS=0 can now be performed only by
using a copying ALTER TABLE statement. Resetting MAX_ROWS
to 0 can no longer be performed using ALGORITHM=INPLACE
or the ONLINE keyword. (Bug #21960004)

* During a system restart, when a node failed due to having
missed sending heartbeats, all other nodes reported only
that another node had failed without any additional
information. Now in such cases, the fact that heartbeats
were missed and the ID of the node that failed to send
heartbeats is reported in both the error log and the data
node log. (Bug #21576576)

* The planned shutdown of an NDB Cluster having more than
10 data nodes was not always performed gracefully. (Bug
#20607730)

* Due to a previous issue with unclear separation between
the optimize and execute phases when a query involved a
GROUP BY, the join-pushable evaluator was not sure
whether its optimized query execution plan was in fact
pushable. For this reason, such grouped joins were always
considered not pushable. It has been determined that the
separation issue has been resolved by work already done
in MySQL 5.6, and so we now remove this limitation. (Bug
#86623, Bug #26239591)

* When deleting all rows from a table immediately followed
by DROP TABLE, it was possible that the shrinking of the
DBACC hash index was not ready prior to the drop. This
shrinking is a per-fragment operation that does not check
the state of the table. When a table is dropped, DBACC
releases resources, during which the description of the
fragment size and page directory is not consistent; this
could lead to reads of stale pages, and undefined
behavior.
Inserting a great many rows followed by dropping the
table should also have had such effects due to expansion
of the hash index.
To fix this problem we make sure, when a fragment is
about to be released, that there are no pending expansion
or shrinkage operations on this fragment. (Bug #86449,
Bug #26138592)

* The internal function execute_signals() in mt.cpp read
three section pointers from the signal even when none was
passed to it. This was mostly harmless, although
unneeded. When the signal read was the last one on the
last page in the job buffer, and the next page in memory
was not mapped or otherwise accessible, ndbmtd failed
with an error. To keep this from occurring, this function
now only reads section pointers that are actually passed
to it. (Bug #86354, Bug #26092639)

* The ndb_show_tables program --unqualified option did not
work correctly when set to 0 (false); this should disable
the option and so cause fully qualified table and index
names to be printed in the output. (Bug #86017, Bug
#25923164)

* When an NDB table with foreign key constraints is
created, its indexes are created first, and then, during
foreign key creation, these indexes are loaded into the
NDB dictionary cache. When a CREATE TABLE statement
failed due to an issue relating to foreign keys, the
indexes already in the cache were not invalidated. This
meant that any subsequent CREATE TABLE with any indexes
having the same names as those in the failed statement
produced inconsistent results. Now, in such cases, any
indexes named in the failed CREATE TABLE are immediately
invalidated from the cache. (Bug #85917, Bug #25882950)

* Attempting to execute ALTER TABLE ... ADD FOREIGN KEY
when the key to be added had the name of an existing
foreign key on the same table failed with the wrong error
message. (Bug #85857, Bug #23068914)

* The node internal scheduler (in mt.cpp) collects
statistics about its own progress and any outstanding
work it is performing. One such statistic is the number
of outstanding send bytes, collected in
send_buffer::m_node_total_send_buffer_size. This
information may later be used by the send thread
scheduler, which uses it as a metric to tune its own send
performance versus latency.
In order to reduce lock contention on the internal send
buffers, they are split into two thr_send_buffer parts,
m_buffer and m_sending, each protected by its own mutex,
and their combined size repesented by
m_node_total_send_buffer_size.
Investigation of the code revealed that there was no
consistency as to which mutex was used to update
m_node_total_send_buffer_size, with the result that there
was no consurrency protection for this value. To avoid
this, m_node_total_send_buffer_size is replaced with two
values, m_buffered_size and m_sending_size, which keep
separate track of the sizes of the two buffers. These
counters are updated under the protection of two
different mutexes protecting each buffer individually,
and are now added together to obtain the total size.
With concurrency control established, updates of the
partial counts should now be correct, so that their
combined value no longer accumulates errors over time.
(Bug #85687, Bug #25800933)

* Dropped TRANS_AI signals that used the long signal format
were not handled by the DBTC kernel block. (Bug #85606,
Bug #25777337)
References: See also: Bug #85519, Bug #27540805.

* To prevent a scan from returning more rows, bytes, or
both than the client has reserved buffers for, the DBTUP
kernel block reports the size of the TRANSID_AI it has
sent to the client in the TUPKEYCONF signal it sends to
the requesting DBLQH block. DBLQH is aware of the maximum
batch size available for the result set, and terminates
the scan batch if this has been exceeded.
The DBSPJ block's FLUSH_AI attribute allows DBTUP to
produce two TRANSID_AI results from the same row, one for
the client, and one for DBSPJ, which is needed for key
lookups on the joined tables. The size of both of these
were added to the read length reported by the DBTUP
block, which caused the controlling DBLQH block to
believe that it had consumed more of the available
maximum batch size than was actually the case, leading to
premature termination of the scan batch which could have
a negative impact on performance of SPJ scans. To correct
this, only the actual read length part of an API request
is now reported in such cases. (Bug #85408, Bug
#25702850)

* When compiling the NDB kernel with gcc version 6.0.0 or
later, it is now built using -flifetime-dse=1. (Bug
#85381, Bug #25690926)

On Behalf of Oracle MySQL Release Engineering Team
Prashant Tekriwal