MySQL Cluster安装与NDBCLUSTER存储引擎详解

需积分: 3 19 浏览量更新于2024-07-31 收藏 2.23MB PDF 举报

MySQL Cluster是MySQL数据库的一种高级版本，专为分布式计算环境设计，旨在提供高可用性和高冗余性。它基于NDBCLUSTER存储引擎（也称为NDB），这个存储引擎在MySQL 5.1.24版本之后不再被包含在标准MySQL服务器二进制包中。对于MySQL Cluster用户，推荐使用MySQL官方发布的最新NDB 7.0或7.1版本，这些版本包含了适用于大多数Linux发行版的RPM包。 MySQL Cluster的核心功能包括： 1. **分布式架构**：MySQL Cluster通过在多台计算机上运行MySQL服务器和相关软件来实现分布式处理，提高了系统的可扩展性和性能。这使得它能够在故障发生时自动切换到其他节点，确保服务连续性。 2. **高可用性**：由于NDBCLUSTER的设计，MySQL Cluster能够实现数据的实时复制和同步，即使在某些节点出现故障时，也能快速恢复，避免单点故障。 3. **数据冗余**：通过复制数据在多个节点之间，MySQL Cluster可以提高数据的可靠性，降低因单个节点故障导致的数据丢失风险。 4. **升级和维护**：对于自定义构建的MySQL Cluster用户，从MySQL 5.1.24开始，标准MySQL源码树中的NDBCLUSTER支持已停止维护。因此，他们应使用针对MySQL Cluster NDB 7.0或更高版本提供的源码。 5. **许可证和法律限制**：MySQL Cluster软件及其文档受版权保护，并受到使用和披露限制。用户必须遵守许可协议，除非法律另有规定，否则禁止进行反向工程、解码或逆向工程等行为。 6. **政府授权**：如果软件或文档交付给美国政府或代表其进行许可，可能会有额外的使用条款和限制，如美国政府权利条款。 MySQL Cluster是为满足大规模、高可用性场景而设计的解决方案，对于需要在分布式环境中处理大量数据并追求高可用性和容错性的企业来说，是一个重要的选择。用户在安装和使用过程中需要注意版本更新、兼容性和遵循相关法律条款。

展开

• Change in ndbinfo database. The experimental ndbinfo.pools table was removed from ndbinfo in MySQL Cluster NDB

7.1.3. Applications which used this table can and should be rewritten to use other ndbinfo tables. For more information, see Sec-

tion 5.8.8, “The ndbinfo pools Table”.

1.4.2. MySQL Cluster Development in MySQL Cluster NDB 7.0

The following list provides an overview of significant feature additions and changes made in MySQL Cluster NDB 7.0. For more de-

tailed information about all feature changes and bugfixes made in MySQL Cluster NDB 7.0, see Changes in MySQL Cluster NDB 7.0.

Important

Early development versions of MySQL Cluster NDB 7.0 were known as “MySQL Cluster NDB 6.4”, and the first four re-

leases in this series were identified as MySQL Cluster NDB 6.4.0 through 6.4.3. Any information relating to these MySQL

Cluster NDB 6.4.x releases appearing in this documentation apply to MySQL Cluster NDB 7.0.

MySQL Cluster NDB 7.0.4 is the fifth MySQL Cluster NDB 7.0 release; it is the successor to MySQL Cluster NDB 6.4.3.

• MySQL Cluster on Windows (alpha). MySQL Cluster is now available on an experimental basis for Windows operating systems.

Features and behavior comparable to those found on platforms that are already supported — such as Linux and Solaris — are

planned for MySQL Cluster on Windows. Currently, you must build from source, although we intend to start making Windows bin-

aries available in the near future. To enable MySQL Cluster support on Windows, you must configure the build using the

WITH_NDBCLUSTER_STORAGE_ENGINE option. For more information, see Installing MySQL from Source on Windows.

• Ability to add nodes and node groups online. Beginning with MySQL Cluster NDB 6.4.0, it is possible to add new node groups

(and thus new data nodes) to a running MySQL Cluster without shutting down and reloading the cluster. As part of enabling this

