干数据库运维这些年“双机热备”这四个字我听了不知道多少遍。早期Windows环境下给SQLServer做高可用最常碰到的方案之一就是Rose HA。很多人一听“Rose”以为是花其实是一家做高可用软件公司的产品名全称一般叫Rose HAHigh Availability专门用来做Windows/Linux平台上的双机热备。放到当年那个环境里SQLServer配Rose基本就是中小企业核心业务库的标配方案。这篇就专门把Rose双机热备这套东西掰开揉碎讲清楚从实现原理到实战部署再到排错经验一次说透。这篇文章适合几类人看刚接手公司老业务库、发现机房里有台“备用服务器”不知道怎么用的新人DBA正在做数据库高可用方案选型、想了解共享存储型双机架构的运维工程师还有那些听甲方提过“双机热备”要求但一直没搞清楚原理的实施人员。看完你不仅能明白Rose是怎么工作的还能自己动手搭出一套来。1. 双机热备方案选型与整体架构设计1.1 为什么当年大家喜欢用Rose而不是其他方案Windows环境下给SQLServer做高可用2010年前后可选的方案说多不多、说少也不少。微软官方有MSCSMicrosoft Cluster Service后来叫Windows Server故障转移集群、还有数据库自带的日志传送、数据库镜像。市面上也有不少第三方软件Rose HA就是其中一个。几套方案定位完全不同。日志传送本质上是一种异步备份恢复机制备库在用日志恢复时是不可读的主库挂了以后备库要手动恢复到最后状态存在数据丢失窗口切换一次少说得几分钟。数据库镜像能把切换时间压缩到几秒但它依赖网络传输对带宽和稳定性要求高而且备库不能直接参与读写本质上还是一主一备。MSCS倒是能管SQLServer但Windows集群配置复杂对硬件和驱动的挑剔程度很高非微软认证的存储配置很容易踩坑。Rose这类第三方高可用软件赢在哪里最大的优势就是它只管“服务可用性”不关心业务逻辑。它盯的是几个资源IP地址、磁盘卷、SQLServer服务进程、数据库状态。一旦这些东西出问题它按预置策略把整个“资源组”从故障机搬到备用机。对SQLServer来说数据文件放在共享存储上主备两台机器访问的是同一份数据所以切换过去以后数据库里的数据天然就是一致的没有日志追赶、没有手工恢复逻辑简单直接。还有一个现实因素成本。数据库镜像要单独开一个端点跑同步长时间高负载下性能会受影响MSCS需要企业版Windows和标准化存储日志传送配置繁琐。Rose HA在当年的授权和部署成本相对可控部署周期短一个熟练工程师半天就能搭完因此银行网点、医院挂号系统、中小制造业的ERP、政务系统里用得非常多。1.2 Rose双机热备的整体拓扑长什么样一套典型的SQLServer Rose HA双机热备架构物理上分三块两台服务器、一套共享存储、两套网络。两台服务器建议同型号、同配置操作系统版本一致安装的SQLServer版本和补丁也一致。为什么这么要求因为Rose做故障切换时备机要完全接管主机的工作如果两台机器配置差太多切换后数据库性能可能直接崩掉。而且后面的实操里Windows服务、注册表、SQLServer实例名都应该保持一致省得切换后出各种幺蛾子。共享存储是最核心的一环。SQLServer的数据文件.mdf、日志文件.ldf、tempdb可以放本地也可以放共享盘但生产上建议留给Rose管理的主库文件放共享盘必须放在共享存储上。共享存储可以是SCSI直连磁盘阵列、光纤通道SAN也可以是后来大量用的iSCSI。这就是“共享存储型双机热备”和后面兴起的“无共享复制型HA”最本质的区别前者是两个人抢同一份数据后者是两份数据互相复制。网络方面至少需要两张网卡一张跑业务流量一张专门做心跳检测。生产环境我强烈建议再加一条心跳线也就是心跳网卡做双网卡绑定避免一块心跳网卡坏了导致整个集群误判。Rose对心跳网络的要求不算高百兆就够用但稳定性要排在第一位。从逻辑上看这套系统对外只暴露一个“服务IP”也叫浮动IP、漂移IP。应用程序连接数据库时连接字符串里写的是这个服务IP不是某台物理机的IP。平时服务IP绑在主机上主机故障后Rose自动把服务IP解绑、重新绑定到备机网卡上。对客户端来说数据库服务的地址一直没变只是底层实现悄悄换了台机器在跑。1.3 理解Rose实现原理的三个关键词想理解Rose双机热备的实现原理死死抓住三个词就行心跳检测、资源接管、共享仲裁。心跳检测负责回答“对方还活着吗”。每台机器上的Rose Agent定时向对端发送检测包一旦连续收不到某条心跳线上的回应就进入“可疑状态”然后启动故障判定流程。资源接管负责回答“对方挂了以后我怎么办”。Rose把所有需要托管的“服务要素”打包成一个资源组里面通常包括服务IP资源、共享磁盘资源、SQLServer服务资源、还有用户自定义的检测脚本资源。当备机判定主机故障后做的动作依次是在共享盘上夺取控制权、挂载盘符、启动SQLServer服务、绑定服务IP、运行健康检查脚本确认一切正常。这一整套动作执行完业务就恢复了。共享仲裁负责回答“万一两个人都觉得自己该上位怎么办”。心跳断开但两台机器都活着这种情况叫“脑裂”。Rose通过共享存储锁机制来仲裁谁拿到锁谁才是合法主机。这部分我在第2章里专门讲。2. 核心实现原理详解2.1 心跳机制双机之间怎样感知对方“挂没挂”心跳机制是双机热备的第一道防线。Rose默认会每隔1到3秒通过心跳网络向对端发送一个状态探测包具体间隔可以在配置里调。对端收到以后由Agent进程回一个确认包。如果连续丢失设定的次数默认一般是3到5次本机就会认为对端出现异常开始走故障接管流程。这里有一个关键点丢失心跳不一定代表对方死了。网线松了、交换机端口down掉、网卡驱动卡死都会导致心跳中断。真正的生产故障里因为心跳交换机闪断导致误切换的事我见过不止一次。所以Rose在设计上强调两条心跳路径只要两条心跳线路里至少一条还能通就不会触发接管。这也是我在上一个章节推荐双心跳网卡的原因。心跳包的内容也不是光“ping”一下那么简单。Rose的心跳包里面通常带上本机的资源状态信息包括当前主机角色、资源组的运行状态、以及一些内部计数器。这样备机不仅知道主机活着还能同步知道当前资源的状态。说实话这些状态信息后来对排查问题帮助挺大比如备机看到主机角色还是“Master”但资源运行状态异常就能预判可能马上要进入接管流程。生产环境要注意心跳网卡千万不能和业务网卡绑成同一个网卡去用也不要把心跳流量和业务流量混在一个交换机上。一块网卡既跑业务又跑心跳一旦出现拥塞丢包率一高Rose会误判对端故障这在行内叫“心跳饿死”后果通常很严重——你明明两台机器都运行正常数据库却在半夜被强行切换了一次。2.2 资源组Rose到底在管哪些东西Rose不是只盯着SQLServer.exe有没有在跑它管的是一个资源组。所谓资源组就是把数据库服务运行所依赖的各项资源打包成的一个“服务单元”。典型的SQLServer资源组包含以下几项。第一项是浮动IP资源。资源组对外提供服务靠的就是这个IP。IP什么时候生效哪台机器变成主机IP就绑定到哪台机器上。切换时旧主机的IP会被卸载新主机的网卡上会被绑定上同一个IP。IP切换是整个切换过程里客户端感知最直观的环节连接数据库的连接池会在IP迁移的瞬间报错等IP重新上线后新连接自然就恢复正常。第二项是共享磁盘资源。Rose需要挂载共享存储上的数据库文件卷。在Windows环境下通常体现为一个盘符比如E盘。切换时新主机要先把这快共享卷挂载为盘符SQLServer才能访问里面的数据文件。某些环境下还需要处理盘符冲突问题——如果两台机器的本地磁盘盘符分配不一致切换后盘符可能对不上。第三项是SQLServer服务本身。Rose通过Windows服务管理接口SCM来控制SQLServer服务的启停。正常情况下备机上的SQLServer服务实际是停着的。切换后新主机把SQLServer服务启动起来SQLServer去读取共享盘的数据文件并开始提供访问。这里有个容易被忽略的细节备机上即使SQLServer服务是停的Rose也会周期性检查它处于“已停止”状态一旦发现备机SQLServer服务被强行启动Rose会再次将它停止防止两台机器同时打开同一份数据文件。第四项是应用程序级检测脚本。常规服务监控只能知道SQLServer服务进程在不在无法判断数据库到底能不能正常读写。有经验的部署会额外加一个监控脚本定时在库里执行一条简单的查询比如SELECT 1或者查系统表。脚本执行失败超过阈值就意味着SQLServer已经“假死”了这时候让Rose触发切换才是真正的高可用。这个细节很多新手会忽略但实际生产环境里数据库挂掉但进程还活着的场景太常见了。2.3 从主机宕机到备机接管完整切换流程把整个切换流程按时间线拆开看有助于理解Rose每一步在干什么。假设主机A突然宕机备机B接管的完整过程大概是这样的。第一步心跳超时。备机B连续几次心跳探测都没有收到主机A的回应B的Rose Agent把A标记为“可疑状态”。第二步确认故障。Rose不会立刻接管而是做一轮确认。确认手段包括再次检查心跳线状态尝试从备用心跳路径发出探测包如果配置了共享存储仲裁备机B会去尝试对共享盘发起SCSI保留Reserve或锁盘操作。如果能在规定时间内成功抢到锁说明A已经无法再掌握存储确认为故障。如果抢不到锁说明A可能还活着B会退出接管流程继续等待。第三步内部状态切换。B把自己从“备机Standby”提升为“新主机Master”这个角色变化会记录到Rose自己的状态文件里。第四步资源接管。按顺序执行挂载共享磁盘卷、启动SQLServer服务、等待实例可用、绑定服务IP到本机网卡。这一步如果设置了应用检测脚本还会额外跑一次脚本验证数据库状态。这整个动作的执行顺序是有讲究的顺序不能乱先挂盘再启动数据库最后浮IP。因为SQLServer启动后要访问共享盘网络服务IP则最后绑定防止数据库还没就绪就有客户端连上来报错。第五步对外通知。新主机向管理控制台、事件日志、告警系统发送切换完成的事件。整个过程快的话十秒到半分钟慢的话可能要一至三分钟。切换时间主要消耗在两个地方一个是系统确认故障的等待时间心跳判定加确认周期这部分时间是可以人工配置的另一个是SQLServer自身启动和数据库恢复的时间。数据库越大、检查点越多SQLServer启动恢复的时间就越长。所以想缩短RTO恢复时间目标除了调快心跳参数更重要的是日常做好数据库维护避免异常断电导致的崩溃恢复。2.4 脑裂问题与锁盘机制为什么共享仲裁这么重要说“脑裂”之前先想一个场景如果主机A和备机B之间的心跳线全断了但两台机器都还在正常运行会发生什么A会发现B失联B也会发现A失联。如果两台机器都认为对方故障都试图接管资源组就会出现一个可怕的结果两台机器同时挂载同一个共享卷同时启动同一个SQLServer数据文件。SQLServer对数据文件的访问没有分布式锁概念两个实例同时打开同一份数据文件整个数据库大概率会损坏比宕机严重得多。所以Rose必须有办法避免这种情况。办法就是“共享仲裁”。在共享存储上Rose利用SCSI保留命令SCSI Reservation或者私有的锁盘区域做一个仲裁位。这个锁的规则很简单谁抢到了锁谁就有资格成为主机。备机B在确认A故障之前会先去抢这把锁A在日常运行中一直持有这把锁只要A没死B就无法夺锁。一旦A死透它对锁的占用自然消失B才能顺利拿锁并开始接管。锁机制解决了“两个节点都想上位”的问题但它也带来一个新风险如果B在尝试获取锁时A其实还活着只是心跳断了A和B就会进入“各自为政”的状态。这时候由于A持有锁B拿不到锁B会判定“对方未死”自动退出接管。从结果上看业务继续跑在A上B退回备机状态等待心跳恢复系统不会因为一次心跳闪断就发生切换。这正是仲裁机制存在的价值。需要注意的是基于共享存储的仲裁要求锁盘本身必须是健康的。如果共享磁盘阵列整体宕机主备都拿不到锁Rose就无法正常切换。好在生产环境里存储阵列通常自带冗余双控制器、多副本这个风险被降到了很低。3. 实操从零搭建一套SQLServer Rose双机热备3.1 动手前先写清单硬件、系统、网络规划理论讲了这么多该上手了。我按自己习惯的部署流程走一遍这里的步骤是通用逻辑因不同Rose版本和存储设备部分按钮或命令会有差异但配置思路是一致的。第一件事列硬件清单。两台服务器CPU、内存、磁盘容量尽量一致。内存大小至少能装下整个数据库缓冲池因为切换过去后内存是重新开始的如果备机内存小于主机大库会直接影响SQLServer性能。网卡配四块两块做业务、两块做心跳。一台存储设备可以是FC SAN、iSCSI存储或直连SCSI盘柜。第二件事规划IP地址。规划三组IP用途主机A主机B业务IP192.168.10.11192.168.10.12浮动IP服务IP192.168.10.100192.168.10.100心跳IP10.10.10.1110.10.10.12表格里浮动IP两台机器写的是同一个IP这正是关键点它平时工作在主机A上切换后漂到主机B上。应用连接串用192.168.10.100不需要感知底层是哪台机器。第三件事系统层面准备。两台机器装相同版本的Windows Server打相同补丁。主机名建议起得有意义比如DBSRV-A和DBSRV-B。两台机器都要配置hosts文件把对方的机器名和IP写进去。为什么要配hosts因为后面SQLServer的安装和Rose通信都要靠计算机名互访某些网络环境里DNS解析不稳定切换时会出现凭据校验超时的情况。还有一个老经验两台服务器的别名要一致SQLServer的默认实例名保持一致。Rose接管时是通过固定的机器名和服务名去启动服务的如果两台机器实例名不一致切换脚本就需要额外适配会平白增加故障点。3.2 SQLServer安装与配置的关键细节SQLServer安装有两类做法一是装到各自机器的本地磁盘数据文件放共享盘二是整个实例装到共享盘上。我强烈推荐第一种也就是程序文件在本地、数据文件在共享盘。原因很简单Rose切换时不需要等系统加载共享盘上的程序文件启动本地程序更快而且MSDTC这类依赖系统组件的服务也不容易出问题。安装前先在存储里划好LUN映射给主机A和主机B在Windows里能看到一块新的未分配磁盘。格式化后给它分配一个固定盘符建议两台机器都用同一个盘符比如F盘。SQLServer安装时实例目录选择本机C盘数据目录指定成共享盘F盘的Data目录日志目录指定成F盘的Log目录。注意tempdb也建议放到本地磁盘避免切换过程中tempdb恢复拖慢时间。不过tempdb放本地会导致两台机器上的tempdb文件不相同好在tempdb本身每次重启会重建不影响数据一致性。安装过程中有一个小坑SQLServer的Windows服务账号。这个服务账号必须是在两台机器上都存在的同一个域账号或者同一用户名、同一密码的本地账号。为什么因为Rose接管时是在备机上调用服务控制管理器去启动SQLServer服务如果备机上对应的账号不存在或密码不一致服务启动会直接失败。我早年就踩过一次这种坑主机A用的账号是SQL_Admin备机B上也建了同名账号但密码不同切换之后SQLServer怎么都起不来查了半天才发现是凭据问题。装好后把SQLServer的认证模式设为混合模式Windows认证SQL认证方便应用使用SA或专用账号连接。sa密码必须设置强密码放在配置文档里存档。接着设置SQLServer最大内存、最大并发度等参数因为最终两台机器跑的是同一份数据文件的配置SQLServer的配置是存在master库里的而master库在默认情况下其实也存在共享数据盘上如果把master库的数据文件也放在共享盘上这样配置就能跟随切换保持一致。3.3 Rose软件安装与集群资源配置Rose软件的安装在两台机器上分别进行安装包是同一个但安装过程中要选择角色一台设为A机主机一台设为B机备机。安装完成后启动Rose HA管理界面操作流程大致如下。先创建集群名字任意比如SQLHA。把两台机器添加为集群节点并指定各自的业务IP和心跳IP。创建集群时Rose会测试两台机器之间心跳是否连通连不通会直接报错误这里也别跳过检测。接着创建资源组。资源组名字可以叫SQLServer_Group。在资源组里添加三项资源共享磁盘资源、SQLServer服务资源、浮动IP资源。每一项都需要绑定到对应的目标上。比如共享磁盘资源选择盘符FSQLServer服务资源选择MSSQLSERVER服务浮动IP资源填192.168.10.100。添加完资源后配置依赖关系。Rose里的依赖关系和编程里的依赖关系意思一样IP要等待磁盘挂载完成后再绑定SQLServer要等磁盘挂载完成后再启动。排序就是磁盘 → SQLServer → IP。这一步配置错了切换后SQLServer可能都还没起来客户端就开始尝试连接然后报一串连接错误。配置完成后别急着投入使用先做一次“手动切换”测试。在Rose管理界面里选中资源组执行“切换Switch Over”。正常情况下主机A上的SQLServer服务停止、浮动IP释放备机B获得锁、挂载F盘、启动SQLServer、绑定IP。整个过程结束后用客户端工具连一下浮动IP能正常查询就说明基本工作正常。3.4 切换演练模拟各种故障环境新装的集群必须演练不然永远不知道真实故障时会发生什么。我会按下面的顺序做几轮演练。第一轮模拟“SQLServer服务故障”直接在主机A上用Windows服务管理器停掉SQLServer服务。观察Rose是否能在预定时间内检测到服务异常并触发数据库层面的检查脚本。如果配置了应用检测脚本这里会触发脚本执行超时判断。第二轮模拟“主机宕机”最直接的方式是直接给主机A断电。注意这是对共享存储架构最有考验的一种演练因为断电环境下硬盘缓存里的数据可能没来得及落盘共享盘上的数据要依靠存储阵列自身的掉电保护来兜底。断电后观察备机接管时间以及SQLServer启动时数据库是否进入恢复状态。恢复时间太长的话后续需要优化数据库检查点配置。第三轮模拟“心跳线路中断”拔掉主机A和备机B之间的一条心跳线确认系统不切换。再把两条心跳线全部拔掉观察系统是否会发生切换。如果没有配置共享仲裁拔掉所有心跳线后两台机器会同时认为对方故障、同时抢资源这就演示了脑裂的危害。正确配置锁盘机制后备机拿不到锁不会抢占业务还是跑在主机上等心跳恢复后系统回到正常状态。每轮演练完成后都要检查数据库完整性执行DBCC CHECKDB确认没有校验错误检查SQLServer错误日志里有没有报严重的I/O错误。整个演练过程中最好有一个人专门盯着业务连接用脚本反复执行简单的SELECT语句观察连接中断窗口实际有多长。4. 常见问题与排查技巧实录4.1 高频故障速查表故障现象直接原因排查方向备机一直处于“等待”状态不接管心跳判定阈值未到 / 锁盘获取失败检查心跳连通性、检查存储锁区域是否被占用切换后SQLServer服务启动失败服务账号密码不一致 / 共享盘盘符不一致检查两台机器SQLServer服务账号、盘符对应关系切换后客户端无法连接数据库浮动IP未成功绑定 / 防火墙拦截查看浮动IP落在哪台机器的哪块网卡上检查Windows防火墙规则两台机器频繁互相抢占资源心跳全部中断仲裁锁配置错误查心跳网卡状态、查锁盘配置确认仲裁机制是否生效数据库提示文件正在使用无法打开备机被手动启动了SQLServer停止备机SQLServer服务确认Rose检测脚本正常切换后数据库记录损坏存储掉电异常 / 共享盘写缓存未关闭检查存储阵列掉电保护策略SQLServer文件卷禁用写缓存这些坑我都实际遇到过尤其第二、三、五条出现的概率极高。前几年帮一个工厂的MES系统做排查数据库每天都自动切换一次查了几天发现是备机上的一个定时任务把SQLServer悄悄拉起来了Rose发现两个节点都在用共享数据文件强制把备机踢下去结果踢的过程里库里正好有 大事务在跑造成SQLServer锁竞争严重最后通过检查Windows计划任务才揪出原因。4.2 排查问题的一般思路遇上Rose双机热备出问题我的排查顺序基本固定硬件链路 → 网络状态 → 系统日志 → Rose日志 → SQLServer日志。先从硬件和链路查起。存储盘阵的管理界面里看看共享LUN是否在线、健康状态如何。接着看心跳网络ping一下对端心跳IP确认延迟正常、没有丢包。然后看系统日志Windows事件查看器里有没有这些标志性事件——SCSI保留冲突、网络链路断开、磁盘错误。Rose自己也有完整的日志管理界面里能看到切换事件的来龙去脉比如“节点B检测到节点A心跳超时”、“节点B开始获取锁”、“节点B挂载磁盘F成功”。最后看SQLServer错误日志。切换后数据库能不能起来SQLServer错误日志会给出最直接的答案。常见的一种记录是“无法打开物理文件...操作系统错误3”这通常是盘符没挂载好或者路径不一致另一种是“文件F:\Data\xxx.mdf 正由另一进程使用”这往往是备机SQLServer还活着还没被完全停掉。排查过程中有个技巧把Rose的管理界面事件列表截图保存很多切换失败的问题看一眼事件时间线就清楚卡在哪一步了。比如时间线停在了“获取SCSI锁”之后、还没执行“挂载磁盘”那问题基本就在存储挂载这个环节。4.3 那些容易被忽略的配置坑第一坑Windows防火墙没放行。Rose的通信端口和SQLServer的1433端口都要在防火墙里放行尤其是服务器区域网络隔离做得比较严格的环境。这个坑最烦人的地方在于平时看起来一切正常一切换就失败查半天发现是防火墙拦截了新主机上的浮动IP流量。第二坑两台机器的网卡驱动版本不一致。我遇到过一台机器网卡是驱动A版本、另一台是驱动B版本平时业务流量不大没感觉大促期间流量上来后其中一块网卡开始大量丢包Rose误判心跳丢失直接触发切换。排查到最后把网卡驱动统一到同一版本现象消失。第三坑杀毒软件实时监控把所有脚本文件给隔离了。Rose的执行脚本如果被杀毒软件查杀故障切换时脚本直接执行不了资源组直接陷入“未知状态”。部署时务必要将Rose安装目录、共享盘数据目录加入杀毒白名单。第四坑虚拟化环境下的存储性能瓶颈。Rose双机热备跑在VMware虚拟机上没问题但如果共享存储用的是虚拟机磁盘而非独立SANI/O延迟会非常高SQLServer启动恢复极慢切换时间可能长达好几分钟。生产环境别省这个钱共享存储一定要走独立存储。5. 一点个人体会说实话这套基于共享存储的双机热备架构放到今天来看确实有点“老派”云数据库、AlwaysOn可用性组、Kubernetes有状态服务这些新方案在弹性、自动化程度和对分布式环境的友好度上都强了很多。但我个人一直觉得Rose这套思路值得每个做数据库运维的人认真学一遍——它把高可用系统最底层的几个问题用非常直白的方式展示出来了怎么判断一台机器故障了、怎么避免两台机器同时操作同一份数据、怎么在切换后保持对外服务地址不变。理解了这些问题再去看AlwaysOn的副本仲裁、看K8s的Leader选举一看就透。最后分享一个实操细节收尾吧。配置Rose双机热备时千万别嫌麻烦跳过“应用检测脚本”这一步而且脚本一定要写成“查询失败才算故障”别写成功才算正常。我见过一个案例脚本逻辑写反了备机执行查询成功反而触发了切换导致业务在正常运行时被切换到备机主备来回拉扯了好几轮才定位到问题。双机热备的目标是让数据库故障无人值守自动恢复但前提是“故障判断”这个逻辑本身必须足够严谨。真正做到位以后你就能体会到系统安静运行一年都不切换才是最让人安心的状态。