- 综合排序
- 最热优先
- 最新优先
- 来自专栏数据和云
MySQL高可用--MGR入门（4）异常恢复
前文阅读： 1.MySQL高可用--MGR入门（1）单主/多主模式搭建 2.MySQL高可用--MGR入门（2）组复制监控常用相关表 3.MySQL高可用--MGR入门（3）单主/多主模式切换 1.网络异常 4.分布式恢复 前面提到了暂时性的集群恢复，这样的恢复会有很大的问题，这里将阐述 MGR 正常的恢复方式。 如果在 binlog 不可用或者差的数据实在太多的情况下，MySQL 在 8.0.17 后退出了克隆的方式进行恢复，即在集群中的所有 MySQL 节点上添加克隆插件，新加入的节点数据将会被全部删除，然后会被自动重新同步数据
2.1K20编辑于 2022-02-17 - 来自专栏技术杂记
Mycat HA(高可用) 与 LB(负载均衡)4
目录结构 [root@h101 sbin]# tree /usr/local/keepalived/ /usr/local/keepalived/ ├── bin │ └── genhash ├── etc │ ├── keepalived │ │ ├── keepalived.conf │ │ └── samples │ │ ├── client.pem │ │ ├── dh1024.pem │ │ ├── keepalived.co
27730编辑于 2021-12-02 - 来自专栏全栈程序员必看
rabbitmq高可用集群搭建_mongodb高可用架构
RabbitMQ 高可用集群搭建 1 集群简介 1.1 集群架构 当单台 RabbitMQ 服务器的处理消息的能力达到瓶颈时，此时可以通过 RabbitMQ 集群来进行扩展，从而达到提升吞吐量的目的 一个高可用，负载均衡的 RabbitMQ 集群架构应类似下图： 这里对上面的集群架构做一下解释说明： 首先一个基本的 RabbitMQ 集群不是高可用的，虽然集群共享队列，但在默认情况下，消息只会被路由到某一个节点的符合条件的队列上 HAProxy 同时支持四层和七层负载均衡，并基于单一进程的事件驱动模型，因此它可以支持非常高的井发连接数。 此时对外服务的 VIP 依然可用，代表已经成功地进行了故障转移。 juejin.im/post/6844904071183220749 RabbitMQ 官方文档 —— 集群指南：www.rabbitmq.com/clustering.… RabbitMQ 官方文档 —— 高可用镜像队列
3K10编辑于 2022-09-30 - 来自专栏菩提树下的杨过
redis 学习笔记(4)-HA高可用方案Sentinel配置
最小化的sentinel配置文件为： 1 port 7031 2 3 dir /opt/app/redis/redis-2.8.17/tmp 4 5 sentinel monitor mymaster /redis-cli -p 7031 sentinel masters 可通过该命令查看当前的master节点情况(注，这里一定要带sentinel的端口) 4、在master上，. shutdown 客户端的使用： 一、Jedis 1 @Test 2 public void testJedis() throws InterruptedException { 3 4 jedis.get(key));// 观察读取是否正常 34 35 sentinelPool.close(); 36 jedis.close(); 37 38 } 4- testRedisson() throws InterruptedException, ExecutionException, 3 TimeoutException { 4
1K70发布于 2018-01-19 - 来自专栏后台技术底层理解
redis高并发高可用
redis 高可用，如果是做主从架构部署，那么加上哨兵就可以了，就可以实现，任何一个实例宕机，可以进行主备切换。 所以就有了几个问题？ 什么是主从架构，主从如何备份？ 优点： 1、有效的解决了redis在分布式方面的需求 2、遇到单机内存，并发和流量瓶颈等问题时，可采用Cluster方案达到负载均衡的目的 3、可实现动态扩容 4、P2P模式，无中心化 5、通过Gossip 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。 ==怎么保证redis是高并发以及高可用的==？ sdown 和 odown 转换机制 sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机。
3.2K10发布于 2020-08-04 - 来自专栏SY小站的专栏
ingress高可用
上可能某个流量路线到某个node上的时候因为`Ingress Controller`的pod不在这个node上,会走这个node的kube-proxy转发到Ingress Controller的pod上,多走一趟路 4、 不创建svc,效率最高,也能四层负载的时候不修改pod的template,唯一要注意的是`hostNetwork: true 高可用选择第四种，采用deploy设置replicas数量 + nodeSeletor
2.6K30发布于 2020-06-15 - 来自专栏问天丶天问
SkyWalking 高可用
生产环境中，后端应用需要支持高吞吐量并且支持高可用来保证服务的稳定，因此需要高可用集群管理。 高可用需要： 至少一个 Nacos（可以是nacos集群） 至少一个 ElasticSearch / mysql（可以是es/msql集群） 至少2个skywalking oap服务； 至少1个UI（UI
50010编辑于 2024-10-03 - 来自专栏写代码和思考
高可用 - 简述
背景 本文记录一些高可用的内容，和数据库在高可用方面的演进过程。 1. 概念 可用性: 即软件系统在一段时间内提供 有用资源 的能力。 可用性 % 停机时间/分钟 停机时间/年 供应商术语 90 52,560.00 36.5 天 一个9 99 5,256.00 4 天 两个9 99.9 525.60 8.8 小时 三个9 99.99 52.56 如何设计来做到高可用 保证系统高可用，架构设计的核心准则是：冗余 和 故障转移。 单点系统的问题是，挂了就完全不可用了，服务会受影响。如果有冗余备份，其他后备的系统能够顶上，保证服务继续可用。 常见的互联网分布式架构是： 前端 ---> 反向代理 --> WEB应用 --> 服务 --> 数据库（及缓存） 其中，高可用可涉及到上面每个节点的高可用保障，我们看下数据的高可用架构的演变过程。 总结 关注快速读写 关注一致性 4. 展望 主备复制为这个领域奠定了重要的基础，但最终，我们需要更好的可用性和更大的规模。
2.1K10发布于 2020-05-08 - 来自专栏编程一生
实践高可用
本篇文章是之前一篇《大话高可用》的高可用心法的案例篇。 说实践之前先说概念。 具体实践如下： 架构高可用 交易这边进行在进行重构。将原有的核心交易从职责上划分为交易收单、交易保障和数据中心三个大块。 从高可用上，交易收单要保证实时交易现场的可用。 所以它才是对高可用需要考虑最多的，对MTBF和MTTR都要考虑和权衡。但是在对高可用要求上交易收单和交易保障是基本职责，指标就是稳定、稳定和稳定。 数据中心关乎的用户体验，是可以持续优化的，但是对高可用是有一定容忍度的：比如页面会加载慢，或者第一次加载不了刷新就成功了。 强依赖高可用 比如数据库的密码，不仅是加密的，而且是在中央集群秘钥管理中心统一管理的。中央集群的就会有秘钥获取不到的风险。按照API，如果获取不到则会抛出指定异常。 这是强依赖，需要容灾。
1.1K30发布于 2018-07-02 - 来自专栏编程一生
大话高可用
今天老大跟我讨论说，没有看到过一篇够全面体系的高可用的文章。谈到高可用，基本都是以偏概全的文章。今晚抽空想了一下这个问题。 高可用我另一个更资深老大其实总结的很全面了：别人死我们不死，自己不作死，不被队友搞死。 然后就是怎么别人死我们不死：最好就是别人的东西和我们没关系，就是去依赖。如果实在有依赖呢，那就尽量弱依赖。
1K20发布于 2018-07-02 - 来自专栏院长运维开发
ingress高可用
app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx --- Ingress Contronler 高可用 上可能某个流量路线到某个node上的时候因为Ingress Controller的pod不在这个node上,会走这个node的kube-proxy转发到Ingress Controller的pod上,多走一趟路 4、 也就是使用了主机的dns,会导致svc的请求直接走宿主机的上到公网的dns服务器而非集群里的dns server,需要设置pod的dnsPolicy: ClusterFirstWithHostNet即可解决 高可用选择第四种
2.6K20发布于 2020-06-13 - 来自专栏用户1337634的专栏
高可用 --- Redis
因为Redis拥有诸多优秀的特性，使用范围越来越广，系统对其可用性的依赖也越来越重，当前绝大部分系统使用的Redis都实现了高可用。 这里主要介绍Redis官方推荐的两种高可用方案Sentinel和Redis Cluster。 （如有不明白可以参考《Redis设计与实现》） 高可用 Redis实现高可用主要有两种方式，一种是Sentinel（3.0之前），一种是3.0正式支持的Redis Cluster（推荐）。 注意事项 因为Sentinel与Redis Cluster都没有实现强一致性（也没有实现最终一致性），所以在使用时，要牢记这一点，不能用在一致性要求特别高的场景，比如全局唯一ID，交易数据等。 如果master没有设置持久化，存在风险，如果不小心重启，则会丢失所有数据，而且从机也会因为同步，丢失所有数据（所以一定要高可用）。
1.2K40发布于 2019-03-27 - 来自专栏PHPer 进击
MySQL - 高可用性：少宕机即高可用？
我们之前了解了复制、扩展性，接下来就让我们来了解可用性。归根到底，高可用性就意味着 "更少的宕机时间"。 老规矩，讨论一个名词，首先要给它下个定义，那么什么是可用性？ 1 什么是可用性 我们常见的可用性通常以百分比表示，这本身就有其隐藏的意味：高可用性不是绝对的。换句话说，100% 的可用性是不可能达到的。没错，这里可以这么肯定的说。 同样的计算，我们可以得出 3 个 9 每年宕机时间为 8.76 小时，4 个 9 的是 52.6 分钟。 3 如何实现高可用性 通过上面的分析，也许你已经发现了，我们可用性取决于两个时间： 应用的平均失效时间 应用的平均恢复时间 因此，提高可用性也可以从这两个方面入手。 4 总结 可用性用宕机时间 n 个 9 来衡量。 实现可用性从平均失效时间和平均恢复时间入手。
1.9K20发布于 2019-05-13 - 来自专栏深入理解Android
高并发与高可用实战
高可用 高可用：相对于高并发来说，高可用并不是一个比较有规律的参数，7*24 是每个网站的梦想，但是你并不知道，在某一刻，他就没理由的宕机了。 高并发设计原则 系统设计不仅需要考虑实现业务功能，还要保证系统高并发、高可用、高可靠等。 高可用设计原则 通过负载均衡和反向代理实现分流。 通过限流保护服务免受雪崩之灾。 通过降级实现部分可用、有损服务。 通过隔离实现故障隔离。 4.业务降级：当高并发流量来袭，在电商系统大促设计时保障用户能下单、能支付是核心要求，并保障数据最终一致性即可。 这样就可以把一些同步调用改成异步调用，优先处理高优先级数据或特殊特征的数据，合理分配进入系统的流量，以保障系统可用。
1.9K20编辑于 2022-06-22 - 来自专栏后台技术底层理解
redis 的高并发高可用
redis 高可用，如果是做主从架构部署，那么加上哨兵就可以了，就可以实现，任何一个实例宕机，可以进行主备切换。 所以就有了几个问题？ 什么是主从架构，主从如何备份？ 优点： 1、有效的解决了redis在分布式方面的需求 2、遇到单机内存，并发和流量瓶颈等问题时，可采用Cluster方案达到负载均衡的目的 3、可实现动态扩容 4、P2P模式，无中心化 5、通过Gossip 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。 怎么保证redis是高并发以及高可用的？ sdown 和 odown 转换机制 sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机。
1.8K00发布于 2020-08-04 - 来自专栏闲余说
架构设计 4-高可用架构之FMEA方法
本文为第三部分，主要介绍 FMEA 方法，以及如何将 FMEA 方法应用于架构设计之中以提高服务可用性。 常见的影响有： 功能点偶尔不可用 功能点完全不可用 部分用户功能点不可用 功能点响应缓慢 功能点出错等 故障影响也需要尽量准确描述。 严重程度 严重程度指站在业务的角度故障的影响程度 一般分为“致命 / 高 / 中 / 低 / 无”五个档次 严重程度按照这个公式进行评估：严重程度 = 功能点重要程度 × 故障影响范围 × 功能点受损程度 自研系统：和开源系统类似，成熟的自研系统故障概率会低，而新开发的系统故障概率会高 风险程度 风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级 风险程度 = 严重程度 × 故障概率。 同时需要考虑资源的投入情况，优先将风险程度高的系统隐患解决。 个人理解 FMEA 方法是一种分析问题的方法，一共列出了 11 个点，我们在分析架构问题的时候，按照每个点逐一去适配、分析。
96940编辑于 2022-08-19 - 来自专栏数据科学专栏
大数据必知必会：Hadoop（4）高可用集群安装
安装前准备高可用集群环境下，至少需要3台服务器，这里准备5台。 JournalNode、NameNode、ResourceManager10.0.0.7node3 JournalNode、DataNode、NodeManager 10.0.0.8node4 单机环境安装参考大数据必知必会：Zookeeper（1）单机环境安装伪分布式安装参考大数据必知必会：Zookeeper（2）伪分布式安装集群环境安装参考大数据必知必会：Zookeeper（3）集群环境安装高可用集群安装高可用集群是在多个节点上运行进程来实现 Using value of YARN_CONF_DIR.node4: WARNING: YARN_CONF_DIR has been replaced by HADOOP_CONF_DIR. Using value of YARN_CONF_DIR.node4: WARNING: YARN_CONF_DIR has been replaced by HADOOP_CONF_DIR.
1.2K30编辑于 2023-02-09 - 来自专栏A周立SpringCloud
从MySQL高可用架构看高可用架构设计
如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。 MySQL高可用 说到MySQL的高可用，不得不提到复制，复制是MySQL高可用的基础。复制解决了什么问题呢？ 此架构特点： 1、安装布署简单，不影响现有架构 2、自动监控和故障转移 3、保障数据一致性 4、故障切换方式可使用手动或自动多向选择 5、适应范围大（适用任何存储引擎） 2.MySQL高可用带给我们对高可用架构设计的思考 为了高可用的保证，有了多主或者主从切换。 数据库的高可用架构一般在系统的底层，这方面的技术要求比较高，整个高可用系统大致如下： ? 3.总结 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。
1.2K20发布于 2019-08-23 - 来自专栏用户8645177的专栏
Redis-高可用
单机版 特点：简单 问题： 1、内存容量有限 2、处理能力有限 3、无法高可用。 特点： 1、master/slave 角色 2、master/slave 数据相同 3、降低 master 读压力在转交从库 问题： 无法保证高可用 没有解决 master 写的压力 哨兵 Redis 特点： 1、保证高可用 2、监控各个节点 3、自动故障迁移 缺点：主从模式，切换需要时间丢数据 没有解决 master 写的压力 集群（proxy 型）： Twemproxy 是一个 Twitter hsieh、murmur、Jenkins 2、支持失败节点自动删除 3、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致 缺点：增加了新的 proxy，需要维护其高可用 4、高可用性，部分节点不可用时，集群仍可用。
77250发布于 2021-05-22 HDFS HA 高可用
HA 概述 1）所谓 HA（High Available），即高可用（7*24 小时不中断服务）。 2）实现高可用最关键的策略是消除单点故障。 4）NameNode 主要在以下两个方面影响 HDFS 集群 NameNode 机器发生意外，如宕机，集群将无法使用，直到管理员重启NameNode 机器需要升级，包括软件、硬件升级，此时集群也将无法使用 必须保证两个 NameNode 之间能够 ssh 无密码登录 4. 自动故障转移为 HDFS 部署增加了两个新组件：ZooKeeper 和 ZKFailoverController（ZKFC）进程，ZooKeeper 是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务
21900编辑于 2025-12-23
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号