服务没有响应控制功能mysql_详解Mysql高可用方案之Failovermha

在分布式系统中&＃xff0c;我们往往会考虑系统的高可用&＃xff0c;对于无状态程序来讲&＃xff0c;高可用实施相对简单一些&＃xff0c;纵向、横向扩展起来相对容易&＃xff0c;然而对于数据密集型应用&＃xff0c;像数据库的高可用&＃xff0c;就不太好扩展。我们在考虑数据库高可用时&＃xff0c;主要考虑发生系统宕机意外中断的时候&＃xff0c;尽可能的保持数据库的可用性&＃xff0c;保证业务不会被影响&＃xff1b;其次是备份库&＃xff0c;只读副本节点需要与主节点保持数据实时一致&＃xff0c;当数据库切换后&＃xff0c;应当保持数据的一致性&＃xff0c;不会存在数据缺失或者数据不一致影响业务。很多分布式数据库都把这个问题解决了&＃xff0c;也能够通过很灵活的方式去满足业务需求&＃xff0c;如同步、半同步方式、数据副本数量、主从切换、failover 等等(下面会提到)&＃xff0c;然而我们平时使用的社区官方版 mysql5.7及以前的版本 (不包括 Mysql 其他分支像 PhxSQL&＃xff0c;Percona XtraDB Cluster&＃xff0c;MariaDB Galera Cluster) 都在支持分布式和系统可用性这块处理得不是很完善。针对这个系列问题&＃xff0c;下面分析下如何解决这个问题。在这期间发现并提交合并了一个mha在线切换master 而导致master 和slave 数据不一致的bug&＃xff1a;https://github.com/yoshinorim/mha4mysql-manager/pull/86何为failover提mha之前&＃xff0c;提前普及一下failover。何为failover&＃xff0c;即当活动的服务或应用意外终止时&＃xff0c;快速启用冗余或备用的服务器、系统、硬件或者网络接替它们工作&＃xff0c;故障转移(failover)与交换转移操作基本相同&＃xff0c;只是故障转移通常是自动完成的&＃xff0c;没有警告提醒手动完成&＃xff0c;而交换转移需要手动进行&＃xff0c;对于要求高可用和高稳定性的服务器、系统或者网络&＃xff0c;系统设计者通常会设计故障转移功能。简单来说就是当系统某块服务不可用了&＃xff0c;系统其它服务模块能够自动的继续提供服务&＃xff0c;有很多设计良好的开源软件设计都会自动包含failover&＃xff0c;像负载均衡nginx&＃xff0c;haproxy可以支持后端检测&＃xff0c;backup&＃xff0c;当检测到后端upstream(endpoints)异常&＃xff0c;会自动的无缝进行切换到正常的backup上&＃xff0c;然后像分布式的数据密集型应用也会包含failover&＃xff0c;包括mongdb副本集&＃xff0c;etcd/zookeeper 节点选举&＃xff0c;elasticsearch副本集等等&＃xff0c;当存在部分数据节点异常&＃xff0c;选举数据节点为master/primary/leader&＃xff0c;甚至消息队列像rabbitmq镜像队列&＃xff0c;kafka replicas都会包含failover。链接:zookeeper leader选举etcd-raftetcd-raft可视化mongdb副本集rabbitmq镜像队列kafka ISR和同步elasticsearch replics数据复制前面提到了failover&＃xff0c;那么既然系统支持failover&＃xff0c;那必须要保证能有 backup 或者是 replics 来作为新 "master"(这里把leader/master/primary都统称为master )继续提供服务。前面提到了很多开源软件设计过程中就自带了数据同步功能&＃xff0c;就是数据所有的插入、删除、更新都在 master 上进行&＃xff0c;然后数据会同步到 slave 里&＃xff0c;简单来说需要保持 master-slave 数据一致。这里同步的方式可以像 mysql-bin log&＃xff0c;mongdb optlog 通过日志的方式实现&＃xff0c;将 update()&＃xff0c;delete()&＃xff0c;insert() 等操作记录到 log 中&＃xff0c;然后这些语句都转发给每个从库&＃xff0c;每个从库解析并执行该SQL语句&＃xff0c;就像从客户端请求收到一样&＃xff0c;在从库中重放该数据&＃xff1b;也可以通过传输预写式日志(wal)的方式&＃xff0c;日志优先写入到磁盘&＃xff0c;如SSTables 和 LSM 树实现的引擎&＃xff0c;所以日志都是包含所有数据库写入的仅追加字节序列&＃xff0c;可以使用完全相同的日志在另一个节点上构建副本&＃xff0c;将日志写入磁盘同时&＃xff0c;主库可以通过网络将其发送给其它从节点&＃xff0c;如etcd状态机同步&＃xff1b;还有的方式是通过集群内部的进程直接发送需要同步的数据&＃xff0c;如rabbitmq镜像队列。下图就是一个数据复制的应用场景&＃xff1a;一个用户有写入操作更新到写库&＃xff0c;然后其他用户可能从从库中读取数据&＃xff0c;可能数据是最新的&＃xff0c;也可能出现从库由于延时不是最新的&＃xff0c;复制系统针对这种场景化分为了几种复制方式。示例数据图复制系统的一个重要细节是&＃xff1a;复制是同步(synchronously)还是异步(asynchronousl)关于复制方式:同步复制(synchronous):同步复制就是当有数据更新请求到 master 节点&＃xff0c;需要保证该更新操作在 slave 节点上执行成功后才返回客户端&＃xff0c;从库保证有与主库完全一致的最新数据副本。如果主库突然失效&＃xff0c;我们可以确信这些数据仍能在从库上找到&＃xff0c;但是该方式也有缺点&＃xff0c;如果从库没有响应(比如它已经崩溃&＃xff0c;或者出现网络故障&＃xff0c;或其它任何原因)&＃xff0c;主库就无法处理写入操作&＃xff0c;主库必须阻止所有写入&＃xff0c;并等待同步副本再次可用&＃xff0c;这个过程数据库是无法更新插入数据。异步复制(asynchronous):异步复制就是当有更新数据请求到 master 节点&＃xff0c;master 操作结束直接返回客户端&＃xff0c;不需要 slave 确认&＃xff0c;slave 后台从 master 更新数据。该方式的缺点是&＃xff0c;如果主库失效且不可恢复&＃xff0c;则任何尚未复制给从库的写入都会丢失&＃xff0c;这意味着即使已经向客户端确认成功&＃xff0c;写入也不能保证持久(Durable)。该方式的优点是&＃xff1a;即使所有的从库都落后了&＃xff0c;主库也可以继续处理写入操作&＃xff0c;服务继续运行。半同步复制(semi-synchronous):半同步复制是一种中间策略&＃xff0c;当有更新数据请求到 master 节点&＃xff0c;需要保证该操作在某个 slave 上也执行成功才最终返回客户端&＃xff0c;如果某个同步的 slave 变得缓慢&＃xff0c;则可以使一个异步 slave 变为同步&＃xff0c;这样在保证一定数据一致性的前提下也能保证可靠性(这里可能会导致数据不一致&＃xff0c;还可能产生数据延时)。mysql的半同步复制(mysql semi-synchronous):master在执行完更新操作后立即向 slave 复制数据&＃xff0c;slave 接收到数据并写到 relay log (无需执行)后才向 master 返回成功信息&＃xff0c;master 必须在接受到 slave 的成功信息后再向客户端返回响应&＃xff0c;仅在数据复制发生异常(slave 节点不可用或者数据复制所用网络发生异常)的情况下&＃xff0c;master 才会暂停(mysql 默认约 10 秒左右) 对客户端的响应&＃xff0c;将复制方式降级为异步复制。当数据复制恢复正常&＃xff0c;复制方式将恢复为半同步复制。mysql 的数据同步和 failovermysql 支持相对严格的 ACID&＃xff0c;是一个性能和稳定性都非常不错的关系型数据库&＃xff0c;但是对分布式支持不是很友好&＃xff0c;虽然它实现了NDB&＃xff0c;不过感觉使用不太广泛&＃xff0c;国内使用较多的还是基础的主从复制方式。mysql支持前面提到的各种数据复制方式&＃xff0c;所以只需要针对各种的场景选取对应的复制方式即可。像对可用性要求较高&＃xff0c;数据一致性要求较低的可以选取异步复制&＃xff1b;对数据一致性要求很高的场景&＃xff0c;金融场景可以选用强同步复制&＃xff1b;互联网场景对可用性和一致性可能都有一定要求&＃xff0c;但要求不是特别高&＃xff0c;可以选择半同步复制。下面简述 mysql 主从同步的逻辑mysql的主从同步逻辑:首先开启mysql master上的 binlog&＃xff0c; mysql slave上通过一个 I/O 线程从  mysql master上读取binlog&＃xff0c;然后传输到 mysql slave 的中继日志中&＃xff0c;接着mysql slave 的 sql  线程从中继日志中读取中继日志&＃xff0c;应用到mysql slave的 数据库中&＃xff0c;这样就实现了主从数据同步功能。mysql主从同步逻辑