feature, a new command CREATE NODEGROUP has been added to the cluster management client and the functionality of the AL-

TER ONLINE TABLE ... REORGANIZE PARTITION SQL statement has been extended. For more information, see Sec-

tion 5.11, “Adding MySQL Cluster Data Nodes Online”.

• Data node multithreading support. Beginning with MySQL Cluster NDB 6.4.0, a multithreaded version of the data node daemon,

named ndbmtd, is available for use on data node hosts with multiple CPU cores. This binary is built automatically when compiling

with MySQL Cluster support; no additional options other than those needed to provide MySQL Cluster support are needed when

configuring the build. In most respects, ndbmtd functions in the same way as ndbd, and can use the same command-line options

and configuration parameters. In addition, the new MaxNoOfExecutionThreads configuration parameter can be used to de-

termine the number of data node process threads for ndbmtd. For more information, see Section 4.3, “ndbmtd — The MySQL

Cluster Data Node Daemon (Multi-Threaded)”.

Note

Disk Data tables are not yet supported for use with ndbmtd.

• Configuration cache. Formerly, MySQL Cluster configuration was stateless — that is, configuration information was reloaded

from the cluster's global configuration file (usually config.ini) each time ndb_mgmd was started. Beginning with MySQL

Cluster NDB 6.4.0, the cluster's configuration is cached internally, and the global configuration file is no longer automatically re-

read when the management server is restarted. This behavior can be controlled via the three new management server options -

-configdir, --initial, and --reload. For more information about this change, see Section 3.2, “MySQL Cluster Config-

uration Files”. For more information about the new management server options, see Section 4.4, “ndb_mgmd — The MySQL

Cluster Management Server Daemon”.

• Snapshot options for backups. Beginning with MySQL Cluster NDB 6.4.0, you can determine when performing a cluster backup

whether the backup matches the state of the data when the backup was started or when it was completed, using the new options

SNAPSHOTSTART and SNAPSHOTEND for the management client's START BACKUP command. See Section 5.3.2, “Using The

MySQL Cluster Management Client to Create a Backup”, for more information.

• Dynamic NDB transporter send buffer memory allocation. Previously, the NDB kernel used a fixed-size send buffer for every

data node in the cluster, which was allocated when the node started. Because the size of this buffer could not be changed after the

cluster was started, it was necessary to make it large enough in advance to accomodate the maximum possible load on any transport-

er socket. However, this was an inefficient use of memory, since much of it often went unused. Beginning with MySQL Cluster

NDB 6.4.0, send buffer memory is allocated dynamically from a memory pool shared between all transporters, which means that the

size of the send buffer can be adjusted as necessary. This change is reflected by the addition of the configuration parameters

TotalSendBufferMemory, ReservedSendBufferMemory, and OverLoadLimit, as well as a change in how the exist-

ing SendBufferMemory configuration parameter is used. For more information, see Section 3.2.13, “Configuring MySQL

MySQL Cluster Overview

Cluster Send Buffer Parameters”.

• Robust DDL operations. Beginning with MySQL Cluster NDB 6.4.0, DDL operations (such as CREATE TABLE or ALTER TA-

BLE) are protected from data node failures; in the event of a data node failure, such operations are now rolled back gracefully. Pre-

viously, if a data node failed while trying to perform a DDL operation, the MySQL Cluster data dictionary became locked and no

further DDL statements could be executed without restarting the cluster.

• IPv6 support in MySQL Cluster Replication. Beginning with MySQL Cluster NDB 6.4.1, IPv6 networking is supported between

MySQL Cluster SQL nodes, which makes it possible to replicate between instances of MySQL Cluster using IPv6 addresses.

However, IPv6 is supported only for direct connections between MySQL servers; all connections within an individual MySQL

Cluster must use IPv4. For more information, see Section 6.3, “Known Issues in MySQL Cluster Replication”.

• Restoring specific databases, tables, or columns from a MySQL Cluster backup. It is now possible to exercise more fine-

grained control when restoring a MySQL Cluster from backup using ndb_restore. Beginning with MySQL Cluster NDB 6.4.3,

you can choose to restore only specified tables or databases, or exclude specific tables or databases from being restored, using the

