高可用

大纲 前言 MHA的架构 环境部署 实验步骤 总结 前言 上篇文章我们实现了 MySQL 的主从复制, 但是我们之前就说过, 主从复制是有很多问题的 , 我们这篇文章为大家介绍一如何使用 MHA 来实现 MySQL 复制集群的高可用 MHA的架构 MHA (Master HA) 实现 MySQL主从复制主节点高可用 , 主要实现了 Automated master monitoring and failover 自主监控和故障转移 Interactive (manual) Master Failover 手动故障转移 Non-interactive master failover 非交互式故障转移 Online switching master to a different host 在线切换到新主机 项目地址 Google Code MHA 服务有两种角色, 完成相应的功能 MHA Manager(管理节点): 通常单独部署在单台主机上, 用来管理多个 Master/Slave 集群, 每个集群通常被称为 Application MHA Slave(数据节点): 通常部署在单台 MySQL 服务器上, 通过监控和具有解析和清理log功能的脚本来加快故障转移 MySQL主节点故障时 , 按下面的步骤进行转移 MHA的各组件 Manager 节点的组件 masterha_check

上一篇写了nginx的配置，nginx确实能帮咱们分配到多个应用中，但是仍然有一个问题，当我其中一个机器down了，比如意外关机了，那么仍然是访问不了了，必须用户手动切换地址才可以访问，所以需要配置高可用，当其中一个nginx意外down了，则自动切换为另外一台nginx上面，即自动主备切换 此时就需要用到 keepalived 具体想了解keepalived的原理以及作用，请参考官网： https://www.keepalived.org/index.html 下面进行keepalived的安装和配置，配合nginx实现高可用 1、安装keepalived 系统为：centos7 直接进行在线安装： yum install keepalived 2、配置keepalived 安装完成后，配置文件为：/etc/keepalived vim keepalived.conf 以下是我配置的所有内容： 主节点： 1 #配置文件 2 ! Configuration File for keepalived 3 4 global_defs { 5 #从服务器最改一下这个 6 router_id node1 #表示运行keepalived服务器的一个标识。发邮件时显示在邮件主题的信息 7 } 8 #监控服务.NGINX mysql等 9 vrrp_script chk_nginx { 10

SpringCloud 关键名词 服务发现(service discovery) 服务ID SpringCloud经常用的5个组建： 服务发现——Netflix Eureka 传统DNS+负载均衡在微服务中不足 服务发现架构 基于云的微服务环境的服务发现其特征 部署高可用eureka server集群 实例1配置 实例2配置 client端配置 客服端负载均衡——Netflix Ribbon/Feign Ribbon + restTemplate 一般都是用 Feign client，比较方便。 断路器——Netflix Hystrix Feign中使用断路器 服务网关——Netflix Zuul 分布式配置——Spring Cloud Config 关键名词 服务发现(service discovery) 在许多分布式系统架构中，都需要去获取机器的物理地址（微服务实例部署的服务器地址及端口）。这一认知在分布式系统架构开始的时候就已经存在，而等到分布式计算出现的时候，被正式称为服务发现(service discovery)。 SpringCloud是微服务架构的集大成者，将一系列优秀的组件进行了整合。基于springboot构建。 SpringCloud的组件相当繁杂，拥有诸多子项目。重点关注Netflix。 服务ID 服务ID只是被服务发现代理用来给不同服务分组而已

1 MHA简介：MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。 在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过SSH访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5

一、高可用简介 Hadoop 高可用 (High Availability) 分为 HDFS 高可用和 YARN 高可用，两者的实现基本类似，但 HDFS NameNode 对数据存储及其一致性的要求比 YARN ResourceManger 高得多，所以它的实现也更加复杂，故下面先进行讲解： 1.1 高可用整体架构 HDFS 高可用架构如下： 图片引用自：https://www.edureka.co/blog/how-to-set-up-hadoop-cluster-with-hdfs-high-availability/ HDFS 高可用架构主要由以下组件所构成： Active NameNode 和 Standby NameNode ：两台 NameNode 形成互备，一台处于 Active 状态，为主 NameNode，另外一台处于 Standby 状态，为备 NameNode，只有主 NameNode 才能对外提供读写服务。 主备切换控制器 ZKFailoverController ：ZKFailoverController 作为独立的进程运行，对 NameNode 的主备切换进行总体控制。ZKFailoverController 能及时检测到 NameNode 的健康状况，在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换，当然