不过 mysql 自身没有实现 failover&＃xff0c;所以当 master 异常的时候&＃xff0c;需要制定策略去实现 failover 并处理数据库切换。failover 的逻辑是当 master 异常&＃xff0c;slave 自动提升为主库的&＃xff0c;然后让其他从库知道新的 master&＃xff0c;并继续从新的 master同步数据。在这里我们就要用到 mha了&＃xff0c;一个mysql 高可用管理工具。mha 能做到在 0~30 秒之内自动完成数据库的故障切换操作&＃xff0c;并且在进行故障切换的过程中&＃xff0c;能在最大程度上保证数据的一致性&＃xff0c;以达到真正意义上的高可用。关于 mha 的各种细节我这里就不详细展开了&＃xff0c;这些内容都在官方wike中(文档真的非常详细&＃xff0c;作者考虑很多通用的场景&＃xff0c;很多参数可配置化)。

链接:mha安装mha优势mha架构mha配置等等等....这里只分析他实现 failover 的架构与原理&＃xff0c;结构如下(官网的图片&＃xff0c;略模糊)mha架构图mha 由两部分组成&＃xff1a;mha manager(管理节点):   单独部署在一台独立的机器上管理多个 master-slave 集群(最好和mysql相关服务器管理)&＃xff0c;也可以部署在一台 slave 节点上&＃xff0c;作用是多mysql server服务的管理&＃xff0c;master检测&＃xff0c;master选举&＃xff0c;连接检查&＃xff0c;master故障切换等工作。mha node(数据节点):   运行在每台 mysql 服务器上&＃xff0c;作用是拷贝 master 二进制日志&＃xff1b;然后拥有最新数据的slave上生成差异中继日志&＃xff0c;应用差异日志&＃xff1b;最后在不停止SQL线程的情况下删除中继日志。原理&＃xff1a;(1)从宕机崩溃的master保存二进制日志事件(binlog events);   (2)识别含有最新更新的slave&＃xff1b;  (3)应用差异的中继日志(relay log)到其他的slave&＃xff1b;  (4)应用从master保存的二进制日志事件(binlog events)&＃xff1b;  (5)使其他的slave连接新的master进行复制&＃xff1b; (6)使其他的slave连接新的master进行复制&＃xff1b;mha需要解决的问题:如何确定新的master:由于 mysql 没有像 elasticsearch, etcd 这样分布式的集群决策节点&＃xff0c;所以这里的 master 选举节点就是 mha manager节点&＃xff0c;mha 主要参考几个因素&＃xff1a;1 配置文件中手动配置的候选servers参数 **candidate_master&＃61;1**(如: 希望同机房&＃xff0c;或则同机架的机器优先为 master)&＃xff0c; 2 依据各个 slave 中最新的二进制文件&＃xff0c;最新的slave节点即可提升为master。选取新的master