new ndb_restore options --include-tables, --include-databases, --exclude-tables, and -

-exclude-databases. Beginning with MySQL Cluster NDB 7.0.7, it is also possible to restore to a table having fewer

columns than the original using the --exclude-missing-columns option. For more information about all of these options,

see Section 4.17, “ndb_restore — Restore a MySQL Cluster Backup”.

• Improved Disk Data filesystem configuration. As of MySQL Cluster NDB 6.4.3, you can specify default locations for MySQL

Cluster Disk Data data files and undo log files using the data node configuration parameters FileSystemPathDD, FileSys-

temPathDataFiles, 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.4.3, 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 state-

ments are required to create these Disk Data objects. For more information, see Disk Data object creation parameters.

• Improved internal message passing and record handling. MySQL Cluster NDB 7.0 contains 2 changes that optimize the use of

network connections by addressing the size and number of messages passed between data nodes, and between data nodes and API

nodes, which can increase MySQL Cluster and application performance:

• Packed reads. Formerly, each read request signal contained a list of columns to be retrieved, each of these column identifiers

using 4 bytes within the message. This meant that the message size increased as the number of columns being fetched increased.

In addition, in the response from the data node, each column result was packed to a 4-byte boundary, which resulted in wasted

space. In MySQL Cluster NDB 7.0, messaging for read operations is optimized in both directions, using a bitmap in the read re-

quest to specify the columns to be fetched. Where many fields are requested, this can result in a significant message size reduc-

tion as compared with the old method. In addition, the 4-byte packing in responses is no longer used, which means that smaller

fields consume less space.

• Long signal transactions. This enhancement reduces the number of messages and signals that are sent to data nodes for com-

plex requests. Prior to MySQL Cluster NDB 7.0, there was a 100 byte limit on the size of the request signal, which meant that

complex requests had to be split up between multiple messages prior to transmission, then reassembled on the receiving end. In

addition to actual payload data, each message required its own operating system and protocol overhead such as header informa-

tion. This often wasted network bandwidth and data node CPU. The maximum size of the message is now 32 KB, which is suffi-

cient to accommodate most queries.

Both of these optimizations are internal to the NDB API, and so is transparent to applications; this is true whether an application

uses the NDB API directly or does so indirectly through an SQL node.

• Configuration parameter data dumps. Starting with MySQL Cluster NDB 7.0.6, the ndb_config utility supports a -

-configinfo option that causes it to dump a list of all configuration parameters supported by the cluster, along with brief de-

scriptions, information about the parameters' default and allowed values, and the sections of the config.ini file in which the

parameters apply. An additional --xml switch causes ndb_config to use XML rather than plaintext output. Using

ndb_config --configinfo or ndb_config --configinfo --xml requires no access to a running MySQL Cluster,

any other programs, or any files. For more information and examples, see Section 4.6, “ndb_config — Extract MySQL Cluster

Configuration Information”.

• Per-table reporting of free space on disk. The INFORMATION_SCHEMA.FILES table shows information about used and free

space in MySQL Cluster Disk Data data files, but this information is not applicable to individual tables. In MySQL Cluster NDB

7.0.8 and later, the ndb_desc utility provides two additional columns in its output that show the amount of space allocated on disk

for a given NDB table as well the amount of space that remains available for additional storage of disk-based column data for that ta-

MySQL Cluster Overview

ble. For more information, see Section 4.9, “ndb_desc — Describe NDB Tables”.

• Improved restart times. Optimizations in redo log handling and other filesystem operations introduced in MySQL Cluster NDB

7.0.9 have the potential to reduce considerably the time required for restarts. While actual performance benefits observed in produc-

tion setups will naturally vary depending on database size, hardware, and other conditions, our own preliminary testing has shown

that these improvements can yield startup times that are faster than those typical of previous MySQL Cluster NDB 7.0 releases by a

factor of 50 or more.

• --nowait-nodes option for management servers. Starting with MySQL Cluster NDB 7.0.10, it is possible to configure a

cluster with two management servers, but to start the cluster using only one of them by starting the management node daemon with

the --nowait-nodes option. The other management server can then be started at a later time to join the running MySQL Cluster.

