MySQL Cluster 7.6.4-dmr has been released
Posted by: Balasubramanian Kandasamy
Date: February 01, 2018 12:34PM
Date: February 01, 2018 12:34PM
Dear MySQL Users,
MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:
- In-Memory storage - Real-time performance (with optional
checkpointing to disk)
- 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.6.4-dmr, 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.6/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.6.4 (5.7.20-ndb-7.6.4) (2018-01-31,
Development Milestone 4)
MySQL NDB Cluster 7.6.4 is a new release of NDB 7.6, based on
MySQL Server 5.7 and including features in version 7.6 of the
NDB storage engine, as well as fixing recently discovered
bugs in previous NDB Cluster releases.
Obtaining NDB Cluster 7.6. NDB Cluster 7.6 source code and
binaries can be obtained from
http://dev.mysql.com/downloads/cluster/.
For an overview of changes made in NDB Cluster 7.6, see What
is New in NDB Cluster 7.6
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-6.html).
This release also incorporates all bug fixes and changes made
in previous NDB Cluster releases, as well as all bug fixes
and feature changes which were added in mainline MySQL 5.7
through MySQL 5.7.20 (see Changes in MySQL 5.7.20
(2017-10-16, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-20.html)).
* Functionality Added or Changed
* Bugs Fixed
Functionality Added or Changed
* Incompatible Change; NDB Disk Data: Due to changes in
disk file formats, it is necessary to perform an
--initial restart of each data node when upgrading to or
downgrading from this release.
* Important Change; NDB Disk Data: NDB Cluster has improved
node restart times and overall performance with larger
data sets by implementing partial local checkpoints.
Prior to this release, an LCP always made a copy of the
entire database.
NDB now supports LCPs that write individual records, so
it is no longer strictly necessary for an LCP to write
the entire database. Since, at recovery, it remains
necessary to restore the database fully, the strategy is
to save one fourth of all records at each LCP, as well as
to write the records that have changed since the last
LCP.
Two data node configuration parameters relating to this
change are introduced in this release: EnablePartialLcp
(default true, or enabled) enables partial LCPs. When
partial LCPs are enabled, RecoveryWork controls the
percentage of space given over to LCPs; it increases with
the amount of work which must be performed on LCPs during
restarts as opposed to that performed during normal
operations. Raising this value causes LCPs during normal
operations to require writing fewer records and so
decreases the usual workload. Raising this value also
means that restarts can take longer.
Important
Upgrading disk data tables to NDB 7.6.4 or downgrading
them from this release requires an initial restart of
each data node. An initial node restart still requires a
complete LCP; a partial LCP is not used for this purpose.
This release also deprecates the data node configuration
parameters BackupDataBufferSize, BackupWriteSize, and
BackupMaxWriteSize; these are now subject to removal in a
future NDB Cluster release.
* Important Change: Added the ndb_perror utility for
obtaining information about NDB Cluster error codes. This
tool replaces perror --ndb; the --ndb option for perror
is now deprecated and raises a warning when used; the
option is subject to removal in a future NDB release.
See ndb_perror --- Obtain NDB error message information
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-programs-ndb-perror.html),
for more information. (Bug
#81703, Bug #81704, Bug #23523869, Bug #23523926)
References: See also: Bug #26966826, Bug #88086.
* NDB Client Programs: NDB Cluster Auto-Installer node
configuration parameters as supported in the UI and
accompanying documentation were in some cases hard coded
to an arbitrary value, or were missing altogether.
Configuration parameters, their default values, and the
documentation have been better aligned with those found
in release versions of the NDB Cluster software.
One necessary addition to this task was implementing the
mechanism which the Auto-Installer now provides for
setting parameters that take discrete values. For
example, the value of the data node parameter Arbitration
must now be one of Default, Disabled, or WaitExternal.
The Auto-Installer also now gets and uses the amount of
disk space available to NDB on each host for deriving
reasonable default values for configuration parameters
which depend on this value.
See The NDB Cluster Auto-Installer
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-install-auto.html),
for more information.
* NDB Client Programs: Secure connection support in the
MySQL NDB Cluster Auto-Installer has been updated or
improved in this release as follows:
+ Added a mechanism for setting SSH membership on a
per-host basis.
+ Updated the Paramiko Python module to the most
recent available version (2.6.1).
+ Provided a place in the GUI for encrypted private
key passwords, and discontinued use of hardcoded
passwords.
Related enhancements implemented in the current release
include the following:
+ Discontinued use of cookies as a persistent store
for NDB Cluster configuration information; these
were not secure and came with a hard upper limit on
storage. Now the Auto-Installer uses an encrypted
file for this purpose.
+ In order to secure data transfer between the web
browser front end and the back end web server, the
default communications protocol has been switched
from HTTP to HTTPS.
See The NDB Cluster Auto-Installer
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-install-auto.html),
for more information.
* It is now possible to specify a set of cores to be used
for I/O threads performing offline multithreaded builds
of ordered indexes, as opposed to normal I/O duties such
as file I/O， compression， or decompression. "Offline" in
this context refers to building of ordered indexes
performed when the parent table is not being written to;
such building takes place when an NDB cluster performs a
node or system restart, or as part of restoring a cluster
from backup using ndb_restore --rebuild-indexes.
In addition, the default behaviour for offline index
build work is modified to use all cores available to
ndbmtd, rather limiting itself to the core reserved for
the I/O thread. Doing so can improve restart and restore
times and performance, availability, and the user
experience.
This enhancement is implemented as follows:
1. The default value for BuildIndexThreads is changed
from 0 to 128. This means that offline ordered index
builds are now multithreaded by default.
2. The default value for TwoPassInitialNodeRestartCopy
is changed from false to true. This means that an
initial node restart first copies all data from a
"live" node to one that is starting---without
creating any indexes---builds ordered indexes
offline, and then again synchronizes its data with
the live node, that is, synchronizing twice and
building indexes offline between the two
synchonizations. This causes an initial node restart
to behave more like the normal restart of a node,
and reduces the time required for building indexes.
3. A new thread type (idxbld) is defined for the
ThreadConfig configuration parameter, to allow
locking of offline index build threads to specific
CPUs.
In addition, NDB now distinguishes the thread types that
are accessible to "ThreadConfig" by the following two
criteria:
1. Whether the thread is an execution thread. Threads
of types main, ldm, recv, rep, tc, and send are
execution threads; thread types io, watchdog, and
idxbld are not.
2. Whether the allocation of the thread to a given task
is permanent or temporary. Currently all thread
types except idxbld are permanent.
For additonal information, see the descriptions of the
parameters in the Manual. (Bug #25835748, Bug #26928111)
* Added the ODirectSyncFlag configuration parameter for
data nodes. When enabled, the data node treats all
completed filesystem writes to the redo log as though
they had been performed using fsync.
Note
This parameter has no effect if at least one of the
following conditions is true:
+ ODirect is not enabled.
+ InitFragmentLogFiles is set to SPARSE.
(Bug #25428560)
* Added the ndbinfo.error_messages table, which provides
information about NDB Cluster errors, including error
codes, status types, brief descriptions, and
classifications. This makes it possible to obtain error
information using SQL in the mysql client (or other MySQL
client program), like this:
mysql> SELECT * FROM ndbinfo.error_messages WHERE error_code='321';
+------------+----------------------+-----------------+---------------
-------+
| error_code | error_description | error_status | error_classifi
cation |
+------------+----------------------+-----------------+---------------
-------+
| 321 | Invalid nodegroup id | Permanent error | Application er
ror |
+------------+----------------------+-----------------+---------------
-------+
1 row in set (0.00 sec)
The query just shown provides equivalent information to
that obtained by issuing ndb_perror 321 or (now
deprecated) perror --ndb 321 on the command line. (Bug
#86295, Bug #26048272)
* When executing a scan as a pushed join, all instances of
DBSPJ were involved in the execution of a single query;
some of these received multiple requests from the same
query. This situation is improved by enabling a single
SPJ request to handle a set of root fragments to be
scanned, such that only a single SPJ request is sent to
each DBSPJ instance on each node and batch sizes are
allocated per fragment, the multi-fragment scan can
obtain a larger total batch size, allowing for some
scheduling optimizations to be done within DBSPJ, which
can scan a single fragment at a time (giving it the total
batch size allocation), scan all fragments in parallel
using smaller sub-batches, or some combination of the
two.
Since the effect of this change is generally to require
fewer SPJ requests and instances, performance of
pushed-down joins should be improved in many cases.
* As part of work ongoing to optimize bulk DDL performance
by ndbmtd, it is now possible to obtain performance
improvements by increasing the batch size for the bulk
data parts of DDL operations which process all of the
data in a fragment or set of fragments using a scan.
Batch sizes are now made configurable for unique index
builds, foreign key builds, and online reorganization, by
setting the respective data node configuration parameters
listed here:
+ MaxFKBuildBatchSize: Maximum scan batch size used
for building foreign keys.
+ MaxReorgBuildBatchSize: Maximum scan batch size used
for reorganization of table partitions.
+ MaxUIBuildBatchSize: Maximum scan batch size used
for building unique keys.
For each of the parameters just listed, the default value
is 64, the minimum is 16, and the maximum is 512.
Increasing the appropriate batch size or sizes can help
amortize inter-thread and inter-node latencies and make
use of more parallel resources (local and remote) to help
scale DDL performance.
* Formerly, the data node LGMAN kernel block processed undo
log records serially; now this is done in parallel. The
rep thread, which hands off undo records to local data
handler (LDM) threads, waited for an LDM to finish
applying a record before fetching the next one; now the
rep thread no longer waits, but proceeds immediately to
the next record and LDM.
There are no user-visible changes in functionality
directly associated with this work; this performance
enhancement is part of the work being done in NDB 7.6 to
improve undo long handling for partial local checkpoints.
* When applying an undo log the table ID and fragment ID
are obtained from the page ID. This was done by reading
the page from PGMAN using an extra PGMAN worker thread,
but when applying the undo log it was necessary to read
the page again.
This became very inefficient when using O_DIRECT (see
ODirect) since the page was not cached in the OS kernel.
Mapping from page ID to table ID and fragment ID is now
done using information the extent header contains about
the table IDs and fragment IDs of the pages used in a
given extent. Since the extent pages are always present
in the page cache, no extra disk reads are required to
perform the mapping, and the information can be read
using existing TSMAN data structures.
* Added the NODELOG DEBUG command in the ndb_mgm client to
provide runtime control over data node debug logging.
NODE DEBUG ON causes a data node to write extra debugging
information to its node log, the same as if the node had
been started with --verbose. NODELOG DEBUG OFF disables
the extra logging.
* Added the LocationDomainId configuration parameter for
management, data, and API nodes. When using NDB Cluster
in a cloud environment, you can set this parameter to
assign a node to a given availability domain or
availability zone. This can improve performance in the
following ways:
+ If requested data is not found on the same node,
reads can be directed to another node in the same
availability domain.
+ Communication between nodes in different
availability domains are guaranteed to use NDB
transporters' WAN support without any further manual
intervention.
+ The transporter's group number can be based on which
availability domain is used, such that also SQL and
other API nodes communicate with local data nodes in
the same availability domain whenever possible.
+ The arbitrator can be selected from an availability
domain in which no data nodes are present, or, if no
such availability domain can be found, from a third
availability domain.
This parameter takes an integer value between 0 and 16,
with 0 being the default; using 0 is the same as leaving
LocationDomainId unset.
Bugs Fixed
* Important Change: The --passwd option for ndb_top is now
deprecated, and thus subject to removal in a future
release of NDB Cluster. (Bug #88236, Bug #20733646)
References: See also: Bug #86615, Bug #26236320.
* Replication: With GTIDs generated for incident log
events, MySQL error code 1590 (ER_SLAVE_INCIDENT) could
not be skipped using the --slave-skip-errors=1590 startup
option on a replication slave. (Bug #26266758)
* NDB Disk Data: An ALTER TABLE that switched the table
storage format between MEMORY and DISK was always
performed in place for all columns. This is not correct
in the case of a column whose storage format is inherited
from the table; the column's storage type is not changed.
For example, this statement creates a table t1 whose
column c2 uses in-memory storage since the table does so
implicitly:
CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT) ENGINE NDB;
The ALTER TABLE statement shown here is expected to cause
c2 to be stored on disk, but failed to do so:
ALTER TABLE t1 STORAGE DISK TABLESPACE ts1;
Similarly, an on-disk column that inherited its storage
format from the table to which it belonged did not have
the format changed by ALTER TABLE ... STORAGE MEMORY.
These two cases are now performed as a copying alter, and
the storage format of the affected column is now changed.
(Bug #26764270)
* NDB Replication: On an SQL node not being used for a
replication channel with sql_log_bin=0 it was possible
after creating and populating an NDB table for a table
map event to be written to the binary log for the created
table with no corresponding row events. This led to
problems when this log was later used by a slave cluster
replicating from the mysqld where this table was created.
Fixed this by adding support for maintaining a cumulative
any_value bitmap for global checkpoint event operations
that represents bits set consistently for all rows of a
specific table in a given epoch, and by adding a check to
determine whether all operations (rows) for a specific
table are all marked as NOLOGGING, to prevent the
addition of this table to the Table_map held by the
binlog injector.
As part of this fix, the NDB API adds a new
getNextEventOpInEpoch3() method which provides
information about any AnyValue received by making it
possible to retrieve the cumulative any_value bitmap.
(Bug #26333981)
* ndbinfo Information Database: Counts of committed rows
and committed operations per fragment used by some tables
in ndbinfo were taken from the DBACC block, but due to
the fact that commit signals can arrive out of order,
transient counter values could be negative. This could
happen if, for example, a transaction contained several
interleaved insert and delete operations on the same row;
in such cases, commit signals for delete operations could
arrive before those for the corresponding insert
operations, leading to a failure in DBACC.
This issue is fixed by using the counts of committed rows
which are kept in DBTUP, which do not have this problem.
(Bug #88087, Bug #26968613)
* Errors in parsing NDB_TABLE modifiers could cause memory
leaks. (Bug #26724559)
* Added DUMP code 7027 to facilitate testing of issues
relating to local checkpoints. For more information, see
DUMP 7027
(http://dev.mysql.com/doc/ndb-internals/en/ndb-internals-dump-command-7027.html).
(Bug #26661468)
* A previous fix intended to improve logging of node
failure handling in the transaction coordinator included
logging of transactions that could occur in normal
operation, which made the resulting logs needlessly
verbose. Such normal transactions are no longer written
to the log in such cases. (Bug #26568782)
References: This issue is a regression of: Bug #26364729.
* Due to a configuration file error, CPU locking capability
was not available on builds for Linux platforms. (Bug
#26378589)
* Some DUMP codes used for the LGMAN kernel block were
incorrectly assigned numbers in the range used for codes
belonging to DBTUX. These have now been assigned symbolic
constants and numbers in the proper range (10001, 10002,
and 10003). (Bug #26365433)
* Node failure handling in the DBTC kernel block consists
of a number of tasks which execute concurrently, and all
of which must complete before TC node failure handling is
complete. This fix extends logging coverage to record
when each task completes, and which tasks remain,
includes the following improvements:
+ Handling interactions between GCP and node failure
handling interactions, in which TC takeover causes
GCP participant stall at the master TC to allow it
to extend the current GCI with any transactions that
were taken over; the stall can begin and end in
different GCP protocol states. Logging coverage is
extended to cover all scenarios. Debug logging is
now more consistent and understandable to users.
+ Logging done by the QMGR block as it monitors
duration of node failure handling duration is done
more frequently. A warning log is now generated
every 30 seconds (instead of 1 minute), and this now
includes DBDIH block debug information (formerly
this was written separately, and less often).
+ To reduce space used, DBTC instance number: is
shortened to DBTC number:.
+ A new error code is added to assist testing.
(Bug #26364729)
* During a restart, DBLQH loads redo log part metadata for
each redo log part it manages, from one or more redo log
files. Since each file has a limited capacity for
metadata, the number of files which must be consulted
depends on the size of the redo log part. These files are
opened, read, and closed sequentially, but the closing of
one file occurs concurrently with the opening of the
next.
In cases where closing of the file was slow, it was
possible for more than 4 files per redo log part to be
open concurrently; since these files were opened using
the OM_WRITE_BUFFER option, more than 4 chunks of write
buffer were allocated per part in such cases. The write
buffer pool is not unlimited; if all redo log parts were
in a similar state, the pool was exhausted, causing the
data node to shut down.
This issue is resolved by avoiding the use of
OM_WRITE_BUFFER during metadata reload, so that any
transient opening of more than 4 redo log files per log
file part no longer leads to failure of the data node.
(Bug #25965370)
* A join entirely within the materialized part of a
semi-join was not pushed even if it could have been. In
addition, EXPLAIN provided no information about why the
join was not pushed. (Bug #88224, Bug #27022925)
References: See also: Bug #27067538.
* When the duplicate weedout algorithm was used for
evaluating a semi-join, the result had missing rows. (Bug
#88117, Bug #26984919)
References: See also: Bug #87992, Bug #26926666.
* A table used in a loose scan could be used as a child in
a pushed join query, leading to possibly incorrect
results. (Bug #87992, Bug #26926666)
* When representing a materialized semi-join in the query
plan, the MySQL Optimizer inserted extra QEP_TAB and
JOIN_TAB objects to represent access to the materialized
subquery result. The join pushdown analyzer did not
properly set up its internal data structures for these,
leaving them uninitialized instead. This meant that later
usage of any item objects referencing the materialized
semi-join accessed an initialized tableno column when
accessing a 64-bit tableno bitmask, possibly referring to
a point beyond its end, leading to an unplanned shutdown
of the SQL node. (Bug #87971, Bug #26919289)
* In some cases, a SCAN_FRAGCONF signal was received after
a SCAN_FRAGREQ with a close flag had already been sent,
clearing the timer. When this occurred, the next
SCAN_FRAGREF to arrive caused time tracking to fail. Now
in such cases, a check for a cleared timer is performed
prior to processing the SCAN_FRAGREF message. (Bug
#87942, Bug #26908347)
* While deleting an element in Dbacc, or moving it during
hash table expansion or reduction, the method used
(getLastAndRemove()) could return a reference to a
removed element on a released page, which could later be
referenced from the functions calling it. This was due to
a change brought about by the implementation of dynamic
index memory in NDB 7.6.2; previously, the page had
always belonged to a single Dbacc instance, so accessing
it was safe. This was no longer the case following the
change; a page released in Dbacc could be placed directly
into the global page pool where any other thread could
then allocate it.
Now we make sure that newly released pages in Dbacc are
kept within the current Dbacc instance and not given over
directly to the global page pool. In addition, the
reference to a released page has been removed; the
affected internal method now returns the last element by
value, rather than by reference. (Bug #87932, Bug
#26906640)
References: See also: Bug #87987, Bug #26925595.
* The DBTC kernel block could receive a TCRELEASEREQ signal
in a state for which it was unprepared. Now it such cases
it responds with a TCRELEASECONF message, and
subsequently behaves just as if the API connection had
failed. (Bug #87838, Bug #26847666)
References: See also: Bug #20981491.
* When a data node was configured for locking threads to
CPUs, it failed during startup with Failed to lock tid.
This was is a side effect of a fix for a previous issue,
which disabled CPU locking based on the version of the
available glibc. The specific glibc issue being guarded
against is encountered only in response to an internal
NDB API call (Ndb_UnlockCPU()) not used by data nodes
(and which can be accessed only through internal API
calls). The current fix enables CPU locking for data
nodes and disables it only for the relevant API calls
when an affected glibc version is used. (Bug #87683, Bug
#26758939)
References: This issue is a regression of: Bug #86892,
Bug #26378589.
* ndb_top failed to build on platforms where the ncurses
library did not define stdscr. Now these platforms
require the tinfo library to be included. (Bug #87185,
Bug #26524441)
* On completion of a local checkpoint, every node sends a
LCP_COMPLETE_REP signal to every other node in the
cluster; a node does not consider the LCP complete until
it has been notified that all other nodes have sent this
signal. Due to a minor flaw in the LCP protocol, if this
message was delayed from another node other than the
master, it was possible to start the next LCP before one
or more nodes had completed the one ongoing; this caused
problems with LCP_COMPLETE_REP signals from previous LCPs
becoming mixed up with such signals from the current LCP,
which in turn led to node failures.
To fix this problem, we now ensure that the previous LCP
is complete before responding to any TCGETOPSIZEREQ
signal initiating a new LCP. (Bug #87184, Bug #26524096)
* NDB Cluster did not compile successfully when the build
used WITH_UNIT_TESTS=OFF. (Bug #86881, Bug #26375985)
* Recent improvements in local checkpoint handling that use
OM_CREATE to open files did not work correctly on Windows
platforms, where the system tried to create a new file
and failed if it already existed. (Bug #86776, Bug
#26321303)
* A potential hundredfold signal fan-out when sending a
START_FRAG_REQ signal could lead to a node failure due to
a job buffer full error in start phase 5 while trying to
perform a local checkpoint during a restart. (Bug #86675,
Bug #26263397)
References: See also: Bug #26288247, Bug #26279522.
* Compilation of NDB Cluster failed when using
-DWITHOUT_SERVER=1 to build only the client libraries.
(Bug #85524, Bug #25741111)
* The NDBFS block's OM_SYNC flag is intended to make sure
that all FSWRITEREQ signals used for a given file are
synchronized, but was ignored by platforms that do not
support O_SYNC, meaning that this feature did not behave
properly on those platforms. Now the synchronization flag
is used on those platforms that do not support O_SYNC.
(Bug #76975, Bug #21049554)
On Behalf of Oracle/MySQL Release Engineering Team
Balasubramanian Kandasamy
Subject
Views
Written By
Posted
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.