引言做数据库这些年被问到最多的一个话题就是你们那个两地三中心到底怎么搞的真的挂了一个机房业务不会停吗数据真的不会丢吗说实话这些问题我都经历过。从最早单机房吭哧吭哧维护到后面被迫上双中心再到金融客户逼着做两地三中心一路踩了不少坑。今天就把TDSQLMySQL版在实际生产环境里怎么部署两地三中心、各层怎么设计、出了问题到底怎么切给大家掰开揉碎了讲一讲。内容可能有点干但都是真金白银踩出来的经验建议收藏慢慢看。一、先说说这个架构长什么样两地三中心听着挺唬人其实拆开来看就三层意思一个是主数据中心放你最核心的业务一个是同城灾备中心跟主中心在同一个城市但不同机房两边用专线连着延迟很低还有一个是异地灾备中心一般放到别的城市专门防那种整座城市出问题的极端情况。以我们实际部署的情况来说主中心在深圳A机房同城备库放在深圳B机房异地中心放在上海。应用在主中心和同城中心都部署一套也就是所谓的双活。用户请求进来先过DNS再过F5负载均衡然后打到Proxy最后落到TDSQL数据库。数据库这边我们用的是一主三备。主库挂掉的时候同机房的备库优先顶上来跨机房的备库跟着重新挂接。这一套跑下来只要不是三个地方同时炸业务基本不会受太大影响。二、一层一层拆给你看1.DNS智能解析DNS是流量的大门。你配置的解析策略直接决定了用户请求往哪走。实际用的时候我们会配智能解析规则——比如按地域、按运营商、按机房负载来做调度。更关键的是DNS本身也是跨机房部署的一个机房挂了不影响解析。还可以配策略控制流量是否允许跨机房这个在容灾演练的时候特别好用。2.F5负载均衡请求过了DNS下一跳就是F5。F5在这里就干一件事把流量均匀地打到后面一堆Proxy上别让某一台Proxy累趴下。部署上每个机房配两台F5一主一备Active Standby。两台之间互相盯着一台挂了另一台秒切。F5还会做健康检查后面哪台Proxy不健康了直接摘掉流量不往那走。F5本身也是一主多从。如果整个机房的F5全挂了流量会自动走到同城机房的F5上去层层兜底。3.Proxy代理层Proxy是应用和数据库之间的中间人。对应用来说它就像个普通MySQL连上去就行根本感知不到后面有多少个分片、主从怎么分布的。Proxy最大的特点是——无状态。啥叫无状态就是每个Proxy看到的数据完全一样不存业务会话。这有什么好处挂了就挂了换个Proxy连就行业务根本无感知。我们每个机房放两台Proxy总共四台。某一台挂了F5检测到直接剔掉应用连接池重连一下秒级恢复。整个过程中用户端可能也就卡一下刷新就好了。4.数据库层核心终于到了重头戏——数据库。这是整个架构里最金贵、也最复杂的一层。TDSQL采用的是一主三备。写请求全部走主库备库通过同步复制跟着主库跑。四个节点跨机房分布主库在A机房一个强同步备库在同城B机房还有一个在同城C机房异地备库可选配到上海。这里有个关键设计——跨IDC强同步。啥意思就是主库提交事务的时候必须等至少一个同城备库确认写完了才给应用返回成功。这一步保证了RPO0也就是主库哪怕瞬间蒸发已提交的数据也不会丢。备份我们也做了独立设计。每个节点都有备份数据落到NAS上。主中心和同城中心各配一套NAS异地中心看需要也可以加。另外注意一点——复制是按实例为单位的。比如你有一个16分片的分布式实例那这16个分片要作为一个整体复制到对端分片数和拓扑结构必须保持一致。非分布式的简单一些一个分片一套数据就完事了。5.管理节点管理节点里面最核心的是ZooKeeper存着整个集群的路由信息、节点状态可以说是整个系统的大脑。ZK我们怎么部署5台221。主中心放2台同城中心放2台第5台放到异地的仲裁区。这个设计非常关键——任何一个机房挂了剩下的节点还能凑出多数派3台以上集群还能继续选举Leader做决策。还有个MC节点负责全局一致性读维护集群的逻辑时钟。部署的时候也得是奇数个保证能选出结果。其他还有一些辅助节点像KEEPER、OSS这些管配置、管监控数据的。生产环境一般4台管理服务器就够了。异地中心也放一套管理节点配置可以低一点但灾备切换的时候必须有。三、数据怎么复制才不丢数据复制是整个容灾的命根子。我们用的是两套策略同城强同步、异地异步。同城的两个机房之间主库写事务必须等备库确认。这个过程会有延迟但在专线环境下一般也就几毫秒对性能影响可控。换来的是RPO0——主库炸了备库上数据一条不少。异地为什么是异步因为跨城延迟太高了几十毫秒起步。如果等异地的确认主库的写入性能直接被拖垮。所以异地用异步复制允许少量延迟。反正异地是防城市级灾难的真到那一天分钟级别的RPO是可以接受的。复制链路建好之后系统会持续监控复制延迟。一旦延迟飙高立刻告警运维同学就可以介入看了。四、出事了怎么切重点说了这么多设计真出问题了到底怎么切这是大家最关心的。我们按故障级别一层一层说。1.F5挂了F5挂了最轻。本机房的Standby秒切成Active业务无感知。如果整个机房的两台F5全挂了流量自动走到同城机房的F5继续往后转发。策略很简单同机房优先跨机房兜底。2.Proxy挂了Proxy挂了也简单。F5健康检查一检测 unhealthy的节点直接摘掉。应用的连接池发现连不上自动重连到别的Proxy。因为Proxy无状态换个节点继续用数据不受影响。整个过程秒级搞定。3.数据库主库挂了这是最紧张也最考验架构的场景。整个切换流程大概是0. 故障检测——管理节点一直在给主库发心跳超时了就判定故障。1.备库选举——优先选同机房的备库延迟最低、数据最全。同机房没有就选跨机房的。2. 原主库降级——把故障主库踢下线防止它恢复之后抢主脑裂。3. 新主库提升——备库升主然后通知所有Proxy更新路由。4. 重建复制——剩下的备库重新挂到新主库上恢复一主三备。这一套流程跑下来RTO一般在30秒左右。快不快取决于当时业务负载——如果主库正在跑大量事务回滚需要时间。但数据不会丢。因为强同步保证了所有已提交的事务至少有两个副本切的时候不会丢数据。这就是RPO0的含义。5.整个机房挂了这是最恐怖的场景但也是两地三中心存在的意义。先说ZK。221的部署就是为了这一刻——挂了2个节点还剩3个仍然满足多数派ZK集群继续工作路由信息不会丢。再说数据库。主库在那个机房对吧没了。这时候跨机房的备库会被选举为新主库。因为跨IDC是强同步数据还是完整的RPO0。只是切换时间会长一点——需要处理一些未完成的事务、回滚进行中的操作所以比同机房切换多耗点时间但一般不会超过30秒。Proxy和F5我们前面说了都是跨机房部署的流量直接切到同城中心就行。应用双活部署业务基本不中断。所以你看整个机房挂了从DNS到F5到Proxy到数据库到管理节点每一层都有高可用设计都能切。这才是真正的机房级容灾。6.同城网络断了同城两个机房之间的网络断了这种情况比较特殊。此时主库和同城备库的强同步链路断了怎么办两条路一条是退化为异步模式主库不等备库确认了继续跑业务。数据一致性会受点影响但业务不停。另一条路是把异地的异步备库临时提升为强同步备库维持强同步关系。如果同城断网时间很长十几二十个小时可以考虑把业务临时回切到主中心单点跑。但要注意——异地是异步复制两边的数据可能对不齐恢复之后需要人工核对或者做数据校验。五、几个血泪建议最后说几个我们踩坑踩出来的经验新手做两地三中心一定要看看1.ZK部署千万别偷懒221不是随便定的是经过验证的方案。仲裁节点一定要放在独立的位置别和主库放一个机房。我们曾经为了省事把ZK都堆在一起结果机房一挂整个集群管理瘫痪。2.监控告警必须到位复制延迟、ZK状态、F5健康检查、Proxy连接数——这些指标一个都不能少。没有监控的容灾等于没有容灾出事了你都不知道该切哪。3.一定要做演练纸上谈兵没用。建议每季度至少做一次主库切换演练每年做一次机房级故障演练。不练不知道一练全是问题。我们第一次演练的时候发现Proxy路由更新慢了10秒这问题不演练根本发现不了。4.同城专线要冗余强同步依赖同城网络专线断了同步就变异步。建议双线冗余两条不同运营商的专线互为备份。同时持续监控网络延迟和丢包率。六、最后说两句两地三中心说起来复杂其实核心思想就一句话不要有任何单点。从DNS到F5到Proxy到数据库到管理节点每一层都能挂、每一层挂了都能切。TDSQL这套架构我们在金融客户那边跑了很久了经历过大大小小各种故障总体来说RPO能做到0RTO控制在30秒以内可用性5个9起步。当然架构是一回事运维是另一回事。再好的架构不监控不演练出事照样抓瞎。希望这篇文章对你有帮助。如果有问题欢迎留言交流大家一起踩坑一起进步。END更多精彩关注我一起学习、成长