scr系统常见故障及解决办法(故障分析从一则)
scr系统常见故障及解决办法(故障分析从一则)
2024-11-24 10:56:52  作者:踏梦女顽童  网址:https://m.xinb2b.cn/life/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-11-25中老年人和小孩要多喝这道汤三伏天,天气炎热,人体容易流汗,在这样酷暑的天气里,人们要多喝水给身体补充水分,而在日常饮食中,要以清淡为主,而且要多食用富含蛋白质和维生素的食物,好让身体维持健康的状态,安然度过夏天今天厨娘和大家分。
  • 知青往事逝去的恋情(他深爱上一位姑娘被父母拆散)
  • 2024-11-25他深爱上一位姑娘被父母拆散六十九岁的广州知青陈恩义是一位从税务部门退休的老干部,他曾在海南岛开荒种树当了十年的知青,一九七九年秋天才通过顶替接班回到了广州说起在海南岛的知青生涯,陈恩义说他最难忘的就是他的初恋,一位叫小梅的海南。
  • 一国两制在港澳成功实践的意义(总结一国两制实践经验)
  • 2024-11-25总结一国两制实践经验作者:陈欣新(中国社会科学院台湾香港澳门法研究中心主任、研究员)中国恢复对香港行使主权以来,“一国两制”在香港的实践取得了举世瞩目的成绩,也经受了前所未有的挑战实事求是总结“一国两制”在香港实践25年。
  • 比亚迪dm-i超级混动车型实测(比亚迪DM-i是超级混动)
  • 2024-11-25比亚迪DM-i是超级混动有数据反映,DM-i的拖欠量已经超过了20万,达到了一个新的高度即便在如此情况下,依然有大量的用户群体愿意去下定DM-i车型,等车半年也在所不惜,从耐得住性子的用户选择上,我们能够看出来一点,DM-i。
  • 上古卷轴5是什么类型的游戏(为什么上古卷轴5那么好玩)
  • 2024-11-25为什么上古卷轴5那么好玩​自从18年B社的老滚六宣布正在制作以来,已经很久没有再听到更多关于滚6的内容了近日,B社高管PeteHines在回答玩家提问时回复到,《上古卷轴6》还需要许多年才会公布消息呢“老滚6是排在《星空》后。
  • 老爸你还能陪我多长时间(我想和你说说心里话)
  • 2024-11-25我想和你说说心里话原创孤月冷梅情不知所起一往而深和老爸冷战的这段日子有很多心里话想对您说看着您的微信却始终不想拨通视频我知道您有博大的胸怀也早已原谅了这个不懂事的女儿那天和您顶嘴你的心口肯定很疼吧事后我好后悔给了自己两。
  • 动脉硬化闭塞的症状(动脉硬化闭塞症)
  • 2024-11-25动脉硬化闭塞症血管,是输送血液的管道,遍布人体全身血管按构造功能不同,分为动脉血管、静脉血管和毛细血管三种其中,主动脉和大动脉的管壁较厚,含有丰富的弹性纤维,具有可扩张性和弹性当心脏收缩射血时,大动脉管壁会扩张,当。
  • 壹米滴答单号签收后维持多久
  • 2024-11-25壹米滴答单号签收后维持多久壹米滴答单号签收后一般维持7天左右,具体时间会因快递公司不同而有所差异签收后时间较短是为了保证物流精准和客户及时反馈,有效减少客户售后投诉,提高物流效率此外,快递公司采取这种签收后维持一定时间的做法,。
  • 自己缴的社保停缴有影响吗(有什么不好的影响)
  • 2024-11-25有什么不好的影响是有的,社保累计缴费未满15年的,退休后将领不到养老金根据《社会保险法》第十六条,参加基本养老保险的个人,达到法定退休年龄时累计缴费满十五年的,按月领取基本养老金医疗保险中途停止缴费的,停缴期间将中止。
  • 萝卜蒸饺的家常做法大全(萝卜蒸饺要怎样才好吃)
  • 2024-11-25萝卜蒸饺要怎样才好吃家道和----萝卜蒸饺“老板娘,再来一份儿素蒸饺!”“好嘞~”未消散的蒸汽萦绕在一盘儿新鲜出炉的蒸饺上薄薄的饺子皮下是内里的丰满轻轻咬一口萝卜的清香在味蕾处绽放满满幸福感食材皮面粉250g开水150g。
  • 洪欣毕滢和张丹峰最新(港媒曝洪欣备孕三胎)
  • 2024-11-25港媒曝洪欣备孕三胎张丹峰与洪欣之间的感情,一直都是大家茶余饭后讨论的对象,两人的婚姻受到了质疑男方跟经纪人多年保持着暧昧关系,甚至还被狗仔拍到过同居出轨,但奈何洪欣作为原配一直选择退让,丝毫没有正宫对战小三的意思张丹峰。