MySQL8-中文参考-四十三-
MySQL8 中文参考(四十三)
25.6.12 NDB 集群中的在线 ALTER TABLE 操作
译文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-online-operations.html
MySQL NDB 集群 8.0 支持使用 ALTER TABLE ... ALGORITHM=DEFAULT|INPLACE|COPY
进行在线表模式更改。NDB 集群处理 COPY
和 INPLACE
如下几段描述的方式。
对于 ALGORITHM=COPY
,mysqld NDB 集群处理程序执行以下操作:
-
告诉数据节点创建表的空副本,并对此副本进行所需的模式更改。
-
从原始表中读取行,并将其写入副本。
-
告诉数据节点删除原始表,然后重命名副本。
我们有时将其称为“复制”或“离线” ALTER TABLE
。
DML 操作不允许与复制的 ALTER TABLE
并发进行。
发出复制 ALTER TABLE
语句的 mysqld 获取元数据锁,但这仅在该 mysqld 上有效。其他 NDB
客户端可以在复制 ALTER TABLE
过程中修改行数据,导致不一致。
对于 ALGORITHM=INPLACE
,NDB 集群处理程序告诉数据节点进行所需的更改,并且不执行任何数据复制。
我们还将其称为“非复制”或“在线” ALTER TABLE
。
非复制 ALTER TABLE
允许并发的 DML 操作。
ALGORITHM=INSTANT
不受 NDB 8.0 支持。
无论使用的算法如何,mysqld 在执行 ALTER TABLE 时会获取全局模式锁(GSL);这会阻止在集群中的此节点或任何其他 SQL 节点上同时执行任何(其他)DDL 或备份。通常情况下,这不会有问题,除非 ALTER TABLE
需要很长时间。
注意
一些较旧的 NDB 集群版本使用特定于 NDB
的语法进行在线 ALTER TABLE
操作。该语法已被移除。
在 NDB
表的可变宽度列上添加和删除索引的操作是在线的。在线操作是非复制的;也就是说,它们不需要重新创建索引。它们不会锁定正在被其他 API 节点访问的 NDB Cluster 中的表(但请参阅限制 NDB 在线操作,本节后面)。这些操作不需要单用户模式用于在具有多个 API 节点的 NDB 集群中进行的 NDB
表更改;事务可以在在线 DDL 操作期间继续无间断。
ALGORITHM=INPLACE
可用于在 NDB
表上执行在线 ADD COLUMN
、ADD INDEX
(包括 CREATE INDEX
语句)和 DROP INDEX
操作。还支持对 NDB
表进行在线重命名(在 NDB 8.0 之前,此类列无法在线重命名)。
无法在线向 NDB
表中添加基于磁盘的列。这意味着,如果您希望向使用表级 STORAGE DISK
选项的 NDB
表添加内存列,必须明确声明新列使用基于内存的存储。例如——假设您已经创建了表空间 ts1
——假设您创建表 t1
如下:
mysql> CREATE TABLE t1 (
> c1 INT NOT NULL PRIMARY KEY,
> c2 VARCHAR(30)
> )
> TABLESPACE ts1 STORAGE DISK
> ENGINE NDB;
Query OK, 0 rows affected (1.73 sec)
Records: 0 Duplicates: 0 Warnings: 0
您可以在线向此表添加一个新的内存列,如下所示:
mysql> ALTER TABLE t1
> ADD COLUMN c3 INT COLUMN_FORMAT DYNAMIC STORAGE MEMORY,
> ALGORITHM=INPLACE;
Query OK, 0 rows affected (1.25 sec)
Records: 0 Duplicates: 0 Warnings: 0
如果省略了 STORAGE MEMORY
选项,则此语句将失败:
mysql> ALTER TABLE t1
> ADD COLUMN c4 INT COLUMN_FORMAT DYNAMIC,
> ALGORITHM=INPLACE;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason:
Adding column(s) or add/reorganize partition not supported online. Try
ALGORITHM=COPY.
如果省略 COLUMN_FORMAT DYNAMIC
选项,则会自动使用动态列格式,但会发出警告,如下所示:
mysql> ALTER ONLINE TABLE t1 ADD COLUMN c4 INT STORAGE MEMORY;
Query OK, 0 rows affected, 1 warning (1.17 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> SHOW WARNINGS\G
*************************** 1\. row ***************************
Level: Warning
Code: 1478
Message: DYNAMIC column c4 with STORAGE DISK is not supported, column will
become FIXED
mysql> SHOW CREATE TABLE t1\G
*************************** 1\. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`c1` int(11) NOT NULL,
`c2` varchar(30) DEFAULT NULL,
`c3` int(11) /*!50606 STORAGE MEMORY */ /*!50606 COLUMN_FORMAT DYNAMIC */ DEFAULT NULL,
`c4` int(11) /*!50606 STORAGE MEMORY */ DEFAULT NULL,
PRIMARY KEY (`c1`)
) /*!50606 TABLESPACE ts_1 STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 1 row in set (0.03 sec)
注意
STORAGE
和 COLUMN_FORMAT
关键字仅在 NDB Cluster 中受支持;在 MySQL 的任何其他版本中,尝试在 CREATE TABLE
或 ALTER TABLE
语句中使用这两个关键字会导致错误。
也可以在 NDB
表上使用语句 ALTER TABLE ... REORGANIZE PARTITION, ALGORITHM=INPLACE
,在没有 *
partition_names* INTO (*
partition_definitions*)
选项的情况下。这可以用于在线在新添加到集群中的数据节点之间重新分配 NDB Cluster 数据。这不会执行任何碎片整理,这需要一个 OPTIMIZE TABLE
或空 ALTER TABLE
语句。更多信息,请参见 Section 25.6.7, “Adding NDB Cluster Data Nodes Online”。
NDB 在线操作的限制
不支持在线DROP COLUMN
操作。
添加列或添加或删除索引的在线ALTER TABLE
、CREATE INDEX
或DROP INDEX
语句受以下限制:
-
给定的在线
ALTER TABLE
只能使用ADD COLUMN
、ADD INDEX
或DROP INDEX
中的一个。可以在单个语句中在线添加一个或多个列;在单个语句中只能创建或删除一个索引。 -
在运行在线
ALTER TABLE
ADD COLUMN
、ADD INDEX
或DROP INDEX
(或CREATE INDEX
或DROP INDEX
语句)时,正在更改的表对于除运行在线操作的 API 节点之外的其他 API 节点不会被锁定。然而,在执行在线操作时,该表会针对相同API 节点上发起的任何其他操作被锁定。 -
要更改的表必须具有显式主键;由
NDB
存储引擎创建的隐藏主键不足以满足此目的。 -
表使用的存储引擎无法在线更改。
-
表使用的表空间无法在线更改。从 NDB 8.0.21 开始,类似
ALTER TABLE *
ndb_table* ... ALGORITHM=INPLACE, TABLESPACE=*
new_tablespace*
的语句被明确禁止。(Bug #99269,Bug #31180526) -
在与 NDB Cluster Disk Data 表一起使用时,无法在线更改列的存储类型(
DISK
或MEMORY
)。这意味着,当以在线方式添加或删除索引时,如果要更改列或列的存储类型,必须在添加或删除索引的语句中使用ALGORITHM=COPY
。
要在线添加的列不能使用BLOB
或TEXT
类型,并且必须满足以下条件:
-
列必须是动态的;也就是说,必须能够使用
COLUMN_FORMAT DYNAMIC
来创建它们。如果省略COLUMN_FORMAT DYNAMIC
选项,则动态列格式会自动使用。 -
列必须允许
NULL
值,并且除NULL
之外不能有任何显式默认值。在线添加的列会自动创建为DEFAULT NULL
,如下所示:mysql> CREATE TABLE t2 ( > c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY > ) ENGINE=NDB; Query OK, 0 rows affected (1.44 sec) mysql> ALTER TABLE t2 > ADD COLUMN c2 INT, > ADD COLUMN c3 INT, > ALGORITHM=INPLACE; Query OK, 0 rows affected, 2 warnings (0.93 sec) mysql> SHOW CREATE TABLE t1\G *************************** 1\. row *************************** Table: t1 Create Table: CREATE TABLE `t2` ( `c1` int(11) NOT NULL AUTO_INCREMENT, `c2` int(11) DEFAULT NULL, `c3` int(11) DEFAULT NULL, PRIMARY KEY (`c1`) ) ENGINE=ndbcluster DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 1 row in set (0.00 sec)
-
必须在任何现有列之后添加列。如果尝试在线在任何现有列之前或使用
FIRST
关键字添加列,则语句将失败并显示错误。 -
无法在线重新排序现有表列。
对于NDB
表的在线ALTER TABLE
操作,在线添加列时,或者在线创建或删除索引时,固定格式列会被转换为动态格式,如下所示(为了清晰起见,重复显示刚刚显示的CREATE TABLE
和ALTER TABLE
语句):
mysql> CREATE TABLE t2 (
> c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY
> ) ENGINE=NDB;
Query OK, 0 rows affected (1.44 sec)
mysql> ALTER TABLE t2
> ADD COLUMN c2 INT,
> ADD COLUMN c3 INT,
> ALGORITHM=INPLACE;
Query OK, 0 rows affected, 2 warnings (0.93 sec)
mysql> SHOW WARNINGS;
*************************** 1\. row ***************************
Level: Warning
Code: 1478
Message: Converted FIXED field 'c2' to DYNAMIC to enable online ADD COLUMN
*************************** 2\. row ***************************
Level: Warning
Code: 1478
Message: Converted FIXED field 'c3' to DYNAMIC to enable online ADD COLUMN 2 rows in set (0.00 sec)
只有在线添加的列或列必须是动态的。现有列不需要;这包括表的主键,也可以是FIXED
,如下所示:
mysql> CREATE TABLE t3 (
> c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY COLUMN_FORMAT FIXED
> ) ENGINE=NDB;
Query OK, 0 rows affected (2.10 sec)
mysql> ALTER TABLE t3 ADD COLUMN c2 INT, ALGORITHM=INPLACE;
Query OK, 0 rows affected, 1 warning (0.78 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> SHOW WARNINGS;
*************************** 1\. row ***************************
Level: Warning
Code: 1478
Message: Converted FIXED field 'c2' to DYNAMIC to enable online ADD COLUMN 1 row in set (0.00 sec)
通过重命名操作不会将列从FIXED
转换为DYNAMIC
列格式。有关COLUMN_FORMAT
的更多信息,请参见第 15.1.20 节,“CREATE TABLE Statement”。
在使用ALGORITHM=INPLACE
的ALTER TABLE
语句中支持KEY
、CONSTRAINT
和IGNORE
关键字。
使用在线ALTER TABLE
语句将MAX_ROWS
设置为 0 是不允许的。您必须使用复制的ALTER TABLE
来执行此操作。(Bug #21960004)
25.6.13 权限同步和 NDB_STORED_USER
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-privilege-synchronization.html
NDB 8.0 引入了一个新的机制,用于在连接到 NDB Cluster 的 SQL 节点之间共享和同步用户、角色和权限。这可以通过授予 NDB_STORED_USER
权限来启用。查看权限的描述以获取使用信息。
NDB_STORED_USER
在 SHOW GRANTS
的输出中与其他权限一样被打印出来,如下所示:
mysql> SHOW GRANTS for 'jon'@'localhost';
+---------------------------------------------------+
| Grants for jon@localhost |
+---------------------------------------------------+
| GRANT USAGE ON *.* TO `jon`@`localhost` |
| GRANT NDB_STORED_USER ON *.* TO `jon`@`localhost` |
+---------------------------------------------------+
您还可以使用 NDB Cluster 提供的 ndb_select_all 实用程序验证此帐户的权限是否已共享,如下所示(一些输出已换行以保持格式):
$> ndb_select_all -d mysql ndb_sql_metadata | grep '`jon`@`localhost`'
12 "'jon'@'localhost'" 0 [NULL] "GRANT USAGE ON *.* TO `jon`@`localhost`"
11 "'jon'@'localhost'" 0 2 "CREATE USER `jon`@`localhost`
IDENTIFIED WITH 'caching_sha2_password' AS
0x2441243030352466014340225A107D590E6E653B5D587922306102716D752E6656772F3038512F
6C5072776D30376D37347A384B557A4C564F70495158656A31382E45324E33
REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK PASSWORD HISTORY DEFAULT
PASSWORD REUSE INTERVAL DEFAULT PASSWORD REQUIRE CURRENT DEFAULT"
12 "'jon'@'localhost'" 1 [NULL] "GRANT NDB_STORED_USER ON *.* TO `jon`@`localhost`"
ndb_sql_metadata
是一个特殊的 NDB
表,不能使用 mysql 或其他 MySQL 客户端看到。
授予 NDB_STORED_USER
权限的语句,例如 GRANT NDB_STORED_USER ON *.* TO 'cluster_app_user'@'localhost'
,通过指示 NDB
使用查询 SHOW CREATE USER cluster_app_user@localhost
和 SHOW GRANTS FOR cluster_app_user@localhost
来创建一个快照,然后将结果存储在 ndb_sql_metadata
中。然后请求任何其他 SQL 节点读取和应用该快照。每当 MySQL 服务器启动并作为 SQL 节点加入集群时,它会执行这些存储的 CREATE USER
和 GRANT
语句作为集群模式同步过程的一部分。
每当在非原始 SQL 节点上执行 SQL 语句时,该语句将在 NDBCLUSTER
存储引擎的实用线程中运行;这是在与 MySQL 复制副本应用程序线程相同的安全环境中完成的。
从 NDB 8.0.27 开始,执行对用户权限的更改的 SQL 节点在执行之前会获取全局锁,这可以防止不同 SQL 节点上的并发 ACL 操作导致死锁。在 NDB 8.0.27 之前,对具有 NDB_STORED_USER
的用户的更改是完全异步更新的,没有任何锁被获取。
请记住,由于共享模式更改操作是同步执行的,因此在更改任何共享用户或用户后,下一个共享模式更改将作为同步点。在模式更改分发开始之前,任何待处理的用户更改都会完成;之后模式更改本身会同步运行。例如,如果一个DROP DATABASE
语句跟随一个DROP USER
对分布式用户的操作,那么在所有 SQL 节点上用户的删除完成之前,数据库的删除无法进行。
如果来自多个 SQL 节点的多个GRANT
、REVOKE
或其他用户管理语句导致给定用户在不同 SQL 节点上的权限不一致,您可以通过在已知权限正确的 SQL 节点上为该用户发出GRANT NDB_STORED_USER
来解决此问题;这将导致对权限的新快照被获取并同步到其他 SQL 节点。
NDB Cluster 8.0 不支持通过更改 MySQL 权限表使其使用NDB
存储引擎来在 NDB Cluster 中的 SQL 节点之间分发 MySQL 用户和权限,就像在 NDB 7.6 和之前的版本中一样(参见 Distributed Privileges Using Shared Grant Tables)。有关此更改对从先前版本升级到 NDB 8.0 的影响的信息,请参见 Section 25.3.7, “Upgrading and Downgrading NDB Cluster”。
25.6.14 NDB 集群的文件系统加密
25.6.14.1 NDB 文件系统加密设置和使用
25.6.14.2 NDB 文件系统加密实现
25.6.14.3 NDB 文件系统加密限制
以下章节提供了关于NDB
数据节点文件系统加密的信息,该加密方式在 NDB 8.0.31 及更高版本中实现。
译文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-tde-setup.html
25.6.14.1 NDB 文件系统加密设置和使用
文件系统加密:要启用先前未加密的文件系统的加密,需要执行以下步骤:
-
在
config.ini
文件的[ndbd default]
部分中设置所需的数据节点参数,如下所示:[ndbd default] EncryptedFileSystem= 1
这些参数必须如所有数据节点所示设置。
-
使用
--initial
或--reload
启动管理服务器,以使其读取更新后的配置文件。 -
执行所有数据节点的滚动初始启动(或重新启动)(参见第 25.6.5 节,“执行 NDB 集群的滚动重启”启动每个数据节点;此外,对每个数据节点进程提供
--filesystem-password
或--filesystem-password-from-stdin
中的任一选项,以及密码。当您在命令行上提供密码时,会显示警告,类似于这样:> ndbmtd -c 127.0.0.1 --filesystem-password=ndbsecret ndbmtd: [Warning] Using a password on the command line interface can be insecure. 2022-08-22 16:17:58 [ndbd] INFO -- Angel connected to '127.0.0.1:1186' 2022-08-22 16:17:58 [ndbd] INFO -- Angel allocated nodeid: 5
--filesystem-password
可以接受来自文件、tty
或stdin
的密码;--filesystem-password-from-stdin
仅接受来自stdin
的密码。后者保护密码免受在进程命令行或文件系统中暴露,并允许从另一个安全应用程序传递密码的可能性。您还可以将密码放在一个
my.cnf
文件中,该文件可以被数据节点进程读取,但不能被系统的其他用户读取。使用与前面示例中相同的密码,文件的相关部分应如下所示:[ndbd] filesystem-password=ndbsecret
您还可以在
my.cnf
文件中使用--filesystem-password-from-stdin
选项提示启动数据节点进程的用户在启动时提供加密密码,如下所示:[ndbd] filesystem-password-from-stdin
在这种情况下,当启动数据节点进程时,用户会被提示输入密码,如下所示:
> ndbmtd -c 127.0.0.1 Enter filesystem password: ********* 2022-08-22 16:36:00 [ndbd] INFO -- Angel connected to '127.0.0.1:1186' 2022-08-22 16:36:00 [ndbd] INFO -- Angel allocated nodeid: 5 >
无论使用何种方法,加密密码的格式与用于加密备份密码的格式相同(参见第 25.6.8.2 节,“使用 NDB 集群管理客户端创建备份”或
--filesystem-password-from-stdin
。
文件系统解密:要从加密文件系统中删除加密,请执行以下操作:
-
在
config.ini
文件的[ndbd default]
部分中,将EncryptedFileSystem = OFF
设置为关闭。 -
使用
--initial
或--reload
重新启动管理服务器。 -
执行数据节点的滚动初始重启。在重新启动节点二进制文件时,不要使用任何与密码相关的选项。
重新启动时,每个数据节点都会清除其磁盘上的状态,并以未加密形式重建。
要查看文件系统加密是否正确配置,可以使用针对ndbinfo
config_values
和config_params
表的查询,类似于这样:
mysql> SELECT v.node_id AS Node, p.param_name AS Parameter, v.config_value AS Value
-> FROM ndbinfo.config_values v
-> JOIN ndbinfo.config_params p
-> ON v.config_param=p.param_number
-> WHERE p.param_name='EncryptedFileSystem';
+------+----------------------+-------+
| Node | Parameter | Value |
+------+----------------------+-------+
| 5 | EncryptedFileSystem | 1 |
| 6 | EncryptedFileSystem | 1 |
| 7 | EncryptedFileSystem | 1 |
| 8 | EncryptedFileSystem | 1 |
+------+----------------------+-------+
4 rows in set (0.10 sec)
在这里,EncryptedFileSystem
在所有数据节点上都等于1
,这意味着文件系统加密已启用。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-tde-implementation.html
25.6.14.2 NDB 文件系统加密实现
对于NDB
透明数据加密(TDE),数据节点在静止状态下加密用户数据,安全性由密码(文件系统密码)提供,该密码用于加密和解密每个数据节点上的秘密文件。秘密文件包含一个节点主密钥(NMK),稍后用于加密用于持久性的不同文件类型。NDB
TDE 加密用户数据文件,包括 LCP 文件、重做日志文件、表空间文件和撤销日志文件。
您可以使用ndbxfrm实用程序查看文件是否已加密,如下所示:
> ndbxfrm -i ndb_5_fs/LCP/0/T2F0.Data
File=ndb_5_fs/LCP/0/T2F0.Data, compression=no, encryption=yes
> ndbxfrm -i ndb_6_fs/LCP/0/T2F0.Data
File=ndb_6_fs/LCP/0/T2F0.Data, compression=no, encryption=no
从 NDB 8.0.31 开始,可以使用在该版本中添加的ndb_secretsfile_reader程序从秘密文件中获取密钥,如下所示:
> ndb_secretsfile_reader --filesystem-password=54kl14 ndb_5_fs/D1/NDBCNTR/S0.sysfile
ndb_secretsfile_reader: [Warning] Using a password on the command line interface can be insecure.
cac256e18b2ddf6b5ef82d99a72f18e864b78453cc7fa40bfaf0c40b91122d18
每个节点的密钥层次结构可以表示如下:
-
用户提供的口令(P)通过使用随机盐的密钥派生函数处理,生成一个唯一的口令密钥(PK)。
-
PK(对每个节点唯一)加密每个节点上的数据在其自己的秘密文件中。
-
秘密文件中的数据包括一个唯一的、随机生成的节点主密钥(NMK)。
-
NMK(使用包装)加密每个加密文件的头部中的一个或多个随机生成的数据加密密钥(DEK)值(包括 LCP 和 TS 文件以及重做和撤销日志)。
-
数据加密密钥值(DEK[0],...,DEK[n])用于加密每个文件中的[子集的]数据。
口令间接加密包含随机 NMK 的秘密文件,该文件加密节点上每个加密文件的一部分头。加密文件头包含用于该文件中数据的随机数据密钥。
加密由数据节点内的NDBFS
层透明实现。NDBFS
内部客户端块对其文件进行正常操作;NDBFS
用额外的头部和尾部信息包装物理文件,支持加密,并在读取和写入文件时加密和解密数据。包装文件格式称为ndbxfrm1
。
节点密码通过 PBKDF2 和随机盐处理,用于加密包含用于加密每个加密文件中的随机生成数据加密密钥的秘密文件。
加密和解密工作是在 NDBFS I/O 线程中执行的(而不是在信号执行线程中,如主线程、tc 线程、ldm 线程或 rep 线程)。这类似于压缩的 LCP 和压缩的备份的处理方式,通常会导致增加 I/O 线程的 CPU 使用率;您可能希望根据 I/O 线程的情况调整ThreadConfig
。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-tde-limitations.html
25.6.14.3 NDB 文件系统加密限制
NDB 集群中的透明数据加密受以下限制和限制:
-
文件系统密码必须提供给每个单独的数据节点。
-
文件系统密码轮换需要对数据节点进行初始滚动重启;这必须手动执行,或者由
NDB
外部应用程序执行。 -
对于仅具有单个副本的集群(
NoOfReplicas = 1
),需要进行完整备份和恢复以进行文件系统密码轮换。 -
所有数据加密密钥的轮换需要初始节点重新启动。
25.6.15 NDB API 统计计数器和变量
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndb-api-statistics.html
有多种类型的统计计数器与由Ndb
对象执行或影响的操作相关联。这些操作包括启动和关闭(或中止)事务;主键和唯一键操作;表、范围和修剪扫描;线程在等待各种操作完成时被阻塞;以及由NDBCLUSTER
发送和接收的数据和事件。在进行 NDB API 调用或将数据发送到数据节点或接收数据时,这些计数器在 NDB 内核内部递增。mysqld将这些计数器公开为系统状态变量;它们的值可以在SHOW STATUS
的输出中读取,或通过查询性能模式session_status
或global_status
表来读取。通过比较操作NDB
表的语句执行前后的值,您可以观察在 API 级别执行的相应操作,从而了解执行语句的成本。
您可以使用以下SHOW STATUS
语句列出所有这些状态变量:
mysql> SHOW STATUS LIKE 'ndb_api%';
+----------------------------------------------+-----------+
| Variable_name | Value |
+----------------------------------------------+-----------+
| Ndb_api_wait_exec_complete_count | 297 |
| Ndb_api_wait_scan_result_count | 0 |
| Ndb_api_wait_meta_request_count | 321 |
| Ndb_api_wait_nanos_count | 228438645 |
| Ndb_api_bytes_sent_count | 33988 |
| Ndb_api_bytes_received_count | 66236 |
| Ndb_api_trans_start_count | 148 |
| Ndb_api_trans_commit_count | 148 |
| Ndb_api_trans_abort_count | 0 |
| Ndb_api_trans_close_count | 148 |
| Ndb_api_pk_op_count | 151 |
| Ndb_api_uk_op_count | 0 |
| Ndb_api_table_scan_count | 0 |
| Ndb_api_range_scan_count | 0 |
| Ndb_api_pruned_scan_count | 0 |
| Ndb_api_scan_batch_count | 0 |
| Ndb_api_read_row_count | 147 |
| Ndb_api_trans_local_read_row_count | 37 |
| Ndb_api_adaptive_send_forced_count | 3 |
| Ndb_api_adaptive_send_unforced_count | 294 |
| Ndb_api_adaptive_send_deferred_count | 0 |
| Ndb_api_event_data_count | 0 |
| Ndb_api_event_nondata_count | 0 |
| Ndb_api_event_bytes_count | 0 |
| Ndb_api_wait_exec_complete_count_slave | 0 |
| Ndb_api_wait_scan_result_count_slave | 0 |
| Ndb_api_wait_meta_request_count_slave | 0 |
| Ndb_api_wait_nanos_count_slave | 0 |
| Ndb_api_bytes_sent_count_slave | 0 |
| Ndb_api_bytes_received_count_slave | 0 |
| Ndb_api_trans_start_count_slave | 0 |
| Ndb_api_trans_commit_count_slave | 0 |
| Ndb_api_trans_abort_count_slave | 0 |
| Ndb_api_trans_close_count_slave | 0 |
| Ndb_api_pk_op_count_slave | 0 |
| Ndb_api_uk_op_count_slave | 0 |
| Ndb_api_table_scan_count_slave | 0 |
| Ndb_api_range_scan_count_slave | 0 |
| Ndb_api_pruned_scan_count_slave | 0 |
| Ndb_api_scan_batch_count_slave | 0 |
| Ndb_api_read_row_count_slave | 0 |
| Ndb_api_trans_local_read_row_count_slave | 0 |
| Ndb_api_adaptive_send_forced_count_slave | 0 |
| Ndb_api_adaptive_send_unforced_count_slave | 0 |
| Ndb_api_adaptive_send_deferred_count_slave | 0 |
| Ndb_api_wait_exec_complete_count_replica | 0 |
| Ndb_api_wait_scan_result_count_replica | 0 |
| Ndb_api_wait_meta_request_count_replica | 0 |
| Ndb_api_wait_nanos_count_replica | 0 |
| Ndb_api_bytes_sent_count_replica | 0 |
| Ndb_api_bytes_received_count_replica | 0 |
| Ndb_api_trans_start_count_replica | 0 |
| Ndb_api_trans_commit_count_replica | 0 |
| Ndb_api_trans_abort_count_replica | 0 |
| Ndb_api_trans_close_count_replica | 0 |
| Ndb_api_pk_op_count_replica | 0 |
| Ndb_api_uk_op_count_replica | 0 |
| Ndb_api_table_scan_count_replica | 0 |
| Ndb_api_range_scan_count_replica | 0 |
| Ndb_api_pruned_scan_count_replica | 0 |
| Ndb_api_scan_batch_count_replica | 0 |
| Ndb_api_read_row_count_replica | 0 |
| Ndb_api_trans_local_read_row_count_replica | 0 |
| Ndb_api_adaptive_send_forced_count_replica | 0 |
| Ndb_api_adaptive_send_unforced_count_replica | 0 |
| Ndb_api_adaptive_send_deferred_count_replica | 0 |
| Ndb_api_event_data_count_injector | 0 |
| Ndb_api_event_nondata_count_injector | 0 |
| Ndb_api_event_bytes_count_injector | 0 |
| Ndb_api_wait_exec_complete_count_session | 0 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 0 |
| Ndb_api_wait_nanos_count_session | 0 |
| Ndb_api_bytes_sent_count_session | 0 |
| Ndb_api_bytes_received_count_session | 0 |
| Ndb_api_trans_start_count_session | 0 |
| Ndb_api_trans_commit_count_session | 0 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 0 |
| Ndb_api_pk_op_count_session | 0 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 0 |
| Ndb_api_trans_local_read_row_count_session | 0 |
| Ndb_api_adaptive_send_forced_count_session | 0 |
| Ndb_api_adaptive_send_unforced_count_session | 0 |
| Ndb_api_adaptive_send_deferred_count_session | 0 |
+----------------------------------------------+-----------+
90 rows in set (0.01 sec)
这些状态变量也可以从性能模式session_status
和global_status
表中获取,如下所示:
mysql> SELECT * FROM performance_schema.session_status
-> WHERE VARIABLE_NAME LIKE 'ndb_api%';
+----------------------------------------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+----------------------------------------------+----------------+
| Ndb_api_wait_exec_complete_count | 617 |
| Ndb_api_wait_scan_result_count | 0 |
| Ndb_api_wait_meta_request_count | 649 |
| Ndb_api_wait_nanos_count | 335663491 |
| Ndb_api_bytes_sent_count | 65764 |
| Ndb_api_bytes_received_count | 86940 |
| Ndb_api_trans_start_count | 308 |
| Ndb_api_trans_commit_count | 308 |
| Ndb_api_trans_abort_count | 0 |
| Ndb_api_trans_close_count | 308 |
| Ndb_api_pk_op_count | 311 |
| Ndb_api_uk_op_count | 0 |
| Ndb_api_table_scan_count | 0 |
| Ndb_api_range_scan_count | 0 |
| Ndb_api_pruned_scan_count | 0 |
| Ndb_api_scan_batch_count | 0 |
| Ndb_api_read_row_count | 307 |
| Ndb_api_trans_local_read_row_count | 77 |
| Ndb_api_adaptive_send_forced_count | 3 |
| Ndb_api_adaptive_send_unforced_count | 614 |
| Ndb_api_adaptive_send_deferred_count | 0 |
| Ndb_api_event_data_count | 0 |
| Ndb_api_event_nondata_count | 0 |
| Ndb_api_event_bytes_count | 0 |
| Ndb_api_wait_exec_complete_count_slave | 0 |
| Ndb_api_wait_scan_result_count_slave | 0 |
| Ndb_api_wait_meta_request_count_slave | 0 |
| Ndb_api_wait_nanos_count_slave | 0 |
| Ndb_api_bytes_sent_count_slave | 0 |
| Ndb_api_bytes_received_count_slave | 0 |
| Ndb_api_trans_start_count_slave | 0 |
| Ndb_api_trans_commit_count_slave | 0 |
| Ndb_api_trans_abort_count_slave | 0 |
| Ndb_api_trans_close_count_slave | 0 |
| Ndb_api_pk_op_count_slave | 0 |
| Ndb_api_uk_op_count_slave | 0 |
| Ndb_api_table_scan_count_slave | 0 |
| Ndb_api_range_scan_count_slave | 0 |
| Ndb_api_pruned_scan_count_slave | 0 |
| Ndb_api_scan_batch_count_slave | 0 |
| Ndb_api_read_row_count_slave | 0 |
| Ndb_api_trans_local_read_row_count_slave | 0 |
| Ndb_api_adaptive_send_forced_count_slave | 0 |
| Ndb_api_adaptive_send_unforced_count_slave | 0 |
| Ndb_api_adaptive_send_deferred_count_slave | 0 |
| Ndb_api_wait_exec_complete_count_replica | 0 |
| Ndb_api_wait_scan_result_count_replica | 0 |
| Ndb_api_wait_meta_request_count_replica | 0 |
| Ndb_api_wait_nanos_count_replica | 0 |
| Ndb_api_bytes_sent_count_replica | 0 |
| Ndb_api_bytes_received_count_replica | 0 |
| Ndb_api_trans_start_count_replica | 0 |
| Ndb_api_trans_commit_count_replica | 0 |
| Ndb_api_trans_abort_count_replica | 0 |
| Ndb_api_trans_close_count_replica | 0 |
| Ndb_api_pk_op_count_replica | 0 |
| Ndb_api_uk_op_count_replica | 0 |
| Ndb_api_table_scan_count_replica | 0 |
| Ndb_api_range_scan_count_replica | 0 |
| Ndb_api_pruned_scan_count_replica | 0 |
| Ndb_api_scan_batch_count_replica | 0 |
| Ndb_api_read_row_count_replica | 0 |
| Ndb_api_trans_local_read_row_count_replica | 0 |
| Ndb_api_adaptive_send_forced_count_replica | 0 |
| Ndb_api_adaptive_send_unforced_count_replica | 0 |
| Ndb_api_adaptive_send_deferred_count_replica | 0 |
| Ndb_api_event_data_count_injector | 0 |
| Ndb_api_event_nondata_count_injector | 0 |
| Ndb_api_event_bytes_count_injector | 0 |
| Ndb_api_wait_exec_complete_count_session | 0 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 0 |
| Ndb_api_wait_nanos_count_session | 0 |
| Ndb_api_bytes_sent_count_session | 0 |
| Ndb_api_bytes_received_count_session | 0 |
| Ndb_api_trans_start_count_session | 0 |
| Ndb_api_trans_commit_count_session | 0 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 0 |
| Ndb_api_pk_op_count_session | 0 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 0 |
| Ndb_api_trans_local_read_row_count_session | 0 |
| Ndb_api_adaptive_send_forced_count_session | 0 |
| Ndb_api_adaptive_send_unforced_count_session | 0 |
| Ndb_api_adaptive_send_deferred_count_session | 0 |
+----------------------------------------------+----------------+
90 rows in set (0.01 sec)
mysql> SELECT * FROM performance_schema.global_status
-> WHERE VARIABLE_NAME LIKE 'ndb_api%';
+----------------------------------------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+----------------------------------------------+----------------+
| Ndb_api_wait_exec_complete_count | 741 |
| Ndb_api_wait_scan_result_count | 0 |
| Ndb_api_wait_meta_request_count | 777 |
| Ndb_api_wait_nanos_count | 373888309 |
| Ndb_api_bytes_sent_count | 78124 |
| Ndb_api_bytes_received_count | 94988 |
| Ndb_api_trans_start_count | 370 |
| Ndb_api_trans_commit_count | 370 |
| Ndb_api_trans_abort_count | 0 |
| Ndb_api_trans_close_count | 370 |
| Ndb_api_pk_op_count | 373 |
| Ndb_api_uk_op_count | 0 |
| Ndb_api_table_scan_count | 0 |
| Ndb_api_range_scan_count | 0 |
| Ndb_api_pruned_scan_count | 0 |
| Ndb_api_scan_batch_count | 0 |
| Ndb_api_read_row_count | 369 |
| Ndb_api_trans_local_read_row_count | 93 |
| Ndb_api_adaptive_send_forced_count | 3 |
| Ndb_api_adaptive_send_unforced_count | 738 |
| Ndb_api_adaptive_send_deferred_count | 0 |
| Ndb_api_event_data_count | 0 |
| Ndb_api_event_nondata_count | 0 |
| Ndb_api_event_bytes_count | 0 |
| Ndb_api_wait_exec_complete_count_slave | 0 |
| Ndb_api_wait_scan_result_count_slave | 0 |
| Ndb_api_wait_meta_request_count_slave | 0 |
| Ndb_api_wait_nanos_count_slave | 0 |
| Ndb_api_bytes_sent_count_slave | 0 |
| Ndb_api_bytes_received_count_slave | 0 |
| Ndb_api_trans_start_count_slave | 0 |
| Ndb_api_trans_commit_count_slave | 0 |
| Ndb_api_trans_abort_count_slave | 0 |
| Ndb_api_trans_close_count_slave | 0 |
| Ndb_api_pk_op_count_slave | 0 |
| Ndb_api_uk_op_count_slave | 0 |
| Ndb_api_table_scan_count_slave | 0 |
| Ndb_api_range_scan_count_slave | 0 |
| Ndb_api_pruned_scan_count_slave | 0 |
| Ndb_api_scan_batch_count_slave | 0 |
| Ndb_api_read_row_count_slave | 0 |
| Ndb_api_trans_local_read_row_count_slave | 0 |
| Ndb_api_adaptive_send_forced_count_slave | 0 |
| Ndb_api_adaptive_send_unforced_count_slave | 0 |
| Ndb_api_adaptive_send_deferred_count_slave | 0 |
| Ndb_api_wait_exec_complete_count_replica | 0 |
| Ndb_api_wait_scan_result_count_replica | 0 |
| Ndb_api_wait_meta_request_count_replica | 0 |
| Ndb_api_wait_nanos_count_replica | 0 |
| Ndb_api_bytes_sent_count_replica | 0 |
| Ndb_api_bytes_received_count_replica | 0 |
| Ndb_api_trans_start_count_replica | 0 |
| Ndb_api_trans_commit_count_replica | 0 |
| Ndb_api_trans_abort_count_replica | 0 |
| Ndb_api_trans_close_count_replica | 0 |
| Ndb_api_pk_op_count_replica | 0 |
| Ndb_api_uk_op_count_replica | 0 |
| Ndb_api_table_scan_count_replica | 0 |
| Ndb_api_range_scan_count_replica | 0 |
| Ndb_api_pruned_scan_count_replica | 0 |
| Ndb_api_scan_batch_count_replica | 0 |
| Ndb_api_read_row_count_replica | 0 |
| Ndb_api_trans_local_read_row_count_replica | 0 |
| Ndb_api_adaptive_send_forced_count_replica | 0 |
| Ndb_api_adaptive_send_unforced_count_replica | 0 |
| Ndb_api_adaptive_send_deferred_count_replica | 0 |
| Ndb_api_event_data_count_injector | 0 |
| Ndb_api_event_nondata_count_injector | 0 |
| Ndb_api_event_bytes_count_injector | 0 |
| Ndb_api_wait_exec_complete_count_session | 0 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 0 |
| Ndb_api_wait_nanos_count_session | 0 |
| Ndb_api_bytes_sent_count_session | 0 |
| Ndb_api_bytes_received_count_session | 0 |
| Ndb_api_trans_start_count_session | 0 |
| Ndb_api_trans_commit_count_session | 0 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 0 |
| Ndb_api_pk_op_count_session | 0 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 0 |
| Ndb_api_trans_local_read_row_count_session | 0 |
| Ndb_api_adaptive_send_forced_count_session | 0 |
| Ndb_api_adaptive_send_unforced_count_session | 0 |
| Ndb_api_adaptive_send_deferred_count_session | 0 |
+----------------------------------------------+----------------+
90 rows in set (0.01 sec)
每个Ndb
对象都有自己的计数器。NDB API 应用程序可以读取这些计数器的值,用于优化或监控。对于同时使用多个Ndb
对象的多线程客户端,还可以从属于给定Ndb_cluster_connection
的所有Ndb
对象获取计数器的总和视图。
有四组这些计数器可供查看。一组适用于当前会话;另外 3 组是全局的。尽管它们的值可以作为mysql客户端的会话或全局状态变量获得。这意味着在SHOW STATUS
中指定SESSION
或GLOBAL
关键字对 NDB API 统计状态变量报告的值没有影响,每个变量的值无论是从session_status
表的等效列还是从global_status
表获得,其值都是相同的。
-
会话计数器(特定会话)
会话计数器与当前会话中使用的
Ndb
对象相关。其他 MySQL 客户端对这些对象的使用不会影响这些计数。为了最大限度地减少与标准 MySQL 会话变量的混淆,我们将与这些 NDB API 会话计数器对应的变量称为“
_session
变量”,带有前导下划线。 -
复制计数器(全局)
这组计数器与复制 SQL 线程(如果有)使用的
Ndb
对象相关。如果此mysqld不充当复制品,或不使用NDB
表,则所有这些计数都为 0。我们将相关的状态变量称为“
_slave
变量”(带有前导下划线)。 -
注入器计数器(全局)
注入器计数器与二进制日志注入器线程监听集群事件所使用的
Ndb
对象相关。即使不写入二进制日志,附加到 NDB 集群的mysqld进程仍会继续监听某些事件,如模式更改。我们将与 NDB API 注入器计数器对应的状态变量称为“
_injector
变量”(带有前导下划线)。 -
服务器(全局)计数器(全局)
这组计数器与当前mysqld使用的所有
Ndb
对象相关。这包括所有 MySQL 客户端应用程序、复制 SQL 线程(如果有)、二进制日志注入器和NDB
实用程序线程。我们将与这些计数器对应的状态变量称为“全局变量”或“mysqld级别变量”。
你可以通过在变量名中额外过滤子字符串 session
、slave
或 injector
(以及共同前缀 Ndb_api
)来获取特定一组变量的值。对于 _session
变量,可以按照这里所示进行操作:
mysql> SHOW STATUS LIKE 'ndb_api%session';
+--------------------------------------------+---------+
| Variable_name | Value |
+--------------------------------------------+---------+
| Ndb_api_wait_exec_complete_count_session | 2 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 1 |
| Ndb_api_wait_nanos_count_session | 8144375 |
| Ndb_api_bytes_sent_count_session | 68 |
| Ndb_api_bytes_received_count_session | 84 |
| Ndb_api_trans_start_count_session | 1 |
| Ndb_api_trans_commit_count_session | 1 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 1 |
| Ndb_api_pk_op_count_session | 1 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 1 |
| Ndb_api_trans_local_read_row_count_session | 1 |
+--------------------------------------------+---------+
18 rows in set (0.50 sec)
要获取 NDB API mysqld 级别状态变量的列表,请过滤以 ndb_api
开头且以 _count
结尾的变量名,就像这样:
mysql> SELECT * FROM performance_schema.session_status
-> WHERE VARIABLE_NAME LIKE 'ndb_api%count';
+------------------------------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+------------------------------------+----------------+
| NDB_API_WAIT_EXEC_COMPLETE_COUNT | 4 |
| NDB_API_WAIT_SCAN_RESULT_COUNT | 3 |
| NDB_API_WAIT_META_REQUEST_COUNT | 28 |
| NDB_API_WAIT_NANOS_COUNT | 53756398 |
| NDB_API_BYTES_SENT_COUNT | 1060 |
| NDB_API_BYTES_RECEIVED_COUNT | 9724 |
| NDB_API_TRANS_START_COUNT | 3 |
| NDB_API_TRANS_COMMIT_COUNT | 2 |
| NDB_API_TRANS_ABORT_COUNT | 0 |
| NDB_API_TRANS_CLOSE_COUNT | 3 |
| NDB_API_PK_OP_COUNT | 2 |
| NDB_API_UK_OP_COUNT | 0 |
| NDB_API_TABLE_SCAN_COUNT | 1 |
| NDB_API_RANGE_SCAN_COUNT | 0 |
| NDB_API_PRUNED_SCAN_COUNT | 0 |
| NDB_API_SCAN_BATCH_COUNT | 0 |
| NDB_API_READ_ROW_COUNT | 2 |
| NDB_API_TRANS_LOCAL_READ_ROW_COUNT | 2 |
| NDB_API_EVENT_DATA_COUNT | 0 |
| NDB_API_EVENT_NONDATA_COUNT | 0 |
| NDB_API_EVENT_BYTES_COUNT | 0 |
+------------------------------------+----------------+
21 rows in set (0.09 sec)
并非所有计数器都反映在所有 4 组状态变量中。对于事件计数器 DataEventsRecvdCount
、NondataEventsRecvdCount
和 EventBytesRecvdCount
,仅有 _injector
和 mysqld 级别的 NDB API 状态变量可用:
mysql> SHOW STATUS LIKE 'ndb_api%event%';
+--------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------+-------+
| Ndb_api_event_data_count_injector | 0 |
| Ndb_api_event_nondata_count_injector | 0 |
| Ndb_api_event_bytes_count_injector | 0 |
| Ndb_api_event_data_count | 0 |
| Ndb_api_event_nondata_count | 0 |
| Ndb_api_event_bytes_count | 0 |
+--------------------------------------+-------+
6 rows in set (0.00 sec)
对于任何其他 NDB API 计数器,都未实现 _injector
状态变量,如下所示:
mysql> SHOW STATUS LIKE 'ndb_api%injector%';
+--------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------+-------+
| Ndb_api_event_data_count_injector | 0 |
| Ndb_api_event_nondata_count_injector | 0 |
| Ndb_api_event_bytes_count_injector | 0 |
+--------------------------------------+-------+
3 rows in set (0.00 sec)
状态变量的名称可以轻松与相应计数器的名称关联起来。每个 NDB API 统计计数器在以下表中列出,包括描述以及与该计数器对应的任何 MySQL 服务器状态变量的名称。
表 25.67 NDB API 统计计数器
| 计数器名称 | 描述 | 状态变量(按统计类型):
-
会话
-
从库(副本)
-
注入器
-
服务器
|
WaitExecCompleteCount |
线程在等待操作完成时被阻塞的次数。包括所有 execute() 调用,以及对 blob 操作和对客户端不可见的自增操作的隐式执行。 |
---|
-
Ndb_api_wait_exec_complete_count_session
-
Ndb_api_wait_exec_complete_count_slave
-
[无]
-
Ndb_api_wait_exec_complete_count
|
WaitScanResultCount |
线程在等待扫描信号时被阻塞的次数,例如等待额外结果或等待扫描关闭。 |
---|
-
Ndb_api_wait_scan_result_count_session
-
Ndb_api_wait_scan_result_count_slave
-
[无]
-
Ndb_api_wait_scan_result_count
|
WaitMetaRequestCount |
线程被阻塞等待基于元数据的信号的次数;当等待 DDL 操作或等待开始(或结束)时代时,可能会发生这种情况。 |
---|
-
Ndb_api_wait_meta_request_count_session
-
Ndb_api_wait_meta_request_count_slave
-
[无]
-
Ndb_api_wait_meta_request_count
|
WaitNanosCount |
从数据节点等待某种信号所花费的总时间(以纳秒为单位)。 |
---|
-
Ndb_api_wait_nanos_count_session
-
Ndb_api_wait_nanos_count_slave
-
[none]
-
Ndb_api_wait_nanos_count
|
BytesSentCount |
发送到数据节点的数据量(以字节为单位)。 |
---|
-
Ndb_api_bytes_sent_count_session
-
Ndb_api_bytes_sent_count_slave
-
[none]
-
Ndb_api_bytes_sent_count
|
BytesRecvdCount |
从数据节点接收的数据量(以字节为单位)。 |
---|
-
Ndb_api_bytes_received_count_session
-
Ndb_api_bytes_received_count_slave
-
[none]
-
Ndb_api_bytes_received_count
|
TransStartCount |
开始的事务数。 |
---|
-
Ndb_api_trans_start_count_session
-
Ndb_api_trans_start_count_slave
-
[none]
-
Ndb_api_trans_start_count
|
TransCommitCount |
提交的事务数。 |
---|
-
Ndb_api_trans_commit_count_session
-
Ndb_api_trans_commit_count_slave
-
[none]
-
Ndb_api_trans_commit_count
|
TransAbortCount |
中止的事务数。 |
---|
-
Ndb_api_trans_abort_count_session
-
Ndb_api_trans_abort_count_slave
-
[none]
-
Ndb_api_trans_abort_count
|
TransCloseCount |
中止的事务数。(此值可能大于TransCommitCount 和TransAbortCount 的总和。) |
---|
-
Ndb_api_trans_close_count_session
-
Ndb_api_trans_close_count_slave
-
[none]
-
Ndb_api_trans_close_count
|
PkOpCount |
基于或使用主键的操作次数。此计数包括 blob-part 表操作、隐式解锁操作和自增操作,以及通常对 MySQL 客户端可见的主键操作。 |
---|
-
Ndb_api_pk_op_count_session
-
Ndb_api_pk_op_count_slave
-
[无]
-
Ndb_api_pk_op_count
|
UkOpCount |
基于或使用唯一键的操作次数。 |
---|
-
Ndb_api_uk_op_count_session
-
Ndb_api_uk_op_count_slave
-
[无]
-
Ndb_api_uk_op_count
|
TableScanCount |
已启动的表扫描次数。这包括对内部表的扫描。 |
---|
-
Ndb_api_table_scan_count_session
-
Ndb_api_table_scan_count_slave
-
[无]
-
Ndb_api_table_scan_count
|
RangeScanCount |
已启动的范围扫描次数。 |
---|
-
Ndb_api_range_scan_count_session
-
Ndb_api_range_scan_count_slave
-
[无]
-
Ndb_api_range_scan_count
|
PrunedScanCount |
已被剪枝为单个分区的扫描次数。 |
---|
-
Ndb_api_pruned_scan_count_session
-
Ndb_api_pruned_scan_count_slave
-
[无]
-
Ndb_api_pruned_scan_count
|
ScanBatchCount |
接收的行批次数。 (在此上下文中,批次是来自单个片段的扫描结果集。) |
---|
-
Ndb_api_scan_batch_count_session
-
Ndb_api_scan_batch_count_slave
-
[无]
-
Ndb_api_scan_batch_count
|
ReadRowCount |
已读取的总行数。包括使用主键、唯一键和扫描操作读取的行。 |
---|
-
Ndb_api_read_row_count_session
-
Ndb_api_read_row_count_slave
-
[无]
-
Ndb_api_read_row_count
|
TransLocalReadRowCount |
从运行事务的同一节点上读取的行数。 |
---|
-
Ndb_api_trans_local_read_row_count_session
-
Ndb_api_trans_local_read_row_count_slave
-
[无]
-
Ndb_api_trans_local_read_row_count
|
DataEventsRecvdCount |
接收的行更改事件数。 |
---|
-
[无]
-
[无]
-
Ndb_api_event_data_count_injector
-
Ndb_api_event_data_count
|
NondataEventsRecvdCount |
接收的事件数,除了行更改事件。 |
---|
-
[无]
-
[无]
-
Ndb_api_event_nondata_count_injector
-
Ndb_api_event_nondata_count
|
EventBytesRecvdCount |
接收的事件字节数。 |
---|
-
[无]
-
[无]
-
Ndb_api_event_bytes_count_injector
-
Ndb_api_event_bytes_count
|
| 计数器名称 | 描述 | 状态变量(按统计类型):
-
会话
-
从属(副本)
-
注入器
-
服务器
|
要查看所有已提交事务的计数,即所有TransCommitCount
计数器状态变量,您可以将SHOW STATUS
的结果过滤为子字符串trans_commit_count
,就像这样:
mysql> SHOW STATUS LIKE '%trans_commit_count%';
+------------------------------------+-------+
| Variable_name | Value |
+------------------------------------+-------+
| Ndb_api_trans_commit_count_session | 1 |
| Ndb_api_trans_commit_count_slave | 0 |
| Ndb_api_trans_commit_count | 2 |
+------------------------------------+-------+
3 rows in set (0.00 sec)
从中您可以确定当前mysql客户端会话中已提交了 1 个事务,并且自上次重新启动以来,此mysqld上已提交了 2 个事务。
您可以通过比较执行语句前后相应_session
状态变量的值来查看给定 SQL 语句如何递增各种 NDB API 计数器。在此示例中,在从SHOW STATUS
获取初始值后,我们在test
数据库中创建一个名为t
的NDB
表,该表只有一列:
mysql> SHOW STATUS LIKE 'ndb_api%session%';
+--------------------------------------------+--------+
| Variable_name | Value |
+--------------------------------------------+--------+
| Ndb_api_wait_exec_complete_count_session | 2 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 3 |
| Ndb_api_wait_nanos_count_session | 820705 |
| Ndb_api_bytes_sent_count_session | 132 |
| Ndb_api_bytes_received_count_session | 372 |
| Ndb_api_trans_start_count_session | 1 |
| Ndb_api_trans_commit_count_session | 1 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 1 |
| Ndb_api_pk_op_count_session | 1 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 1 |
| Ndb_api_trans_local_read_row_count_session | 1 |
+--------------------------------------------+--------+
18 rows in set (0.00 sec)
mysql> USE test;
Database changed
mysql> CREATE TABLE t (c INT) ENGINE NDBCLUSTER;
Query OK, 0 rows affected (0.85 sec)
现在,您可以执行一个新的SHOW STATUS
语句并观察更改,如下所示(在输出中突出显示更改的行):
mysql> SHOW STATUS LIKE 'ndb_api%session%';
+--------------------------------------------+-----------+
| Variable_name | Value |
+--------------------------------------------+-----------+ *| Ndb_api_wait_exec_complete_count_session | 8 |* | Ndb_api_wait_scan_result_count_session | 0 |
*| Ndb_api_wait_meta_request_count_session | 17 |*
*| Ndb_api_wait_nanos_count_session | 706871709 |*
*| Ndb_api_bytes_sent_count_session | 2376 |*
*| Ndb_api_bytes_received_count_session | 3844 |*
*| Ndb_api_trans_start_count_session | 4 |*
*| Ndb_api_trans_commit_count_session | 4 |*
| Ndb_api_trans_abort_count_session | 0 |
*| Ndb_api_trans_close_count_session | 4 |*
*| Ndb_api_pk_op_count_session | 6 |*
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
*| Ndb_api_read_row_count_session | 2 |*
| Ndb_api_trans_local_read_row_count_session | 1 |
+--------------------------------------------+-----------+
18 rows in set (0.00 sec)
同样,您可以看到通过向t
插入一行导致的 NDB API 统计计数器的变化:插入行,然后运行与前一个示例中使用的相同的SHOW STATUS
语句,如下所示:
mysql> INSERT INTO t VALUES (100);
Query OK, 1 row affected (0.00 sec)
mysql> SHOW STATUS LIKE 'ndb_api%session%';
+--------------------------------------------+-----------+
| Variable_name | Value |
+--------------------------------------------+-----------+
*| Ndb_api_wait_exec_complete_count_session | 11 |*
*| Ndb_api_wait_scan_result_count_session | 6 |*
*| Ndb_api_wait_meta_request_count_session | 20 |*
*| Ndb_api_wait_nanos_count_session | 707370418 |*
*| Ndb_api_bytes_sent_count_session | 2724 |*
*| Ndb_api_bytes_received_count_session | 4116 |*
*| Ndb_api_trans_start_count_session | 7 |*
*| Ndb_api_trans_commit_count_session | 6 |*
| Ndb_api_trans_abort_count_session | 0 |
*| Ndb_api_trans_close_count_session | 7 |*
*| Ndb_api_pk_op_count_session | 8 |*
| Ndb_api_uk_op_count_session | 0 |
*| Ndb_api_table_scan_count_session | 1 |*
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
*| Ndb_api_read_row_count_session | 3 |*
*| Ndb_api_trans_local_read_row_count_session | 2 |*
+--------------------------------------------+-----------+
18 rows in set (0.00 sec)
我们可以从这些结果中得出许多观察结果:
-
虽然我们创建了
t
,没有明确的主键,但在此过程中执行了 5 次主键操作(Ndb_api_pk_op_count_session
的“之前”和“之后”值的差异,或者 6 减 1)。这反映了隐藏主键的创建,这是所有使用NDB
存储引擎的表的特点。 -
通过比较
Ndb_api_wait_nanos_count_session
的连续值,我们可以看到实现CREATE TABLE
语句的 NDB API 操作等待的时间要长得多(706871709 - 820705 = 706051004 纳秒,或大约 0.7 秒),以获取来自数据节点的响应,比执行INSERT
的操作(707370418 - 706871709 = 498709 ns,或大约 0.0005 秒)要长。在mysql客户端中报告的执行时间与这些数字大致相关。在没有足够(纳秒)时间分辨率的平台上,由于执行非常快的 SQL 语句而导致
WaitNanosCount
NDB API 计数器值的微小变化,可能不总是在Ndb_api_wait_nanos_count_session
、Ndb_api_wait_nanos_count_slave
或Ndb_api_wait_nanos_count
的值中可见。 -
INSERT
语句增加了ReadRowCount
和TransLocalReadRowCount
NDB API 统计计数器,反映在Ndb_api_read_row_count_session
和Ndb_api_trans_local_read_row_count_session
的增加值。
25.6.16 ndbinfo: NDB 集群信息数据库
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo.html
25.6.16.1 ndbinfo arbitrator_validity_detail 表
25.6.16.2 ndbinfo arbitrator_validity_summary 表
25.6.16.3 ndbinfo backup_id 表
25.6.16.4 ndbinfo blobs 表
25.6.16.5 ndbinfo blocks 表
25.6.16.6 ndbinfo cluster_locks 表
25.6.16.7 ndbinfo cluster_operations 表
25.6.16.8 ndbinfo cluster_transactions 表
25.6.16.9 ndbinfo config_nodes 表
25.6.16.10 ndbinfo config_params 表
25.6.16.11 ndbinfo config_values 表
25.6.16.12 ndbinfo counters 表
25.6.16.13 ndbinfo cpudata 表
25.6.16.14 ndbinfo cpudata_1sec 表
25.6.16.15 ndbinfo cpudata_20sec 表
25.6.16.16 ndbinfo cpudata_50ms 表
25.6.16.17 ndbinfo cpuinfo 表
25.6.16.18 ndbinfo cpustat 表
25.6.16.19 ndbinfo cpustat_50ms 表
25.6.16.20 ndbinfo cpustat_1sec 表
25.6.16.21 ndbinfo cpustat_20sec 表
25.6.16.22 ndbinfo dictionary_columns 表
25.6.16.23 ndbinfo dictionary_tables 表
25.6.16.24 ndbinfo dict_obj_info 表
25.6.16.25 ndbinfo dict_obj_tree 表
25.6.16.26 ndbinfo dict_obj_types 表
25.6.16.27 ndbinfo disk_write_speed_base 表
25.6.16.28 ndbinfo disk_write_speed_aggregate 表
25.6.16.29 ndbinfo disk_write_speed_aggregate_node 表
25.6.16.30 ndbinfo diskpagebuffer 表
25.6.16.31 ndbinfo diskstat 表
25.6.16.32 ndbinfo diskstats_1sec 表
25.6.16.33 ndbinfo error_messages 表
25.6.16.34 ndbinfo events 表
25.6.16.35 ndbinfo files 表
25.6.16.36 ndbinfo foreign_keys 表
25.6.16.37 ndbinfo hash_maps 表
25.6.16.38 ndbinfo hwinfo 表
25.6.16.39 ndbinfo index_columns 表
25.6.16.40 ndbinfo index_stats 表
25.6.16.41 ndbinfo locks_per_fragment 表
25.6.16.42 ndbinfo logbuffers 表
25.6.16.43 ndbinfo logspaces 表
25.6.16.44 ndbinfo membership 表
25.6.16.45 ndbinfo memoryusage 表
25.6.16.46 ndbinfo memory_per_fragment 表
25.6.16.47 ndbinfo nodes 表
25.6.16.48 ndbinfo operations_per_fragment 表
25.6.16.49 ndbinfo pgman_time_track_stats 表
25.6.16.50 ndbinfo processes 表
25.6.16.51 ndbinfo resources 表
25.6.16.52 ndbinfo restart_info 表
25.6.16.53 ndbinfo server_locks 表
25.6.16.54 ndbinfo server_operations 表
25.6.16.55 ndbinfo server_transactions 表
25.6.16.56 ndbinfo table_distribution_status 表
25.6.16.57 ndbinfo table_fragments 表
25.6.16.58 ndbinfo table_info 表
25.6.16.59 ndbinfo table_replicas 表
25.6.16.60 ndbinfo tc_time_track_stats 表
25.6.16.61 ndbinfo threadblocks 表
25.6.16.62 ndbinfo threads 表
25.6.16.63 ndbinfo threadstat 表
25.6.16.64 ndbinfo transporter_details 表
25.6.16.65 ndbinfo transporters 表
ndbinfo
是一个包含特定于 NDB Cluster 的信息的数据库。
该数据库包含许多表,每个表提供关于 NDB Cluster 节点状态、资源使用情况和操作的不同类型数据。您可以在接下来的几节中找到关于每个表的更详细信息。
ndbinfo
包含在 MySQL Server 中的 NDB Cluster 支持中;不需要特殊的编译或配置步骤;当 MySQL Server 连接到集群时,这些表由 MySQL Server 创建。您可以使用SHOW PLUGINS
验证给定 MySQL Server 实例中是否激活了ndbinfo
支持;如果启用了ndbinfo
支持,您应该看到Name
列中包含ndbinfo
,Status
列中包含ACTIVE
的行,如下所示(强调文本):
mysql> SHOW PLUGINS;
+----------------------------------+--------+--------------------+---------+---------+
| Name | Status | Type | Library | License |
+----------------------------------+--------+--------------------+---------+---------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | GPL |
| mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| sha256_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| caching_sha2_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| sha2_cache_cleaner | ACTIVE | AUDIT | NULL | GPL |
| daemon_keyring_proxy_plugin | ACTIVE | DAEMON | NULL | GPL |
| CSV | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL |
| InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL |
| INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMPMEM | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMPMEM_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP_PER_INDEX | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP_PER_INDEX_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_BUFFER_PAGE | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_BUFFER_PAGE_LRU | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_BUFFER_POOL_STATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TEMP_TABLE_INFO | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_METRICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_DEFAULT_STOPWORD | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_BEING_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_CONFIG | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_INDEX_CACHE | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_FT_INDEX_TABLE | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLESTATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_INDEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLESPACES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_COLUMNS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_VIRTUAL | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CACHED_INDEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_SESSION_TEMP_TABLESPACES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MRG_MYISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | NULL | GPL |
| TempTable | ACTIVE | STORAGE ENGINE | NULL | GPL |
| ARCHIVE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| BLACKHOLE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| ndbcluster | ACTIVE | STORAGE ENGINE | NULL | GPL |
*| ndbinfo | ACTIVE | STORAGE ENGINE | NULL | GPL |*
| ndb_transid_mysql_connection_map | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| ngram | ACTIVE | FTPARSER | NULL | GPL |
| mysqlx_cache_cleaner | ACTIVE | AUDIT | NULL | GPL |
| mysqlx | ACTIVE | DAEMON | NULL | GPL |
+----------------------------------+--------+--------------------+---------+---------+
47 rows in set (0.00 sec)
您还可以通过检查SHOW ENGINES
的输出,查看包含ndbinfo
的行以及Support
列中的YES
,如下所示(强调文本):
mysql> SHOW ENGINES\G
*************************** 1\. row ***************************
Engine: ndbcluster
Support: YES
Comment: Clustered, fault-tolerant tables
Transactions: YES
XA: NO
Savepoints: NO
*************************** 2\. row ***************************
Engine: CSV
Support: YES
Comment: CSV storage engine
Transactions: NO
XA: NO
Savepoints: NO
*************************** 3\. row ***************************
Engine: InnoDB
Support: DEFAULT
Comment: Supports transactions, row-level locking, and foreign keys
Transactions: YES
XA: YES
Savepoints: YES
*************************** 4\. row ***************************
Engine: BLACKHOLE
Support: YES
Comment: /dev/null storage engine (anything you write to it disappears)
Transactions: NO
XA: NO
Savepoints: NO
*************************** 5\. row ***************************
Engine: MyISAM
Support: YES
Comment: MyISAM storage engine
Transactions: NO
XA: NO
Savepoints: NO
*************************** 6\. row ***************************
Engine: MRG_MYISAM
Support: YES
Comment: Collection of identical MyISAM tables
Transactions: NO
XA: NO
Savepoints: NO
*************************** 7\. row ***************************
Engine: ARCHIVE
Support: YES
Comment: Archive storage engine
Transactions: NO
XA: NO
Savepoints: NO
**************************** 8\. row ***************************
Engine: ndbinfo
Support: YES
Comment: NDB Cluster system information storage engine
Transactions: NO
XA: NO
Savepoints: NO*
*************************** 9\. row ***************************
Engine: PERFORMANCE_SCHEMA
Support: YES
Comment: Performance Schema
Transactions: NO
XA: NO
Savepoints: NO
*************************** 10\. row ***************************
Engine: MEMORY
Support: YES
Comment: Hash based, stored in memory, useful for temporary tables
Transactions: NO
XA: NO
Savepoints: NO 10 rows in set (0.00 sec)
如果启用了ndbinfo
支持,则可以使用 SQL 语句在mysql或其他 MySQL 客户端中访问ndbinfo
。例如,您可以在SHOW DATABASES
的输出中看到ndbinfo
,如下所示(强调文本):
mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
*| ndbinfo |*
| performance_schema |
| sys |
+--------------------+
5 rows in set (0.04 sec)
如果mysqld进程未使用--ndbcluster
选项启动,则ndbinfo
不可用,并且不会显示在SHOW DATABASES
中。如果mysqld曾连接到 NDB Cluster 但集群不可用(由于事件如集群关闭、网络连接丢失等),ndbinfo
及其表仍然可见,但尝试访问任何表(除了blocks
或config_params
)将失败,并显示错误 157 'Connection to NDB failed' from NDBINFO。
除了blocks
和config_params
表之外,我们所说的ndbinfo
“表”实际上是从内部NDB
表生成的视图,通常对 MySQL Server 不可见。您可以通过将ndbinfo_show_hidden
系统变量设置为ON
(或1
)来使这些表可见,但通常不需要这样做。
所有 ndbinfo
表都是只读的,并在查询时按需生成。因为许多表是由数据节点并行生成的,而其他表是特定于给定的 SQL 节点,所以不能保证提供一致的快照。
此外,在 ndbinfo
表上不支持连接的下推;因此,连接大型 ndbinfo
表可能需要将大量数据传输到请求的 API 节点,即使查询使用 WHERE
子句。
ndbinfo
表不包含在查询缓存中。(Bug #59831)
你可以使用 USE
语句选择 ndbinfo
数据库,然后发出 SHOW TABLES
语句获取表的列表,就像对待任何其他数据库一样,如下所示:
mysql> USE ndbinfo;
Database changed
mysql> SHOW TABLES;
+---------------------------------+
| Tables_in_ndbinfo |
+---------------------------------+
| arbitrator_validity_detail |
| arbitrator_validity_summary |
| backup_id |
| blobs |
| blocks |
| cluster_locks |
| cluster_operations |
| cluster_transactions |
| config_nodes |
| config_params |
| config_values |
| counters |
| cpudata |
| cpudata_1sec |
| cpudata_20sec |
| cpudata_50ms |
| cpuinfo |
| cpustat |
| cpustat_1sec |
| cpustat_20sec |
| cpustat_50ms |
| dict_obj_info |
| dict_obj_tree |
| dict_obj_types |
| dictionary_columns |
| dictionary_tables |
| disk_write_speed_aggregate |
| disk_write_speed_aggregate_node |
| disk_write_speed_base |
| diskpagebuffer |
| diskstat |
| diskstats_1sec |
| error_messages |
| events |
| files |
| foreign_keys |
| hash_maps |
| hwinfo |
| index_columns |
| index_stats |
| locks_per_fragment |
| logbuffers |
| logspaces |
| membership |
| memory_per_fragment |
| memoryusage |
| nodes |
| operations_per_fragment |
| pgman_time_track_stats |
| processes |
| resources |
| restart_info |
| server_locks |
| server_operations |
| server_transactions |
| table_distribution_status |
| table_fragments |
| table_info |
| table_replicas |
| tc_time_track_stats |
| threadblocks |
| threads |
| threadstat |
| transporters |
+---------------------------------+
64 rows in set (0.00 sec)
在 NDB 8.0 中,所有 ndbinfo
表都使用 NDB
存储引擎;然而,在SHOW ENGINES
和SHOW PLUGINS
的输出中仍会出现一个 ndbinfo
条目,如前所述。
你可以执行对这些表的SELECT
语句,就像你通常期望的那样:
mysql> SELECT * FROM memoryusage;
+---------+---------------------+--------+------------+------------+-------------+
| node_id | memory_type | used | used_pages | total | total_pages |
+---------+---------------------+--------+------------+------------+-------------+
| 5 | Data memory | 425984 | 13 | 2147483648 | 65536 |
| 5 | Long message buffer | 393216 | 1536 | 67108864 | 262144 |
| 6 | Data memory | 425984 | 13 | 2147483648 | 65536 |
| 6 | Long message buffer | 393216 | 1536 | 67108864 | 262144 |
| 7 | Data memory | 425984 | 13 | 2147483648 | 65536 |
| 7 | Long message buffer | 393216 | 1536 | 67108864 | 262144 |
| 8 | Data memory | 425984 | 13 | 2147483648 | 65536 |
| 8 | Long message buffer | 393216 | 1536 | 67108864 | 262144 |
+---------+---------------------+--------+------------+------------+-------------+
8 rows in set (0.09 sec)
更复杂的查询,比如以下两个使用memoryusage
表的SELECT
语句,是可能的:
mysql> SELECT SUM(used) as 'Data Memory Used, All Nodes'
> FROM memoryusage
> WHERE memory_type = 'Data memory';
+-----------------------------+
| Data Memory Used, All Nodes |
+-----------------------------+
| 6460 |
+-----------------------------+
1 row in set (0.09 sec)
mysql> SELECT SUM(used) as 'Long Message Buffer, All Nodes'
> FROM memoryusage
> WHERE memory_type = 'Long message buffer';
+-------------------------------------+
| Long Message Buffer Used, All Nodes |
+-------------------------------------+
| 1179648 |
+-------------------------------------+
1 row in set (0.08 sec)
ndbinfo
表和列名区分大小写(ndbinfo
数据库本身的名称也是如此)。这些标识符是小写的。尝试使用错误的大小写会导致错误,如下例所示:
mysql> SELECT * FROM nodes;
+---------+--------+---------+-------------+-------------------+
| node_id | uptime | status | start_phase | config_generation |
+---------+--------+---------+-------------+-------------------+
| 5 | 17707 | STARTED | 0 | 1 |
| 6 | 17706 | STARTED | 0 | 1 |
| 7 | 17705 | STARTED | 0 | 1 |
| 8 | 17704 | STARTED | 0 | 1 |
+---------+--------+---------+-------------+-------------------+
4 rows in set (0.06 sec)
mysql> SELECT * FROM Nodes;
ERROR 1146 (42S02): Table 'ndbinfo.Nodes' doesn't exist
mysqldump 完全忽略 ndbinfo
数据库,并将其从任何输出中排除。即使使用 --databases
或 --all-databases
选项也是如此。
NDB Cluster 还在 INFORMATION_SCHEMA
信息数据库中维护表,包括包含有关用于 NDB Cluster 磁盘数据存储的文件的信息的FILES
表,以及显示事务、事务协调器和 NDB Cluster API 节点之间关系的ndb_transid_mysql_connection_map
表。有关更多信息,请参阅表的描述或第 25.6.17 节,“NDB Cluster 的 INFORMATION_SCHEMA 表”。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-arbitrator-validity-detail.html
25.6.16.1 ndbinfo arbitrator_validity_detail
表
arbitrator_validity_detail
表显示集群中每个数据节点对仲裁者的视图。它是membership
表的子集。
arbitrator_validity_detail
表包含以下列:
-
node_id
此节点的节点 ID
-
仲裁者
仲裁者的节点 ID
-
arb_ticket
用于跟踪仲裁的内部标识符
-
arb_connected
此节点是否连接到仲裁者;是
Yes
或No
中的一个 -
arb_state
仲裁状态
备注
节点 ID 与ndb_mgm -e "SHOW"报告的相同。
所有节点应该显示相同的仲裁者
和arb_ticket
值,以及相同的arb_state
值。可能的arb_state
值包括ARBIT_NULL
、ARBIT_INIT
、ARBIT_FIND
、ARBIT_PREP1
、ARBIT_PREP2
、ARBIT_START
、ARBIT_RUN
、ARBIT_CHOOSE
、ARBIT_CRASH
和UNKNOWN
。
arb_connected
显示当前节点是否连接到仲裁者
。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-arbitrator-validity-summary.html
25.6.16.2 ndbinfo 仲裁者有效性摘要表
arbitrator_validity_summary
表提供了关于集群数据节点的仲裁者的综合视图。
arbitrator_validity_summary
表包含以下列:
-
arbitrator
仲裁者的节点 ID
-
arb_ticket
用于跟踪仲裁的内部标识符
-
arb_connected
是否这个仲裁者连接到集群
-
consensus_count
视为仲裁者的数据节点数量;可能是
Yes
或No
备注
在正常操作中,这个表应该在相当长的时间内只有 1 行。如果在超过几分钟的时间内有多于 1 行,则可能是并非所有节点都连接到仲裁者,或者所有节点都连接了,但对同一个仲裁者意见不一致。
arbitrator
列显示仲裁者的节点 ID。
arb_ticket
是这个仲裁者使用的内部标识符。
arb_connected
显示这个节点是否作为仲裁者连接到集群。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-backup-id.html
25.6.16.3 ndbinfo backup_id
表
该表提供了一种查找最近为该集群启动的备份的 ID 的方法。
backup_id
表包含一个名为 id
的单列,该列对应使用 ndb_mgm 客户端执行 START BACKUP
命令进行的备份 ID。该表包含一行。
示例: 假设在 NDB 管理客户端中发出以下一系列 START BACKUP
命令,自集群首次启动以来没有进行其他备份:
ndb_mgm> START BACKUP
Waiting for completed, this may take several minutes
Node 5: Backup 1 started from node 50
Node 5: Backup 1 started from node 50 completed
StartGCP: 27894 StopGCP: 27897
#Records: 2057 #LogRecords: 0
Data: 51580 bytes Log: 0 bytes
ndb_mgm> START BACKUP 5
Waiting for completed, this may take several minutes
Node 5: Backup 5 started from node 50
Node 5: Backup 5 started from node 50 completed
StartGCP: 27905 StopGCP: 27908
#Records: 2057 #LogRecords: 0
Data: 51580 bytes Log: 0 bytes
ndb_mgm> START BACKUP
Waiting for completed, this may take several minutes
Node 5: Backup 6 started from node 50
Node 5: Backup 6 started from node 50 completed
StartGCP: 27912 StopGCP: 27915
#Records: 2057 #LogRecords: 0
Data: 51580 bytes Log: 0 bytes
ndb_mgm> START BACKUP 3
Connected to Management Server at: localhost:1186
Waiting for completed, this may take several minutes
Node 5: Backup 3 started from node 50
Node 5: Backup 3 started from node 50 completed
StartGCP: 28149 StopGCP: 28152
#Records: 2057 #LogRecords: 0
Data: 51580 bytes Log: 0 bytes
ndb_mgm>
之后,使用 mysql 客户端,backup_id
表包含如下所示的单行:
mysql> USE ndbinfo;
Database changed
mysql> SELECT * FROM backup_id;
+------+
| id |
+------+
| 3 |
+------+
1 row in set (0.00 sec)
如果找不到任何备份,则表中包含一个 id
值为 0
的单行。
backup_id
表在 NDB 8.0.24 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-blobs.html
25.6.16.4 ndbinfo blobs 表
此表提供了存储在NDB
中的 blob 值的信息。blobs
表包含以下列:
-
table_id
包含列的表的唯一 ID
-
database_name
此表所在的数据库的名称
-
table_name
表的名称
-
column_id
表内此列的唯一 ID
-
column_name
列的名称
-
inline_size
列的内联大小
-
part_size
列的部分大小
-
stripe_size
列的条带大小
-
blob_table_name
包含此列 blob 数据的 blob 表的名称(如果有)
此表中存在行,用于存储超过 255 字节的BLOB
、TEXT
值的NDB
表列,因此需要使用 blob 表。超过 4000 字节的JSON
值的部分也存储在此表中。有关 NDB 集群如何存储此类类型列的更多信息,请参阅字符串类型存储要求。
可以使用包含NDB
表列注释的CREATE TABLE
和ALTER TABLE
语句设置NDB
blob 列的部分和(NDB 8.0.30 及更高版本)内联大小(请参阅 NDB_COLUMN 选项);这也可以在 NDB API 应用程序中完成(请参阅Column::setPartSize()
和setInlineSize()
)。
blobs
表在 NDB 8.0.29 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-blocks.html
25.6.16.5 ndbinfo 表
blocks
表是一个静态表,仅包含所有 NDB 内核块的名称和内部 ID(参见 NDB 内核块)。它供其他ndbinfo
表(其中大部分实际上是视图)使用,以将块号映射到块名称,以生成人类可读的输出。
blocks
表包含以下列:
-
block_number
块号
-
block_name
块名称
笔记
要获取所有块名称的列表,只需执行SELECT block_name FROM ndbinfo.blocks
。尽管这是一个静态表,但其内容可能会因不同的 NDB Cluster 版本而有所不同。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cluster-locks.html
25.6.16.6 ndbinfo cluster_locks
表
cluster_locks
表提供有关 NDB 集群中NDB
表上持有和等待锁的当前锁请求的信息,并且旨在作为cluster_operations
的伴随表。从cluster_locks
表中获取的信息可能有助于调查停顿和死锁。
cluster_locks
表包含以下列:
-
node_id
报告节点的 ID
-
block_instance
报告 LDM 实例的 ID
-
tableid
包含此行的表的 ID
-
fragmentid
包含锁定行的片段的 ID
-
rowid
锁定行的 ID
-
transid
事务 ID
-
mode
锁请求模式
-
state
锁定状态
-
detail
是否是排队中第一个持有锁的
-
op
操作类型
-
duration_millis
等待或持有锁的毫秒数
-
lock_num
锁对象的 ID
-
waiting_for
等待具有此 ID 的锁
备注
表 ID(tableid
列)是内部分配的,与其他ndbinfo
表中使用的相同。它也显示在ndb_show_tables的输出中。
事务 ID(transid
列)是由 NDB API 为请求或持有当前锁的事务生成的标识符。
mode
列显示锁模式;始终是S
(表示共享锁)或X
(独占锁)。如果事务对给定行持有独占锁,则该行上的所有其他锁都具有相同的事务 ID。
state
列显示锁状态。其值始终是H
(持有)或W
(等待)。等待的锁请求等待由不同事务持有的锁。
当detail
列包含*
(星号字符)时,这意味着这个锁是受影响行锁队列中第一个持有的锁;否则,此列为空。此信息可用于帮助识别锁请求列表中的唯一条目。
op
列显示请求锁的操作类型。始终是READ
、INSERT
、UPDATE
、DELETE
、SCAN
或REFRESH
中的一个值。
duration_millis
列显示此锁请求等待或持有锁的毫秒数。当为等待请求授予锁时,此值将重置为 0。
锁 ID(lockid
列)对于此节点和块实例是唯一的。
锁定状态显示在lock_state
列中;如果是W
,则表示锁正在等待授予,而waiting_for
列显示此请求正在等待的锁对象的锁 ID。否则,waiting_for
列为空。waiting_for
只能指向同一行上的锁,由node_id
、block_instance
、tableid
、fragmentid
和rowid
标识。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cluster-operations.html
25.6.16.7 ndbinfo cluster_operations 表
cluster_operations
表提供了从本地数据管理(LQH)块的角度查看 NDB 集群中所有活动的每个操作(有状态的主键操作)视图(请参阅 DBLQH 块)。
cluster_operations
表包含以下列:
-
node_id
报告的 LQH 块的节点 ID
-
block_instance
LQH 块实例
-
transid
事务 ID
-
operation_type
操作类型(请参阅文本以获取可能的值)
-
state
操作状态(请参阅文本以获取可能的值)
-
tableid
表 ID
-
fragmentid
片段 ID
-
client_node_id
客户端节点 ID
-
client_block_ref
客户端块引用
-
tc_node_id
事务协调器节点 ID
-
tc_block_no
事务协调器块编号
-
tc_block_instance
事务协调器块实例
注释
事务 ID 是一个唯一的 64 位数字,可以使用 NDB API 的getTransactionId()
方法获取。(目前,MySQL 服务器不公开正在进行的事务的 NDB API 事务 ID。)
operation_type
列可以采用以下任一值:READ
、READ-SH
、READ-EX
、INSERT
、UPDATE
、DELETE
、WRITE
、UNLOCK
、REFRESH
、SCAN
、SCAN-SH
、SCAN-EX
或<unknown>
。
state
列可以具有以下任一值之一:ABORT_QUEUED
、ABORT_STOPPED
、COMMITTED
、COMMIT_QUEUED
、COMMIT_STOPPED
、COPY_CLOSE_STOPPED
、COPY_FIRST_STOPPED
、COPY_STOPPED
、COPY_TUPKEY
、IDLE
、LOG_ABORT_QUEUED
、LOG_COMMIT_QUEUED
、LOG_COMMIT_QUEUED_WAIT_SIGNAL
、LOG_COMMIT_WRITTEN
、LOG_COMMIT_WRITTEN_WAIT_SIGNAL
、LOG_QUEUED
、PREPARED
、PREPARED_RECEIVED_COMMIT
、SCAN_CHECK_STOPPED
、SCAN_CLOSE_STOPPED
、SCAN_FIRST_STOPPED
、SCAN_RELEASE_STOPPED
、SCAN_STATE_USED
、SCAN_STOPPED
、SCAN_TUPKEY
、STOPPED
、TC_NOT_CONNECTED
、WAIT_ACC
、WAIT_ACC_ABORT
、WAIT_AI_AFTER_ABORT
、WAIT_ATTR
、WAIT_SCAN_AI
、WAIT_TUP
、WAIT_TUPKEYINFO
、WAIT_TUP_COMMIT
或WAIT_TUP_TO_ABORT
。(如果 MySQL 服务器使用ndbinfo_show_hidden
启用运行,则可以通过从通常隐藏的ndb$dblqh_tcconnect_state
表中选择来查看此状态列表。)
您可以通过检查ndb_show_tables的输出来从其表 ID 获取NDB
表的名称。
fragid
与ndb_desc --extra-partition-info
(简写为-p
)输出中看到的分区号相同。
在client_node_id
和client_block_ref
中,client
指的是 NDB 集群 API 或 SQL 节点(即,NDB API 客户端或连接到集群的 MySQL 服务器)。
block_instance
和tc_block_instance
列分别提供DBLQH
和DBTC
块实例编号。您可以将这些与块名称一起使用,从threadblocks
表中获取有关特定线程的信息。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cluster-transactions.html
25.6.16.8 ndbinfo cluster_transactions 表
cluster_transactions
表显示了 NDB 集群中所有正在进行的事务的信息。
cluster_transactions
表包含以下列:
-
node_id
事务协调器的节��ID
-
block_instance
TC 块实例
-
transid
事务 ID
-
state
操作状态(请参阅文本以获取可能的值)
-
count_operations
事务中有状态的主键操作数(包括带锁的读取以及 DML 操作)
-
outstanding_operations
仍在本地数据管理块中执行的操作
-
inactive_seconds
等待 API 的时间
-
client_node_id
客户端节点 ID
-
client_block_ref
客户端块引用
注意
事务 ID 是一个唯一的 64 位数字,可以使用 NDB API 的getTransactionId()
方法获取。 (目前,MySQL 服务器不会公开正在进行的事务的 NDB API 事务 ID。)
block_instance
指的是内核块的一个实例。与块名称一起,这个数字可以用来在threadblocks
表中查找给定实例。
state
列可以有以下任一值:CS_ABORTING
、CS_COMMITTING
、CS_COMMIT_SENT
、CS_COMPLETE_SENT
、CS_COMPLETING
、CS_CONNECTED
、CS_DISCONNECTED
、CS_FAIL_ABORTED
、CS_FAIL_ABORTING
、CS_FAIL_COMMITTED
、CS_FAIL_COMMITTING
、CS_FAIL_COMPLETED
、CS_FAIL_PREPARED
、CS_PREPARE_TO_COMMIT
、CS_RECEIVING
、CS_REC_COMMITTING
、CS_RESTART
、CS_SEND_FIRE_TRIG_REQ
、CS_STARTED
、CS_START_COMMITTING
、CS_START_SCAN
、CS_WAIT_ABORT_CONF
、CS_WAIT_COMMIT_CONF
、CS_WAIT_COMPLETE_CONF
、CS_WAIT_FIRE_TRIG_REQ
。(如果 MySQL 服务器正在运行时启用了ndbinfo_show_hidden
,您可以通过从ndb$dbtc_apiconnect_state
表中选择来查看此状态列表,该表通常是隐藏的。)
在client_node_id
和client_block_ref
中,client
指的是 NDB 集群 API 或 SQL 节点(即,连接到集群的 NDB API 客户端或 MySQL 服务器)。
tc_block_instance
列提供了DBTC
块实例号。您可以将此与块名称一起使用,从threadblocks
表中获取有关特定线程的信息。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-config-nodes.html
25.6.16.9 ndbinfo config_nodes 表
config_nodes
表显示在 NDB 集群 config.ini
文件中配置的节点。对于每个节点,表显示包含节点 ID、节点类型(管理节点、数据节点或 API 节点)以及配置为运行的主机的名称或 IP 地址的行。
此表不显示给定节点是否实际运行,或者当前是否连接到集群。有关连接到 NDB 集群的节点的信息可以从 nodes
和 processes
表中获取。
config_nodes
表包含以下列:
-
node_id
节点的 ID
-
node_type
节点的类型
-
node_hostname
节点所在主机的名称或 IP 地址
注意
node_id
列显示在 config.ini
文件中用于此节点的节点 ID;如果未指定任何节点 ID,则显示将自动分配给此节点的节点 ID。
node_type
列显示以下三个值之一:
-
MGM
: 管理节点。 -
NDB
: 数据节点。 -
API
: API 节点;包括 SQL 节点。
node_hostname
列显示在 config.ini
文件中指定的节点主机。对于 API 节点,如果在集群配置文件中未设置 HostName
,则此处可能为空。如果在配置文件中未为数据节点设置 HostName
,则此处使用 localhost
。如果未为管理节点指定 HostName
,则也使用 localhost
。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-config-params.html
25.6.16.10 ndbinfo config_params 表
config_params
表是一个静态表,提供了 NDB Cluster 配置参数的名称、内部 ID 号以及其他信息。该表还可与config_values
表一起使用,以获取有关节点配置参数的实时信息。
config_params
表包含以下列:
-
param_number
参数的内部 ID 号
-
param_name
参数的名称
-
param_description
参数的简要描述
-
param_type
参数的数据类型
-
param_default
参数的默认值(如果有的话)
-
param_min
参数的最大值(如果有的话)
-
param_max
参数的最小值(如果有的话)
-
param_mandatory
如果参数是必需的,则为 1,否则为 0
-
param_status
目前未使用
注意事项
该表是只读的。
尽管这是一个静态表,但其内容可能因 NDB Cluster 安装而异,因为受支持的参数可能因软件版本、集群硬件配置和其他因素的差异而变化。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-config-values.html
25.6.16.11 ndbinfo config_values 表
config_values
表提供有关节点配置参数值的当前状态的信息。表中的每一行对应于给定节点上参数的当前值。
config_values
表包含以下列:
-
node_id
集群中节点的 ID
-
config_param
参数的内部 ID 编号
-
config_value
参数的当前值
注意
此表的config_param
列和config_params
表的param_number
列使用相同的参数标识符。通过在这些列上连接两个表,您可以获取有关所需节点配置参数的详细信息。此处显示的查询提供了集群中每个数据节点的所有参数的当前值,按节点 ID 和参数名称排序:
SELECT v.node_id AS 'Node Id',
p.param_name AS 'Parameter',
v.config_value AS 'Value'
FROM config_values v
JOIN config_params p
ON v.config_param=p.param_number
WHERE p.param_name NOT LIKE '\_\_%'
ORDER BY v.node_id, p.param_name;
在用于简单测试的小型示例集群上运行上一个查询的部分输出:
+---------+------------------------------------------+----------------+
| Node Id | Parameter | Value |
+---------+------------------------------------------+----------------+
| 2 | Arbitration | 1 |
| 2 | ArbitrationTimeout | 7500 |
| 2 | BackupDataBufferSize | 16777216 |
| 2 | BackupDataDir | /home/jon/data |
| 2 | BackupDiskWriteSpeedPct | 50 |
| 2 | BackupLogBufferSize | 16777216 |
...
| 3 | TotalSendBufferMemory | 0 |
| 3 | TransactionBufferMemory | 1048576 |
| 3 | TransactionDeadlockDetectionTimeout | 1200 |
| 3 | TransactionInactiveTimeout | 4294967039 |
| 3 | TwoPassInitialNodeRestartCopy | 0 |
| 3 | UndoDataBuffer | 16777216 |
| 3 | UndoIndexBuffer | 2097152 |
+---------+------------------------------------------+----------------+
248 rows in set (0.02 sec)
WHERE
子句过滤掉以双下划线(__
)开头的参数;这些参数是为 NDB 开发人员的测试和其他内部用途保留的,并不打算在生产 NDB 集群中使用。
通过发出适当的查询,您可以获得更具体、更详细或两者兼具的输出。此示例提供了有关集群中所有数据节点当前设置的NodeId
、NoOfReplicas
、HostName
、DataMemory
、IndexMemory
和TotalSendBufferMemory
参数的所有类型的可用信息:
SELECT p.param_name AS Name,
v.node_id AS Node,
p.param_type AS Type,
p.param_default AS 'Default',
p.param_min AS Minimum,
p.param_max AS Maximum,
CASE p.param_mandatory WHEN 1 THEN 'Y' ELSE 'N' END AS 'Required',
v.config_value AS Current
FROM config_params p
JOIN config_values v
ON p.param_number = v.config_param
WHERE p. param_name
IN ('NodeId', 'NoOfReplicas', 'HostName',
'DataMemory', 'IndexMemory', 'TotalSendBufferMemory')\G
在用于简单测试的具有 2 个数据节点的小型 NDB 集群上运行此查询的输出如下所示:
*************************** 1\. row ***************************
Name: NodeId
Node: 2
Type: unsigned
Default:
Minimum: 1
Maximum: 144
Required: Y
Current: 2
*************************** 2\. row ***************************
Name: HostName
Node: 2
Type: string
Default: localhost
Minimum:
Maximum:
Required: N
Current: 127.0.0.1
*************************** 3\. row ***************************
Name: TotalSendBufferMemory
Node: 2
Type: unsigned
Default: 0
Minimum: 262144
Maximum: 4294967039
Required: N
Current: 0
*************************** 4\. row ***************************
Name: NoOfReplicas
Node: 2
Type: unsigned
Default: 2
Minimum: 1
Maximum: 4
Required: N
Current: 2
*************************** 5\. row ***************************
Name: DataMemory
Node: 2
Type: unsigned
Default: 102760448
Minimum: 1048576
Maximum: 1099511627776
Required: N
Current: 524288000
*************************** 6\. row ***************************
Name: NodeId
Node: 3
Type: unsigned
Default:
Minimum: 1
Maximum: 144
Required: Y
Current: 3
*************************** 7\. row ***************************
Name: HostName
Node: 3
Type: string
Default: localhost
Minimum:
Maximum:
Required: N
Current: 127.0.0.1
*************************** 8\. row ***************************
Name: TotalSendBufferMemory
Node: 3
Type: unsigned
Default: 0
Minimum: 262144
Maximum: 4294967039
Required: N
Current: 0
*************************** 9\. row ***************************
Name: NoOfReplicas
Node: 3
Type: unsigned
Default: 2
Minimum: 1
Maximum: 4
Required: N
Current: 2
*************************** 10\. row ***************************
Name: DataMemory
Node: 3
Type: unsigned
Default: 102760448
Minimum: 1048576
Maximum: 1099511627776
Required: N
Current: 524288000 10 rows in set (0.01 sec)
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-counters.html
25.6.16.12 ndbinfo 计数器表
counters
表提供了特定内核块和数据节点的事件(如读取和写入)的累计总数。计数从最近的节点启动或重新启动开始保持;节点的启动或重新启动会重置该节点上的所有计数器。并非所有内核块都具有所有类型的计数器。
counters
表包含以下列:
-
node_id
数据节点 ID
-
block_name
关联的 NDB 内核块的名称(请参阅 NDB 内核块)。
-
block_instance
区块实例
-
counter_id
计数器的内部 ID 号码;通常为 1 到 10 之间的整数。
-
counter_name
计数器的名称。请参阅各个计数器的名称和每个计数器关联的 NDB 内核块的文本。
-
val
计数器的值
注意事项
每个计数器都与特定的 NDB 内核块相关联。
OPERATIONS
计数器与DBLQH
(本地查询处理程序)内核块相关联。主键读取计为一个操作,主键更新也是如此。对于读取,每个DBTC
中的操作在DBLQH
中有一个操作。对于写入,每个分片副本计为一个操作。
ATTRINFO
、TRANSACTIONS
、COMMITS
、READS
、LOCAL_READS
、SIMPLE_READS
、WRITES
、LOCAL_WRITES
、ABORTS
、TABLE_SCANS
和RANGE_SCANS
计数器与DBTC
(事务协调器)内核块相关联。
LOCAL_WRITES
和LOCAL_READS
是在一个节点中使用事务协调器的主键操作,该节点还持有记录的主分片副本。
READS
计数器包括所有读取。LOCAL_READS
仅包括与此事务协调器相同节点上的主分片副本的读取。SIMPLE_READS
仅包括那些读取,其中读取操作是给定事务的开始和结束操作。简单读取不持有锁,但是作为事务的一部分,它们观察由包含它们的事务进行的未提交更改,而不是任何其他未提交事务。从 TC 块的角度来看,这样的读取是“简单的”;由于它们不持有锁,它们不是持久的,一旦DBTC
将它们路由到相关的 LQH 块后,它不为它们保留状态。
ATTRINFO
记录将解释程序发送到数据节点的次数。有关NDB
内核中ATTRINFO
消息的更多信息,请参阅 NDB 协议消息。
LOCAL_TABLE_SCANS_SENT
、READS_RECEIVED
、PRUNED_RANGE_SCANS_RECEIVED
、RANGE_SCANS_RECEIVED
、LOCAL_READS_SENT
、CONST_PRUNED_RANGE_SCANS_RECEIVED
、LOCAL_RANGE_SCANS_SENT
、REMOTE_READS_SENT
、REMOTE_RANGE_SCANS_SENT
、READS_NOT_FOUND
、SCAN_BATCHES_RETURNED
、TABLE_SCANS_RECEIVED
和 SCAN_ROWS_RETURNED
计数器与DBSPJ
(选择推送连接)内核块相关联。
block_name
和 block_instance
列分别提供适用的 NDB 内核块名称和实例编号。您可以使用这些信息从threadblocks
表中获取有关特定线程的信息。
一些计数器提供了有关传输器过载和发送缓冲区大小的信息,用于排除此类问题。对于每个 LQH 实例,在以下列表中的每个计数器中都有一个实例:
-
LQHKEY_OVERLOAD
: 由于传输器过载而导致 LQH 块实例拒绝主键请求的次数。 -
LQHKEY_OVERLOAD_TC
: 计算 TC 节点传输器过载的实例数。 -
LQHKEY_OVERLOAD_READER
: 计算出现 API 读取节点(仅读取)过载的LQHKEY_OVERLOAD
实例数。 -
LQHKEY_OVERLOAD_NODE_PEER
: 计算下一个备份数据节点(仅写入)过载的LQHKEY_OVERLOAD
实例数。 -
LQHKEY_OVERLOAD_SUBSCRIBER
: 计算出现事件订阅者(仅写入)过载的LQHKEY_OVERLOAD
实例数。 -
LQHSCAN_SLOWDOWNS
: 计算由于扫描 API 传输器过载而导致片段扫描批量大小减少的实例数。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cpudata.html
25.6.16.13 ndbinfo cpudata 表
cpudata
表提供了最近一秒钟的 CPU 使用情况数据。
cpustat
表包含以下列:
-
node_id
节点 ID
-
cpu_no
CPU ID
-
cpu_online
如果 CPU 当前在线,则为 1,否则为 0
-
cpu_userspace_time
CPU 花费在用户空间的时间
-
cpu_idle_time
CPU 空闲时间
-
cpu_system_time
CPU 花费在系统时间的时间
-
cpu_interrupt_time
CPU 花费在处理中断(硬件和软件)的时间
-
cpu_exec_vm_time
CPU 花费在虚拟机执行的时间
注意事项
cpudata
表仅在 Linux 和 Solaris 操作系统上可用。
该表在 NDB 8.0.23 版本中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cpudata-1sec.html
25.6.16.14 ndbinfo cpudata_1sec 表
cpudata_1sec
表提供了过去 20 秒内每秒的 CPU 使用情况数据。
cpustat
表包含以下列:
-
node_id
节点 ID
-
measurement_id
测量序列 ID;后续测量具有较低的 ID
-
cpu_no
CPU ID
-
cpu_online
如果 CPU 当前在线,则为 1,否则为 0
-
cpu_userspace_time
在用户空间中花费的 CPU 时间
-
cpu_idle_time
空闲时花费的 CPU 时间
-
cpu_system_time
在系统时间中花费的 CPU 时间
-
cpu_interrupt_time
处理中断(硬件和软件)所花费的 CPU 时间
-
cpu_exec_vm_time
在虚拟机执行中花费的 CPU 时间
-
elapsed_time
用于此测量的微秒时间
注意事项
cpudata_1sec
表仅在 Linux 和 Solaris 操作系统上可用。
该表在 NDB 8.0.23 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cpudata-20sec.html
25.6.16.15 ndbinfo cpudata_20sec 表
cpudata_20sec
表提供了过去 400 秒内每 20 秒间隔的 CPU 使用情况数据。
cpustat
表包含以下列:
-
node_id
节点 ID
-
measurement_id
测量序列 ID;后续测量具有较低的 ID
-
cpu_no
CPU ID
-
cpu_online
如果 CPU 当前在线,则为 1,否则为 0
-
cpu_userspace_time
CPU 在用户空间中花费的时间
-
cpu_idle_time
CPU 空闲时间
-
cpu_system_time
CPU 在系统时间中花费的时间
-
cpu_interrupt_time
CPU 处理中断(硬件和软件)所花费的时间
-
cpu_exec_vm_time
CPU 在虚拟机执行中花费的时间
-
elapsed_time
用于此测量的微秒时间
注意
cpudata_20sec
表仅适用于 Linux 和 Solaris 操作系统。
此表在 NDB 8.0.23 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cpudata-50ms.html
25.6.16.16 ndbinfo cpudata_50ms 表
cpudata_50ms
表提供了关于过去一秒钟内每 50 毫秒间隔的 CPU 使用情况的数据。
cpustat
表包含以下列:
-
node_id
节点 ID
-
measurement_id
测量序列 ID;后续测量具有较低的 ID
-
cpu_no
CPU ID
-
cpu_online
如果 CPU 当前在线,则为 1,否则为 0
-
cpu_userspace_time
CPU 时间花费在用户空间上
-
cpu_idle_time
CPU 空闲时间
-
cpu_system_time
CPU 时间花费在系统时间上
-
cpu_interrupt_time
CPU 时间花费在处理中断(硬件和软件)上
-
cpu_exec_vm_time
CPU 时间花费在虚拟机执行上
-
elapsed_time
用于此测量的微秒时间
注释
cpudata_50ms
表仅在 Linux 和 Solaris 操作系统上可用。
这个表是在 NDB 8.0.23 中添加的。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cpuinfo.html
25.6.16.17 ndbinfo
cpuinfo
表
cpuinfo
表提供了关于给定数据节点执行的 CPU 的信息。
cpuinfo
表包含以下列:
-
node_id
节点 ID
-
cpu_no
CPU ID
-
cpu_online
如果 CPU 在线,则为 1,否则为 0
-
core_id
CPU 核心 ID
-
socket_id
CPU 插槽 ID
注意事项
cpuinfo
表在所有由NDB
支持的操作系统上都可用,除了 MacOS 和 FreeBSD。
该表在 NDB 8.0.23 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cpustat.html
25.6.16.18 ndbinfo cpustat 表
cpustat
表每秒提供每个线程在NDB
内核中运行的每个线程的 CPU 统计信息。
cpustat
表包含以下列:
-
node_id
线程所在节点的 ID
-
thr_no
线程 ID(特定于此节点)
-
OS_user
操作系统用户时间
-
OS_system
操作系统系统时间
-
OS_idle
操作系统空闲时间
-
thread_exec
线程执行时间
-
thread_sleeping
线程睡眠时间
-
thread_spinning
线程旋转时间
-
thread_send
线程发送时间
-
thread_buffer_full
线程缓冲区满时间
-
elapsed_time
经过的时间
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cpustat-50ms.html
25.6.16.19 The ndbinfo cpustat_50ms Table
cpustat_50ms
表提供了每个运行在 NDB
内核中的线程每 50 毫秒获取的原始、每线程的 CPU 数据。
类似于cpustat_1sec
和cpustat_20sec
,该表显示每个线程的 20 个测量集,每个集合引用一个命名持续时间的周期。因此,cpsustat_50ms
提供了 1 秒的历史记录。
cpustat_50ms
表包含以下列:
-
node_id
线程所在节点的 ID
-
thr_no
线程 ID(特定于此节点)
-
OS_user_time
操作系统用户时间
-
OS_system_time
操作系统空闲时间
-
OS_idle_time
操作系统空闲时间
-
exec_time
线程执行时间
-
sleep_time
线程睡眠时间
-
spin_time
线程自旋时间
-
send_time
线程发送时间
-
buffer_full_time
线程缓冲区满时间
-
elapsed_time
经过的时间
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cpustat-1sec.html
25.6.16.20 cpustat_1sec
表
cpustat-1sec
表提供每秒为 NDB
内核中运行的每个线程获取的原始的每线程 CPU 数据。
与cpustat_50ms
和cpustat_20sec
类似,该表每个线程显示 20 个测量集,每个集合引用一个指定持续时间的周期。因此,cpsustat_1sec
提供了 20 秒的历史记录。
cpustat_1sec
表包含以下列:
-
node_id
线程所在节点的 ID
-
thr_no
线程 ID(特定于此节点)
-
OS_user_time
操作系统用户时间
-
OS_system_time
操作系统系统时间
-
OS_idle_time
操作系统空闲时间
-
exec_time
线程执行时间
-
sleep_time
线程休眠时间
-
spin_time
线程自旋时间
-
send_time
线程发送时间
-
buffer_full_time
线程缓冲区满时间
-
elapsed_time
经过时间
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cpustat-20sec.html
25.6.16.21 ndbinfo cpustat_20sec
表
cpustat_20sec
表提供每 20 秒获取一次的原始、每个运行在 NDB
内核中的线程的 CPU 数据。
像cpustat_50ms
和cpustat_1sec
一样,此表显示每个线程的 20 个测量集,每个集合引用命名持续时间的一个时期。因此,cpsustat_20sec
提供了 400 秒的历史记录。
cpustat_20sec
表包含以下列:
-
node_id
线程所在节点的 ID
-
thr_no
线程 ID(特定于此节点)
-
OS_user_time
操作系统用户时间
-
OS_system_time
操作系统系统时间
-
OS_idle_time
操作系统空闲时间
-
exec_time
线程执行时间
-
sleep_time
线程睡眠时间
-
spin_time
线程旋转时间
-
send_time
线程发送时间
-
buffer_full_time
线程缓冲区满时间
-
elapsed_time
经过时间
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-dictionary-columns.html
25.6.16.22 ndbinfo
字典列表
该表提供有关NDB
表列的NDB
字典信息。dictionary_columns
列在此处列出(带有简要描述):
-
table_id
包含列的表的 ID
-
column_id
列的唯一 ID
-
name
列名
-
column_type
来自 NDB API 的列的数据类型;请参阅 Column::Type,了解可能的值
-
default_value
列的默认值,如果有的话
-
nullable
NULL
或NOT NULL
中的任一值 -
array_type
列的内部属性存储格式;其中之一为
FIXED
、SHORT_VAR
或MEDIUM_VAR
;有关更多信息,请参阅 NDB API 文档中的Column::ArrayType
-
storage_type
表使用的存储类型;
MEMORY
或DISK
中的任一值 -
primary_key
如果这是一个主键列,则为
1
,否则为0
-
partition_key
如果这是一个分区键列,则为
1
,否则为0
-
dynamic
如果列是动态的,则为
1
,否则为0
-
auto_inc
如果这是一个
AUTO_INCREMENT
列,则为1
,否则为0
通过将dictionary_columns
与dictionary_tables
表连接,您可以获取给定表中所有列的信息,就像这样:
SELECT dc.*
FROM dictionary_columns dc
JOIN dictionary_tables dt
ON dc.table_id=dt.table_id
WHERE dt.table_name='t1'
AND dt.database_name='mydb';
dictionary_columns
表在 NDB 8.0.29 中添加。
注意
Blob 列不会显示在此表中。这是一个已知问题。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-dictionary-tables.html
25.6.16.23 ndbinfo dictionary_tables 表
此表为NDB
表提供NDB
字典信息。dictionary_tables
包含以下列:
-
table_id
表的唯一 ID
-
database_name
包含表的数据库的名称
-
table_name
表的名称
-
status
表状态;其中之一为
New
、Changed
、Retrieved
、Invalid
或Altered
。(有关对象状态值的更多信息,请参阅 Object::Status。) -
attributes
表属性数
-
primary_key_cols
表主键中的列数
-
primary_key
表主键中列的逗号分隔列表
-
storage
表使用的存储类型;其中之一为
memory
、disk
或default
-
logging
是否为此表启用了日志记录
-
dynamic
如果表是动态的,则为
1
;否则为0
;如果*
table*->``getForceVarPart()
为真,或者至少一个表列是动态的,则表被视为动态的 -
read_backup
如果从任何副本读取(为此表启用了
READ_BACKUP
选项,则为1
,否则为0
;请参阅 Section 15.1.20.12, “Setting NDB Comment Options”) -
fully_replicated
如果为此表启用了
FULLY_REPLICATED
(集群中的每个数据节点都有表的完整副本),则为1
;否则为0
;请参阅 Section 15.1.20.12, “Setting NDB Comment Options” -
checksum
如果此表使用校验和,则此列中的值为
1
;否则为0
-
row_size
可以存储在一行中的数据量(以字节为单位),不包括单独存���在 blob 表中的任何 blob 数据;请参阅 Table::getRowSizeInBytes(),API 文档中获取更多信息
-
min_rows
用于计算分区的最小行数;请参阅 Table::getMinRows(),API 文档中获取更多信息
-
max_rows
用于计算分区的最大行数;请参阅 Table::getMaxRows(),API 文档中获取更多信息
-
tablespace
表所属的表空间的 ID,如果表不使用磁盘上的数据,则为
0
-
fragment_type
表的片段类型;其中之一为
Single
、AllSmall
、AllMedium
、AllLarge
、DistrKeyHash
、DistrKeyLin
、UserDefined
、unused
或HashMapPartition
;有关更多信息,请参阅 Object::FragmentType,NDB API 文档中 -
hash_map
表使用的哈希映射
-
fragments
表片段数
-
partitions
表使用的分区数
-
partition_balance
使用的分区平衡类型,如果有的话;可以是
FOR_RP_BY_NODE
、FOR_RA_BY_NODE
、FOR_RP_BY_LDM
、FOR_RA_BY_LDM
、FOR_RA_BY_LDM_X_2
、FOR_RA_BY_LDM_X_3
或FOR_RA_BY_LDM_X_4
中的一个;参见第 15.1.20.12 节,“设置 NDB 注释选项” -
contains_GCI
如果表包含全局检查点索引,则为
1
,否则为0
-
single_user_mode
单用户模式生效时允许对表的访问类型;可以是
locked
、read_only
或read_write
中的一个;这些等同于 NDB API 中的Table::SingleUserMode
类型的SingleUserModeLocked
、SingleUserModeReadOnly
和SingleUserModeReadWrite
值 -
force_var_part
如果
*
table*->``getForceVarPart()
对于此表为真,则为1
,否则为0
-
GCI_bits
用于测试
-
author_bits
用于测试
dictionary_tables
表在 NDB 8.0.29 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-dict-obj-info.html
25.6.16.24 The ndbinfo dict_obj_info Table
dict_obj_info
表提供有关 NDB
数据字典(DICT
)对象(如表和索引)的信息。 (可以查询 dict_obj_types
表以获取所有类型的列表。)此信息包括对象的类型、状态、父对象(如果有)和完全限定名称。
dict_obj_info
表包含以下列:
-
type
DICT
对象类型;与dict_obj_types
连接以获取名称 -
id
对象标识符;对于磁盘数据撤销日志文件和数据文件,这与信息模式
FILES
表中的LOGFILE_GROUP_NUMBER
列显示的值相同;对于撤销日志文件,它也与ndbinfo
logbuffers
和logspaces
表中的log_id
列显示的值相同 -
version
对象版本
-
state
对象状态;参见 Object::State 获取值和描述。
-
parent_obj_type
父对象的类型(
dict_obj_types
类型 ID);0 表示对象没有父对象 -
parent_obj_id
父对象 ID(如基表);0 表示对象没有父对象
-
fq_name
完全限定对象名称;对于表,格式为
*
database_name*/def/*
table_name*
,对于主键,格式为sys/def/*
table_id*/PRIMARY
,对于唯一键,格式为sys/def/*
table_id*/*
uk_name*$unique
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-dict-obj-tree.html
25.6.16.25 The ndbinfo dict_obj_tree Table
dict_obj_tree
表提供了来自dict_obj_info
表的基于树的表信息视图。这主要用于测试,但在可视化NDB
数据库对象的层次结构方面也很有用。
dict_obj_tree
表包含以下列:
-
type
DICT
对象的类型;连接dict_obj_types
以获取对象类型的名称 -
id
对象标识符;与
dict_obj_info
表中的id
列相同对于磁盘数据撤销日志文件和数据文件,这与信息模式
FILES
表中的LOGFILE_GROUP_NUMBER
列中显示的值相同;对于撤销日志文件,这也与 ndbinfologbuffers
和logspaces
表中log_id
列显示的值相同 -
name
对象的完全限定名称;与
dict_obj_info
表中的fq_name
列相同对于表,其形式为
*
database_name*/def/*
table_name*
(与其parent_name
相同);对于任何类型的索引,形式为
NDB$INDEX_index_id
_CUSTOM` -
parent_type
此对象父对象的
DICT
对象类型;连接dict_obj_types
以获取对象类型的名称 -
parent_id
此对象父对象的标识符;与
dict_obj_info
表的id
列相同 -
parent_name
此对象父对象的完全限定名称;与
dict_obj_info
表的fq_name
列相同对于表,其形式为
*
database_name*/def/*
table_name*
。对于索引,名称为sys/def/*
table_id*/*
index_name*
。对于主键,为sys/def/*
table_id*/PRIMARY
,对于唯一键,为sys/def/*
table_id*/*
uk_name*$unique
-
root_type
根对象的
DICT
对象类型;连接dict_obj_types
以获取对象类型的名称 -
root_id
根对象的标识符;与
dict_obj_info
表的id
列相同 -
root_name
根对象的完全限定名称;与
dict_obj_info
表的fq_name
列相同 -
level
层次结构中对象的级别
-
path
NDB
对象层次结构中对象的完整路径;对象之间用右箭头(表示为->
)分隔,从左侧的根对象开始 -
indented_name
带有右箭头(表示为
->
)前缀的name
,前面有一些空格,这些空格对应于层次结构中对象的深度
path
列对于在单行中获取给定NDB
数据库对象的完整路径非常有用,而indented_name
列可用于获取所需对象的完整层次结构信息的类似树状布局。
示例:假设存在一个名为test
的数据库,并且在此数据库中不存在名为t1
的现有表,请执行以下 SQL 语句:
CREATE TABLE test.t1 (
a INT PRIMARY KEY,
b INT,
UNIQUE KEY(b)
) ENGINE = NDB;
您可以使用此处显示的查询获取刚创建的表的路径:
mysql> SELECT path FROM ndbinfo.dict_obj_tree
-> WHERE name LIKE 'test%t1';
+-------------+
| path |
+-------------+
| test/def/t1 |
+-------------+
1 row in set (0.14 sec)
您可以使用表的路径作为查询中的根名称,查看此表的所有依赖对象的路径,类似于以下查询:
mysql> SELECT path FROM ndbinfo.dict_obj_tree
-> WHERE root_name = 'test/def/t1';
+----------------------------------------------------------+
| path |
+----------------------------------------------------------+
| test/def/t1 |
| test/def/t1 -> sys/def/13/b |
| test/def/t1 -> sys/def/13/b -> NDB$INDEX_15_CUSTOM |
| test/def/t1 -> sys/def/13/b$unique |
| test/def/t1 -> sys/def/13/b$unique -> NDB$INDEX_16_UI |
| test/def/t1 -> sys/def/13/PRIMARY |
| test/def/t1 -> sys/def/13/PRIMARY -> NDB$INDEX_14_CUSTOM |
+----------------------------------------------------------+
7 rows in set (0.16 sec)
要获取具有所有依赖对象的t1
表的分层视图,请执行类似于以下查询的查询,该查询选择具有test/def/t1
作为其根对象名称的每个对象的缩进名称:
mysql> SELECT indented_name FROM ndbinfo.dict_obj_tree
-> WHERE root_name = 'test/def/t1';
+----------------------------+
| indented_name |
+----------------------------+
| test/def/t1 |
| -> sys/def/13/b |
| -> NDB$INDEX_15_CUSTOM |
| -> sys/def/13/b$unique |
| -> NDB$INDEX_16_UI |
| -> sys/def/13/PRIMARY |
| -> NDB$INDEX_14_CUSTOM |
+----------------------------+
7 rows in set (0.15 sec)
在处理磁盘数据表时,请注意,在此上下文中,表空间或日志文件组被视为根对象。这意味着您必须知道与给定表相关联的任何表空间或日志文件组的名称,或者从SHOW CREATE TABLE
中获取此信息,然后查询INFORMATION_SCHEMA.FILES
或类似的方式,如下所示:
mysql> SHOW CREATE TABLE test.dt_1\G
*************************** 1\. row ***************************
Table: dt_1
Create Table: CREATE TABLE `dt_1` (
`member_id` int unsigned NOT NULL AUTO_INCREMENT,
`last_name` varchar(50) NOT NULL,
`first_name` varchar(50) NOT NULL,
`dob` date NOT NULL,
`joined` date NOT NULL,
PRIMARY KEY (`member_id`),
KEY `last_name` (`last_name`,`first_name`)
) /*!50100 TABLESPACE `ts_1` STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 1 row in set (0.00 sec)
mysql> SELECT DISTINCT TABLESPACE_NAME, LOGFILE_GROUP_NAME
-> FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='ts_1';
+-----------------+--------------------+
| TABLESPACE_NAME | LOGFILE_GROUP_NAME |
+-----------------+--------------------+
| ts_1 | lg_1 |
+-----------------+--------------------+
1 row in set (0.00 sec)
现在,您可以像这样获取有关表、表空间和日志文件组的分层信息:
mysql> SELECT indented_name FROM ndbinfo.dict_obj_tree
-> WHERE root_name = 'test/def/dt_1';
+----------------------------+
| indented_name |
+----------------------------+
| test/def/dt_1 |
| -> sys/def/23/last_name |
| -> NDB$INDEX_25_CUSTOM |
| -> sys/def/23/PRIMARY |
| -> NDB$INDEX_24_CUSTOM |
+----------------------------+
5 rows in set (0.15 sec)
mysql> SELECT indented_name FROM ndbinfo.dict_obj_tree
-> WHERE root_name = 'ts_1';
+-----------------+
| indented_name |
+-----------------+
| ts_1 |
| -> data_1.dat |
| -> data_2.dat |
+-----------------+
3 rows in set (0.17 sec)
mysql> SELECT indented_name FROM ndbinfo.dict_obj_tree
-> WHERE root_name LIKE 'lg_1';
+-----------------+
| indented_name |
+-----------------+
| lg_1 |
| -> undo_1.log |
| -> undo_2.log |
+-----------------+
3 rows in set (0.16 sec)
dict_obj_tree
表是在 NDB 8.0.24 中添加的。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-dict-obj-types.html
25.6.16.26 ndbinfo dict_obj_types 表
dict_obj_types
表是一个静态表,列出了 NDB 内核中使用的可能的字典对象类型。这些类型与 NDB API 中的 Object::Type
中定义的类型相同。
dict_obj_types
表包含以下列:
-
type_id
此类型的类型 ID
-
type_name
此类型的名称
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-disk-write-speed-base.html
25.6.16.27 ndbinfo disk_write_speed_base 表
disk_write_speed_base
表提供了有关 LCP、备份和恢复操作期间磁盘写入速度的基本信息。
disk_write_speed_base
表包含以下列:
-
node_id
此节点的节点 ID
-
thr_no
此 LDM 线程的线程 ID
-
millis_ago
自此报告期结束以来的毫秒数
-
millis_passed
在此报告期间经过的毫秒数
-
backup_lcp_bytes_written
在此期间由本地检查点和备份过程写入磁盘的字节数
-
redo_bytes_written
在此期间写入 REDO 日志的字节数
-
target_disk_write_speed
每个 LDM 线程的实际磁盘写入速度(基础数据)
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-disk-write-speed-aggregate.html
25.6.16.28 ndbinfo disk_write_speed_aggregate 表
disk_write_speed_aggregate
表提供了有关 LCP、备份和恢复操作期间磁盘写入速度的聚合信息。
disk_write_speed_aggregate
表包含以下列:
-
node_id
此节点的节点 ID
-
thr_no
此 LDM 线程的线程 ID
-
backup_lcp_speed_last_sec
备份和 LCP 进程上一秒写入磁盘的字节数
-
redo_speed_last_sec
上一秒写入 REDO 日志的字节数
-
backup_lcp_speed_last_10sec
备份和 LCP 进程每秒写入磁盘的字节数,过去 10 秒的平均值
-
redo_speed_last_10sec
每秒写入 REDO 日志的字节数,过去 10 秒的平均值
-
std_dev_backup_lcp_speed_last_10sec
备份和 LCP 进程每秒写入磁盘的字节数的标准偏差,过去 10 秒的平均值
-
std_dev_redo_speed_last_10sec
每秒写入 REDO 日志的字节数的标准偏差,过去 10 秒的平均值
-
backup_lcp_speed_last_60sec
备份和 LCP 进程每秒写入磁盘的字节数,过去 60 秒的平均值
-
redo_speed_last_60sec
每秒写入 REDO 日志的字节数,过去 10 秒的平均值
-
std_dev_backup_lcp_speed_last_60sec
备份和 LCP 进程每秒写入磁盘的字节数的标准偏差,过去 60 秒的平均值
-
std_dev_redo_speed_last_60sec
每秒写入 REDO 日志的字节数的标准偏差,过去 60 秒的平均值
-
slowdowns_due_to_io_lag
自上次节点启动以来,由于 REDO 日志 I/O 延迟而导致磁盘写入减速的秒数
-
slowdowns_due_to_high_cpu
自上次节点启动以来,由于高 CPU 使用率而导致磁盘写入减速的秒数
-
disk_write_speed_set_to_min
自上次节点启动以来,磁盘写入速度被设置为最小的秒数
-
current_target_disk_write_speed
每个 LDM 线程的实际磁盘写入速度(聚合)
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-disk-write-speed-aggregate-node.html
25.6.16.29 ndbinfo disk_write_speed_aggregate_node 表
disk_write_speed_aggregate_node
表提供了有关在 LCP、备份和恢复操作期间磁盘写入速度的每个节点的汇总信息。
disk_write_speed_aggregate_node
表包含以下列:
-
node_id
此节点的节点 ID
-
backup_lcp_speed_last_sec
上一秒由备份和 LCP 进程写入磁盘的字节数
-
redo_speed_last_sec
上一秒写入重做日志的字节数
-
backup_lcp_speed_last_10sec
每秒由备份和 LCP 进程写入磁盘的字节数,平均值为过去 10 秒
-
redo_speed_last_10sec
每秒写入重做日志的字节数,平均值为过去 10 秒
-
backup_lcp_speed_last_60sec
每秒由备份和 LCP 进程写入磁盘的字节数,平均值为过去 60 秒
-
redo_speed_last_60sec
每秒写入重做日志的字节数,平均值为过去 60 秒
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-diskpagebuffer.html
25.6.16.30 ndbinfo diskpagebuffer 表
diskpagebuffer
表提供有关 NDB Cluster Disk Data 表使用的磁盘页面缓冲区的统计信息。
diskpagebuffer
表包含以下列:
-
node_id
数据节点 ID
-
block_instance
块实例
-
pages_written
写入磁盘的页面数量。
-
pages_written_lcp
本地检查点写入的页面数量。
-
pages_read
从磁盘读取的页面数量
-
log_waits
等待将页面写入磁盘的页面写入数量
-
page_requests_direct_return
请求页面在缓冲区中可用的请求数量
-
page_requests_wait_queue
等待页面在缓冲区中变为可用的请求数量
-
page_requests_wait_io
需要从磁盘上的页面读取的请求数量(页面在缓冲区中不可用)
注意
您可以将此表与 NDB Cluster Disk Data 表一起使用,以确定 DiskPageBufferMemory
是否足够大,以允许数据从缓冲区而不是磁盘读取;减少磁盘寻道可以帮助提高这些表的性能。
您可以使用类似以下查询来确定从 DiskPageBufferMemory
读取的比例占总读取次数的百分比,从而获得这个比率:
SELECT
node_id,
100 * page_requests_direct_return /
(page_requests_direct_return + page_requests_wait_io)
AS hit_ratio
FROM ndbinfo.diskpagebuffer;
此查询的结果应类似于此处显示的内容,每个数据节点在集群中占据一行(在此示例中,集群有 4 个数据节点):
+---------+-----------+
| node_id | hit_ratio |
+---------+-----------+
| 5 | 97.6744 |
| 6 | 97.6879 |
| 7 | 98.1776 |
| 8 | 98.1343 |
+---------+-----------+
4 rows in set (0.00 sec)
hit_ratio
值接近 100% 表明只有极少数读取是从磁盘而不是缓冲区进行的,这意味着磁盘数据读取性能接近最佳水平。如果其中任何值低于 95%,这是一个强烈的指示,需要在 config.ini
文件中增加 DiskPageBufferMemory
的设置。
注意
更改 DiskPageBufferMemory
需要在其生效之前对集群的所有数据节点进行滚动重启。
block_instance
指的是内核块的一个实例。与块名称一起,此数字可用于在 threadblocks
表中查找给定实例。使用这些信息,您可以获取与单个线程相关的磁盘页面缓冲区指标的信息;这里显示了一个使用 LIMIT 1
限制输出为单个线程的示例查询:
mysql> SELECT
> node_id, thr_no, block_name, thread_name, pages_written,
> pages_written_lcp, pages_read, log_waits,
> page_requests_direct_return, page_requests_wait_queue,
> page_requests_wait_io
> FROM ndbinfo.diskpagebuffer
> INNER JOIN ndbinfo.threadblocks USING (node_id, block_instance)
> INNER JOIN ndbinfo.threads USING (node_id, thr_no)
> WHERE block_name = 'PGMAN' LIMIT 1\G
*************************** 1\. row ***************************
node_id: 1
thr_no: 1
block_name: PGMAN
thread_name: rep
pages_written: 0
pages_written_lcp: 0
pages_read: 1
log_waits: 0
page_requests_direct_return: 4
page_requests_wait_queue: 0
page_requests_wait_io: 1 1 row in set (0.01 sec)
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-diskstat.html
25.6.16.31 ndbinfo diskstat 表
diskstat
表提供了关于过去 1 秒内对磁盘数据表空间的写入的信息。
diskstat
表包含以下列:
-
node_id
此节点的节点 ID
-
block_instance
报告
PGMAN
实例的 ID -
pages_made_dirty
过去一秒内使页面变脏的次数
-
reads_issued
过去一秒内发出的读取次数
-
reads_completed
过去一秒内完成的读取次数
-
writes_issued
过去一秒内发出的写入次数
-
writes_completed
过去一秒内完成的写入次数
-
log_writes_issued
过去一秒内页面写入需要进行日志写入的次数
-
log_writes_completed
过去一秒内完成的日志写入次数
-
get_page_calls_issued
过去一秒内发出的
get_page()
调用次数 -
get_page_reqs_issued
过去一秒内
get_page()
调用导致等待 I/O 或已经开始的 I/O 完成的次数 -
get_page_reqs_completed
过去一秒内等待 I/O 或 I/O 完成的
get_page()
调用次数
注意
此表中的每一行对应一个PGMAN
实例;每个 LDM 线程对应一个这样的实例,每个数据节点还有一个额外的实例。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-diskstats-1sec.html
25.6.16.32 ndbinfo diskstats_1sec 表
diskstats_1sec
表提供了过去 20 秒内对磁盘数据表空间的写入信息。
diskstat
表包含以下列:
-
node_id
此节点的节点 ID
-
block_instance
PGMAN
的报告实例 ID -
pages_made_dirty
指定的 1 秒间隔内使页面变脏的页数
-
reads_issued
指定的 1 秒间隔内发出的读取
-
reads_completed
指定的 1 秒间隔内完成的读取
-
writes_issued
指定的 1 秒间隔内发出的写入
-
writes_completed
指定的 1 秒间隔内完成的写入
-
log_writes_issued
指定的 1 秒间隔内,页面写入需要日志写入的次数
-
log_writes_completed
指定的 1 秒间隔内完成的日志写入次数
-
get_page_calls_issued
指定的 1 秒间隔内发出的
get_page()
调用次数 -
get_page_reqs_issued
get_page()
调用导致等待 I/O 或 I/O 已开始完成的次数,在指定的 1 秒间隔内 -
get_page_reqs_completed
等待 I/O 或 I/O 完成的
get_page()
调用次数,在指定的 1 秒间隔内已完成 -
seconds_ago
过去的时间间隔内的 1 秒间隔数,适用于此行
备注
此表中的每一行对应于PGMAN
的一个实例,在从 0 到 19 秒前的 1 秒间隔内发生;每个 LDM 线程有一个这样的实例,每个数据节点还有一个额外的实例。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-error-messages.html
25.6.16.33 ndbinfo error_messages 表
error_messages
表提供有关
error_messages
表包含以下列:
-
错误代码
数字错误代码
-
错误描述
错误描述
-
error_status
错误状态码
-
错误分类
错误分类代码
注意
error_code
是一个数字 NDB 错误代码。这是可以提供给 ndb_perror 的相同错误代码。
错误描述
提供导致错误的条件的基本描述。
error_status
列提供与错误相关的状态信息。此列的可能值在此处列出:
-
无错误
-
非法连接字符串
-
非法服务器句柄
-
服务器回复非法
-
节点数量非法
-
非法节点状态
-
内存不足
-
管理服务器未连接
-
无法连接到套接字
-
启动失败
-
停止失败
-
重新启动失败
-
无法启动备份
-
无法中止备份
-
无法进入单用户模式
-
无法退出单用户模式
-
无法完成配置更改
-
获取配置失败
-
使用错误
-
成功
-
永久错误
-
临时错误
-
未知结果
-
临时错误,重新启动节点
-
永久错误,需要外部操作
-
Ndbd 文件系统错误,重新启动节点初始
-
未知
error_classification 列显示错误分类。有关分类代码及其含义的信息,请参阅 NDB 错误分类。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-events.html
25.6.16.34 ndbinfo 事件表
此表提供有关NDB
中事件订阅的信息。events
表的列在此处列出,并附有每个列的简短描述:
-
event_id
事件 ID
-
name
事件的名称
-
table_id
事件发生的表的 ID
-
reporting
其中之一是
updated
、all
、subscribe
或DDL
-
columns
受事件影响的列的逗号分隔列表
-
table_event
一个或多个
INSERT
、DELETE
、UPDATE
、SCAN
、DROP
、ALTER
、CREATE
、GCP_COMPLETE
、CLUSTER_FAILURE
、STOP
、NODE_FAILURE
、SUBSCRIBE
、UNSUBSCRIBE
和ALL
(由 NDB API 中的Event::TableEvent
定义)
events
表是在 NDB 8.0.29 中添加的。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-files.html
25.6.16.35 ndbinfo 文件表
files
表提供了关于NDB
磁盘数据表使用的文件和其他对象的信息,并包含以下列:
-
id
对象 ID
-
type
对象的类型;可以是
Log file group
、Tablespace
、Undo file
或Data file
之一 -
name
对象的名称
-
parent
父对象的 ID
-
parent_name
父对象的名称
-
free_extents
空闲范围的数量
-
total_extents
总范围数
-
extent_size
范围大小(MB)
-
initial_size
初始大小(字节)
-
maximum_size
最大大小(字节)
-
autoextend_size
自动扩展大小(字节)
对于日志文件组和表空间,parent
始终为0
,而parent_name
、free_extents
、total_extents
、extent_size
、initial_size
、maximum_size
和autoentend_size
列都为NULL
。
如果在NDB
中没有创建磁盘数据对象,则files
表为空。有关更多信息,请参见第 25.6.11.1 节,“NDB Cluster Disk Data Objects”。
files
表是在 NDB 8.0.29 中添加的。
另请参阅第 28.3.15 节,“INFORMATION_SCHEMA FILES Table”。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-foreign-keys.html
25.6.16.36 ndbinfo foreign_keys 表
foreign_keys
表提供关于 NDB
表上的外键的信息。该表具有以下列:
-
object_id
外键的对象 ID
-
name
外键的名称
-
parent_table
外键的父表的名称
-
parent_columns
父列的逗号分隔列表
-
child_table
子表的名称
-
child_columns
子列的逗号分隔列表
-
parent_index
父索引的名称
-
child_index
子索引的名称
-
on_update_action
ON UPDATE
指定的外键操作;其中之一是No Action
、Restrict
、Cascade
、Set Null
或Set Default
-
on_delete_action
ON DELETE
指定的外键操作;其中之一是No Action
、Restrict
、Cascade
、Set Null
或Set Default
foreign_keys
表在 NDB 8.0.29 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-hash-maps.html
25.6.16.37 ndbinfo hash_maps 表
-
id
哈希映射的唯一 ID
-
version
哈希映射版本(整数)
-
state
哈希映射状态;参见 Object::State 获取数值和描述。
-
fq_name
哈希映射的完全限定名称
hash_maps
表实际上是一个视图,由四列组成,这四列与dict_obj_info
表的列名相同,如下所示:
CREATE VIEW hash_maps AS
SELECT id, version, state, fq_name
FROM dict_obj_info
WHERE type=24; # Hash map; defined in dict_obj_types
更多信息请参阅dict_obj_info
的描述。
hash_maps
表在 NDB 8.0.29 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-hwinfo.html
25.6.16.38 ndbinfo hwinfo 表
hwinfo
表提供了关于给定数据节点所在硬件的信息。
hwinfo
表包含以下列:
-
node_id
节点 ID
-
cpu_cnt_max
此主机上的处理器数量
-
cpu_cnt
此节点可用的处理器数量
-
num_cpu_cores
此主机上的 CPU 核心数
-
num_cpu_sockets
此主机上的 CPU 插槽数量
-
HW_memory_size
此主机上可用的内存量
-
model_name
CPU 型号名称
注意事项
hwinfo
表在所有由NDB
支持的操作系统上都可用。
此表在 NDB 8.0.23 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-index-columns.html
25.6.16.39 ndbinfo index_columns
表
该表提供关于NDB
表上的索引的信息。index_columns
表的列在此处列出,并附有简要描述:
-
table_id
NDB
表的唯一 ID,定义了该索引 -
包含此表的数据库的名称
varchar(64)
-
table_name
表的名称
-
index_object_id
此索引的对象 ID
-
index_name
索引的名称;如果索引没有命名,则使用索引中的第一列的名称。
-
index_type
索引类型;通常为 3(唯一哈希索引)或 6(有序索引);这些值与
dict_obj_types
表中的type_id
列中的值相同 -
status
其中之一是
new
、changed
、retrieved
、invalid
或altered
-
columns
由构成索引的列组成的逗号分隔列表
index_columns
表在 NDB 8.0.29 中添加。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-index-stats.html
25.6.16.40 ndbinfo index_stats
表
index_stats
表提供关于 NDB
索引统计的基本信息。
使用 ndb_index_stat 实用程序可以获得更完整的索引统计信息。
index_stats
表包含以下列:
-
index_id
索引 ID
-
index_version
索引版本
-
sample_version
样本版本
注意
该表在 NDB 8.0.28 版本中添加。
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-locks-per-fragment.html
25.6.16.41 The ndbinfo locks_per_fragment Table
locks_per_fragment
表提供了关于锁索赔请求计数以及这些请求的结果的信息,以每个片段为基础,作为 operations_per_fragment
和 memory_per_fragment
的伴随表。该表还显示了自片段或表创建以来成功和失败等待锁的总时间,或自最近一次重新启动以来的时间。
locks_per_fragment
表包含以下列:
-
fq_name
完全限定表名
-
parent_fq_name
父对象的完全限定名称
-
type
表类型;请参阅文本以获取可能的值
-
table_id
表 ID
-
node_id
报告节点 ID
-
block_instance
LDM 实例 ID
-
fragment_num
片段标识符
-
ex_req
排他锁请求已开始
-
ex_imm_ok
立即授予的排他锁请求
-
ex_wait_ok
等待后授予的排他锁请求
-
ex_wait_fail
未授予的排他锁请求
-
sh_req
已开始的共享锁请求
-
sh_imm_ok
立即授予的共享锁请求
-
sh_wait_ok
等待后授予的共享锁请求
-
sh_wait_fail
未授予共享锁请求
-
wait_ok_millis
等待授予的锁请求花费的时间,以毫秒为单位
-
wait_fail_millis
等待失败的锁请求花费的时间,以毫秒为单位
注意
block_instance
指的是内核块的一个实例。与块名���一起,此数字可用于在 threadblocks
表中查找给定实例。
fq_name
是以database
/schema
/name
格式表示的完全限定数据库对象名称,例如 test/def/t1
或 sys/def/10/b$unique
。
parent_fq_name
是此对象的父对象(表)的完全限定名称。
table_id
是由 NDB
生成的表的内部 ID。这是其他 ndbinfo
表中显示的相同内部表 ID;它也可在 ndb_show_tables 的输出中看到。
type
列显示表的类型。这始终是 System table
、User table
、Unique hash index
、Hash index
、Unique ordered index
、Ordered index
、Hash index trigger
、Subscription trigger
、Read only constraint
、Index trigger
、Reorganize trigger
、Tablespace
、Log file group
、Data file
、Undo file
、Hash map
、Foreign key definition
、Foreign key parent trigger
、Foreign key child trigger
或 Schema transaction
中的一个。
所有列ex_req
、ex_req_imm_ok
、ex_wait_ok
、ex_wait_fail
、sh_req
、sh_req_imm_ok
、sh_wait_ok
和sh_wait_fail
中显示的值代表自表或片段创建以来的累积请求次数,或自此节点上次重新启动以来的时间,以后者为准。对于wait_ok_millis
和wait_fail_millis
列中显示的时间值也是如此。
每个锁请求被认为是正在进行中,或以某种方式已经完成(即成功或失败)。这意味着以下关系是正确的:
ex_req >= (ex_req_imm_ok + ex_wait_ok + ex_wait_fail)
sh_req >= (sh_req_imm_ok + sh_wait_ok + sh_wait_fail)
当前正在进行的请求数量是当前未完成请求的数量,可以按照以下所示找到:
[exclusive lock requests in progress] =
ex_req - (ex_req_imm_ok + ex_wait_ok + ex_wait_fail)
[shared lock requests in progress] =
sh_req - (sh_req_imm_ok + sh_wait_ok + sh_wait_fail)
失败的等待表示一个中止的事务,但中止可能或可能不是由于锁等待超时引起的。您可以按照以下所示获取等待锁时中止的总数:
[aborts while waiting for locks] = ex_wait_fail + sh_wait_fail
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-logbuffers.html
25.6.16.42 ndbinfo
日志缓冲区表
logbuffer
表提供了关于 NDB 集群日志缓冲区使用情况的信息。
logbuffers
表包含以下列:
-
node_id
此数据节点的 ID。
-
log_type
日志类型。其中之一:
REDO
、DD-UNDO
、BACKUP-DATA
或BACKUP-LOG
。 -
log_id
日志 ID;对于磁盘数据撤销日志文件,这与信息模式
FILES
表中的LOGFILE_GROUP_NUMBER
列显示的值以及ndbinfo
logspaces
表的log_id
列显示的值相同 -
log_part
日志部分编号
-
total
此日志可用的总空间
-
used
此日志使用的空间
笔记
在执行 NDB 备份时,logbuffers
表行反映了另外两种日志类型。其中一行具有日志类型 BACKUP-DATA
,显示了在备份期间用于将片段复制到备份文件的数据缓冲区的使用量。另一行具有日志类型 BACKUP-LOG
,显示了在备份开始后记录所做更改时备份期间使用的日志缓冲区的使用量。在集群中的每个数据节点的 logbuffers
表中分别显示了这些 log_type
行。除非当前正在执行 NDB 备份,否则这些行不会出现。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-logspaces.html
25.6.16.43 ndbinfo
日志空间表
该表提供了关于 NDB 集群日志空间使用情况的信息。
logspaces
表包含以下列:
-
node_id
此数据节点的 ID。
-
log_type
日志类型;可以是
REDO
或DD-UNDO
之一。 -
node_id
日志 ID;对于磁盘数据撤销日志文件,这与信息模式
FILES
表中的LOGFILE_GROUP_NUMBER
列显示的值相同,以及ndbinfo
logbuffers
表中的log_id
列显示的值相同 -
log_part
日志部分编号。
-
total
该日志可用的总空间。
-
used
此日志使用的空间。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-membership.html
25.6.16.44 ndbinfo membership 表
membership
表描述了集群中每个数据节点对其他所有节点的视图,包括节点组成员资格、主节点、仲裁者、仲裁者后继、仲裁者连接状态和其他信息。
membership
表包含以下列:
-
node_id
此节点的节点 ID
-
group_id
此节点所属的节点组
-
left node
前一个节点的节点 ID
-
right_node
下一个节点的节点 ID
-
president
主节点的节点 ID
-
successor
继任主席的节点 ID
-
succession_order
此节点继任主席的顺序
-
Conf_HB_order
-
arbitrator
仲裁者的节点 ID
-
arb_ticket
用于跟踪仲裁的内部标识符
-
arb_state
仲裁状态
-
arb_connected
此节点是否连接到仲裁者;
Yes
或No
中的任意一个 -
connected_rank1_arbs
一级仲裁者连接
-
connected_rank2_arbs
一级仲裁者连接
备注
节点 ID 和节点组 ID 与ndb_mgm -e "SHOW"报告的相同。
left_node
和right_node
根据连接所有数据节点的模型定义,按照节点 ID 的顺序连接成一个圆圈,类似于时钟表盘上数字的顺序,如下所示:
图 25.6 NDB 集群节点的循环排列
在此示例中,我们有 8 个数据节点,编号为 5、6、7、8、12、13、14 和 15,按顺时针顺序排列在一个圆圈中。我们从圆圈的内部确定“左”和“右”。节点 5 左侧的节点是节点 15,节点 5 右侧的节点是节点 6。您可以通过运行以下查询并观察输出来查看所有这些关系:
mysql> SELECT node_id,left_node,right_node
-> FROM ndbinfo.membership;
+---------+-----------+------------+
| node_id | left_node | right_node |
+---------+-----------+------------+
| 5 | 15 | 6 |
| 6 | 5 | 7 |
| 7 | 6 | 8 |
| 8 | 7 | 12 |
| 12 | 8 | 13 |
| 13 | 12 | 14 |
| 14 | 13 | 15 |
| 15 | 14 | 5 |
+---------+-----------+------------+
8 rows in set (0.00 sec)
“左”和“右”这些称号在事件日志中以相同方式使用。
president
节点是当前节点视为负责设置仲裁者的节点(参见 NDB 集群启动阶段)。如果主节点失败或断开连接,当前节点期望显示在successor
列中的节点 ID 成为新的主节点。succession_order
列显示当前节点视自己在继任队列中的位置。
在正常的 NDB 集群中,所有数据节点应该将相同的节点视为president
,并将相同的节点(除了主节点)视为其successor
。此外,当前主节点应该将自己视为继任顺序中的1
,successor
节点应该将自己视为2
,依此类推。
所有节点应显示相同的arb_ticket
值以及相同的arb_state
值。可能的arb_state
值包括ARBIT_NULL
、ARBIT_INIT
、ARBIT_FIND
、ARBIT_PREP1
、ARBIT_PREP2
、ARBIT_START
、ARBIT_RUN
、ARBIT_CHOOSE
、ARBIT_CRASH
和UNKNOWN
。
arb_connected
显示此节点是否连接到显示为此节点的arbitrator
的节点。
connected_rank1_arbs
和connected_rank2_arbs
列分别显示一个或多个仲裁者的列表,这些仲裁者的ArbitrationRank
分别等于 1 或 2。
注意
管理节点和 API 节点都有资格成为仲裁者。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-memoryusage.html
25.6.16.45 ndbinfo memoryusage
表
查询此表提供类似于ALL REPORT MemoryUsage
命令在ndb_mgm客户端中提供的信息,或由ALL DUMP 1000
记录的信息。
memoryusage
表包含以下列:
-
node_id
此数据节点的节点 ID。
-
memory_type
Data memory
、Index memory
或Long message buffer
中的一个。 -
used
此数据节点当前用于数据内存或索引内存的字节数。
-
used_pages
此数据节点当前用于数据内存或索引内存的页面数;参见文本。
-
total
数据节点可用的数据内存或索引内存的总字节数;参见文本。
-
total_pages
数据内存或索引内存在此数据节点上可用的内存页总数;参见文本。
注
total
列表示特定数据节点上给定资源(数据内存或索引内存)的可用内存总量(以字节为单位)。此数字应大致等于config.ini
文件中相应配置参数的设置。
假设集群有 2 个数据节点,节点 ID 分别为5
和6
,config.ini
文件包含以下内容:
[ndbd default]
DataMemory = 1G
IndexMemory = 1G
还假设LongMessageBuffer
配置参数的值允许采用其默认值(64 MB)。
以下查询显示大致相同的值:
mysql> SELECT node_id, memory_type, total
> FROM ndbinfo.memoryusage;
+---------+---------------------+------------+
| node_id | memory_type | total |
+---------+---------------------+------------+
| 5 | Data memory | 1073741824 |
| 5 | Index memory | 1074003968 |
| 5 | Long message buffer | 67108864 |
| 6 | Data memory | 1073741824 |
| 6 | Index memory | 1074003968 |
| 6 | Long message buffer | 67108864 |
+---------+---------------------+------------+
6 rows in set (0.00 sec)
在这种情况下,索引内存的total
列值略高于IndexMemory
设置值,这是由于内部四舍五入导致的。
对于used_pages
和total_pages
列,资源以页面为单位进行度量,对于DataMemory
为 32K,对于IndexMemory
为 8K。对于长消息缓冲内存,页面大小为 256 字节。
原文:
dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-memory-per-fragment.html
25.6.16.46 ndbinfo memory_per_fragment 表
-
memory_per_fragment 表:注释
-
memory_per_fragment 表:示例
memory_per_fragment
表提供有关单个片段内存使用情况的信息。请参阅本节后面的 注释 以了解如何使用此信息查找 NDB
表使用了多少内存。
memory_per_fragment
表包含以下列:
-
fq_name
此片段的名称
-
parent_fq_name
此片段的父级名称
-
type
用于此片段的字典对象类型(
Object::Type
,在 NDB API 中)之一:System table
、User table
、Unique hash index
、Hash index
、Unique ordered index
、Ordered index
、Hash index trigger
、Subscription trigger
、Read only constraint
、Index trigger
、Reorganize trigger
、Tablespace
、Log file group
、Data file
、Undo file
、Hash map
、Foreign key definition
、Foreign key parent trigger
、Foreign key child trigger
或Schema transaction
。您还可以通过在 mysql 客户端中执行
TABLE
ndbinfo.dict_obj_types
来获取此列表。 -
table_id
此表的表 ID
-
node_id
此节点的节点 ID
-
block_instance
NDB 内核块实例 ID;您可以使用此数字从
threadblocks
表中获取有关特定线程的信息。 -
fragment_num
片段 ID(数字)
-
fixed_elem_alloc_bytes
为固定大小元素分配的字节数
-
fixed_elem_free_bytes
分配给固定大小元素的页面中剩余的空闲字节数
-
fixed_elem_size_bytes
每个固定大小元素的字节长度
-
fixed_elem_count
固定大小元素的数量
-
fixed_elem_free_count
用于固定大小元素的空闲行数
-
var_elem_alloc_bytes
为可变大小元素分配的字节数
-
var_elem_free_bytes
分配给可变大小元素的页面中剩余的空闲字节数
-
var_elem_count
可变大小元素的数量
-
hash_index_alloc_bytes
为哈希索引分配的字节数
memory_per_fragment 表:注释
memory_per_fragment
表包含系统中每个表片段副本和每个索引片段副本的一行;这意味着,例如,当NoOfReplicas=2
时,通常每个片段都有两个片段副本。只要所有数据节点都在运行并连接到集群,这一点就成立;对于缺失的数据节点,它承载的片段副本没有行。
memory_per_fragment
表的列可以根据其功能或目的分组如下:
-
键列:
fq_name
、type
、table_id
、node_id
、block_instance
和fragment_num
-
关系列:
parent_fq_name
-
固定大小存储列:
fixed_elem_alloc_bytes
、fixed_elem_free_bytes
、fixed_elem_size_bytes
、fixed_elem_count
和fixed_elem_free_count
-
可变大小存储列:
var_elem_alloc_bytes
、var_elem_free_bytes
和var_elem_count
-
哈希索引列:
hash_index_alloc_bytes
parent_fq_name
和 fq_name
列可用于识别与表关联的索引。类似的模式对象层次结构信息在其他ndbinfo
表中也可用。
表和索引片段副本以 32KB 页面分配DataMemory
。这些内存页面的管理如下所示:
-
固定大小页:这些存储在给定片段中存储的行的固定大小部分。每行都有一个固定大小部分。
-
可变大小页:这些为片段中的行存储可变大小部分。每行具有一个或多个可变大小部分,一个或多个动态列(或两者都有)的行具有可变大小部分。
-
哈希索引页:这些被分配为 8 KB 子页,存储主键哈希索引结构。
NDB
表中的每行都有一个固定大小部分,包括行头和一个或多个固定大小列。该行还可能包含一个或多个变量大小部分引用,一个或多个磁盘部分引用,或两者都有。每行还有一个主键哈希索引条目(对应于每个NDB
表中的隐藏主键)。
从前述内容我们可以看到,每个表片段和索引片段一起分配了根据此处计算的DataMemory
数量:
DataMemory =
(*number_of_fixed_pages* + *number_of_var_pages*) * 32KB
+ *number_of_hash_pages* * 8KB
由于fixed_elem_alloc_bytes
和var_elem_alloc_bytes
始终是 32768 字节的倍数,我们可以进一步确定*
number_of_fixed_pages* = fixed_elem_alloc_bytes / 32768
和*
number_of_var_pages* = var_elem_alloc_bytes / 32768
。hash_index_alloc_bytes
始终是 8192 字节的倍数,因此*
number_of_hash_pages* = hash_index_alloc_bytes / 8192
。
固定大小页具有内部标头和多个固定大小槽,每个槽可以包含一行的固定大小部分。给定行的固定大小部分的大小取决于模式,并由fixed_elem_size_bytes
列提供;每页的固定大小槽数量可以通过计算总槽数量和总页数来确定,如下所示:
*fixed_slots* = fixed_elem_count + fixed_elem_free_count
*fixed_pages* = fixed_elem_alloc_bytes / 32768
*slots_per_page* = total_slots / total_pages
fixed_elem_count
实际上是给定表碎片的行数,因为每行有 1 个固定元素,fixed_elem_free_count
是分配的页中所有固定大小空槽的总数。fixed_elem_free_bytes
等于fixed_elem_free_count * fixed_elem_size_bytes
。
一个碎片可以有任意数量的固定大小页;当固定大小页上的最后一行被删除时,该页将释放到DataMemory
页池中。固定大小页可以被碎片化,分配的页比实际使用的固定大小槽数量多。您可以通过比较所需页数和分配的页数来检查是否是这种情况,计算方法如下:
*fixed_pages_required* = 1 + (fixed_elem_count / *slots_per_page*)
fixed_page_utilization = *fixed_pages_required* / *fixed_pages*
可变大小页具有内部标头,并使用剩余空间存储一个或多个可变大小行部分;存储的部分数量取决于模式和实际存储的数据。由于并非所有模式或行都有可变大小部分,var_elem_count
可能小于fixed_elem_count
。碎片中所有可变大小页上的总可用空间由var_elem_free_bytes
列显示;因为此空间可能分布在多个页上,所以不能必然用于存储特定大小的条目。根据需要重新组织每个可变大小页,以适应插入、更新和删除可变大小行部分的变化大小;如果给定行部分增长到超出所在页的大小,则可以将其移动到另一页。
可变大小页的利用率可以按照这里所示进行计算:
*var_page_used_bytes* = var_elem_alloc_bytes - var_elem_free_bytes
*var_page_utilisation* = var_page_used_bytes / var_elem_alloc_bytes
*avg_row_var_part_size* = *var_page_used_bytes* / fixed_elem_count
我们可以按照以下方式获得每行的平均可变部分大小:
*avg_row_var_part_size* = *var_page_used_bytes* / fixed_elem_count
次要唯一索引在内部实现为具有以下模式的独立表:
-
主键:基表中的索引列。
-
值:基表中的主键列。
这些表像普通表一样分布和碎片化。这意味着它们的碎片副本使用固定、可变和哈希索引页,就像任何其他NDB
表一样。
次序有序索引与基表相同方式进行碎片化和分布。有序索引片段是维护平衡树的 T 树结构,其中包含按索引列暗示的顺序包含行引用。由于树包含引用而不是实际数据,因此 T 树存储成本不取决于索引列的大小或数量,而是取决于行数。树是使用固定大小节点结构构建的,每个节点可以包含多个行引用;所需的节点数量取决于表中的行数,以及表示排序所需的树结构。在memory_per_fragment
表中,我们可以看到有序索引仅分配固定大小页面,因此像往常一样,此表中相关列如下所列:
-
fixed_elem_alloc_bytes
: 这等于固定大小页面的数量乘以 32768。 -
fixed_elem_count
: 正在使用的 T 树节点数。 -
fixed_elem_size_bytes
: 每个 T 树节点的字节数。 -
fixed_elem_free_count
: 分配的页面中可用的 T 树节点槽位数。 -
fixed_elem_free_bytes
: 这等于fixed_elem_free_count * fixed_elem_size_bytes
。
如果页面中的空闲空间是碎片化的,则页面将被整理。OPTIMIZE TABLE
可用于整理表的可变大小页面;这将在页面之间移动行的可变大小部分,以便一些整个页面可以被释放以供重新使用。
memory_per_fragment 表:示例
-
获取有关片段和内存使用情况的一般信息
-
查找表及其索引
-
查找模式元素分配的内存
-
查找表及其所有索引分配的内存
-
查找每行分配的内存
-
查找每行使用的总内存
-
查找每个元素分配的内存
-
按元素查找每行分配的平均内存
-
查找每行分配的平均内存
-
查找表格每行分配的平均内存
-
按每个模式元素查找使用的内存
-
按每个模式元素查找使用的平均内存
-
按元素查找每行使用的平均内存
-
查找每行使用的总平均内存
对于以下示例,我们创建一个简单的表格,包含三个整数列,其中一个具有主键,一个具有唯一索引,一个没有索引,以及一个没有索引的VARCHAR
列,如下所示:
mysql> CREATE DATABASE IF NOT EXISTS test;
Query OK, 1 row affected (0.06 sec)
mysql> USE test;
Database changed
mysql> CREATE TABLE t1 (
-> c1 BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
-> c2 INT,
-> c3 INT UNIQUE,
-> ) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (0.27 sec)
创建表格后,我们插入包含随机数据的 50,000 行;生成和插入这些行的确切方法在实际上没有任何区别,我们将完成方法的实现留给用户作为练习。
获取片段和内存使用的一般信息
此查询显示每个片段的内存使用情况的一般信息:
mysql> SELECT
-> fq_name, node_id, block_instance, fragment_num, fixed_elem_alloc_bytes,
-> fixed_elem_free_bytes, fixed_elem_size_bytes, fixed_elem_count,
-> fixed_elem_free_count, var_elem_alloc_bytes, var_elem_free_bytes,
-> var_elem_count
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = "test/def/t1"\G
*************************** 1\. row ***************************
fq_name: test/def/t1
node_id: 5
block_instance: 1
fragment_num: 0
fixed_elem_alloc_bytes: 1114112
fixed_elem_free_bytes: 11836
fixed_elem_size_bytes: 44
fixed_elem_count: 24925
fixed_elem_free_count: 269
var_elem_alloc_bytes: 1245184
var_elem_free_bytes: 32552
var_elem_count: 24925
*************************** 2\. row ***************************
fq_name: test/def/t1
node_id: 5
block_instance: 1
fragment_num: 1
fixed_elem_alloc_bytes: 1114112
fixed_elem_free_bytes: 5236
fixed_elem_size_bytes: 44
fixed_elem_count: 25075
fixed_elem_free_count: 119
var_elem_alloc_bytes: 1277952
var_elem_free_bytes: 54232
var_elem_count: 25075
*************************** 3\. row ***************************
fq_name: test/def/t1
node_id: 6
block_instance: 1
fragment_num: 0
fixed_elem_alloc_bytes: 1114112
fixed_elem_free_bytes: 11836
fixed_elem_size_bytes: 44
fixed_elem_count: 24925
fixed_elem_free_count: 269
var_elem_alloc_bytes: 1245184
var_elem_free_bytes: 32552
var_elem_count: 24925
*************************** 4\. row ***************************
fq_name: test/def/t1
node_id: 6
block_instance: 1
fragment_num: 1
fixed_elem_alloc_bytes: 1114112
fixed_elem_free_bytes: 5236
fixed_elem_size_bytes: 44
fixed_elem_count: 25075
fixed_elem_free_count: 119
var_elem_alloc_bytes: 1277952
var_elem_free_bytes: 54232
var_elem_count: 25075 4 rows in set (0.12 sec)
查找表格及其索引
此查询可用于查找特定表格及其索引:
mysql> SELECT fq_name
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
-> GROUP BY fq_name;
+----------------------+
| fq_name |
+----------------------+
| test/def/t1 |
| sys/def/13/PRIMARY |
| sys/def/13/c3 |
| sys/def/13/c3$unique |
+----------------------+
4 rows in set (0.13 sec)
mysql> SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
| 50000 |
+----------+
1 row in set (0.00 sec)
查找模式元素分配的内存
此查询显示每个模式元素分配的内存(在所有副本中总计):
mysql> SELECT
-> fq_name AS Name,
-> SUM(fixed_elem_alloc_bytes) AS Fixed,
-> SUM(var_elem_alloc_bytes) AS Var,
-> SUM(hash_index_alloc_bytes) AS Hash,
-> SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes) AS Total
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
-> GROUP BY fq_name;
+----------------------+---------+---------+---------+----------+
| Name | Fixed | Var | Hash | Total |
+----------------------+---------+---------+---------+----------+
| test/def/t1 | 4456448 | 5046272 | 1425408 | 10928128 |
| sys/def/13/PRIMARY | 1966080 | 0 | 0 | 1966080 |
| sys/def/13/c3 | 1441792 | 0 | 0 | 1441792 |
| sys/def/13/c3$unique | 3276800 | 0 | 1425408 | 4702208 |
+----------------------+---------+---------+---------+----------+
4 rows in set (0.11 sec)
查找为表格及所有索引分配的内存
可以使用以下查询获取为表格及其所有索引分配的内存总和(在所有副本中总计):
mysql> SELECT
-> SUM(fixed_elem_alloc_bytes) AS Fixed,
-> SUM(var_elem_alloc_bytes) AS Var,
-> SUM(hash_index_alloc_bytes) AS Hash,
-> SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes) AS Total
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+----------+---------+---------+----------+
| Fixed | Var | Hash | Total |
+----------+---------+---------+----------+
| 11141120 | 5046272 | 2850816 | 19038208 |
+----------+---------+---------+----------+
1 row in set (0.12 sec)
这是前一个查询的简化版本,仅显示表格使用的总内存:
mysql> SELECT
-> SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes) AS Total
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+----------+
| Total |
+----------+
| 19038208 |
+----------+
1 row in set (0.12 sec)
查找每行分配的内存
以下查询显示每行分配的总内存(在所有副本中):
mysql> SELECT
-> SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes)
-> /
-> SUM(fixed_elem_count) AS Total_alloc_per_row
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1';
+---------------------+
| Total_alloc_per_row |
+---------------------+
| 109.2813 |
+---------------------+
1 row in set (0.12 sec)
查找每行使用的总内存
要获取每行使用的总内存(在所有副本中),我们需要将总内存使用量除以行数,即基本表的fixed_elem_count
,如下所示:
mysql> SELECT
-> SUM(
-> (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
-> + (var_elem_alloc_bytes - var_elem_free_bytes)
-> + hash_index_alloc_bytes
-> )
-> /
-> SUM(fixed_elem_count)
-> AS total_in_use_per_row
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1';
+----------------------+
| total_in_use_per_row |
+----------------------+
| 107.2042 |
+----------------------+
1 row in set (0.12 sec)
查找每个元素分配的内存
每个模式元素分配的内存(在所有副本中总共)可以使用以下查询找到:
mysql> SELECT
-> fq_name AS Name,
-> SUM(fixed_elem_alloc_bytes) AS Fixed,
-> SUM(var_elem_alloc_bytes) AS Var,
-> SUM(hash_index_alloc_bytes) AS Hash,
-> SUM(fixed_elem_alloc_bytes + var_elem_alloc_bytes + hash_index_alloc_bytes)
-> AS Total_alloc
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
-> GROUP BY fq_name;
+----------------------+---------+---------+---------+-------------+
| Name | Fixed | Var | Hash | Total_alloc |
+----------------------+---------+---------+---------+-------------+
| test/def/t1 | 4456448 | 5046272 | 1425408 | 10928128 |
| sys/def/13/PRIMARY | 1966080 | 0 | 0 | 1966080 |
| sys/def/13/c3 | 1441792 | 0 | 0 | 1441792 |
| sys/def/13/c3$unique | 3276800 | 0 | 1425408 | 4702208 |
+----------------------+---------+---------+---------+-------------+
4 rows in set (0.11 sec)
按元素查找每行分配的平均内存
要获取每个模式元素分配的平均每行内存(在所有副本中),我们使用子查询每次获取基本表固定元素计数以获得每行平均值,因为索引的fixed_elem_count
不一定与基本表相同,如下所示:
mysql> SELECT
-> fq_name AS Name,
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS Table_rows,
->
-> SUM(fixed_elem_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS Avg_fixed_alloc,
->
-> SUM(var_elem_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') as Avg_var_alloc,
->
-> SUM(hash_index_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') as Avg_hash_alloc,
->
-> SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') as Avg_total_alloc
->
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' or parent_fq_name='test/def/t1'
-> GROUP BY fq_name;
+----------------------+------------+-----------------+---------------+----------------+-----------------+
| Name | Table_rows | Avg_fixed_alloc | Avg_var_alloc | Avg_hash_alloc | Avg_total_alloc |
+----------------------+------------+-----------------+---------------+----------------+-----------------+
| test/def/t1 | 100000 | 44.5645 | 50.4627 | 14.2541 | 109.2813 |
| sys/def/13/PRIMARY | 100000 | 19.6608 | 0.0000 | 0.0000 | 19.6608 |
| sys/def/13/c3 | 100000 | 14.4179 | 0.0000 | 0.0000 | 14.4179 |
| sys/def/13/c3$unique | 100000 | 32.7680 | 0.0000 | 14.2541 | 47.0221 |
+----------------------+------------+-----------------+---------------+----------------+-----------------+
4 rows in set (0.70 sec)
按行查找每行分配的平均内存
每行分配的平均内存(在所有副本中总共):
mysql> SELECT
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS Table_rows,
->
-> SUM(fixed_elem_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS Avg_fixed_alloc,
->
-> SUM(var_elem_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS Avg_var_alloc,
->
-> SUM(hash_index_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS Avg_hash_alloc,
->
-> SUM(fixed_elem_alloc_bytes + var_elem_alloc_bytes + hash_index_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS Avg_total_alloc
->
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+------------+-----------------+---------------+----------------+-----------------+
| Table_rows | Avg_fixed_alloc | Avg_var_alloc | Avg_hash_alloc | Avg_total_alloc |
+------------+-----------------+---------------+----------------+-----------------+
| 100000 | 111.4112 | 50.4627 | 28.5082 | 190.3821 |
+------------+-----------------+---------------+----------------+-----------------+
1 row in set (0.71 sec)
查找表格每行分配的平均内存
要获取整个表中每行分配的平均内存(在所有副本中),我们可以使用这里显示的查询:
mysql> SELECT
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS table_rows,
->
-> SUM(fixed_elem_alloc_bytes + var_elem_alloc_bytes + hash_index_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_total_alloc
->
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+------------+-----------------+
| table_rows | avg_total_alloc |
+------------+-----------------+
| 100000 | 190.3821 |
+------------+-----------------+
1 row in set (0.33 sec)
查找每个模式元素使用的内存
要获取所有副本中每个模式元素使用的内存,我们需要对每个元素的分配和空闲内存之间的差值求和,如下所示:
mysql> SELECT
-> fq_name AS Name,
-> SUM(fixed_elem_alloc_bytes - fixed_elem_free_bytes) AS fixed_inuse,
-> SUM(var_elem_alloc_bytes-var_elem_free_bytes) AS var_inuse,
-> SUM(hash_index_alloc_bytes) AS hash_memory,
-> SUM( (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
-> + (var_elem_alloc_bytes - var_elem_free_bytes)
-> + hash_index_alloc_bytes) AS total_alloc
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
-> GROUP BY fq_name;
+----------------------+-------------+-----------+---------+-------------+
| fq_name | fixed_inuse | var_inuse | hash | total_alloc |
+----------------------+-------------+-----------+---------+-------------+
| test/def/t1 | 4422304 | 4872704 | 1425408 | 10720416 |
| sys/def/13/PRIMARY | 1950848 | 0 | 0 | 1950848 |
| sys/def/13/c3 | 1428736 | 0 | 0 | 1428736 |
| sys/def/13/c3$unique | 3212800 | 0 | 1425408 | 4638208 |
+----------------------+-------------+-----------+---------+-------------+
4 rows in set (0.13 sec)
按每个模式元素查找使用的平均内存
这个查询获取所有副本中每个模式元素使用的平均内存:
mysql> SELECT
-> fq_name AS Name,
->
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS table_rows,
->
-> SUM(fixed_elem_alloc_bytes - fixed_elem_free_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_fixed_inuse,
->
-> SUM(var_elem_alloc_bytes - var_elem_free_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_var_inuse,
->
-> SUM(hash_index_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_hash,
->
-> SUM(
-> (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
-> + (var_elem_alloc_bytes - var_elem_free_bytes) + hash_index_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_total_inuse
->
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
-> GROUP BY fq_name;
+----------------------+------------+-----------------+---------------+----------+-----------------+
| Name | table_rows | avg_fixed_inuse | avg_var_inuse | avg_hash | avg_total_inuse |
+----------------------+------------+-----------------+---------------+----------+-----------------+
| test/def/t1 | 100000 | 44.2230 | 48.7270 | 14.2541 | 107.2042 |
| sys/def/13/PRIMARY | 100000 | 19.5085 | 0.0000 | 0.0000 | 19.5085 |
| sys/def/13/c3 | 100000 | 14.2874 | 0.0000 | 0.0000 | 14.2874 |
| sys/def/13/c3$unique | 100000 | 32.1280 | 0.0000 | 14.2541 | 46.3821 |
+----------------------+------------+-----------------+---------------+----------+-----------------+
4 rows in set (0.72 sec)
按元素查找每行使用的平均内存
这个查询获取所有副本中每行按元素使用的平均内存:
mysql> SELECT
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS table_rows,
->
-> SUM(fixed_elem_alloc_bytes - fixed_elem_free_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_fixed_inuse,
->
-> SUM(var_elem_alloc_bytes - var_elem_free_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_var_inuse,
->
-> SUM(hash_index_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_hash,
->
-> SUM(
-> (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
-> + (var_elem_alloc_bytes - var_elem_free_bytes)
-> + hash_index_alloc_bytes)
-> /
-> ( SELECT SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_total_inuse
->
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+------------+-----------------+---------------+----------+-----------------+
| table_rows | avg_fixed_inuse | avg_var_inuse | avg_hash | avg_total_inuse |
+------------+-----------------+---------------+----------+-----------------+
| 100000 | 110.1469 | 48.7270 | 28.5082 | 187.3821 |
+------------+-----------------+---------------+----------+-----------------+
1 row in set (0.68 sec)
查找每行使用的总平均内存
这个查询获取每行使用的总平均内存:
mysql> SELECT
-> SUM(
-> (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
-> + (var_elem_alloc_bytes - var_elem_free_bytes)
-> + hash_index_alloc_bytes)
-> /
-> ( SELECT
-> SUM(fixed_elem_count)
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name='test/def/t1') AS avg_total_in_use
-> FROM ndbinfo.memory_per_fragment
-> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+------------------+
| avg_total_in_use |
+------------------+
| 187.3821 |
+------------------+
1 row in set (0.24 sec)
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· 记一次.NET内存居高不下排查解决与启示
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· .NET10 - 预览版1新功能体验(一)