scr系统常见故障及解决办法(故障分析从一则)
scr系统常见故障及解决办法(故障分析从一则)
2024-09-30 10:41:27  作者:踏梦女顽童  网址:https://m.xinb2b.cn/know/cnq274553.html

作者:李锡超

一个爱笑的江苏苏宁银行 数据库工程师,主要负责数据库日常运维、自动化建设、DMP平台运维。擅长mysql、Python、Oracle,爱好骑行、研究技术。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。

1. 问题现象:

9月15日,收到告警提示测试环境某系统的 MySQL MGR 集群存在异常。

日志内容如下:

// 10.x.y.97 节点MySQL 错误日志提示节点 10.x.y.95 不可达:2022-09-15T19:26:14.320181 08:00 0 "Warning" "MY-011493" "Repl" Plugin group_replication reported: "Member with address 10.x.y.95:3306 has become unreachable." // 随后mgraliver(MGR 探针)日志提示进行了切换:"2022-09-15 19:26:16" : Exception: Invalid primary_member_ip: or secondary_node_list:""10.x.y.96", "10.x.y.97"" ."2022-09-15 19:26:16" : Exception: MGR is likely to be switching, Sleep 1 sec and continue ."2022-09-15 19:27:01" : Exception: MGR running with WARN. ONLINE nodes Pri:10.x.y.96 Sec:10.x.y.97 diff from conf_node:10.x.y.95,10.x.y.96,10.x.y.97 .

即告警提示应用系统 MySQL MGR 发生了切换,由故障前的三节点 MGR 集群,切换为包括 Pri:10.x.y.96 Sec:10.x.y.97 两个节点集群。

2. 初步分析

收到告警后,通过分析MySQL错误日志、操作系统系统、监控日志等信息,发现操作系统的时间存在异常:

具体异常截图,如下图:


即:存在【Time has been changed 】异常。

结合mysql官方文档说明:其明确说明其故障检测基于时间:

如果一个成员在 5 秒内没有收到另一个成员的消息,则怀疑该成员发生故障,并在自己的 Performance Schema 表 replication_group_members 中将该成员的状态列为 UNREACHABLE。如果怀疑持续超过 10 秒,则怀疑成员会尝试将其认为可疑成员有错误的观点传播给该组的其他成员。 具体参考:https://dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure.html

由此初步怀疑是操作系统的时间发生了跳变,触发MySQL MGR发生故障切换。

并将相关异常,反馈系统系统管理部相关老师进行进一步确认。

3. 根本原因

经过系统专家深入分析,确认其根本原因是由于问题时段服务器底层存在异常。

导致 19:27:13左右 虚拟机发生挂起(此时虚拟机的任何操作都不能进行,包括监控脚本、时间、MGR的心跳等)。

虚拟机挂起后,由于除故障节点外的其它两个节点无法与故障节点进行通信,因此认为该节点存在异常并将其驱逐。并最终产生如上告警信息。

至此,该问题得到最终确认。

4. 关于时间对MGR的影响

既然该问题最终确认是由于虚拟机挂起导致主节点被驱逐。那么如果不是挂起,只是虚拟机的时间发生跳变,那还会触发故障切换么??

为此,通过测试环境进行了测试,其测试结论为:

当MGR集群中一个节点时间发生变化后(比如突然快了1小时、慢了1小时),MGR集群的同步状态并不会因此受到影响。error_log 里面也未看到明显的报错!

即:MGR 节点的时间异常,并不会触发MGR发生故障切换。

那具体是什么机制呢??为此结合源码进行确认!!

5. 我们知道,源码中涉及节点间探测,主要包括如下函数(alive_task/detector_task):

函数总体调用关系:

