- 综合排序
- 最热优先
- 最新优先
- 来自专栏用户1175783的专栏
# 故障恢复
mysqld] read_only=1 1 2 通过sql命令（配合第一种方式使用） 该命令需要超级管理员才有权限执行，在自动切换主从时有用 set global read_only=1; 1 # 故障恢复 如果master宕机后恢复 对新的master节点加全库只读锁，阻止所有写入操作，并计下master节点当前得binlog信息，然后备份数据并恢复到宕机得节点中，恢复完成后让宕机得节点作为slave 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故障恢复策略 参数用于定义故障服务的最大排除比例。
30231编辑于 2023-05-05 - 来自专栏深度学习与python
构建故障恢复系统
请注意，这篇文章将着重于微服务设计中的健壮性和故障恢复，尤其着重于微服务间的通信与故障恢复。 故障与恢复 其基本可以分成两大大类： 服务之间的故障：这些是在 Capillary 内运行的其他微型服务 基础设施级别的通信故障：这些故障可能包含基础设施组件，如数据库（MySQL）、队列（RabbitMQ 识别问题： 任何恢复工作首先要了解故障。了解问题是否存在、问题在何处，以及问题是什么，这对处理故障缓解问题的工程师来说非常关键。 故障恢复前的弹性： 如果其中一个服务实例发生故障，服务的职责仍然必须得到满足。微服务应当横向扩展，以允许多个实例，确保如果服务的一个实例发生故障，其他实例可以接管并响应调用者的服务。 以前，所有这些故障都与整个产品的故障相对应，但现在，在重试之后，这些故障得到了自动恢复。
1.4K20编辑于 2023-03-29 - 来自专栏全栈程序员必看
rabbitmq集群故障恢复详解
要恢复镜像队列，可以尝试在30秒之内同时启 动所有节点。 8. 或者先启动A，再在30秒之内启动B即可恢复镜像队列。 * 场景2: A, B同时停。 该场景可能是由掉电等原因造成，只需在30秒之内连续启动A和B即可恢复镜像队列。 * 场景3：A先停，B后停，且A无法恢复。 最后 将新的slave节点加入A即可重新恢复镜像队列。 * 场景5: A先停，B后停，且A、B均无法恢复，但是能得到A或B的磁盘文件。 该场景是场景4的加强版，更加难处理。 最后将新的slave节点加入C即可重新恢复镜像队列。 * 场景6：A先停，B后停，且A、B均无法恢复，且无法得到A或B的磁盘文件。 洗洗睡吧，该场景下已无法恢复A、B队列中的内容了。
86320编辑于 2022-07-20 - 来自专栏学习
【redis】哨兵：人工恢复主节点故障和哨兵自动恢复主节点故障
20250323223036_347.png]] redis-sentinel：不负责存储数据，只是对其他的 redis-server 进程起到监控作用 通常哨兵节点也会搞一个集合（多个哨兵节点构成），避免单个哨兵挂了 人工恢复主节点故障 报警程序” 发现服务器的运行状态出现状态异常了 给程序员报警，通知程序员，这个服务器挂了/出问题了（短信/电话/邮件/微信/钉钉/飞书…） 操作流程 运维人员通过监控系统，发现 redis 主节点故障宕机 ，程序员如何恢复？ 通过人工干预的做法，就算程序员第一时间看到了报警信息，第一时间处理，也需要消耗较长时间 哨兵自动恢复主节点故障 哨兵节点集合就是多个单独的 redis sentinel 进程（部署在三台不同的服务器上） 万一这个哨兵节点挂了，redis 节点也挂了，就无法进行自动的恢复过程了 哨兵节点出现误判的概率也比较高。
39010编辑于 2025-03-25 CVM 常见故障恢复
1 背景CVM (Cloud Virtual Machine) 是运行在云上的虚拟机.云上环境使其能够自由迁移,具备了规避绝大多数硬件故障的能力.但是由于各种各样的原因,有时候也难免出现软件故障导致无法使用 .本文将对常见的 CVM 软件故障进行分析,并介绍快速恢复的办法.2 基本原理2.1 基本操作流程CVM故障时通常已经无法正常进入操作系统,此时需要在救援模式下启动另外一个 OS来修复当前系统下的问题. 其基本步骤为:进入救援模式;挂载故障 CVM磁盘;排查并修复问题;退出救援模式.其基本流程如下图所示:2.2 操作步骤说明进入救援模式可以通过登录腾讯云控制台,找到故障的CVM 实例,在菜单:更多->运维与检测 ,特别是日志文件占用特别大.处理方法就是将旧的日志文件删除,退出救援模式后,重启就可以恢复了.3.2 磁盘信息变化带有本地盘的 CVM,例如:IT型号的机器,裸金属机器,以及某些 GPU 机型,若所在母机发生故障换盘了 .若无法恢复,则建议客户备份出数据后重装系统.备份数据的操作可以在救援模式下进行.4 问题讨论1) 如何减少 CVM 故障发生?
1.3K21编辑于 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 - 来自专栏数据库
数据库的故障恢复
，可以说，数据库中事务的ACID特性的保障有很大一部分都源于数据库的故障恢复功能，在数据库的编写代码中，有10%左右的代码都是关于故障恢复，本文旨在介绍数据库的故障恢复类型以及恢复手段 前置知识 在了解故障恢复机制之前 数据库故障恢复 故障类型 数据库的故障主要有以下几个方面： 事务故障：该类型故障主要是某一个程序(事务)自身运行错误所引起的故障，它会影响该程序本身 系统故障：由于外界因素(掉电、非正常关机)引起的故障 ，数据库制定了不同的恢复策略： 事务故障恢复 由于事务故障时程序本身运行错误导致的，因此我们通过使用重做日志(Redo Log)与撤销日志(Undo Log)进行解决，对此可以看我的这篇文章：https ，我们从检查点开始查看运行日志，在故障点前结束的事务（红色实线）就重做(Redo Log)，故障点前未结束的事务进行撤销(Undo Log) 介质故障恢复 对于介质故障恢复，也就是磁盘的数据丢失，我们可以通过增加副本来恢复 ，因此当发生介质故障恢复时，我们会从运行日志的转储点开始对备份文件进行恢复： 至此，我们便解决了数据库中的故障恢复，数据库通过事务的撤销与重做、运行日志和备份来进行故障恢复，保证事务的原子性与一致性，提高数据库的可靠性
99710编辑于 2024-12-11 - 来自专栏大数据成长之路
HDFS中namenode故障恢复(8)
value>file:///export/servers/Hadoop-2.6.0-cdh5.14.0/HadoopDatas/dfs/nn/snn/edits</value> </property> 故障恢复步骤 start-all.sh 4.浏览器页面正常访问 http://xxxx:50070/explorer.html#/【xxxx为namenode所在节点的ip】 发现一切正常,说明故障恢复成功
58110发布于 2021-01-22 - 来自专栏MySQL参数系列
orchestrator系列(二)--故障检测与恢复
有一些情况下不希望进行恢复： *集群没有被列为自动故障转移的候选项； 管理员指示不应在特定服务器上进行恢复； 管理员全局禁用了恢复操作； 在之前的故障转移完成后不久，进行了反复操作； 故障类型被认为不值得进行恢复 在其他情况下，例如被阻止的恢复，恢复可能在检测后的几分钟内进行。* 检测是独立于恢复的，并且始终处于启用状态。 对于短暂的网络问题，此设置尝试快速恢复复制，如果成功，将避免由协调器执行的一般故障/恢复操作。 orchestrator 能够从一系列故障场景中进行恢复。 特别是，它可以从主服务器或中间主服务器的故障中恢复。 自动和手动恢复 orchestrator 支持以下恢复方式： 自动恢复（在意外故障时采取行动）。 优雅、计划的主库提升。 手动恢复。
93621编辑于 2023-09-08 - 来自专栏Hadoop实操
CDH高可用集群误删NameNode故障恢复
4.保存以上修改的配置后，回到CM主页 [vaqlq4qw71.jpeg] [66swhmovey.jpeg] [kxs7o6pmk2.png] [t5iya8laue.jpeg] 5.重启完成集群恢复正常
3.1K120发布于 2018-03-29 大模型训练故障恢复效率提升方案
在这种资源密集型场景下，硬件和软件故障频发，有时每天会发生多次。 传统容错方案依赖网络存储服务器定期保存模型状态检查点（通常每3小时一次），但存在两个显著缺陷：1）向远程存储写入检查点需30-40分钟；2）故障后恢复检查点需额外10-20分钟。 这导致每次故障可能损失数小时训练进度。 内存采用双缓冲机制：当一半缓冲区向CPU传输数据时，另一半接收新检查点数据检查点分块传输以避免GPU内存溢出性能验证在三种主流大语言模型训练中测试支持每次训练迭代后进行检查点保存相比优化后的远程存储方案，故障恢复时间减少 系统同时保留向远程存储写入检查点的能力，用于迁移学习、模型调试等非故障恢复场景。
34910编辑于 2025-08-05- 来自专栏技术成长
MySQL进行故障恢复以及处理长事务
MySQL在发生故障时，可以通过以下步骤进行故障恢复：检测故障：MySQL会通过日志和错误日志来检测和记录故障信息，例如错误的查询或者数据库服务的崩溃。 自动故障恢复：MySQL InnoDB存储引擎具有自动故障恢复能力。当MySQL重启时，InnoDB会检查其日志文件，并根据日志文件进行恢复操作。 使用二进制日志进行故障恢复：MySQL可以使用二进制日志来进行故障恢复。二进制日志记录了数据库中的所有更改操作。当数据库重新启动时，可以使用二进制日志重放的方式将更改应用到故障前的状态。 使用物理备份进行故障恢复：如果MySQL数据库无法通过自动故障恢复或二进制日志进行恢复，可以使用物理备份进行恢复。物理备份是对数据库的完整副本，可以将备份恢复到故障前的状态。 需要注意的是，故障恢复的具体步骤和策略会根据故障的类型和严重程度而有所不同。此外，MySQL的不同版本可能还会有不同的故障恢复机制。
78271编辑于 2023-11-07 - 来自专栏Spark学习技巧
3，Structured Streaming使用checkpoint进行故障恢复
使用checkpoint进行故障恢复 如果发生故障或关机，可以恢复之前的查询的进度和状态，并从停止的地方继续执行。这是使用Checkpoint和预写日志完成的。
1.3K40发布于 2018-06-22 YashanDB日志管理及故障恢复实战指南
日志管理作为数据库核心机制之一，对于保障数据的持久化、支持事务的原子性及实现故障恢复具有重要作用。 该缓存设计确保日志数据顺序一致，可支持主备复制和故障恢复需求。 故障恢复流程YashanDB的故障恢复基于redo日志的回放和undo数据的回滚，能够有效地恢复数据库至崩溃前的正确状态，保障数据完整性。详细流程包括：1. 结论YashanDB以其完善的日志体系与高效的故障恢复机制，为业务系统提供稳定可靠的数据保障。 通过合理配置与运用这些技术手段，可以显著提升数据库的稳定运行能力和故障恢复效率。
25810编辑于 2025-08-20- 来自专栏开源部署
GreenPlum数据库故障恢复测试
本文介绍gpdb的master故障及恢复测试以及segment故障恢复测试。 select * from gp_segment_configuration; 4、这里可能需要同步配置一下pg_hba.conf文件，才能通过客户端进行远程连接 到这里我们已经完成了master节点的故障切换工作 当standby 提升为master的时候，原master服务器从故障中恢复过来，需要以standby的角色加入 2、在原master服务器225上的数据进行备份 cd master/ lsgpseg 重新加入集群 cd master/ mv gpseg-1/ backupgpseg-1 7、在master上重启集群 gpstop -M immediate gpstart -a 8、在master上恢复集群 $ gprecoverseg 虽然所有的segment均已启动，但server11上有还是有两组的primary segment 9、在master上恢复segment节点分布到原始状态 $ gprecoverseg
1.1K30编辑于 2022-08-16 大模型训练故障恢复效率提升方案
大模型训练故障恢复效率提升方案背景挑战当前大型机器学习模型（如生成式语言模型或视觉语言模型）的训练需要分布在数千甚至数万个GPU上。即使采用如此大规模的并行处理，训练过程仍经常持续数月。 在这种大规模资源部署下，硬件和软件故障频发，通常每天会发生多次。为了减少资源故障时的工作浪费，大模型训练流程采用检查点技术，即定期将模型状态复制到网络存储服务器。 如果发生资源故障，训练必须回退到最后一次检查点，可能导致数小时的工作损失。此外，从存储检索检查点还需要10-20分钟。若每天发生多次故障，将严重拖慢训练进度。 这使得检查点保存和检索效率大幅提升，甚至可以每个训练步骤后都执行检查点保存，从而显著减少故障导致的训练回退。 技术架构优势实现检查点保存与训练通信流量的高效共存通过分层存储策略支持故障恢复、迁移学习和模型调试等多重需求在保证训练效率的同时显著提升系统容错能力该方案为大规模分布式机器学习训练提供了更可靠的故障恢复机制
26910编辑于 2025-09-28- 来自专栏ytkah
微信部分功能故障 已全部恢复
今天下午，微信部分功能出现故障，影响公众号、支付、搜索、小程序等功能的正常使用，目前已经全部恢复。 现在卡券、微信支付、搜索、小程序等功能，全部都可以正常使用了。
1.1K70发布于 2018-03-06 - 来自专栏数据和云
故障恢复：一次底层超融合故障导致的异常处理
墨墨导读：底层超融合故障导致数据库产生较多坏块，最终导致数据库宕机。 背景概述 某客户数据由于底层超融合故障导致数据库产生有大量的坏块，最终导致数据库宕机，通过数据抢救，恢复了全部的数据。 下面是详细的故障分析诊断过程，以及详细的解决方案描述： 故障现象 数据库宕机之后，现场工程师开始用rman备份恢复数据库，当数据库alert日志提示控制文件有大量坏块。 ? 恢复过程 客户只restore了数据，通过编写脚本recover数据库。 ? recover失败提示控制文件有坏块 ? 发现控制文件已经损坏，开始重建控制文件 ? 查看x$kcvfh.afs，发现都为0，不需要介质恢复。 ? ? 通过添加参数尝试打开 *._allow_resetlogs_corruption=TRUE *. START DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) ----- Successfully dispatched 发现访问14号回滚段后出现故障
1K20发布于 2020-08-18 - 来自专栏颇忒脱的技术博客
Redis Cluster配置传播及故障恢复笔记
本笔记是对Redis Cluster Spec - Configuration handling, propagation, and failovers的归纳总结。
88010发布于 2019-07-15
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号