如何保证数据一致性:

mha 最大程度的保证数据不丢失&＃xff0c;当 mysql master 异常时&＃xff0c;但是机器正常提供服务&＃xff0c;那么 mha 会去对比 master 节点与将成为 master 节点的 slave 节点的数据差&＃xff0c;然后将差值数据拷贝到新的 slave&＃xff0c;然后应用这部分数据差去补全数据。diff master如果是  mysql  master 异常&＃xff0c;机器也异常&＃xff0c;那么系统中保存的二进制 binlog 文件也无法访问&＃xff0c;这就没法拷贝&＃xff0c;那么会略过拷贝流程&＃xff0c;直接会从 salve 候选者中选取新的 master。如果使用 mysql 5.5 的半同步复制&＃xff0c;可以大大降低数据丢失的风险。拷贝bin-log

节点之间数据如何拷贝:

由于 mysql 内部没有做这样的 bin-log 拷贝功能&＃xff0c;所以我们有自定义的需求去实现复制。这里 mha 需要依赖 ssh 协议&＃xff0c;就是通过 scp 协议传输文件(搭建 mha 需要保证各个主机间可以 ssh 互通)。拷贝bin-log

其他 slave 节点如何知道新的 master:

当候选 master 提升为 master 后&＃xff0c;mha manager 会用 mysql change replication 的方式更改目前集群的所有 slave的同步源。slave更新master管理节点如何解决网络分区问题:在上边的网络结构中&＃xff0c;我们可以猜到系统可能存在一个很大问题&＃xff0c;就是网络分区。网络分区指的是由于网络分离造成系统分裂为两个集群&＃xff0c;各自相互不信任。对应无状态的系统&＃xff0c;几乎没有影响&＃xff0c;正常处理请求&＃xff0c;比如nginx&＃xff1b;数据系统出现分区问题时&＃xff0c;如果系统设计或者配置存在不合理就会导致数据不一致&＃xff0c;而这个问题修复起来会非常复杂&＃xff0c;所以 elasticsearch , etcd, mongdb 等天生支持分布式的数据系统中&＃xff0c;都有机制避免由于网络分区导致的数据不一致问题&＃xff0c;解决方式是让集群大多数能正常通信的节点正常服务。比如你的集群是有 5 个节点&＃xff0c;分区导致一个分区 2 个节点&＃xff0c;一个分区 3 个&＃xff0c;那么 2 个节点的分区就会被认为是异常的&＃xff0c;不能正常提供服务&＃xff0c;这里也会有一些特定的算法可以解决类似的问题&＃xff0c;如raft。比如下边这个图&＃xff0c;3个节点&＃xff0c;那么最少信任集群的节点数应该有2个&＃xff0c;所以C节点会被标记为异常&＃xff0c;不会正常提供服务mha 的网络分区和上边提到的有点不同&＃xff0c;由于集群只有一个 mha management(注意这里只能部署一个management&＃xff0c;不允许部署多个&＃xff0c;否则会出现异常)&＃xff0c;所以 mha management 不存在脑裂问题&＃xff0c;这里指的网络分区指的 mha management 节点与 mysql master 节点出现分区&＃xff0c;如下&＃xff1a;mha management与mysql master发生网络分区当 mha management   和 mysql  master 出现在两个分区&＃xff0c;mha 认为 mysql master 异常&＃xff0c;但是实际 mysql master 和 mysql slave都正常工作&＃xff0c;提供服务&＃xff0c;但是这时候  mha  还是会切换 master&＃xff0c;可能对应用程序来说(如果前端有负载均衡器)&＃xff0c;会出现2个master&＃xff0c;而导致数据不一致。面对这种情况&＃xff0c;mha 提供了一种二次检测的方式&＃xff0c;既多条链路检测&＃xff0c;1 条链路是 mha management 是通过直接检测 mysql master节点&＃xff0c; 2 其他链路是 mha managerment 通过ssh登录到其他 slave 的方式去检测 mysql master 是否正常&＃xff0c;这样就能够解决 mha managerment 和 mysql master 的网络分区问题&＃xff0c;防止误切换。客户端应用自动恢复一般来说自带 failover 的分布式系统系统都能够自己恢复服务&＃xff0c;像elasticsearch , etcd&＃xff0c; 他们客户端和集群都能够自动感知集群节点的变化&＃xff0c;客户端连接的是一组集群地址&＃xff0c;看下边示例&＃xff0c;像 etcd 连接的服务端地址 Endpoints []string 是个数组&＃xff0c;这就保证了当某个节点 ip 失效&＃xff0c;或者机器不能访问&＃xff0c;机器异常&＃xff0c;机器负载的情况加&＃xff0c; 都有其他节点进行处理&＃xff0c;etcd连接如下:

cfg :&＃61; client.Config { Endpoints: []string{"http://127.0.0.1:2379"}, Transport: client.DefaultTransport, // set timeout per request to fail fast when the target endpoint is unavailable HeaderTimeoutPerRequest: time.Second, }然而像 mysql 默认的连接方式&＃xff0c;应用 tomcat 或其他 client 连接数据库的默认的方式是mysql 驱动&＃xff0c;就没法连接一个数组。所以我们的解决方案是要减少客户端感知&＃xff0c;减少逻辑变更&＃xff0c;让客户端和原来一样只需要连接一个 ip就好&＃xff0c;这里的 ip是 proxy ip, 这里会有多种方式(这里不考虑分片和其他高级的路由&＃xff0c;只考虑对应用连接&＃xff0c;proxy的高可用方式可以通过keepalived来配合做互备)

• 七层支持mysql协议的proxy:
  • mycat
  • kingshard
  • Atlas
  • vitess
  • phxsql
  • MaxScale

通过代理的方式对客户端体验最好&＃xff0c;原理上是 proxy 解析了mysql协议&＃xff0c;然后根据不同的库&＃xff0c;表&＃xff0c;请求类型路由(读写分离)到后端合适的 mysql 服务器&＃xff0c;但是因为加了这样一个 7 层的proxy解析&＃xff0c; 所以性能会损失&＃xff0c;一般在 20% 左右&＃xff0c;上边的各个 proxy 会有各自的优势&＃xff0c;和功能&＃xff0c;详情可以去看看相关对比&＃xff0c;我们需要做的就是在 proxy 后端配置我们的服务应用组&＃xff0c;配置读写分离&＃xff0c;当 master异常&＃xff0c;能够切换。

• 4层proxy
  • lvs
  • haproxy

4层 proxy 就不会解析出 mysql 7层 协议&＃xff0c;只能解析4层&＃xff0c;所以保证 mysql 后端端口通就可以了&＃xff0c;就是检测到后端master 不可用的时候&＃xff0c;切换到 backup master&＃xff0c;由于是 4层协议 所以不能配置自动读写分离&＃xff0c;只能单独配置 master 端口&＃xff0c;slave 端口了(如果配置keepalived可以自定义有脚本可以进行切换&＃xff0c;自定义脚本可以配置主从同步延时)

• 直接使用vip
  • 脚本配置vip
  • keepalived配置vip

最后这个方式逻辑就是:手动配置vip: 在 master 机器上配置虚拟vip&＃xff0c;当mysql master异常&＃xff0c;mha management 通过配置的 master_ip_online_change_script 的脚本&＃xff0c;当  master 异常的时候&＃xff0c;利用该脚本在新的 slave 上启动新的 ip&＃xff0c;这样对客户端来说也是无影响的&＃xff0c;配置vip比较容易关于配置流程[配置流程](https://www.cnblogs.com/gomysql/p/3675429.html)&＃xff0c;这里说的很清楚了&＃xff0c;我就不详细解析了。我们生产环境实际上是使用maxscale&＃xff0c;利用它来进行读写分离&＃xff0c;他的文档特别全面&＃xff0c;我们选用他的原因是他稳定高效&＃xff0c;能无缝配合 mha&＃xff0c;不需要 mha 配置任何 ip 切换之类的逻辑&＃xff0c;当 mha 进行切换后&＃xff0c;maxscale 会自动的进行感知系统中 servres 的角色&＃xff0c;master切换它能感知到&＃xff0c;对应用是完全无影响&＃xff0c;如下图:自动识别roke总结:这里解决的是 mysql 原官方社区版的高可用问题&＃xff0c;利用 mha &＃43; maxscale 的方式&＃xff0c;该方案能以最小的代价对现有系统进行变更&＃xff0c;提高系统的可用性和稳定性。前面提到以前版本(5.7以前) mysql 对集群化支持相对较弱&＃xff0c;但是其实 mysql 也一直在发展&＃xff0c;社区也开发出了很多方案&＃xff0c;像PhxSQL&＃xff0c;Percona XtraDB Cluster&＃xff0c;MariaDB Galera Cluster&＃xff0c;mysql 官方也开发出了使用 MySQL Group Replication的GA&＃xff0c;来使用分布式协议来解决数据一致性问题了&＃xff0c;非常期待未来越来越多的解决方案被提出&＃xff0c;来更好的解决mysql高可用问题。作者&＃xff1a;张志远&＃xff0c;百度 · 高级工程师&＃xff0c;sre 分布式系统&＃xff0c;数据库原文&＃xff1a;https://zhuanlan.zhihu.com/p/64383402

--end--

K8S培训推荐

Kubernetes线下实战培训&＃xff0c;采用3&＃43;1&＃43;1新的培训模式(3天线下实战培训&＃xff0c;1年内可免费再次参加&＃xff0c;每期前10名报名&＃xff0c;可免费参加价值3600元的线上直播班&＃xff1b;)&＃xff0c;资深一线讲师&＃xff0c;实操环境实践&＃xff0c;现场答疑互动&＃xff0c;培训内容覆盖&＃xff1a;Kubernetes集群搭建、Kubernetes设计、Pod、常用对象操作&＃xff0c;Kuberentes调度系统、QoS、Helm、网络、存储、CI/CD、日志监控等。点击查看更多课程信息&＃xff01;成都&＃xff1a;8月16-18日

推荐阅读

• 人均年薪80万以上&＃xff0c;Docker 入坑不亏&＃xff1f;

• 超炫酷的Docker终端UI&＃xff0c;想看哪里点哪里

• 使用 kubeadm 安装最新 Kubernetes 1.15 版本

• 2019年已过半&＃xff0c;精选往期 Kubernetes 干货文章

• 50个你必须了解的Kubernetes面试问题

• Promethues监控从VM迁移K8S实录

• 避坑&＃xff1a;Kubernetes中pull私有镜像

• 一份非常完整、详细的MySQL规范

• Docker stop或者Docker kill为何不能停止容器

• Docker中Image、Container与Volume的迁

• 国内拉取google Kubernetes镜像