• Increased flexibility in online upgrade procedure. Previously, when performing an upgrade of a running MySQL cluster, the or-

der in which the types of cluster nodes had to be upgraded was very strict. However, beginning with MySQL Cluster NDB 7.0.10,

MySQL Cluster supports online upgrading of API nodes (including MySQL servers running as SQL nodes) online upgrading man-

agement nodes, data nodes, or both.

Important

Before attempting to use this new upgrade functionality, see Section 2.6.1, “Performing a Rolling Restart of a MySQL

Cluster”, for additional information, especially if you are planning an online upgrade to MySQL Cluster NDB 7.0 from

MySQL Cluster NDB 6.3.

• New replication conflict resolution strategy. Beginning with MySQL Cluster NDB 7.0.11, the function

NDB$MAX_DELETE_WIN() is available to implement “greatest timestamp, delete wins” conflict resolution. See

NDB$MAX_DELETE_WIN(column_name), for more information.

• Improved lock handling for primary key lookups on BLOB tables. A MySQL Cluster table stores all but the first 256 bytes of

any BLOB or TEXT column values in a separate BLOB table; when executing queries against such tables, a shared lock is obtained.

Prior to MySQL Cluster NDB 7.0.12, when the query used a primary key lookup and took place within a transaction, the lock was

held for the duration of the transaction, even after no more data was being read from the NDB table. Now in such cases, the lock is

released when all BLOB data associated with the table has been read. (Bug#49190)

Note

A shared lock is also taken for unique key lookups; it is still the case that this lock is held for the duration of the transac-

tion.

• Heartbeat thread policy and priority. Beginning with MySQL Cluster NDB 7.0.13, a new configuration parameter Heart-

beatThreadPriority makes it possible to set the policy and the priority for the heartbeat thread on management and API

nodes.

• 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 7.0.13, the --blob-info option causes this program to

include partition information for BLOB tables in its output. Beginning with MySQL Cluster NDB 7.0.14, 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). Each of these options 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 ad-

ded in MySQL Cluster NDB 7.0.14.

• Replication attribute promotion and demotion. Beginning with MySQL Cluster NDB 7.0.14, MySQL Cluster Replication sup-

ports attribute promotion and demotion when replicating between columns of different but similar types on the master and the slave.

For example, it is possible to promote an INT column on the master to a BIGINT column on the slave, and to demote a TEXT

column to a VARCHAR column.

The implementation of type demotion distinguishes between lossy and non-lossy type conversions, and their use on the slave can be

controlled by setting the slave_type_conversions global server system variable.

For more information, see Attribute promotion and demotion (MySQL Cluster).

1.4.3. MySQL Cluster Development in MySQL Cluster NDB 6.3

The following list provides an overview of significant feature additions and changes first made in MySQL Cluster NDB 6.3. For more

MySQL Cluster Overview

detailed information about all feature changes and bugfixes made in MySQL Cluster NDB 6.3, see Changes in MySQL Cluster NDB

6.3.

• Conflict detection and resolution. It is now possible to detect and resolve conflicts that arise in multi-master replication scenarios,

such as circular replication, when different masters may try to update the same row on the slave with different data. Both “greatest

timestamp wins” and “same timestamp wins” scenarios are supported. For more information, see Section 6.11, “MySQL Cluster

Replication Conflict Resolution”.

• Recovery of “one master, many slaves” replication setups. Recovery of multi-way replication setups (“one master, many

slaves”) is now supported via the --ndb-log-orig server option and changes in the mysql.ndb_binlog_index table. See

Section 6.4, “MySQL Cluster Replication Schema and Tables”, for more information.

• Enhanced selection options for transaction coordinator. New values and behaviors are introduced for -

-ndb_optimized_node_selection allowing for greater flexibility when an SQL node chooses a transaction coordinator.

For more information, see the description of ndb_optimized_node_selection in Section 3.4.3, “MySQL Cluster System

Variables”.

• Replication heartbeats. Replication heartbeats facilitate the task of monitoring and detecting failures in master-slave connections

in real time. This feature is implemented via a new MASTER_HEARTBEAT_PERIOD = value clause for the CHANGE MASTER

