不知道你在把GBase 8s的高可用方案真正落到生产环境之后是不是也有过这种错觉HAC、SSC、RSS这些模式都装上集群状态看起来正常就觉得高可用这件事已经稳了。我当初也是这么想的。直到某个周一早晨监控大屏上一排标红的告警把我拽回现实——备用节点的同步延迟从秒级跳到了分钟级业务侧已经开始出现写入超时。后来排查了一上午发现根本不是方案本身的问题而是我在把这些模式组合起来部署时漏掉了几个很容易被忽略的细节。这篇是GBase 8s高可用架构保障方案全解析的第三篇我不想再重复讲怎么搭建而是换个角度把组合架构上线之后真正会出问题的地方拆开聊日志同步链路、故障切换的触发与回切、以及日常运维里那些比搭建更容易漏掉的检查项。适合正在用、或者准备用GBase 8s做高可用生产的DBA、架构师和运维同学参考。1. 组合架构的选型复盘HAC、SSC、RSS不是三选一1.1 三种高可用模式的真实分工GBase 8s自带的高可用能力落到生产上最常用的就是HAC、SSC、RSS三种模式。很多初次接触的人会把它们当成三个并列选型觉得“选一个最合适的就行”但实际生产里它们定位不同、解决的故障场景也不同。HAC主备高可用是典型的日志复制模式一主一备或者一主多备备机可以接收复制并提供只读能力。它解决的是单节点故障比如主节点的服务器宕机、操作系统卡死、数据库进程崩溃。HAC的同步方式可以调成同步或异步同步模式下RPO可以压到接近于零但对网络质量很敏感。SSC共享存储集群的特点是多个节点挂载同一份存储所有节点可以同时对外提供服务。它的优势是没有日志重放延迟因为数据文件本身就是共享的节点间的一致性由存储和锁机制来保证。但它也有一个绕不开的短板存储是整个架构的单点存储设备一旦故障所有节点一起失效。RSS远程独立备节点是面向异地容灾设计的数据通过日志流复制到远端的独立节点平时只读不承担业务流量。它解决的是“整个数据中心不可用”这种极端场景。因为异地网络的延迟不可控RSS一般跑异步复制RPO目标通常放宽到分钟级。三种模式放在一起看关系很清楚模式节点角色数据同步方式典型RPO目标适用场景HAC一主一备/一主多备备机可读日志复制可同步/异步同步模式接近零同城主备容灾SSC多节点共享存储可并发读写共享存储依赖存储无复制延迟读写分离、多活扩展RSS异地备机只读日志复制通常异步分钟级取决于网络异地容灾、数据保全所以选型的时候要问的不是“选哪个”而是“这个架构要防的是哪种故障”。单节点故障用HAC读扩展靠SSC数据中心级别的容灾只能靠RSS。1.2 一套可以对照的组合部署形态我手头这个生产环境用的就是组合架构。核心交易库走HAC一组主备节点放在同城两个机房报表类的查询流量单独走SSC读节点避免分析查询把主库的资源占满异地机房再放一个RSS节点专门用于容灾保全。整个数据流向大致是这样的交易应用通过统一的连接管理入口连到主HAC节点日常读写都走主节点备份HAC节点实时接收日志流处于只读状态主节点故障时由连接管理组件完成切换SSC读节点挂共享存储承担报表、统计类查询降低主节点的读压力RSS节点在异地机房接收异步复制平时不承接业务只做容灾和离线校验。这个形态的好处是同城故障可以由HAC快速切换兜底读流量被SSC分流整个机房级别的灾难还能靠RSS把数据拉回来。坏处也很直接运维复杂度成倍增加不同模式的监控命令、状态视图、故障排查思路都不一样出了问题首先要判断故障到底落在哪一层。1.3 选型时容易被忽视的隐性代价组合架构不是把三种方案堆在一起就完事。有几个代价我在上线前没有充分意识到事后回头才想明白。第一个是SSC对存储可靠性的依赖。SSC把可用性压力转移给了存储层意味着存储必须自己做冗余否则数据库层做得再好也白搭。存储设备的选型、链路冗余、快照策略这些成本都要算进架构总账。第二个是HAC同步模式对网络质量的敏感度。同城专线偶尔一次抖动如果跑的是强同步复制主节点的提交事务就要等待备机确认网络一抖业务写入就跟着超时。不是每条业务线都愿意为“零丢失”付出这么高的延迟代价。第三个是RSS的带宽占用。日志量大的业务比如批量跑批或者频繁的大表更新产生的日志流可能让异地专线带宽吃紧。上RSS之前最好先用日志增长速度估算一下带宽需求别等上线之后发现带宽被日志同步拖垮。组合架构的运维成本是一笔实打实的账。要想清楚每个模式解决什么问题、代价是什么再决定要不要组合、怎么组合。2. 同步链路里的日志流主节点提交之后到底发生了什么2.1 一次事务提交日志走了三条路HAC和RSS依赖的都是日志复制所以要想真正驾驭这套架构先得搞明白主节点上的一个事务提交之后日志到底怎么流转。GBase 8s沿用了传统事务型数据库的日志体系物理日志和逻辑日志各司其职。物理日志记录数据页被修改之前的映像作用是系统崩溃时快速恢复逻辑日志记录的是事务层面的操作逻辑承担事务回滚、时间点恢复和高可用复制这些任务。一次事务提交的时候主节点先把修改动作写入自己的日志再把日志流通过网络传递给备节点。备节点拿到日志后在自己的环境里按顺序重放把它变成自己磁盘上的数据变更。打个比方物理日志像是施工前给墙面拍的一张原状照片崩溃了可以按照片恢复原样逻辑日志则是施工过程的全程录像备机靠这段录像在自己这边重新演一遍整个施工流程才能保证两边数据走到同一个状态。高可用复制的本质就是这台“录像机”不能停、不能乱、不能丢。2.2 同步模式和备机确认机制是两码事日志从主节点流向备节点可以采用同步或异步两种方式区别在于主节点要不要等备机确认。同步模式下主节点要等到备机确认已经收到并应用了日志才向应用返回事务提交成功。这个模式下主备数据基本是实时的RPO极其接近零代价是每次写入都额外多了备机这趟网络往返写入延迟明显上升。异步模式下主节点写完本地日志就直接返回成功不等备机确认。业务响应快主节点吞吐不受备机影响但一旦主节点瞬间故障还没有复制过去的日志就丢了RPO不为零。实际生产中我不建议把同步模式当成一个“开了就完事”的开关。我见过有人把同步级别调到最严格结果同城专线抖动一次业务写入直接被打回超时一片。正确的做法是先看业务的容忍度核心支付类、订单类数据不能丢可以接受写入延迟增加日志类、报表类数据丢了还能补就没必要让网络抖动牵连业务。同步还是异步是按业务数据重要性做的取舍不是拍脑袋定的。2.3 延迟怎么观测命令、指标和告警思路同步链路健康与否最直观的就是延迟。GBase 8s沿用了Informix体系中常用的状态检查命令可以通过onstat -g dis查看数据复制的整体状态包括主备节点的连接情况、复制模式、备机已经应用到的日志位置。把备机当前日志位置和主节点最新日志位置做差就是实时的复制延迟。如果是RSS节点用onstat -g rss查看独立备节点的状态SSC节点则看onstat -g sds。不同版本输出字段会有差异以你实际环境版本为准但观察思路是一致的连接是否正常、应用到的日志位置在不在追赶主节点。监控不能只靠人肉盯命令。我建议写一个简单脚本定时抓取onstat -g dis的输出解析出延迟字段超过阈值就告警。脚本不复杂关键是持续运行#!/bin/bash # GBase 8s 同步延迟监控脚本示意 while true; do ts$(date %Y-%m-%d %H:%M:%S) # 此处按实际版本解析 onstat -g dis 输出中的延迟字段 lag$(onstat -g dis | grep -i lag | awk {print $NF}) if [ -n $lag ] [ $lag -gt 60 ]; then echo $ts WARN sync lag${lag}s /var/log/gbase8s_lag.log fi sleep 30 done字段位置需要根据你部署的版本做调整但思路可以照搬。延迟类告警比连接状态告警更能提前暴露隐患因为连接断开往往已经晚了延迟增大才是那个可以提前介入的信号。2.4 延迟突然飙升的定位思路延迟告警出现之后怎么排查比告警本身更值得讲。我遇到过一次典型的延迟飙升现象是备机同步延迟从秒级涨到几千秒而网络监控一切正常。当时按这个链路走的先确认是网络问题还是备机应用问题。在主备两端的网卡和交换机上看丢包率和流量排除了网络。再到备机上看系统负载发现磁盘IO util已经接近100%。问题定位了备机磁盘性能比主机差了一截主库日志产生的速度超过备机磁盘写入速度重放就跟不上了。后续处理是给备机存储做了升级和主机对齐了规格并把那个产生大量日志的批量任务做了拆分。这里还有一个很容易踩的坑备机在重放主机日志时自己也要写逻辑日志文件如果备机逻辑日志空间不足复制会直接卡住。这个坑巡检必须专门看因为备机报错不会直接体现在主节点监控上等你发现的时候延迟可能已经大到不可收拾了。另外提醒一句别忽视锁和长事务对同步链路的间接影响。主节点上一个超长事务长时间持锁业务被阻塞日志流却还在产生备机虽然能拿到日志但如果它上面也有查询在跑锁冲突会让重放同样被卡住。数据库并发锁、死锁这类问题在高可用架构里不只是影响业务性能还可能波及同步延迟排查时要一起考虑进去。3. 切换与回切高可用能不能用看的是这个过程3.1 自动切换背后的触发链路高可用架构的真正考验不是平时同步有多平稳而是主节点故障时系统能不能在可接受的时间内完成切换、让业务恢复。自动切换不是数据库自己拍脑袋决定的背后有一套触发链路。GBase 8s的Connection Manager连接管理器负责节点的健康检查和连接路由。主备节点之间通过专用通道互发心跳心跳超过预定阈值判定节点失联。确认主节点不可用之后连接管理组件会执行故障转移把备用节点提升为新的主节点同时把应用连接重定向到新主。这里有一个关键机制脑裂防护。如果主节点本身还活着只是网络分区导致心跳断了两个节点就可能同时想当主节点。GBase 8s的集群机制里设计了仲裁逻辑目的就是避免出现“双主”这种既危险又难恢复的状态。我之前的测试环境有一次主备节点之间的虚拟交换机配置错误导致心跳中断两边同时尝试接管服务幸好是测试环境没有影响线上。生产环境务必把心跳通道和业务通道隔离并且在网络调整时格外小心别动到心跳链路。3.2 切换阈值不是越短越好自动切换的触发阈值直接关系到“故障发现时间”和“误切换概率”的平衡。阈值设得太短一次轻微网络抖动就可能触发切换切完业务还没恢复主节点又回来了来回折腾比故障本身更伤。阈值设得太长故障发生到业务恢复的时间就拉长了用户体验变差。我的经验值是这样同城高可用环境心跳故障检测周期放到10秒到30秒级别比较稳妥给网络抖动留出缓冲又不至于让业务等太久。更重要的是一并考虑应用侧的超时设置应用连接池的超时时间、SQL执行的超时时间都要和数据库层的故障发现时间匹配。如果应用侧5秒就超时报错数据库层30秒才完成切换业务早就等不及了。参数调完之后一定要用故障演练去验证阈值是不是合理。纸上谈兵永远发现不了问题只有真正把主节点进程杀掉一次才能知道切换全链路要多久、哪里是瓶颈。3.3 手动切换的正确打开方式维护窗口内的主动切换和故障后的自动切换操作逻辑不一样。手动切换讲究的是“先确认状态再执行计划”。我一般按这几步走提前确认备机同步状态正常延迟为零或极小通知业务侧停止写入视维护策略而定只读窗口可以不停完全在主节点执行降级操作让主节点转为备节点角色在备节点执行升级操作提升为新的主节点用onstat -g dis确认角色切换成功、连接状态正常让应用通过连接管理组件或修改后的连接串重连新主验证基础读写。核心命令形如-- 备机提升为主节点 onmode -d primary primary_hostname -- 原主节点降级为备机 onmode -d secondary original_primary_hostname命令在不同版本可能有参数差异执行前一定以官方文档和实际环境测试为准。这里要特别强调手动切换之前状态确认比命令本身重要一百倍。备机延迟没追平的时候强行切换换过去的是一个数据残缺的新主后续恢复成本极高。3.4 回切为什么最容易翻车故障切换之后原主节点修复完成接下来要做的是回切。很多人觉得回切就是把角色再换回来操作上确实是一来一回两个命令但流程上最容易翻车。原主节点故障恢复后不能直接把它切回主节点。正确流程是先让它以备节点角色重新加入集群等待日志追平观察一段时间运行稳定再执行切换把角色换回来。如果忽视了“追平日志”这一步可能出现原主节点数据落后、一切回来就丢数据或者两个节点数据短暂冲突的情况。回切参考步骤原主节点修复后以secondary角色启动加入现有集群观察onstat -g dis里的延迟指标从大逐渐归零代表日志已追平追平后执行切换操作把新主节点降级把原主节点提升切换完成后再次确认连接状态和业务读写正常。回切过程中另一个高频事故点是应用连接池。数据库角色切换成功了应用侧连接池里可能还缓存着旧主节点的连接。如果应用连接串只配了单一主机名应用不会自动重连到新主业务就一直报错。这个问题根因不在数据库而在应用配置。强烈建议生产环境用连接管理器做统一入口或者给应用连接串配置多个候选主机。很多切换后业务仍然不可用的案例排查到最后都是连到了已经降级的旧主节点上。4. 上线之后的运营这些检查项比搭建时更容易被忽略4.1 巡检清单从每日到每季度架构刚上线的时候通常一切正常真正的风险都藏在日复一日的运行里。我的巡检习惯是分三个周期每日巡检看的是“活没活着”主备节点状态、RSS节点连接状态、同步延迟曲线、逻辑日志空间使用率、网络丢包率。这些指标适合自动化采集异常直接告警人工值班只需要处理告警而不是刷页面。每周巡检看的是“有没有变差的趋势”备份任务执行情况、主备节点磁盘空间均衡度、TOP SQL和大事务审视。很多同步延迟问题不是突然发生的而是日志量慢慢增长、磁盘空间悄悄缩水积累出来的。每季度做的是深度检查切换演练、数据一致性抽样校验、容量评估。这三件事单次都看不出什么但坚持一个季度一年能提前发现存储容量不足、日志增长速度异常这些慢性问题。4.2 高可用不等于数据一致校验得自己做这是我最想强调的一点高可用架构保证的是“节点故障时服务不中断”并不保证“数据永远一致”。日志重放异常、人为误操作、复制中断后恢复不当都可能导致备机数据和主节点不一致。所以一致性校验必须纳入日常运营。具体做法我常用三招一是在备机或RSS节点上做抽样查询与主库比对关键业务表的行数、关键字段的汇总值。二是在备机节点上用oncheck类的一致性检查工具扫描数据页和索引完整性。三是对关键表做一个基于校验和的对比脚本定时比对关键表的结构元数据、行数和业务关键列的和值。做这些校验的时候注意不要在业务高峰期跑全量校验也不要在主节点上跑重型的校验任务。备机和RSS节点本身就是天然的校验场所这也是它们除了容灾之外的另一个重要价值。4.3 备份策略与高可用要分开看很多人部署完HAC之后觉得“有实时备份了备份任务不用做了”这是非常危险的误解。HAC的复制会把主节点上的一切操作原样搬到备机包括误删表、误更新这种逻辑错误。备机不是备份它是主节点的“双胞胎”犯了同一个错误而不自知。备份必须独立于高可用存在。我的习惯是每天做物理备份保留多个备份周期定期把备份恢复到隔离环境验证可恢复性再配合关键表的逻辑导出用于单表级别的快速恢复。高可用管的是“节点挂了”备份管的是“数据坏了”这两件事谁也别想替代谁。4.4 两个很容易被反复踩的环境坑一个是时间同步。主备节点的系统时间如果相差太多心跳判断和日志里的时间戳都可能出现混乱严重时会影响切换决策。部署时一定要把NTP时间同步配置好巡检时也要看时间偏差。这个坑太基础了但越是基础越容易被漏掉。另一个是备机磁盘空间。备机重放主机日志时自己也要写逻辑日志文件磁盘满了复制直接卡住。而备机磁盘空间不足不会在主节点上体现主节点监控依然全绿等你发现延迟异常时往往已经积累了很长时间。备机的磁盘空间和逻辑日志空间监控必须和主节点一样纳入告警体系。4.5 故障演练怎么组织才有价值演练的目的不是“验证一次能切过去”而是反复验证在真实故障场景下整个链路的表现是否稳定。我建议至少覆盖三类场景主节点数据库进程异常退出模拟的是最常见的软件故障验证自动切换能否触发、业务恢复时间是否达标。主节点服务器完全失联模拟的是硬件层面故障验证心跳判定和仲裁机制是否可靠。备节点故障模拟的是反向场景验证主节点业务是否受影响、备机修复后能否顺利追平日志重新加入。每一轮演练都要记录故障注入时间、告警产生时间、切换完成时间、业务恢复时间、数据丢失量。这五个数字拿出来和RTO/RPO目标一对比架构到底行不行一目了然。演练中发现的问题比平时监控里发现的有价值得多因为它是真实故障链路上暴露的短板。写到这里其实也只是把组合架构里最容易出问题的那几段讲透了。我个人最大的体会是高可用架构的搭建只是起点真正的保障能力来自持续监控、定期演练以及对每一次异常的不放过。特别是延迟和切换这两个指标平时看着全绿真到故障那天才会暴露问题。如果你手头正好有GBase 8s的生产环境建议先把两件事安排上一个是把同步延迟监控脚本跑起来另一个是把备机的逻辑日志空间巡检加进值班表。这两件事做踏实了高可用才能从“纸面可用”变成真正扛得住故障的“生产可用”。