MySQL NDB Cluster 7.5 Release Notes
Important Change:
When creating or adding columns to NDB
tables, the default value used for both the
COLUMN_FORMAT and
ROW_FORMAT options is now
DYNAMIC rather than FIXED.
This change does not affect the row format or column format used
by existing tables. New columns added to such tables use the new
defaults, and existing columns are changed to use these as well,
provided that the ALTER TABLE
statement in question uses ALGORITHM=COPY.
Note that this cannot be done implicitly if
mysqld is run with
--ndb-allow-copying-alter-table=FALSE
(the default is TRUE).
A new MySQL server option
--ndb-default-column-format is
added for backwards compatibility; set this to
FIXED to force the old defaults to be used
for COLUMN_FORMAT and
ROW_FORMAT.
This behavior change is superseded in MySQL NDB Cluster 7.5.4.
(WL #8573)
Scans have been improved by replacing the
DIH_SCAN_GET_NODES_REQ signal, formerly used
for communication between the DBTC and
DBDIH kernel blocks in
NDB, with the
DIGETNODESREQ signal, which supports direct
execution and allows for the elimination of
DIH_SCAN_GET_NODES_REF and
DIH_SCAN_GET_NODES_CONF, as well as for
DIH_SCAN_TAB_REQ and
DIH_SCAN_TAB_COMPLETE_REP signals to
EXECUTE_DIRECT. This enables enable higher
scalability of data nodes when used for scan operations by
decreasing the use of CPU resources for scan operations by an
estimated five percent in some cases. This should also improve
response times, which could help prevent issues with overload of
the main threads.
As part of these changes, scans made in the
BACKUP kernel block have also been improved
and made more efficient.
(WL #8937)
References: See also: Bug #80640, Bug #22884995.
The following improvements have been made to event buffer reporting in the cluster log:
Each report now identifies the API node that sent it.
The fields shown in the report have been improved and
expanded. Percentages are now better specified and used only
when appropriate. For improved clarity, the
apply_epoch and
latest_epoch fields have been renamed to
latest_consumed_epoch and
latest_buffered_epoch, respectively. The
ID of the Ndb object
serving as the source of the report is now shown, as is the
reason for making the report (as the
report_reason field).
The frequency of unnecessary reporting has been reduced by limiting reports to those showing only significant changes in event buffer usage.
The MGM API adds a new
NDB_LE_EventBufferStatus2 event type to
handle the additional information provided by the new event
buffer reporting. The
NDB_LE_EventBufferStatus event type used
in older versions of MySQL NDB Cluster is now deprecated,
and will eventually be removed.
For more information, see Event Buffer Reporting in the Cluster Log, as well as The ndb_logevent Structure. (WL #8626)
Important Change:
The minimum value for the
BackupDataBufferSize
data node configuration parameter has been lowered from 2 MB to
512 KB. The default and maximum values for this parameter remain
unchanged.
(Bug #22749509)
OS X: Processing of local checkpoints was not handled correctly on Mac OS X, due to an uninitialized variable. (Bug #80236, Bug #22647462)
Microsoft Windows:
Compilation of MySQL with Visual Studio 2015 failed in
ConfigInfo.cpp, due to a change in Visual
Studio's handling of spaces and concatenation.
(Bug #22558836, Bug #80024)
Microsoft Windows:
When setting up event logging for ndb_mgmd on
Windows, MySQL NDB Cluster tries to add a registry key to
HKEY_LOCAL_MACHINE, which fails if the user
does not have access to the registry. In such cases
ndb_mgmd logged the error Could
neither create or open key, which is not accurate
and which can cause confusion for users who may not realize that
file logging is available and being used. Now in such cases,
ndb_mgmd logs a warning Could not
create or access the registry key needed for the application to
log to the Windows EventLog. Run the application with sufficient
privileges once to create the key, or add the key manually, or
turn off logging for that application. An error (as
opposed to a warning) is now reported in such cases only if
there is no available output at all for
ndb_mgmd event logging.
(Bug #20960839)
Microsoft Windows:
MySQL NDB Cluster did not compile correctly with Microsoft
Visual Studio 2015, due to a change from previous versions in
the VS implementation of the _vsnprintf()
function.
(Bug #80276, Bug #22670525)
During node failure handling, the request structure used to drive the cleanup operation was not maintained correctly when the request was executed. This led to inconsistencies that were harmless during normal operation, but these could lead to assertion failures during node failure handling, with subsequent failure of additional nodes. (Bug #22643129)
The previous fix for a lack of mutex protection for the internal
TransporterFacade::deliver_signal() function
was found to be incomplete in some cases.
(Bug #22615274)
References: This issue is a regression of: Bug #77225, Bug #21185585.
When setup of the binary log as an atomic operation on one SQL node failed, this could trigger a state in other SQL nodes in which they appeared to detect the SQL node participating in schema change distribution, whereas it had not yet completed binary log setup. This could in turn cause a deadlock on the global metadata lock when the SQL node still retrying binary log setup needed this lock, while another mysqld had taken the lock for itself as part of a schema change operation. In such cases, the second SQL node waited for the first one to act on its schema distribution changes, which it was not yet able to do. (Bug #22494024)
Duplicate key errors could occur when
ndb_restore was run on a backup containing a
unique index. This was due to the fact that, during restoration
of data, the database can pass through one or more inconsistent
states prior to completion, such an inconsistent state possibly
having duplicate values for a column which has a unique index.
(If the restoration of data is preceded by a run with
--disable-indexes and
followed by one with
--rebuild-indexes, these
errors are avoided.)
Added a check for unique indexes in the backup which is performed only when restoring data, and which does not process tables that have explicitly been excluded. For each unique index found, a warning is now printed. (Bug #22329365)
NdbDictionary metadata
operations had a hard-coded 7-day timeout, which proved to be
excessive for short-lived operations such as retrieval of table
definitions. This could lead to unnecessary hangs in user
applications which were difficult to detect and handle
correctly. To help address this issue, timeout behaviour is
modified so that read-only or short-duration dictionary
interactions have a 2-minute timeout, while schema transactions
of potentially long duration retain the existing 7-day timeout.
Such timeouts are intended as a safety net: In the event of
problems, these return control to users, who can then take
corrective action. Any reproducible issue with
NdbDictionary timeouts should be reported as
a bug.
(Bug #20368354)
Optimization of signal sending by buffering and sending them
periodically, or when the buffer became full, could cause
SUB_GCP_COMPLETE_ACK signals to be
excessively delayed. Such signals are sent for each node and
epoch, with a minimum interval of
TimeBetweenEpochs; if
they are not received in time, the SUMA
buffers can overflow as a result. The overflow caused API nodes
to be disconnected, leading to current transactions being
aborted due to node failure. This condition made it difficult
for long transactions (such as altering a very large table), to
be completed. Now in such cases, the ACK
signal is sent without being delayed.
(Bug #18753341)
When setting CPU spin time, the value was needlessly cast to a
boolean internally, so that setting it to any nonzero value
yielded an effective value of 1. This issue, as well as the fix
for it, apply both to setting the
SchedulerSpinTimer
parameter and to setting spintime as part of
a ThreadConfig
parameter value.
(Bug #80237, Bug #22647476)
A logic error in an if statement in
storage/ndb/src/kernel/blocks/dbacc/DbaccMain.cpp
rendered useless a check for determining whether
ZREAD_ERROR should be returned when comparing
operations. This was detected when compiling with
gcc using
-Werror=logical-op.
(Bug #80155, Bug #22601798)
References: This issue is a regression of: Bug #21285604.
Suppressed a CMake warning that was caused by use of an incorrectly quoted variable name. (Bug #80066, Bug #22572632)
When using CREATE INDEX to add an
index on either of two NDB tables
sharing circular foreign keys, the query succeeded but a
temporary table was left on disk, breaking the foreign key
constraints. This issue was also observed when attempting to
create an index on a table in the middle of a chain of foreign
keys—that is, a table having both parent and child keys,
but on different tables. The problem did not occur when using
ALTER TABLE to perform the same
index creation operation; and subsequent analysis revealed
unintended differences in the way such operations were performed
by CREATE INDEX.
To fix this problem, we now make sure that operations performed
by a CREATE INDEX statement are always
handled internally in the same way and at the same time that the
same operations are handled when performed by ALTER
TABLE or DROP INDEX.
(Bug #79156, Bug #22173891)
The PortNumber SCI, SHM, and TCP
configuration parameters, which were deprecated in MySQL 5.1.3,
have now been removed and are no longer accepted in
configuration files.
This change does not affect the
PortNumber management
node configuration parameter, whose behavior remains unaltered.
(Bug #77405, Bug #21280456)