AI 助理
备案控制台
开发者社区 数据库 文章 正文

探索MySQL-Cluster奥秘系列之日志管理(12)

2022-10-21 344
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
RDS MySQL Serverless 高可用系列，价值2615元额度，1个月
云数据库 RDS MySQL，高可用系列 2核4GB
简介： 无论是对于哪种数据库产品，日志的重要性是不言而喻的，所以掌握如何对于MySQL-Cluster集群的日志进行管理，对于我们每一个维护MySQL-Cluster技术人员来说都是非常重要的。

作为数据库的维护人员（即 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 集群环境的备份。

文章标签：
云数据库 RDS MySQL 版
日志服务
SQL
关系型数据库
数据库管理
文件存储
MySQL
数据库
关键词：
云数据库 RDS MySQL 版日志
mysql日志服务
云数据库 RDS MySQL 版日志管理
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发，帮助IT从业者们通过“阿里云Web应用上云解决方案”，了解一个企业级Web应用上云的常见架构，了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品：云数据库RDS MySQL 版 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务，提供容灾、备份、恢复、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
子钰
目录
相关文章
蓝易云
|
3月前
|
SQL 运维 关系型数据库
深入探讨MySQL的二进制日志（binlog）选项
总结而言，对MySQL binlogs深度理解并妥善配置对数据库运维管理至关重要；它不仅关系到系统性能优化也是实现高可靠性架构设计必须考虑因素之一。通过精心规划与周密部署可以使得该机能充分发挥作用而避免潜在风险带来影响。
蓝易云
126 6
蓝易云
|
9月前
|
数据可视化 关系型数据库 MySQL
ELK实现nginx、mysql、http的日志可视化实验
通过本文的步骤，你可以成功配置ELK（Elasticsearch, Logstash, Kibana）来实现nginx、mysql和http日志的可视化。通过Kibana，你可以直观地查看和分析日志数据，从而更好地监控和管理系统。希望这些步骤能帮助你在实际项目中有效地利用ELK来处理日志数据。
蓝易云
666 90
蓝易云
|
7月前
|
SQL 监控 关系型数据库
MySQL日志分析：binlog、redolog、undolog三大日志的深度探讨。
数据库管理其实和写小说一样，需要规划，需要修订，也需要有能力回滚。理解这些日志的作用与优化，就像把握写作工具的使用与运用，为我们的数据库保驾护航。
蓝易云
291 23
游客bmwhmm6u34qx6
|
8月前
|
SQL 运维 关系型数据库
MySQL Binlog 日志查看方法及查看内容解析
本文介绍了 MySQL 的 Binlog（二进制日志）功能及其使用方法。Binlog 记录了数据库的所有数据变更操作，如 INSERT、UPDATE 和 DELETE，对数据恢复、主从复制和审计至关重要。文章详细说明了如何开启 Binlog 功能、查看当前日志文件及内容，并解析了常见的事件类型，包括 Format_desc、Query、Table_map、Write_rows、Update_rows 和 Delete_rows 等，帮助用户掌握数据库变化历史，提升维护和排障能力。
游客bmwhmm6u34qx6
3234 6
SlackClimb
|
10月前
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log（重做日志）是数据库中用于记录数据页修改的物理日志，确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式，在内存中缓存修改操作，并在适当时候刷入磁盘，减少随机写入带来的性能损耗。WAL（Write-Ahead Logging）技术的核心思想是先将修改操作记录到日志文件中，再择机写入磁盘，从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数（如 `innodb_flush_log_at_trx_commit`），以平衡性能与数据安全性。
SlackClimb
444 5
图解MySQL【日志】——Redo Log
SlackClimb
|
10月前
|
关系型数据库 MySQL 数据库
图解MySQL【日志】——两阶段提交
两阶段提交是为了解决Redo Log和Binlog日志在事务提交时可能出现的半成功状态，确保两者的一致性。它分为准备阶段和提交阶段，通过协调者和参与者协作完成。准备阶段中，协调者向所有参与者发送准备请求，参与者执行事务并回复是否同意提交；提交阶段中，若所有参与者同意，则协调者发送提交请求，否则发送回滚请求。MySQL通过这种方式保证了分布式事务的一致性，并引入组提交机制减少磁盘I/O次数，提升性能。
SlackClimb
709 4
图解MySQL【日志】——两阶段提交
蓝易云
|
9月前
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用，对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化，可以显著提升MySQL的运行效率和数据可靠性。
蓝易云
215 16
蓝易云
|
9月前
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用，对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化，可以显著提升MySQL的运行效率和数据可靠性。
蓝易云
167 4
SlackClimb
|
10月前
|
关系型数据库 MySQL
图解MySQL【日志】——磁盘 I/O 次数过高时优化的办法
当 MySQL 磁盘 I/O 次数过高时，可通过调整参数优化。控制刷盘时机以降低频率：组提交参数 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count` 调整等待时间和事务数量；`sync_binlog=N` 设置 write 和 fsync 频率，`innodb_flush_log_at_trx_commit=2` 使提交时只写入 Redo Log 文件，由 OS 择机持久化，但两者在 OS 崩溃时有丢失数据风险。
SlackClimb
248 3
互联网课堂
|
10月前
|
关系型数据库 MySQL 数据库
MySQL日志
本文介绍了MySQL中三个重要的日志：binlog、redolog和undolog。binlog记录数据库更改操作，支持数据恢复、复制和审计；redolog保证事务的原子性和持久性，实现crash-safe；undolog用于事务回滚及MVCC的实现。每个日志都有其独特的作用和应用场景，确保数据库的稳定性和数据一致性。
互联网课堂
180 1

热门文章

最新文章

  • 1
    【紧急救援】MySQL CPU 100%！一套组合拳教你快速定位并解决！
  • 2
    SLS Copilot 实践：基于 SLS 灵活构建 LLM 应用的数据基础设施
  • 3
    MySQL中日期和时间函数的使用指南
  • 4
    别再满世界找日志了：聊聊如何用AI帮运维团队快速排查故障
  • 5
    程序出错瞎找？教你写“会说话”的错误日志，秒定位原因
  • 6
    5 个 IIS 日志记录最佳实践
  • 7
    Kubernetes日志管理：使用Loki进行日志采集
  • 8
    Python日志模块配置：从print到logging的优雅升级指南
  • 9
    SQL日志优化策略：提升数据库日志记录效率
  • 10
    EventLog Analyzer：高效的Web服务器日志监控与审计解决方案
  • 1
    AWK在网络安全中的高效应用：从日志分析到威胁狩猎
    193
  • 2
    警惕日志采集失败的 6 大经典雷区：从本地管理反模式到 LoongCollector 标准实践
    1009
  • 3
    Aipy实战：分析apache2日志中的网站攻击痕迹
    195
  • 4
    【Application Insights】Application Insights存储的Function App的日志存在"Operation Link" 为空的情况
    155
  • 5
    StarRocks+Paimon 落地阿里日志采集：万亿级实时数据秒级查询
    594
  • 6
    日志与追踪的完美融合：OpenTelemetry MDC 实践指南
    498
  • 7
    MySQL日志分析：binlog、redolog、undolog三大日志的深度探讨。
    291
  • 8
    阿里云发布可观测MCP！支持自然语言查询和分析多模态日志
    849
  • 9
    兄弟，你还在翻日志看故障？AI都快替你写日报了！
    486
  • 10
    Tomcat运行日志字符错乱/项目启动时控制台日志乱码问题
    1265

    • 相关课程

    更多
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 阿里云数据库产品家族及特性
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • PostgresChina2018_赖思超_PostgreSQL10_hash索引的WAL日志修改版final
  • Kubernetes下日志实时采集、存储与计算实践
  • 日志数据采集与分析对接

    • 推荐镜像

    更多
  • mysql
    • 下一篇
    阿里云负载均衡收费标准：ALB、NLB和CLB价格，包括LCU费用、实例费和公网带宽价格