基于DNS的mysql高可用_网易杭研总结：数据库高可用技术之道（6）

数据库作为IT系统中最关键的服务之一，其可用性一直是系统设计中的重点考虑因素。同时，由于数据库有数据有状态的天性，数据库高可用有其天然的复杂性和难点，云原生架构下尤其如此，是一个值得深入探讨的课题。本系列文章将基于网易杭州研究院的研究与实践，解析数据库高可用技术要点，梳理主流数据库方案，为数据库技术建设规划提供参考。

本文由作者授权网易云发布，未经许可，请勿转载！

作者：倪山三，网易杭州研究院运维工程师

Catalog0. Prologue

1. 数据库高可用技术要点1.1. 冗余设计 — 数据冗余方案

1.2. 冗余设计 — 冗余数据间的一致性

1.3. 冗余设计 — 实例冗余

1.4. 故障切换 — 服务角色

1.5. 故障切换 — 故障感知与应对

1.6. 故障切换 — 业务连接切换

2. 主流数据库方案概览2.1. 主流数据库高可用功能概览

2.2. MySQL数据库高可用功能概览

接上文：

1.6. 故障切换 — — 业务连接切换与过渡

关于高可用最后一个技术要点, 也经常容易被忽视. 业务使用数据库通常是长连接, 这意味着在后台数据库由于可用性问题需要发生服务切换的时候, 应用客户端的长连接首先会(也必须)断开, 然后能够尝试不断重建连接, 这之后有两个具体要求.一旦确定切换, 尝试重建的连接不应该再成功连上切换前的老服务.

不断重试一段时间后, 需要能够正确定位并连接上切换后替换上来的新服务.

要实现这一点其实并不简单. 由于业务对数据库访问地址无法轻易或者快速改变, 那么就要求数据库服务层来通过各种方案实现业务连接从失效地址转移到新服务地址的目的.

1.6.1. 可漂移资源

较为常见的一种方案, 在访问门牌号不能变的情况下, 将门牌号从故障地址转移到新地址去. 业务应用访问数据库一般需要通过一个类似URL的连接字符串来定位具体服务的网络位置.

jdbc:mysql://192.168.1.1:3306/mydb

其中最重要的定位手段是"地址 + 端口"部分, 这个地址可以是虚拟IP, 也可以是DNS域名, 因此在业务不改变连接字符串配置的前提下, 如果能够操作目标IP或域名的归属, 就能够起到操作业务具体连接目标的目的. 这一方法被称为可漂移资源, 通过高可用切换时漂移虚拟IP或域名的方式完成业务连接目标的切换.

显而易见, 可漂移资源主要是网络资源, 并不是数据库服务的固有资源, 因此该方案多用于自身缺乏高可用保障机制, 需要外部框架来完成监控+切换流程的数据库服务, 是一种较原始的连接切换方案. 说白了, VIP或域名切换应用如此广泛的主要原因就是MySQL应用广, 而MySQL通过我们前面的分析, 相信大家都理解了传统上MySQL是一种缺乏高可用设计的数据库.图38, 任何具备后端服务健康监控+VIP管理能力的服务都可以作为MySQL高可用切换框架使用, 例如keepalive.图39, MHA作为MySQL切换框架严格来说其连接切换能力是开放式的, 交由DBA实现的, 但是由于原生MHA其受限的脚本调用和执行能力, 最常用的实现手段还是VIP漂移.

而在两种最主要的漂移资源 —— VIP和域名 —— 之中, 我认为域名切换比VIP切换更可靠更安全. 原因在于VIP作为需要保证全局唯一的资源, 其切换操作需要两个步骤, 首先在故障节点删除VIP, 然后才能在切换目标节点添加VIP. 而前者是无法保证执行成功率的. 如果故障节点是显而易见的断电问题那还好, 即使不用删除VIP, 该VIP也相当于下线, 但是如果VIP所在的故障节点是某些复杂的hang死问题, 非常容易出现数据库被判定不可用, 但是VIP未离线且删除VIP操作失败. 这个情况下, VIP切换操作无法保证原子性, 第二步操作做不做都有很大问题, 如果不做, 那么切换实际上失败; 如果做, IP出现冲突, 导致VIP无法访问, 切换依然失败. 因此我始终强调关于高可用切换方案, 如果依赖故障节点上任何必须成功的操作, 那么就是不可靠的. 这是VIP切换方案难以根治的问题.

对比而言域名方案要好多了, 因为域名作为漂移资源是由DNS服务集中管理控制, 切换本身不依赖也不需要对故障节点进行任何操作, 而DNS服务的高可用和冗余机制是另外一套较为完善的体系, 因此基于DNS的域名切