- 综合排序
- 最热优先
- 最新优先
- 来自专栏腾讯云混沌工程团队
【云顾问-混沌】云 MySQL 主节点故障
MySQL 主节点故障是指在 MySQL 主从复制架构中，主数据库服务器（主节点）出现问题，无法正常提供数据库服务的情况。主从复制架构通常用于提高数据库的可用性和性能。 MySQL 主节点故障原理 该故障会向实例注入致命错误，来模拟多节点架构实例主节点故障。在故障动作执行期间会出现短暂数据库连接断开或者无法连接状况，进而造成数据库无法访问，请谨慎操作！ 故障注入后，MySQL 实例会进行主从切换，原从节点会成为新主节点，并会在原主可用区拉起新节点作为新备节点。 为何需要进行 MySQL 主节点故障演练？ Mysql 主节点故障演练是为了保证数据库的高可用性和数据的完整性。在分布式数据库系统中，主节点负责处理写操作，同时也会将数据复制到从节点。 进行 MySQL 主节点故障可以让您验证这些方法是否可以保证数据不丢失。在遇到该问题时，您也可以从容地应对～
1.9K10编辑于 2024-03-15 - 来自专栏爱可生开源社区
故障分析 | MySQL 节点宕机分析一例
之前遇到一个问题，用户反馈 MySQL MGR 环境发生了故障切换。作为一名运维，首先应该知道从日志信息里面去找信息。我们很幸运，在对应的时间点，有错误日志信息。 MySQL8.0.18的row0pread.cc, line 727内容： 图片 对比后续版本MySQL 8.0.28和MySQL 8.0.18差异，可以看到MySQL8.0.28中已经去掉了对应ut_a MySQL 8.0.18： 图片 MySQL 8.0.28： 图片 查找变更历史，找到官方对去掉ut_a(!page_cur_is_after_last(&page_cursor))；的描述。 找到MySQL Bug#30060690。涉及到如下bug，详见bug描述。 https://github.com/mysql/mysql-server/commit/911be2d742985f191464c9f2dabcf81e0bac7cbc 图片 根据bug描述，可以看到此
1.2K30编辑于 2022-11-01 - 来自专栏MySQL修行 | 老叶茶馆
MySQL 8.0.23中复制架构从节点自动故障转移
二、 Asynchronous Connection Failover MySQL 8.0.22,推出了异步复制连接故障转移，很多朋友都发文做了介绍，这里我只简单描述下： 1）同机房1主1从，异地机房单独放一个 3）如果对Slave-02配置了“异步连接故障转移配置”，那么Slave-02在识别原Master故障后，会自动尝试按照预先定义好的配置，与原Slave-01（新Master）建立复制关系： ? 这个功能非常好，引用三方工具（例如MHA的修复主从关系）已经可以被MySQL原生功能代替了。 但我测试完，又有了几点疑虑： 1. “异步”复制故障转移，难道不支持半同步架构？ 要预先配置故障转移的Master List，那么A机房架构变更，还要去维护机房B的节点吗？ 答：是的。 3. 最后让我们跑一圈： 1）首先我们有3节点的MGR集群，版本8.0.22（异步连接故障转移，是作用在Slave的IO Thread上的，所以Slave是8.0.23版本就成） +-------------
1.3K20发布于 2021-02-23 - 来自专栏爱可生开源社区
故障分析 | MySQL 优化案例 - 字符集转换
---- 本文关键字：SQL 优化、字符集 相关文章推荐： 故障分析 | MySQL 派生表优化 故障分析 | 有效解决 MySQL 行锁等待超时问题【建议收藏】 一、背景 开发联系我，说是开发库上有一张视图查询速度很慢 二、问题 SQL Server version: 5.7.24-log MySQL Community Server (GPL) 这个 SQL 非常简单，定义如下，其中就引用了 view_dataquality_analysis 那么基本可以验证我的猜想，当 MySQL 创建视图时，如果发现表连接字段字符集不相同时，会自动添加字符集转换。 另外之前我们有个为什么 b 表没有走索引，是因为缺失了索引吗？的疑问。 六、修改字符集 为了验证因为字符集问题而导致表连接没有走索引，我们选择将 b 表 metadata_tablebasicinfo 的字符集修改为 utf8mb4。 其实这个问题有点类似于 int=varchar 隐式转换问题，等号左边为 int 类型，右边为 varchar 类型，那么 MySQL 会自动转换类型为一致，因而无法走索引。
1.6K10发布于 2020-07-02 - 来自专栏GreatSQL出品技术文章
故障解析丨Clone节点导致主从故障
故障解析丨Clone节点导致主从故障 1.背景概述 在一次主从复制架构中，由于主节点binlog损坏，导致从节点无法正常同步数据，只能重做从节点；因此使用MySQL 8.0.17开始提供的clone技术进行恢复 # 安装克隆插件，主从节点都需要 greatsql> install plugin clone soname 'mysql_clone.so'; # 从节点进行clone greatsql> set 9.故障解决 greatsql> alter event event_test DISABLE; Query OK, 0 rows affected (0.01 sec) 关闭从节点的定时任务event 3.总结 1.如果主库有定时任务，通过clone的方式搭建从库，在从库恢复之后需要关闭定时任务，避免主从同时执行定时任务导致主从故障。 MySQL5.7即将停服… 图文结合丨Prometheus+Grafana+GreatSQL性能监控系统搭建指南(下) 聊聊即将到来的MySQL5.7停服事件 GreatSQL社区月报 | 2023.09
48361编辑于 2023-10-25 - 来自专栏MySQL修行 | 老叶茶馆
故障解析丨Clone节点导致主从故障
故障解析丨Clone节点导致主从故障 1.背景概述 在一次主从复制架构中，由于主节点binlog损坏，导致从节点无法正常同步数据，只能重做从节点；因此使用MySQL 8.0.17开始提供的clone技术进行恢复 通过解析binlog发现，同一时刻主从节点都在执行同一条语句，因此询问业务是否在主从节点都执行了定时任务，业务回复定时任务只在主节点执行。 # 安装克隆插件，主从节点都需要 greatsql> install plugin clone soname 'mysql_clone.so'; # 从节点进行clone greatsql> set 9.故障解决 greatsql> alter event event_test DISABLE; Query OK, 0 rows affected (0.01 sec) 关闭从节点的定时任务event 3.总结 1.如果主库有定时任务，通过clone的方式搭建从库，在从库恢复之后需要关闭定时任务，避免主从同时执行定时任务导致主从故障。
36810编辑于 2024-03-02 - 来自专栏学习
【redis】哨兵：人工恢复主节点故障和哨兵自动恢复主节点故障
（多个哨兵节点构成），避免单个哨兵挂了 人工恢复主节点故障 在实际开发中，对于服务器后端开发，监控程序是非常必要的 服务器要求有比较高的可用性，7*24 运行 服务器长期运行，总会有一些“意外”，具体什么时候出现意外 往往还需要搭配“报警程序” 发现服务器的运行状态出现状态异常了 给程序员报警，通知程序员，这个服务器挂了/出问题了（短信/电话/邮件/微信/钉钉/飞书…） 操作流程 运维人员通过监控系统，发现 redis 主节点故障宕机 通过人工干预的做法，就算程序员第一时间看到了报警信息，第一时间处理，也需要消耗较长时间 哨兵自动恢复主节点故障 哨兵节点集合就是多个单独的 redis sentinel 进程（部署在三台不同的服务器上） slaveof 到新的主节点上 哨兵节点会自动的通知客户端程序，告知新的主节点是谁，并且后续客户端再进行写操作，就会针对新的主节点进行操作了 redis 哨兵的核心功能： 监控 自动的故障转移 通知 哨兵集 redis 哨兵节点，有一个也是可以完场上述的需求的 但是： 如果哨兵节点只有一个，其自身也容易出现问题。
39210编辑于 2025-03-25 - 来自专栏爱可生开源社区
故障分析 | 一则 MySQL 从节点 hung 死问题分析
近期，发现一个 MySQL 从节点提示同步异常。执行 show replica status 都被挂起。 :enum_worker_stage::REGISTERED |-this->m_workers.push(worker->id) // 此节点的 4问题总结与建议 4.1 问题总结 综合以上分析过程，导致此次故障的根本原因还是在于数据库的 Redo 配置参数过小，在问题时段从节点的压力下，Redo 的使用率过高，导致 InnoDB 无法完成检查点 并进一步导致从节点的 worker 线程在执行事务时，检查 Redo Log 是否存在有剩余 Log 文件时，而发生等待。 当前一个 worker 线程执行事务挂起后，由于从节点采用 MTS，且 slave_preserve_commit_order=on，因此其它 worker 线程需要等待之前的事务提交，最终导致所有 worker
66510编辑于 2024-04-11 - 来自专栏Java学习网
MySQL数据库，浅谈MySQL集群主从复制
在实际的开发环境中，数据的重要性不言而喻，每一个数据都是有其价值的，提供安全可靠的数据保障是技术与运维部门的职责所在；为了保障数据的安全性，大多数的开发都采用了数据库的主从复制，其中MySQL集群主从复制也是保障 一般情况下,MySQL集群主从复制的具体架构还得看数据量大小来定，数据量规模较小的情况下,使用一主一从的架构的较多。 一主一从的弊端就是容易出现单点故障，一旦主库故障便不能进行写入操作，所以，数据量较大时就需要使用处理高并发的思想来解决问题了，比如:一方面可以做分压处理(Nginx集群，MySQL集群等等)，一方面可以做异步处理 MySql高并发的处理方案就是多主多从，可以极大地提高数据库的容灾能力，降低磁盘I/O访问的评率，提高单个机器的I/O性能。 下面我们来看看MySQL集群主从复制的具体步骤： 1. 总而言之，MySQL集群主从复制的存在是符合客观规律的，既实现服务器负载均衡，又通过复制实现数据的异地备份，从而提高了数据库系统的可用性。
3.4K20发布于 2021-03-29 - 来自专栏仙士可博客
关于mysql集群主从服务器搭建
mysql读写分离 我们可以分析,程序对于mysql的操作无非就2种,写入数据/更新数据(数据变更),读取数据. 数据变更,因为要保证数据可靠以及数据同步问题,无法直接通过开多台服务器解决. mysql集群有着以下几种方式: 1:mysql一主一从,mysql读写分离,使数据库压力分散,提高服务器性能 2:mysql一主多从,当主服务器出问题后,可以选择一台从服务器变更为主服务器,继续提供服务 ,就可以开始搭建主从集群环境了,我们需要准备: 1:2台服务器(虚拟机) 2:2台都需要安装mysql环境 目前我使用的是宝塔安装的mysql 5.6,可以自行安装mysql用于测试. 120 192.168.192.131 rep 123456 3306 60 0 0 1800.000 0 86400 0 [root@localhost data]# 启动从服务器节点 如果你的mysql服务器是直接克隆的,需要注意删除mysql数据目录下的auto.cnf文件,并重启一次服务器,改文件记录了数据库的uuid,如果重复则会出错.
1.6K10发布于 2020-04-16 - 来自专栏DevOps持续集成
MFS-master节点故障切换
1、问题描述： 六个节点底层部署了mfs分布式存储，node4(mfsmaster), 其中node1-6都为mfschunkserver，分别开启了metalogger服务。 准备切换到node6节点中。 2、问题分析： mfsmaster节点宕机，mfsmount挂载失败，需要通过metalogger恢复mfsmaster的数据 3、解决方案： 在node2或者node3节点， 通过metalogger
1.7K10发布于 2019-10-18 - 来自专栏CSDN技术头条
ZooKeeper故障节点替换过程详解
一、环境描述 我的生产环境ZooKeeper 版本3.4.6，5个节点组成的ZooKeeper集群。ZooKeeper集群为一套8个节点的Hadoop集群和HBase 集群提供高可用保障。 二、问题描述 因为某些特殊原因，需要替换掉myid为5（IP：10.10.10.30）的ZooKeeper节点，故障节点IP：10.10.10.30替换为10.10.10.37。 10.10.10.37节点是现有环境的namenode节点，Hadoop用户、相关目录，授权、hosts文件已经满足ZooKeeper的部署要求。 ZooKeeper 节点数一般为奇数个，比如我的环境部署了5个节点的ZooKeeper服务，如果有两个节点的ZooKeeper异常是不会影响ZooKeeper集群对外提供服务的。 七、重启相关服务 部署ZooKeeper节点比较简单，当初部署集群的时候怎么部署的，现在就重新部署一个节点就可以，注意修改zoo.cfg配置文件。
3.1K50发布于 2018-02-13 Hadoop集群故障节点隔离操作指南
一、确认故障节点状态 1.查看集群节点状态 hdfs dfsadmin -report # 显示所有DataNode状态（存活/宕机/存储利用率） 输出中标记为 Dead 或 Decommissioning 二、下线故障节点 1.编辑排除列表文件 在NameNode的 hdfs-site.xml 配置文件中指定 dfs.hosts.exclude 路径： <property> <name -refreshNodes # 强制NameNode重新加载排除列表，触发节点下线: 执行后，故障节点进入 Decommissioning 状态，停止接收新数据写入。 三、终止故障节点服务 1.停止DataNode服务 hadoop-daemon.sh stop datanode # 终止故障节点的DataNode进程 2.停止NodeManager服务 yarn-daemon.sh # 列出受损数据块，触发自动副本修复 2.手动触发数据均衡（可选） hdfs balancer -threshold 10 # 启动Balancer，将故障节点数据迁移至健康节点（阈值默认10%
28510编辑于 2025-12-23- 来自专栏爱可生开源社区
故障分析 | MySQL convert 函数导致的字符集报错处理
作者：徐耀荣 爱可生南区交付服务部 DBA 团队成员，主要负责MySQL故障处理以及相关技术支持。爱好电影，游戏，旅游以及桌球。 ，所以创建视图时 MySQL 会自动使用 convert 函数转换字符集。 从上述原文可知如果 convert 只指定了字符集，那么该结果的排序规则就是所指定字符集的默认规则，由之前的测试情况可知，convert 使用的是 INFORMATION_SCHEMA.COLLATIONS 当需要创建非默认字符集 database / table 时，需要在 sql 中明确指定字符集和排序规则。 使用convert函数转换字符集时，当字段排序规则不是转换后字符集的默认排序规则，需要指定具体的排序规则。
1.5K20编辑于 2023-02-13 - 来自专栏颇忒脱的技术博客
Redis Cluster节点故障探测算法笔记
A：因为在多数派方，这个Master有可能会被Slave顶替，如果允许少数派继续工作，那么就会形成两个Master，造成split brain Q：少数派节点是如何知道自己应该停止工作的？ Q：多数派节点时如何知道自己应该停止工作的？ A：如果这个Cluster要求所有Slots被覆盖，那么当有一个Master处于FAIL状态时，便停止工作，见源码。
1K30发布于 2019-07-10 - 来自专栏我的博客
MySQL主从故障解决
Slave_SQL_Running: No解决 1、在从数据库执行slave stop，停掉同步 2、查看主数据库状态 File: mysql-bin.000003 Position: 1151 10.200.11.224′,master_user=’slave_test’, master_password=’123456′, master_port=3306, master_log_file=’mysql-bin
96960发布于 2018-04-28 - 来自专栏伪架构师
重新加载故障节点上的 Ceph 卷
在 Kubernetes 节点发生故障时，在 40 秒内（由 Controller Manager 的 --node-monitor-grace-period 参数指定），节点进入 NotReady 状态 ，经过 5 分钟（由 --pod-eviction-timeout 参数指定），Master 会开始尝试删除故障节点上的 Pod，然而由于节点已经失控，这些 Pod 会持续处于 Terminating 一旦 Pod 带有一个独占卷，例如我现在使用的 Ceph RBD 卷，情况就会变得更加尴尬：RBD 卷被绑定在故障节点上，PV 映射到这个镜像，PVC 是独占的，无法绑定到新的 Pod，因此该 Pod 节点主机可用 有些情况下，节点作为 Kubernetes Node 的功能无法正常工作，但是节点本身是可用的，例如无法连接到 API Server 的情况。 unmounted volumes=[pvc1]. list of unattached volumes=[pvc1 default-token-97tqr] 此处信息表明，RBD 镜像被占用，接下来我们去故障节点解除这个占用
3.1K20发布于 2020-10-27 - 来自专栏爱可生开源社区
故障分析 | MySQL 无监听端口故障排查
作者：王向爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的处理。擅长数据库故障处理。对数据库技术和 python 有着浓厚的兴趣。 ---前言最近解决了一个比较基础的问题故障，由于排查过程挺有意思，于是就以此为素材写出了本篇文章。故障现场防火墙什么的均正常但是无法被远程访问到。简单的使用客户端登录了一下。 ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)根据以往经验大脑中浮现了几个常见的排查此类故障手法1.排查进程存在 --pid-file=/mysqldata/mysql/data/3308/mysqld.pid --user=mysql --socket=/mysqldata/mysql/data/3308/mysqld.sock 解决方案因为配置 skip-grants-tables 引起无法远程连接 mysql 服务端的故障，解决方法也是非常的简单注释重启。
1.2K20编辑于 2022-09-08 - 来自专栏杨建荣的学习笔记
故障分析 | MySQL 无监听端口故障排查
作者：王向 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的处理。擅长数据库故障处理。对数据库技术和 python 有着浓厚的兴趣。 ---- 前言 最近解决了一个比较基础的问题故障，由于排查过程挺有意思，于是就以此为素材写出了本篇文章。 故障现场 防火墙什么的均正常但是无法被远程访问到。简单的使用客户端登录了一下。 ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111) 根据以往经验大脑中浮现了几个常见的排查此类故障手法 1. 解决方案 因为配置 skip-grants-tables 引起无法远程连接 mysql 服务端的故障，解决方法也是非常的简单注释重启。 本文关键字：#故障排查# ---- 文章推荐： 技术分享 | 国产麒麟 arm 上编译安装 xtrabackup8 技术分享 | MySQL 会受到“Unix千年虫“的影响吗 技术分享 | MHA-MasterFailover
2.6K30编辑于 2022-09-14 - 来自专栏爱可生开源社区
故障分析 | MySQL OOM 故障应如何下手
首先第一个就是 MySQL 自身内存的规划有问题，这就涉及到 mysql 相应的配置参数。 机制，最终 MySQL 无辜躺枪牺牲。” all-important：MySQL 自身内存规划 说到 MySQL 自身的内存规划，最先想到的就是 MySQL 中各种 buffer 的大小，innodb buffer pool 就是最鹤立鸡群的那个 log-file=/tmp/valgrind-mysql.log /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --user=root 注意 MySQL 自身的内存规划，为保证 MySQL 的性能，innodb buffer pool 大小设置要合理，可以根据实例读写负载的情况适当调整 buffer pool 的大小。
2.3K20发布于 2020-04-27
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号