作为数据库的维护人员（即 DBA），除了工作中在应用端对数据库进行增删改操作外，更多是需要每天巡检与常规维护运行的 MySQL Cluster 环境，确保 MySQL Cluster 环境可以正常运行。所以说，我们需要掌握 MySQL Cluster 维护性方面的技能，例如如何通过日志信息排查问题、如何对数据进行有效的备份等 。
这一小节，我们就先来看一下 MySQL Cluster 集群环境日志管理的内容，主要讲解当MySQL Cluster环境出现问题时如何来诊断，以及对日志在信息输出上进行一些细粒度的控制。
MySQL Cluster 集群日志主要分为集群日志、节点日志：
- 集群日志文件存储于管理节点上，用来记录整个集群的运行情况，如各个节点的连通性等，以及所有节点的运行情况。
- 节点日志文件存储于单独的某个节点上，只是用来记录本地节点上的服务运行情况。
首先我们来看集群日志文件在管理上面的内容。
集群日志文件
集群日志文件默认位于管理节点上的 datadir 目录下，我们可以看一下当前环境的配置文件。
[mysql@mysql03 mysql_cluster]$ more config.ini [ndbd default] NoOfReplicas=2 DataMemory=200M IndexMemory=30M [ndb_mgmd] hostname=192.168.1.3 datadir=/mysql/mydata [ndbd] hostname=192.168.1.6 datadir=/mysql/mydata [ndbd] hostname=192.168.1.7 datadir=/mysql/mydata [mysqld] hostname=192.168.1.4 [mysqld] hostname=192.168.1.5
在当前的配置文件中，datadir 目录路径为 /mysql/mydata，集群日志文件命名为 ndb_1_cluster.log，文件名中的 1 代表的是管理节点的 nodeid，下面这段代码中显示的管理节点的id=1，那么其实在工作中如果不清楚某一个数据节点或者SQL节点的id值，则可以在ndb_mgm控制台上进行查看。
[mysql@mysql03 mydata]$ ndb_mgm -- NDB Cluster -- Management Client -- ndb_mgm> show; Connected to Management Server at: localhost:1186 Cluster Configuration [ndbd(NDB)] 2 node(s) id=2 (not connected, accepting connect from 192.168.1.6) id=3 (not connected, accepting connect from 192.168.1.7) [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.1.3 (mysql-5.7.36 ndb-7.6.20) [mysqld(API)] 2 node(s) id=4 (not connected, accepting connect from 192.168.1.4) id=5 (not connected, accepting connect from 192.168.1.5)
我们来看一下集群日志文件 ndb_1_cluster.log 中所记录的信息。
[mysql@mysql03 mydata]$ tail -30 ndb_1_cluster.log 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: m_LAST_LCP_FRAG_ORD = [SignalCounter: m_count=0 0000000000000000] 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: m_LCP_COMPLETE_REP_From_Master_Received = 1 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: GCP Take over started 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: Node 3 taking over as DICT master 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: GCP Take over completed 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: kk: 63150/7 0 0 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: LCP Take over completed (state = 4) 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: ParticipatingDIH = 0000000000000000 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: ParticipatingLQH = 0000000000000000 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: m_LCP_COMPLETE_REP_Counter_DIH = [SignalCounter: m_count=0 0000000000000000] 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: m_LCP_COMPLETE_REP_Counter_LQH = [SignalCounter: m_count=0 0000000000000000] 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: m_lastLCP_COMPLETE_REP_id = 6 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: m_lastLCP_COMPLETE_REP_ref = f60002 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: noOfLcpFragRepOutstanding: 0 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: m_LAST_LCP_FRAG_ORD = [SignalCounter: m_count=0 0000000000000000] 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: m_LCP_COMPLETE_REP_From_Master_Received = 1 2022-03-22 17:25:47 [MgmtSrvr] INFO -- Node 3: NR Status: node=2,OLD=Node failed, fail handling ongoing,NEW=Node failure handling complete 2022-03-22 17:25:48 [MgmtSrvr] INFO -- Node 3: Started arbitrator node 1 [ticket=1396000207fa2381] 2022-03-22 17:25:51 [MgmtSrvr] INFO -- Node 3: Communication to Node 2 opened 2022-03-22 17:26:03 [MgmtSrvr] INFO -- Node 3: Node shutdown completed. Initiated by signal 15. 2022-03-22 17:26:03 [MgmtSrvr] ALERT -- Node 1: Node 3 Disconnected 2022-03-22 17:31:48 [MgmtSrvr] INFO -- Shutting down server... 2022-03-22 17:31:55 [MgmtSrvr] INFO -- Shutdown complete 2022-03-22 17:32:40 [MgmtSrvr] INFO -- Loaded config from '/usr/local/mysql/mysql-cluster/ndb_1_config.bin.1' 2022-03-22 17:32:41 [MgmtSrvr] INFO -- Node 1: Node 1 Connected 2022-03-22 17:32:41 [MgmtSrvr] INFO -- Id: 1, Command port: *:1186 2022-03-22 17:32:41 [MgmtSrvr] INFO -- MySQL Cluster Management Server mysql-5.7.36 ndb-7.6.20 started 2022-03-22 17:32:41 [MgmtSrvr] INFO -- Node 1 connected 2022-03-22 17:33:11 [MgmtSrvr] INFO -- Loaded config from '/usr/local/mysql/mysql-cluster/ndb_1_config.bin.1' 2022-03-22 17:33:11 [MgmtSrvr] ERROR -- Couldn't start as daemon, error: 'Failed to lock pidfile '/mysql/mydata/ndb_1.pid', already locked by pid=3193, errno: 11'
通过日志的输出可以看到，集群日志文件中记录了每个数据节点及每个SQL节点的运行情况，还显示了不同级别的信息，如上面的日志中包括有 INFO、ALERT、ERROR，当然除了这几类，还有 WARNING、CRITICAL和DEBUG 级别。这几类日志级别的信息严重程度不同，是逐级递减的，顺序下：ALERT、CRITICAL、ERROR、WARNING、INFO、DEBUG。
每个级别的日志所表描述的日志信息内容如下：
严重级别 |
事件定义 |
ALERT |
应立刻更正的情况，如损坏的系统数据库 |
CRITICAL |
临界状况，如设备错误或资源不足 |
ERROR |
应予以更正的状况，如配置错误 |
WARNING |
不能称为错误的情况，但仍需要特别处理 |
INFO |
通报性信息 |
DEBUG |
调试信息，用于NDB Cluster开发 |
在工作中，当遇到 WARNING 及以上级别的日志信息时，需要格外注意并及时处理了。
在了解完不同级别的日志所代表的信息后，接下来我们继续对集群日志信息进行一些自定义的操作，因为在集群日志文件中会集中显示所有数据节点和SQL节点的运行情况，在日志的输出上是非常大的，这样会给我们在排查问题上带来一些不便，所以我们在工作中很有必须对于一些不太关注的信息进行屏蔽。比如：
- 临时关闭集群日志信息的输出；
- 或者关闭某几个级别的日志信息输出（像 INFO 和 DEBUG 级别的日志信息只是输出一些常规的运行情况，这些信息对问题的排查起不到有效作用）。
首先我们来看一下，如果关闭集群全部的日志信息，具体要怎么操作。
当磁盘的空间比较紧张或者在一些压力测试的场景下，我们不怎么在意集群的日志信息输出，这时可以将集群的日志信息整体关闭，关闭时要在管理节点上的 ndb_mgm 控制台下进行操作，具体如何操作呢？接下来我们进行一个演示。
[mysql@mysql03 mydata]$ ndb_mgm -- NDB Cluster -- Management Client -- ndb_mgm> clusterlog info; Severities enabled: INFO WARNING ERROR CRITICAL ALERT ndb_mgm> clusterlog off; Cluster logging is disabled ndb_mgm> clusterlog info; Cluster logging is disabled. ndb_mgm> clusterlog on; Cluster logging is enabled. ndb_mgm> clusterlog info; Severities enabled: INFO WARNING ERROR CRITICAL ALERT
通过上面的代码，我们可以掌握以下几点信息：
- 关闭集群日志功能是使用 clusterlog off 命令来实现；
- 开启集群日志功能是使用 clusterlog on 命令来实现；
- 查看当前的日志级别使用 clusterlog info 命令；
- 默认开启的日志级别为 INFO WARNING ERROR CRITICAL ALERT。
由于 DEBUG 级别的日志信息是用来调试和观察数据库内部运行机理，在日志输出上更为详细，同时输出的日志量也非常大，所以我们一般不需要开启。如果要进行开启 DEBUG 级别的日志信息输出，可以使用如下的方式：
ndb_mgm> clusterlog toggle debug; DEBUG enabled ndb_mgm> clusterlog info; Severities enabled: DEBUG INFO WARNING ERROR CRITICAL ALERT
那么如何只开启部分级别的日志输出呢？同样是需要在 ndb_mgm 控制台操作，例如我们只需要开启WARNING 及以上级别的日志输出，则可以这样进行操作：
ndb_mgm> clusterlog info; Severities enabled: DEBUG INFO WARNING ERROR CRITICAL ALERT ndb_mgm> clusterlog toggle debug info; DEBUG disabled INFO disabled ndb_mgm> clusterlog info; Severities enabled: WARNING ERROR CRITICAL ALERT
即对于某个级别日志信息输出功能的开启和关闭是使用 clusterlog toggle 命令实现的，在操作上非常简单。以上是集群日志文件日常管理方面内容的讲解。接下来，我们来看一下节点日志文件，在节点日志方面，因为其是存放在各自的节点上的，在日志的输出上也只是显示当前节点的运行情况，所以大家只需要了解每种节点（数据节点、SQL 节点）上日志文件存放的位置就行，这样当某个节点出现故障时，要知道从哪里可以获取到相关的信息。
节点日志文件
数据节点的日志文件默认时存放在 datadir 目录下，名称一般为 ndb_<nodeid>_out.log。如环境中的ndb_3_out.log。
[mysql@mysql07 ~]$ ls -l /mysql/mydata/ total 80 drwxr-x--- 11 mysql mysql 99 Mar 8 22:34 ndb_3_fs -rw-r--r-- 1 mysql mysql 76331 Mar 10 13:28 ndb_3_out.log -rw-r--r-- 1 mysql mysql 4 Mar 10 13:28 ndb_3.pid
而 SQL 节点的日志文件默认时存放在 datadir 目录下，名称一般为<hostname>.err。如环境中的mysql04.err。
[mysql@mysql04 mydata]$ ls -l /mysql/mydata/ total 123020 -rw-r----- 1 mysql mysql 56 Mar 8 22:35 auto.cnf -rw------- 1 mysql mysql 1676 Mar 8 22:35 ca-key.pem -rw-r--r-- 1 mysql mysql 1140 Mar 8 22:35 ca.pem -rw-r--r-- 1 mysql mysql 1140 Mar 8 22:35 client-cert.pem -rw------- 1 mysql mysql 1680 Mar 8 22:35 client-key.pem -rw-r----- 1 mysql mysql 358 Mar 10 11:09 ib_buffer_pool -rw-r----- 1 mysql mysql 12582912 Mar 10 13:28 ibdata1 -rw-r----- 1 mysql mysql 50331648 Mar 10 13:28 ib_logfile0 -rw-r----- 1 mysql mysql 50331648 Mar 8 22:35 ib_logfile1 -rw-r----- 1 mysql mysql 12582912 Mar 10 13:28 ibtmp1 drwxr-x--- 2 mysql mysql 4096 Mar 8 22:36 mysql -rw-r----- 1 mysql mysql 55332 Mar 10 13:28 mysql04.err -rw-r----- 1 mysql mysql 5 Mar 10 13:28 mysql04.pid srwxrwxrwx 1 mysql mysql 0 Mar 10 13:28 mysql.sock -rw------- 1 mysql mysql 5 Mar 10 13:28 mysql.sock.lock drwxr-x--- 2 mysql mysql 4096 Mar 8 22:35 ndbinfo drwxr-x--- 2 mysql mysql 8192 Mar 8 22:35 performance_schema -rw------- 1 mysql mysql 1676 Mar 8 22:35 private_key.pem -rw-r--r-- 1 mysql mysql 452 Mar 8 22:35 public_key.pem -rw-r--r-- 1 mysql mysql 1140 Mar 8 22:35 server-cert.pem -rw------- 1 mysql mysql 1680 Mar 8 22:35 server-key.pem drwxr-x--- 2 mysql mysql 8192 Mar 8 22:35 sys drwxr-x--- 2 mysql mysql 104 Mar 10 09:53 testdb
好了，以上就是 MySQL Cluster 集群环境中，日志管理方面内容的讲解。在下一小节中，我们开始讲解MySQL Cluster 集群环境的备份。