alive_task task_now may_be_dead task_nowdetector_task check_global_node_set DETECT task_now check_local_node_set DETECT task_now// alive_task :int alive_task(task_arg arg MY_ATTRIBUTE((unused))) { while (!xcom_shutdown) { .. // 超过0.5秒,广播我是 alive f (server_active(site, get_nodeno(site)) < task_now() - 0.5) { replace_pax_msg(&ep->i_p, pax_msg_new(alive_synode, site)); ep->i_p->op = i_am_alive_op; send_to_all_site(site, ep->i_p, "alive_task"); } ... { double sec = task_now(); // 超过4秒没有心跳,询问你是否活着 if (i != get_nodeno(site) && may_be_dead(site->detected, i, sec)) { replace_pax_msg(&ep->you_p, pax_msg_new(alive_synode, site)); ep->you_p->op = are_you_alive_op; ep->you_p->a = new_app_data(); ep->you_p->a->app_key.group_id = ep->you_p->a->group_id = get_group_id(site); ep->you_p->a->body.c_t = xcom_boot_type; init_node_list(1, &site->nodes.node_list_val[i], &ep->you_p->a->body.app_u_u.nodes); send_server_msg(site, i, ep->you_p); } } TASK_DELAY(1.0); }}// DETECT #define DETECTOR_LIVE_TIMEOUT 5.0 // 判断心跳是否超时 #define DETECT(site, i) \ (i == get_nodeno(site)) || \ (site->detected[i] DETECTOR_LIVE_TIMEOUT > task_now())static void check_global_node_set(site_def *site, int *notify) { u_int i; u_int nodes = get_maxnodes(site); site->global_node_count = 0; for (i = 0; i < nodes && i < site->global_node_set.node_set_len; i ) { int detect = DETECT(site, i); if (site->global_node_set.node_set_val[i]) site->global_node_count ; // 本次捕获的心跳状态,则表示有节点心跳突变: 无心跳->有心跳 有心跳->无心跳 if (site->global_node_set.node_set_val[i] != detect) { // 需要通知全局状态发生变化 *notify = 1; } DBGOHK(FN; NDBG(i, u); NDBG(*notify, d)); }}static void check_local_node_set(site_def *site, int *notify) { u_int i; u_int nodes = get_maxnodes(site); for (i = 0; i < nodes && i < site->global_node_set.node_set_len; i ) { int detect = DETECT(site, i); // 本次捕获的心跳状态,则表示有节点心跳突变: 无心跳->有心跳 有心跳->无心跳 if (site->local_node_set.node_set_val[i] != detect) { site->local_node_set.node_set_val[i] = detect; // 需要通知本地识别到可疑节点 *notify = 1; } DBGOHK(FN; NDBG(i, u); NDBG(*notify, d)); }}// detector_taskint detector_task(task_arg arg [[maybe_unused]]) { while (!xcom_shutdown) { { site_def *x_site = get_executor_site_rw(); if (x_site && get_nodeno(x_site) != VOID_NODE_NO) { if (x_site != last_x_site) { reset_disjunct_servers(last_x_site, x_site); } update_detected(x_site); if (x_site != last_x_site) { last_x_site = x_site; ep->notify = 1; ep->local_notify = 1; } check_global_node_set(x_site, &ep->notify); //判断是否有节点心跳超时,需要发起全局view变更通知 update_global_count(x_site); //更新全局节点个数 if (ep->notify && iamtheleader(x_site) && enough_live_nodes(x_site)) { ep->notify = 0; send_my_view(x_site);//如果有节点心跳异常,且当前节点是0号主节点,且多数派的节点存活, 则发送视图变更通知,即驱逐心跳异常节点,并处理新节点加入或老节点退出 } } if (x_site && get_nodeno(x_site) != VOID_NODE_NO) { update_global_count(x_site); //更新全局节点个数 check_local_node_set(x_site, &ep->local_notify);//判断是否有节点心跳超时,需要发起suspicion操作 if (ep->local_notify) { ep->local_notify = 0; deliver_view_msg(x_site); //驱逐心跳异常节点 } } } TIMED_TASK_WAIT(&detector_wait, 1.0); } }}

重点

通过阅读以上代码,可知函数 alive_task/detector_task 都通过 task_now() 获取当前时间,并进行判断是否超过对应的阈值。 那么进一步分析 task_now() 逻辑如下:

