- 综合排序
- 最热优先
- 最新优先
- 来自专栏用户1175783的专栏
# 故障恢复
auto_increment_offset = 2 auto_increment_increment = 2 log-slave-updates = true relay-log=mysql-relay relay-log=mysql-relay log-slave-updates = true [mysqld2] auto_increment_offset = 2 auto_increment_increment ，在自动切换主从时有用 set global read_only=1; 1 # 故障恢复 如果master宕机后恢复 对新的master节点加全库只读锁，阻止所有写入操作，并计下master节点当前得 binlog信息，然后备份数据并恢复到宕机得节点中，恢复完成后让宕机得节点作为slave加入当前master节点。 slave节点宕机后恢复 通常只需要重启slave节点就行，无需其它操作
1.1K20发布于 2020-05-09 - 来自专栏玖叁叁
DestinationRule故障恢复策略
DestinationRule故障恢复策略在分布式系统中，故障恢复策略是保证服务高可用性和稳定性的关键因素之一。 在Istio中，我们可以通过DestinationRule对象来定义故障恢复策略，并通过Outlier Detection机制来实现服务故障的自动排除和恢复。 以下是一个DestinationRule故障恢复策略的示例：apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: baseEjectionTime: 60s maxEjectionPercent: 50在上述配置中，我们为DestinationRule对象定义了一个Outlier Detection故障恢复策略 参数用于定义故障服务的最大排除比例。
30931编辑于 2023-05-05 - 来自专栏深度学习与python
构建故障恢复系统
请注意，这篇文章将着重于微服务设计中的健壮性和故障恢复，尤其着重于微服务间的通信与故障恢复。 故障与恢复 其基本可以分成两大大类： 服务之间的故障：这些是在 Capillary 内运行的其他微型服务 基础设施级别的通信故障：这些故障可能包含基础设施组件，如数据库（MySQL）、队列（RabbitMQ 识别问题： 任何恢复工作首先要了解故障。了解问题是否存在、问题在何处，以及问题是什么，这对处理故障缓解问题的工程师来说非常关键。 以前，所有这些故障都与整个产品的故障相对应，但现在，在重试之后，这些故障得到了自动恢复。 target=https%3A%2F%2Fmedium.com%2Fcapillary-tech%2Ftowards-building-a-failure-resilient-system-82885a6204b
1.4K20编辑于 2023-03-29 - 来自专栏全栈程序员必看
rabbitmq集群故障恢复详解
2. ha-mode参数和durable declare对exclusive队列都不生效，因为exclusive队列是连接独占的，当连接断开，队列自动删除。 2)选举最老的slave为master。若此时所有slave处于未同步状态，则未同步部分消息丢失。 或者先启动A，再在30秒之内启动B即可恢复镜像队列。 * 场景2: A, B同时停。 该场景可能是由掉电等原因造成，只需在30秒之内连续启动A和B即可恢复镜像队列。 * 场景3：A先停，B后停，且A无法恢复。 最后将新的slave节点加入C即可重新恢复镜像队列。 * 场景6：A先停，B后停，且A、B均无法恢复，且无法得到A或B的磁盘文件。 洗洗睡吧，该场景下已无法恢复A、B队列中的内容了。
87320编辑于 2022-07-20 - 来自专栏学习
【redis】哨兵：人工恢复主节点故障和哨兵自动恢复主节点故障
20250323223036_347.png]] redis-sentinel：不负责存储数据，只是对其他的 redis-server 进程起到监控作用 通常哨兵节点也会搞一个集合（多个哨兵节点构成），避免单个哨兵挂了 人工恢复主节点故障 报警程序” 发现服务器的运行状态出现状态异常了 给程序员报警，通知程序员，这个服务器挂了/出问题了（短信/电话/邮件/微信/钉钉/飞书…） 操作流程 运维人员通过监控系统，发现 redis 主节点故障宕机 ，程序员如何恢复？ 通过人工干预的做法，就算程序员第一时间看到了报警信息，第一时间处理，也需要消耗较长时间 哨兵自动恢复主节点故障 哨兵节点集合就是多个单独的 redis sentinel 进程（部署在三台不同的服务器上） 万一这个哨兵节点挂了，redis 节点也挂了，就无法进行自动的恢复过程了 哨兵节点出现误判的概率也比较高。
39410编辑于 2025-03-25 CVM 常见故障恢复
.本文将对常见的 CVM 软件故障进行分析,并介绍快速恢复的办法.2 基本原理2.1 基本操作流程CVM故障时通常已经无法正常进入操作系统,此时需要在救援模式下启动另外一个 OS来修复当前系统下的问题. ,特别是日志文件占用特别大.处理方法就是将旧的日志文件删除,退出救援模式后,重启就可以恢复了.3.2 磁盘信息变化带有本地盘的 CVM,例如:IT型号的机器,裸金属机器,以及某些 GPU 机型,若所在母机发生故障换盘了 .若无法恢复,则建议客户备份出数据后重装系统.备份数据的操作可以在救援模式下进行.4 问题讨论1) 如何减少 CVM 故障发生? ,记得创建快照.这样当发现CVM异常时可以选择某个正常时间点的快照迅速回滚恢复. “道路千万条,安全第一条”,创建快照无疑是最重要的手段.2) 不同操作系统如何进入救援模式?腾讯云控制台提供的救援模式镜像当前只有 CentOS.
1.5K21编辑于 2024-02-08- 来自专栏MyBatis入门案例-注解
namenode出现故障后，如何恢复？？
value>file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/dfs/nn/snn/edits</value> </property> 故障恢复步骤
1.2K20发布于 2021-02-05 - 来自专栏大数据成长之路
HDFS中namenode故障恢复(8)
value>file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/dfs/nn/snn/edits</value> </property> 故障恢复步骤 hadoopDatas/namenodeDatas/* rm -rf /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits/* 2. start-all.sh 4.浏览器页面正常访问 http://xxxx:50070/explorer.html#/【xxxx为namenode所在节点的ip】 发现一切正常,说明故障恢复成功
58610发布于 2021-01-22 - 来自专栏数据库
数据库的故障恢复
，可以说，数据库中事务的ACID特性的保障有很大一部分都源于数据库的故障恢复功能，在数据库的编写代码中，有10%左右的代码都是关于故障恢复，本文旨在介绍数据库的故障恢复类型以及恢复手段 前置知识 在了解故障恢复机制之前 数据库故障恢复 故障类型 数据库的故障主要有以下几个方面： 事务故障：该类型故障主要是某一个程序(事务)自身运行错误所引起的故障，它会影响该程序本身 系统故障：由于外界因素(掉电、非正常关机)引起的故障 ，数据库制定了不同的恢复策略： 事务故障恢复 由于事务故障时程序本身运行错误导致的，因此我们通过使用重做日志(Redo Log)与撤销日志(Undo Log)进行解决，对此可以看我的这篇文章：https ，我们从检查点开始查看运行日志，在故障点前结束的事务（红色实线）就重做(Redo Log)，故障点前未结束的事务进行撤销(Undo Log) 介质故障恢复 对于介质故障恢复，也就是磁盘的数据丢失，我们可以通过增加副本来恢复 ，因此当发生介质故障恢复时，我们会从运行日志的转储点开始对备份文件进行恢复： 至此，我们便解决了数据库中的故障恢复，数据库通过事务的撤销与重做、运行日志和备份来进行故障恢复，保证事务的原子性与一致性，提高数据库的可靠性
1K10编辑于 2024-12-11 - 来自专栏MySQL参数系列
orchestrator系列(二)--故障检测与恢复
2、检测和恢复（Detection and recovery） 检测并不总是导致恢复。 有一些情况下不希望进行恢复： *集群没有被列为自动故障转移的候选项； 管理员指示不应在特定服务器上进行恢复； 管理员全局禁用了恢复操作； 在之前的故障转移完成后不久，进行了反复操作； 故障类型被认为不值得进行恢复 countReplicas}' >> /tmp/recovery.log" ], } MySQL 侧设置： set global slave_net_timeout = 4 在从库和主库之间设置一个较短（2秒 对于短暂的网络问题，此设置尝试快速恢复复制，如果成功，将避免由协调器执行的一般故障/恢复操作。 特别是，它可以从主服务器或中间主服务器的故障中恢复。 自动和手动恢复 orchestrator 支持以下恢复方式： 自动恢复（在意外故障时采取行动）。 优雅、计划的主库提升。 手动恢复。
94621编辑于 2023-09-08 - 来自专栏数据和云
经典故障：四个雷，3*2*2*3种随机方法的特殊恢复案例
墨墨导读：恢复专家前辈给我们精心准备了个故障，埋了四个雷，整个恢复过程感觉像是过山车，整理分享至此，希望对大家有帮助。 恢复文件 就给一个压缩的system，起库。 ? ? 恢复过程 首先，获取system文件的字符集，数据库名，然后创建参数文件，重建控制文件，这里就不过多介绍，话不多说，先尝试启动数据库。 number 27 with name "$" too small Process ID: 17397 Session ID: 1 Serial number: 5 ORA-01555快照过旧的报错，这个故障熟悉又陌生 og=3,plh=0,tim=1587333670689090 BINDS #140193661586512: event 10046 trace 发现在访问块241的时候出现故障，这里我们就去看看这个块到底有什么问题 ROWS=n buffer=102400000 总结 通过这个3x2x2x3种随机方法来处理这个异常恢复案例分享，希望大家有所收获。
76720发布于 2020-06-24 - 来自专栏Hadoop实操
CDH高可用集群误删NameNode故障恢复
异常如下 [whelwyqz2l.jpeg] 2.问题复现 ---- 测试环境： CDH5.11.2 1.一个健康集群并配置了HA [d5zj2n231u.jpeg] [gj1dq41gmp.jpeg] 2.停止StandbyNameNode服务并删除 [apf41djab9.png] [np3x4nxo0g.jpeg] 3.集群异常 [2gx2iuhe6r.jpeg] 4.再次通过CM启用HA [njd8n9ps9p.jpeg 3.解决方法 ---- 1.向集群添加一个新的NameNode角色 [206390w3xi.jpeg] [98kibf80h.jpeg] 新增NN角色 [x05u8gi1p1.jpeg] 2.添加完成NN 后集群异常如下 [vp2f7r7c2z.jpeg] 3.修改新增角色的配置如下 [q1qyz6m06e.jpeg] [1odw67lmkl.jpeg] [dwgh9w2oxs.jpeg] 4.保存以上修改的配置后 ，回到CM主页 [vaqlq4qw71.jpeg] [66swhmovey.jpeg] [kxs7o6pmk2.png] [t5iya8laue.jpeg] 5.重启完成集群恢复正常 [7688tzw5h8
3.1K120发布于 2018-03-29 大模型训练故障恢复效率提升方案
在这种资源密集型场景下，硬件和软件故障频发，有时每天会发生多次。 传统容错方案依赖网络存储服务器定期保存模型状态检查点（通常每3小时一次），但存在两个显著缺陷：1）向远程存储写入检查点需30-40分钟；2）故障后恢复检查点需额外10-20分钟。 这导致每次故障可能损失数小时训练进度。 内存采用双缓冲机制：当一半缓冲区向CPU传输数据时，另一半接收新检查点数据检查点分块传输以避免GPU内存溢出性能验证在三种主流大语言模型训练中测试支持每次训练迭代后进行检查点保存相比优化后的远程存储方案，故障恢复时间减少 系统同时保留向远程存储写入检查点的能力，用于迁移学习、模型调试等非故障恢复场景。
37110编辑于 2025-08-05- 来自专栏技术成长
MySQL进行故障恢复以及处理长事务
MySQL在发生故障时，可以通过以下步骤进行故障恢复：检测故障：MySQL会通过日志和错误日志来检测和记录故障信息，例如错误的查询或者数据库服务的崩溃。 自动故障恢复：MySQL InnoDB存储引擎具有自动故障恢复能力。当MySQL重启时，InnoDB会检查其日志文件，并根据日志文件进行恢复操作。 使用二进制日志进行故障恢复：MySQL可以使用二进制日志来进行故障恢复。二进制日志记录了数据库中的所有更改操作。当数据库重新启动时，可以使用二进制日志重放的方式将更改应用到故障前的状态。 使用物理备份进行故障恢复：如果MySQL数据库无法通过自动故障恢复或二进制日志进行恢复，可以使用物理备份进行恢复。物理备份是对数据库的完整副本，可以将备份恢复到故障前的状态。 需要注意的是，故障恢复的具体步骤和策略会根据故障的类型和严重程度而有所不同。此外，MySQL的不同版本可能还会有不同的故障恢复机制。
78471编辑于 2023-11-07 - 来自专栏Spark学习技巧
3，Structured Streaming使用checkpoint进行故障恢复
使用checkpoint进行故障恢复 如果发生故障或关机，可以恢复之前的查询的进度和状态，并从停止的地方继续执行。这是使用Checkpoint和预写日志完成的。
1.3K40发布于 2018-06-22 - 来自专栏ytkah
微信部分功能故障 已全部恢复
今天下午，微信部分功能出现故障，影响公众号、支付、搜索、小程序等功能的正常使用，目前已经全部恢复。 现在卡券、微信支付、搜索、小程序等功能，全部都可以正常使用了。
1.1K70发布于 2018-03-06 - 来自专栏开源部署
GreenPlum数据库故障恢复测试
本文介绍gpdb的master故障及恢复测试以及segment故障恢复测试。 INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 5.5.0 build commit:67afa18296aa238d53a2dfcc724da60ed2f944f0 master Greenplum Version: 'PostgreSQL 8.3.23 (Greenplum Database 5.5.0 build commit:67afa18296aa238d53a2dfcc724da60ed2f944f0 select * from gp_segment_configuration; 4、这里可能需要同步配置一下pg_hba.conf文件，才能通过客户端进行远程连接 到这里我们已经完成了master节点的故障切换工作 当standby 提升为master的时候，原master服务器从故障中恢复过来，需要以standby的角色加入 2、在原master服务器225上的数据进行备份 cd master/ lsgpseg
1.2K30编辑于 2022-08-16 大模型训练故障恢复效率提升方案
大模型训练故障恢复效率提升方案背景挑战当前大型机器学习模型（如生成式语言模型或视觉语言模型）的训练需要分布在数千甚至数万个GPU上。即使采用如此大规模的并行处理，训练过程仍经常持续数月。 在这种大规模资源部署下，硬件和软件故障频发，通常每天会发生多次。为了减少资源故障时的工作浪费，大模型训练流程采用检查点技术，即定期将模型状态复制到网络存储服务器。 如果发生资源故障，训练必须回退到最后一次检查点，可能导致数小时的工作损失。此外，从存储检索检查点还需要10-20分钟。若每天发生多次故障，将严重拖慢训练进度。 这使得检查点保存和检索效率大幅提升，甚至可以每个训练步骤后都执行检查点保存，从而显著减少故障导致的训练回退。 技术架构优势实现检查点保存与训练通信流量的高效共存通过分层存储策略支持故障恢复、迁移学习和模型调试等多重需求在保证训练效率的同时显著提升系统容错能力该方案为大规模分布式机器学习训练提供了更可靠的故障恢复机制
28210编辑于 2025-09-28YashanDB日志管理及故障恢复实战指南
日志管理作为数据库核心机制之一，对于保障数据的持久化、支持事务的原子性及实现故障恢复具有重要作用。 2. 归档日志文件：redo日志文件达到一定容量或触发特定条件时，将其保存为归档日志，便于基于时间点的恢复（PITR）及备库数据同步。归档日志管理支持日志的传输、存储及清理策略。3. 该缓存设计确保日志数据顺序一致，可支持主备复制和故障恢复需求。 故障恢复流程YashanDB的故障恢复基于redo日志的回放和undo数据的回滚，能够有效地恢复数据库至崩溃前的正确状态，保障数据完整性。详细流程包括：1. 检查点机制：定期触发全量或增量检查点，将缓存中的脏页批量刷新到数据文件，减少实例恢复时的回放区间。检查点触发场景包括数据库关闭、系统时间间隔和表空间调整。2.
27110编辑于 2025-08-20- 来自专栏数据和云
故障恢复：一次底层超融合故障导致的异常处理
墨墨导读：底层超融合故障导致数据库产生较多坏块，最终导致数据库宕机。 背景概述 某客户数据由于底层超融合故障导致数据库产生有大量的坏块，最终导致数据库宕机，通过数据抢救，恢复了全部的数据。 下面是详细的故障分析诊断过程，以及详细的解决方案描述： 故障现象 数据库宕机之后，现场工程师开始用rman备份恢复数据库，当数据库alert日志提示控制文件有大量坏块。 ? 恢复过程 客户只restore了数据，通过编写脚本recover数据库。 ? recover失败提示控制文件有坏块 ? 发现控制文件已经损坏，开始重建控制文件 ? 查看x$kcvfh.afs，发现都为0，不需要介质恢复。 ? ? 通过添加参数尝试打开 *._allow_resetlogs_corruption=TRUE *. 后台日志出现undotbs2有坏块，尝试重建undo ?
1K20发布于 2020-08-18
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号