The following list provides an overview of significant feature additions and changes made in MySQL Cluster NDB 6.2. All of the changes in this list are also available in MySQL Cluster NDB 6.3 . For more detailed information about all feature changes and bugfixes made in MySQL Cluster NDB 6.2, see Section 17.7.4, “Changes in MySQL Cluster NDB 6.2”.
Enhanced backup status reporting.
Backup status reporting has been improved, aided in part
by the introduction of a
BackupReportFrequency
configuration
parameter; see
Defining
Data Nodes:
BackupReportFrequency
,
for more information.
Multiple cluster connections per SQL node.
A single MySQL server acting as a MySQL Cluster SQL node
can employ multiple connections to the cluster using the
--ndb-cluster-connection-pool
startup
option for mysqld. This option is
described in
MySQL
Cluster-Related Command Options for
mysqld:
--ndb-cluster-connection-pool
option.
New data access interface.
The NdbRecord
interface provides a
new and simplified data handler for use in NDB API
applications. See The NdbRecord
Interface, for
more information.
New reporting commands.
The new management client REPORT
BackupStatus
and REPORT
MemoryUsage
commands provide better access to
information about the status of MySQL Cluster backups
and how much memory is being used by MySQL Cluster for
data and index storage. See
Section 17.5.2, “Commands in the MySQL Cluster Management Client”, for
more information about the REPORT
commands. In addition, in-progress status reporting is
provided by the ndb_restore utility;
see
Section 17.4.17, “ndb_restore — Restore a MySQL Cluster Backup”.
Improved memory allocation and configuration.
Memory is now allocated by the
NDB
kernel to tables on a
page-by-page basis, which significantly reduces the
memory overhead required for maintaining
NDBCLUSTER
tables. In
addition, the MaxAllocate
configuration parameter now makes it possible to set the
maximum size of the allocation unit used for table
memory; for more information about this configuration
parameter, see
Defining
Data Nodes:
MaxAllocate
.
Choice of fixed-width or variable-width columns.
You can control whether fixed-width or variable-width
storage is used for a given column of an
NDB
table by employing of
the COLUMN_FORMAT
specifier as part
of the column's definition in a
CREATE TABLE
or
ALTER TABLE
statement. In
addition, the ability to control whether a given column
of an NDB
table is stored
in memory or on disk, using the
STORAGE
specifier as part of the
column's definition in a CREATE
TABLE
or ALTER
TABLE
statement. For more information, see
Section 12.1.17, “CREATE TABLE
Syntax”, and
Section 12.1.7, “ALTER TABLE
Syntax”.
Controlling management client connections.
The --bind-address
cluster management
server startup option makes it possible to restrict
management client connections to
ndb_mgmd to a single host (IP address
or host name) and port, which can make MySQL Cluster
management operations more secure. For more information
about this option, see
Section 17.4.4, “ndb_mgmd — The MySQL Cluster Management Server Daemon”.
Micro-GCPs.
Due to a change in the protocol for handling of global
checkpoints (GCPs handled in this manner sometimes being
referred to as “micro-GCPs”), it is now
possible to control how often the GCI number is updated,
and how often global checkpoints are written to disk,
using the TimeBetweenEpochs
configuration parameter. This improves the reliability
and performance of MySQL Cluster Replication. For more
information, see
Defining
Data Nodes:
TimeBetweenEpochs
and
Defining
Data Nodes:
TimeBetweenEpochsTimeout
.
Core online schema change support.
Support for the online ALTER
TABLE
operations ADD
COLUMN
, ADD INDEX
, and
DROP INDEX
is available.
When the ONLINE
keyword is used, the
ALTER TABLE
is
noncopying, which means that indexes do not have to be
re-created, which provides these benefits:
Single user mode is no longer required for
ALTER TABLE
operations that can be performed online.
Transactions can continue during
ALTER TABLE
operations that can be performed online.
Tables being altered online are not locked against access by other SQL nodes.
However, such tables are locked against other
operations on the same SQL
node for the duration of the
ALTER TABLE
. We are
working to overcome this limitation in a future
MySQL Cluster release.
Online CREATE INDEX
and
DROP INDEX
statements are
also supported. Online changes can be suppressed using
the OFFLINE
key word. See
Section 12.1.7, “ALTER TABLE
Syntax”,
Section 12.1.13, “CREATE INDEX
Syntax”, and
Section 12.1.24, “DROP INDEX
Syntax”, for more detailed
information.
mysql.ndb_binlog_index
improvements.
More information has been added to the
mysql.ndb_binlog_index
table so that
it is possible to determine which originating epochs
have been applied inside an epoch. This is particularly
useful for 3-way replication. See
Section 17.6.4, “MySQL Cluster Replication Schema and Tables”, for
more information.
Epoch lag control.
The MaxBufferedEpochs
data node
configuration parameter provides a means to control the
maximum number of unprocessed epochs by which a
subscribing node can lag. Subscribers which exceed this
number are disconnected and forced to reconnect. For a
discussion of this configuration parameter, see
Defining
Data Nodes:
MaxBufferedEpochs
.
Fully automatic database discovery.
It is no longer a requirement for database autodiscovery
that an SQL node already be connected to the cluster at
the time that a database is created on another SQL node,
or for a CREATE DATABASE
or
CREATE
SCHEMA
statement to be issued on the new SQL
node after it joins the cluster.
Multiple data node processes per host. In earlier MySQL Cluster release series, we did not support MySQL Cluster deployments in production where more than one ndbd process was run on a single physical machine. However, beginning with MySQL Cluster NDB 6.2.0, you can use multiple data node processes on a single host.
A multi-threaded version of ndbd tailored for use on hosts with multiple CPUs or cores was introduced in MySQL Cluster NDB 7.0. See Section 17.1.4.5, “MySQL Cluster Development in MySQL Cluster NDB 7.0”, and Section 17.4.3, “ndbmtd — The MySQL Cluster Data Node Daemon (Multi-Threaded)”, for more information.
Improved Disk Data filesystem configuration.
As of MySQL Cluster NDB 6.2.17, you can specify default
locations for MySQL Cluster Disk Data data files and
undo log files using the data node configuration
parameters FileSystemPathDD
,
FileSystemPathDataFiles
, and
FileSystemPathUndoFiles
. This
eliminates the need to use symbolic links in order to
place Disk Data files separately from other files in
data node filesystems to improve Disk Data performance.
For more information, see
Disk Data filesystem parameters.
Automatic creation of Disk Data log file groups and tablespaces.
Beginning with MySQL Cluster NDB 6.2.17, using the data
node configuration parameters
InitialLogFileGroup
and
InitialTablespace
, you can cause the
creation of a MySQL Cluster Disk Data log file group,
tablespace, or both, when the cluster is first started.
When using these parameters, no SQL statements are
required to create these Disk Data objects. For more
information, see
Disk
Data object creation parameters.
Improved access to partitioning information.
The ndb_desc utility now provides
additional information about the partitioning of data
stored in MySQL Cluster. Beginning with MySQL Cluster
NDB 6.2.19, the
--extra-node-info
option causes ndb_desc to include
information about data distribution (that is, which
table fragments are stored on which data nodes). This
option also requires the use of the
--extra-partition-info
option.
Information about partition-to-node mappings can also be
obtained using the
Table::getFragmentNodes()
method, also
added in MySQL Cluster NDB 6.2.19.
User Comments
Add your own comment.