TO statement and the addition of two status variables Slave_heartbeat_period and Slave_received_heartbeats.

For more information, see CHANGE MASTER TO Syntax.

• NDB thread locks. It is possible to lock NDB execution threads and maintenance threads (such as file system and other operating

system threads) to specific CPUs on multiprocessor data node hosts, and to leverage real-time scheduling.

• Improved performance of updates using primary keys or unique keys. The number of unnecessary reads when performing a

primary key or unique key update has been greatly reduced. Since it is seldom necessary to read a record prior to an update, this can

yield a considerable improvement in performance. In addition, primary key columns are no longer written to when not needed dur-

ing update operations.

• Batching improvements. Support of batched DELETE and UPDATE operations has been significantly improved. Batching of UP-

DATE WHERE... and multiple DELETE operations is also now implemented.

• Improved SQL statement performance metrics. The Ndb_execute_count system status variable measures the number of

round trips made by SQL statements to the NDB kernel, providing an improved metric for determining efficiency with which state-

ments are excuted. For more information, see MySQL Cluster Status Variables: Ndb_execute_count.

• Compressed LCPs and backups. Compressed local checkpoints and backups can save 50% or more of the disk space used by un-

compressed LCPs and backups. These can be enabled using the two new data node configuration parameters CompressedLCP

and CompressedBackup, respectively. See MySQL Cluster Status Variables: CompressedBackup, and MySQL Cluster

Status Variables: CompressedLCP, for more information about these parameters.

• OPTIMIZE TABLE support with NDBCLUSTER tables. OPTIMIZE TABLE is supported for dynamic columns of in-memory

NDB tables. In such cases, it is no longer necessary to drop (and possibly to re-create) a table, or to perform a rolling restart, in order

to recover memory from deleted rows for general re-use by Cluster. The performance of OPTIMIZE on Cluster tables can be tuned

by adjusting the value of the ndb_optimization_delay system variable, which controls the number of milliseconds to wait

between processing batches of rows by OPTIMIZE TABLE. In addition, OPTIMIZE TABLE on an NDBCLUSTER table can be in-

terrupted by, for example, killing the SQL thread performing the OPTIMIZE operation.

• Batching of transactions. It is possible to cause statements occurring within the same transaction to be run as a batch by setting the

session variable transaction_allow_batching to 1 or ON. To use this feature, autocommit must be set to 0 or OFF.

Batch sizes can be controlled using the --ndb-batch-size option for mysqld. For additional information, see Section 3.4.2,

“mysqld Command Options for MySQL Cluster”, and Section 3.4.3, “MySQL Cluster System Variables”.

• Attribute promotion with ndb_restore. It is possible using ndb_restore to restore data reliably from a column of a given

type to a column that uses a “larger” type. This is sometimes referred to as attribute promotion. For example, MySQL Cluster

backup data that originated in a SMALLINT column can be restored to a MEDIUMINT, INT, or BIGINT column. See Section 4.17,

“ndb_restore — Restore a MySQL Cluster Backup”, for more information.

• Parallel data node recovery. Recovery of multiple data nodes can now be done in parallel, rather than sequentially. In other

words, several data nodes can be restored concurrently, which can often result in much faster recovery times than when they are re-

stored one at a time.

• Increased local checkpoint efficiency. Only 2 local checkpoints are stored, rather than 3, lowering disk space requirements and the

MySQL Cluster Overview

size and number of redo log files.

• NDBCLUSTER table persistence control. Persistence of NDB tables can be controlled using the session variables

ndb_table_temporary and ndb_table_no_logging. ndb_table_no_logging causes NDB tables not to be check-

pointed to disk; ndb_table_temporary does the same, and in addition, no schema files are created. See Section 3.4.1,

“MySQL Cluster Server Option and Variable Reference”.

• Epoll support (Linux only). Epoll is an improved method for handling file descriptors, which is more efficient than scanning to de-

termine whether a file descriptor has data to be read. (The term epoll is specific to Linux and equivalent functionality is known by

other names on other platforms such as Solaris and FreeBSD.) Currently, MySQL Cluster supports this functionality on Linux only.