task_now xcom_init_clock xcom_monotonic_secondssecondsstatic void xcom_init_clock(xcom_clock *clock) { // 调用Linux 的 clock_gettime 函数,获取从系统启动时开始计时,以秒为单位(小于1秒以小数表示)。该时间不受系统影响,也不会被用户改变。 clock->monotonic_start = get_monotonic_time(); // 调用Linux 的 clock_gettime 函数,获取系统时间(如date),以秒为单位(小于1秒以小数表示)。该时间随着系统时间的改变而改变。 clock->real_start = get_real_time(); // 计算系统时间与启动计时的差值(offset) clock->offset = clock->real_start - clock->monotonic_start; // 通过差值 启动计时,得到时间。 xcom_monotonic_seconds(clock); // 修改计算标记为1。此后,只要MGR正常运行,MGR节点所获取时间等于=此处获取的差值(offset) 启动计时。 // 因此,无论系统时间如何变化,MGR都将获取“正确”的时间。 // 具体逻辑见如下代码: clock->done = 1;}static double xcom_monotonic_seconds(xcom_clock *clock) { // 初始化时获取的差值(offset) 启动计时。 clock->now = get_monotonic_time() clock->offset; return clock->now;}// 后续其它操作获取时间的函数:double seconds() { // 当第一步初始化后,!task_timer.done 始终未false if (!task_timer.done) { , xcom_init_clock(&task_timer); } // 因此初始化之后调用seconds()返回 :xcom_monotonic_seconds(&task_timer) return xcom_monotonic_seconds(&task_timer);}double task_now() { // 当第一步初始化后,!task_timer.done 始终未false。 if (!task_timer.done) { xcom_init_clock(&task_timer); } // 直接返回计算的 task_timer.now return task_timer.now;}对于 task_timer.now,通过跟踪发现多个逻辑都在调用,部分位置参考,如下代码栈:

6. debug 验证记录

基于如上代码分析,总结如下:

1). MGR 集群中获取时间=初始化时获取的固定差值(offset) 启动计时。由于offset是不变的值,启动计时在OS正常运行时,是一个恒定增加的数字。 即MGR集群心跳的时间不受系统时间的控制。因此在步骤3,进行测试时,未发现MGR集群存在异常。也确认本次故障确实不是由于时间发生变化而引起。

  • 春天的七种野菜(春天这几种野菜)
  • 2024-10-01春天这几种野菜今天早饭点刚过,村里张明信家的婶子就站在了以往人们聚集晒暖拉呱的向阳地向村头张望着了原来,张婶子家在济南工作的小儿子今天要带女朋友来认们了九点多钟时来晒暖的人陆续多了起来,不大一会功夫,张婶子家的小儿。
  • 大型挖掘机采挖现场(园林树木快速移栽设备)
  • 2024-10-01园林树木快速移栽设备随着人工成本的增加和人工的老龄化,设备取代人工成了趋势挖树机通过刀片切断树根,切口平整,大限度的增加树的存活率,苹果型的土球不仅美观还方便包扎平均1-3分钟挖一棵树,效率是人工的40倍,挖树机认准济宁。
  • 肌酐高不能吃什么水果啊(肌酐高什么水果不能吃啊)
  • 2024-10-01肌酐高什么水果不能吃啊一般对不能吃的水果要分几大类含钾高类水果,主要包括西瓜,葡萄,香蕉,西红柿等肾功能不全,肌酐高,肾脏排泄功能很弱,容易引起高钾血症,所以这一类水果不能吃尽量避免含盐高的食物,因为肌酐高容易引起高血压,。
  • 粥店开在哪里比较合适(如何开好一家粥店)
  • 2024-10-01如何开好一家粥店开一家粥店如何能做好?其实,开好一家粥店是有门道的最主要的是品牌的选择和定位,以及口味和灵活性下面麦玲粥店那个爱管闲事的小编就告诉你,开一家粥店如何能做好?诀窍在这里!1.顾客可以每天从早到晚4餐(早。
  • 82版西游记嫦娥扮演者
  • 2024-10-0182版西游记嫦娥扮演者扮演者是邱佩宁,原名邱沛宁,1958年6月23日出生于中华人民共和国北京市,中国内地女演员,毕业于中央民族学院艺术系舞蹈专业1986年因在央视版《西游记》中扮演嫦娥一角而为西游记迷们所熟悉1974年至。
  • 财务管理制度与报销制度(财务人员岗位职责)
  • 2024-10-01财务人员岗位职责财务经理:1.协助财务总监建立并完善企业财务管理体系,对财务部门的日常管理、财务预算、资金运作等各项工作进行总体控制,提升企业财务管理水平2.根据企业中、长期经营计划,组织编制企业年度财务工作计划与控。
  • 累的经典句子(累的经典句子有啥)
  • 2024-10-01累的经典句子有啥生存即苦难,活着即炼狱,我们无处可逃只有一棵树目睹了我的眼泪还有我藏在心里的深深深深的忧伤每个伤口都像是一朵黑色的曼陀罗,一边妖艳一边疼痛,并且涌动无穷无尽的黑色暗香靠着别人给的快乐好累、从今以后、自。
  • 初学化妆该买哪些化妆品(到底该买什么化妆品)
  • 2024-10-01到底该买什么化妆品作为初学者你是不是还在买初学者必备集美白隔离防晒一体的万能霜!!网上呼声最高的性价比隔离霜!吊炸天的feel!2.谜尚大红bb霜(160/支)超保湿!很滋润!很服帖!而且也是远近闻名唯一一点就是持久的。
  • 欧尚z6 这款车怎么样(2.0T爆233马力配爱信8AT变速箱)
  • 2024-10-012.0T爆233马力配爱信8AT变速箱不得不说,哈弗H6确实是SUV市场上的“常青树”,历经三代车型更迭的它,每一代车型的销量都可圈可点,尽管第三代车型的价格更贵了,可是并没有阻挡它在销量上继续“披荆斩棘”,哈弗H6依然是15万级国产SU。
  • 芜湖电子通行证在哪(芜湖市区禁区通行证可以便捷办理)
  • 2024-10-01芜湖市区禁区通行证可以便捷办理记者20日从芜湖市公安局交警支队获悉,为切实做好疫情防控期间企业复工复产、工人返岗过程中的道路交通保障工作,坚决贯彻落实相关指示精神,有效保障企业货运、客运及单位通勤车辆市区禁区通行证便捷、高效办理,。
  • 苏东坡一生都去过哪(假如苏东坡在消博会逛展)
  • 2024-10-01假如苏东坡在消博会逛展今天(7月24日)海南日报继续以整版的篇幅推出“东坡逛消博”特别报道2022年7月24日海南日报A05版版面图余生欲老海南村聚四海宾朋,汇天下奇珍,盛会引消费新潮,海南添乐活魅力第二届消博会如约而至,。
  • 一战中最残酷的战役(一战时期人类历史上最惨的一场战役)
  • 2024-10-01一战时期人类历史上最惨的一场战役#新作者扶植计划第二期#凡尔登战役,被称作凡尔登绞肉机,是第一次世界大战期间最惨烈的战役,但是索姆河战役和凡尔登战役相比起来丝毫不逊色索姆河战役是第一次世界大战期间一场规模最大的会战当时英法联军在索姆。