1、谈谈Redis的主从复制流程 有几个重点： 主节点负责写，从节点负责读，slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。 必须开启 master node 的持久化，不建议用 slave node 作为 master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了。 当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，同时还会将从客户端 client 新收到的所有写命令缓存在内存中。 断点续传是通过offset机制。 如果 master node 重启或者数据出现了变化，那么 slave node 应该根据不同的 run id 区分。 更详细见：https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/redis-master-slave.md 2

介绍：Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API的非关系型数据库。 传统数据库遵循 ACID 规则。而 Nosql（Not Only SQL 的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称） 一般为分布式而分布式一般遵循 CAP 定理。 Github 源码：https://github.com/antirez/redis Redis 官网：https://redis.io/ Redis支持的数据类型？ String字符串： 格式: set key value string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。 string类型是Redis最基本的数据类型，一个键最大能存储512MB。 Hash（哈希） 格式: hmset name key1 value1 key2 value2 Redis hash 是一个键值(key=>value)对集合。 Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。 List（列表） Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边） 格式:

在上节文章 https://blog.csdn.net/oLinBSoft/article/details/85418953 学习笔记:微服务-8 nginx+zuul 实现高可用负载均衡 实现了nginx + zuul实现微服务高可以 ，实现原理图片如下 在这个图中，还是存在单点故障问题，就是ngnix服务只有一台，如何避免这个单点故障呢，可以采用 nginx+keepalived的双机热备 方式实现。 原理图如下： 就是dns解析的ip，指向到一个虚拟的ip上，通过keepalived 软件，一个Master 一个slave 两台都虚拟ip192.168.41.148 但只有一个激活虚拟ip对外服务，两个keepalived会相互检测心跳，当主服务器ip宕机时，备份服务器自动激活虚拟ip，接替虚拟ip的工作。即在同一时刻只有一个192.168.41.148. 安装配置，两台服务器分别安装 1. 两台服务器都安装keepalived 和 nginx 安装nginx参见前文，安装keepalived： yum install keepalived 2.配置 vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { }

目录 集群Cluster keepalived： 组件： KeepAlived实现 KeepAlived双主配置示例： 集群Cluster 集群类型： LB lvs/nginx（http/upstream, stream/upstream） HA 高可用性 SPoF: Single Point of Failure HPC 系统可用性的公式： A = M T B F / （ M T B F + M T T R ） A=MTBF/（MTBF+MTTR） A = M T B F / （ M T B F + M T T R ） 指标: 99%, …, 99.999%，99.9999% 提升系统高用性的解决方案之降低MTTR 手段：冗余redundant active/passive 主备 active/active 双主 active --> HEARTBEAT --> passive active <–> HEARTBEAT <–> active 高可用的是"服务" HA nginx service：   vip/nginx process[/shared storage] 资源：组成一个高可用服务的“组件” (1) passive node的数量 (2) 资源切换 文件共享: NAS：文件共享服务器； SAN：存储区域网络，块级别的共享 网络分区: quorum：法定人数 with

本文将在前文基础上介绍k8s集群的高可用实践，一般来讲，k8s集群高可用主要包含以下几个内容： 1、etcd集群高可用 2、集群dns服务高可用 3、kube-apiserver、kube-controller-manager、kube-scheduler等master组件的高可用 其中etcd实现的办法较为容易，具体实现办法可参考前文： https://blog.51cto.com/ylw6006/2095871 集群dns服务高可用，可以通过配置dns的pod副本数为2，通过配置label实现2个副本运行在在不同的节点上实现高可用。 kube-apiserver服务的高可用，可行的方案较多，具体介绍可参考文档： https://jishu.io/kubernetes/kubernetes-master-ha/ kube-controller-manager、kube-scheduler等master组件的高可用相对容易实现，运行多份实例即可。 一、环境介绍 master节点1： 192.168.115.5/24 主机名：vm1 master节点2： 192.168.115.6/24 主机名：vm2 VIP地址： 192.168.115.4/24 (使用keepalived实现) Node节点1: 192.168.115.6/24 主机名：vm2 Node节点2: 192.168