• Distribution awareness (SQL nodes). In MySQL Cluster NDB 6.3, SQL nodes can take advantage of distribution awareness. Here

we provide a brief example showing how to design a table to make a given class of queries distrubtion-aware. Suppose an NDB-

CLUSTER table t1 has the following schema:

CREATE TABLE t1 (

userid INT NOT NULL,

serviceid INT NOT NULL AUTO_INCREMENT PRIMARY KEY,

data VARCHAR(255)

) ENGINE=NDBCLUSTER;

Suppose further that most of the queries to be used in our application test values of the userid column of this table. The form of

such a query looks something like this:

SELECT columns FROM t1

WHERE userid relation value;

In this query, relation represents some relational operator, such as =, <, >, and so on. Queries using IN and a list of values can

also be used:

SELECT columns FROM t1

WHERE userid IN value_list;

In order to make use of distribution awareness, we need to make the userid column part of the table's primary key, then explicitly

partition the table with this column being used as the partitioning key. (Recall that for a partitioned table having one or more unique

keys, all columns of the table's partitioning key must also be part of all of the unique keys — for more information and examples,

see Partitioning Keys, Primary Keys, and Unique Keys.) In other words, the table schema should be equivalent to the following

CREATE TABLE statement:

CREATE TABLE t1 (

userid INT NOT NULL,

serviceid INT NOT NULL AUTO_INCREMENT,

data VARCHAR(255),

PRIMARY KEY p (userid,serviceid)

) ENGINE=NDBCLUSTER

PARTITION BY KEY(userid);

When the table is partitioned in this way, all rows having the same userid value are found on the same node group, and the

MySQL Server can immediately select the optimal node to use as the transaction coordinator.

• Realtime extensions for multiple CPUs. When running MySQL Cluster data nodes on hosts with multiple processors, the realtime

extensions make it possible to give priority to the data node process and control on which CPU cores it should operate. This can be

done using the data node configuration parameters RealtimeScheduler, SchedulerExecutionTimer and Scheduler-

SpinTimer. Doing so properly can significantly lower response times and make them much more predictable response. For more

information about using these parameters, see Defining Data Nodes: Realtime Performance Parameters

• Fully automatic database discovery. It is no longer a requirement for database autodiscovery that an SQL node already be con-

nected 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.

• Restoring specific databases, tables, or columns from a MySQL Cluster backup. It is now possible to exercise more fine-

grained control when restoring a MySQL Cluster from backup using ndb_restore. Beginning with MySQL Cluster NDB 6.3.22,

you can choose to restore only specified tables or databases, or exclude specific tables or databases from being restored, using the

new ndb_restore options --include-tables, --include-databases, --exclude-tables, and -

-exclude-databases. Beginning with MySQL Cluster NDB 6.3.26, it is also possible to restore to a table having fewer

columns than the original using the --exclude-missing-columns option. For more information about all of these options,

see Section 4.17, “ndb_restore — Restore a MySQL Cluster Backup”.

• Improved Disk Data filesystem configuration. As of MySQL Cluster NDB 6.3.22, you can specify default locations for MySQL

Cluster Disk Data data files and undo log files using the data node configuration parameters FileSystemPathDD, FileSys-

MySQL Cluster Overview

剩余287页未读，继续阅读

身份认证购VIP最低享 7 折!

30元优惠券

guofs123

粉丝: 0

MySQL Cluster安装与NDBCLUSTER存储引擎详解

mysql-cluster-8.0.27-linux-glibc2.12-x86_64.part1.rar

MySQL Cluster 8.0.27（mysql-cluster-8.0.27-winx64.zip）

mysql-cluster-8.0.20-winx64.zip

mysql-cluster:启动并运行mysql-cluster的示例

linux下MySQL-Cluster集群研究.doc linux下MySQL-Cluster集群研究.doc

mysql-cluster-windows

MySQL-Cluster-shared

MySQL Cluster 8.0.27（mysql-cluster-community-server-8.0.27）

MySQL Cluster 8.0.27（mysql-cluster-community-server-8.0.27 ）

MySQL Cluster 8.0.27（ mysql-cluster-community-server-8.0.27）

最新资源