在Cache 2018之前的版本中,数据库的高可用是通过第三方HA软件保障的,Cache数据库在2018以后及IRIS支持MIRROR技术,通过MIRROR可以保障数据库的高可用及数据的冗余,那么在新版本中,第三方HA软件与MIRROR是否可以同时使用以实现更高的数据库可用性?使用起来有哪些需要注意的?本文重点介绍探讨上述两个问题。
为得出正确结论,我们搭建了如下实验环境:
我们采用3个服务器节点A、B、C分别部署IRIS 2021.1数据库,其中A节点、B节点部署第三方HA软件组成数据库高可用主备集群(本例中,采用的是基于POWER平台的PowerHA),该集群中定义A节点为主节点,B节点为备用节点,HA集群的共享资源组存放在共享SAN存储上,通过HA,生成HA集群的对外服务IP,即我们通常说的Service ip,保证在生产节点发生网络故障、主机故障、以及操作系统故障、手动切换等情况下,IRIS服务、共享资源组、以及HA的Service IP可自动切换至另外一台服务器,保障IRIS高可用,经测试,HA集群内部节点间服务切换时间约为30秒。
搭建IRIS的MIRROR集群,其中A、B两个节点组成的HA集群通过Service IP添加至MIRROR集群中,做为MIRROR集群的一个Failover member,C节点做为MIRROR集群的另外一个Failover member或者DR节点,镜像服务质量超时时间保持默认(8000ms),D节点只部署ISC Agent,做为Arbiter(Mirror的仲裁程序节点),整个集群通过Mirror集群的VIP对外提供服务。
测试环境的架构视图下所示:
首先,我们将HA集群做为Mirror的主Failover Member,C为Mirror的备Failover Member,此时HA Service IP及Mirror VIP均位于A节点上,数据库通过A节点向外提供服务,此时,我们在默认的镜像服务质量超时时间(8s)及调试后的镜像服务质量超时时间(80s)下,分别模拟A节点故障、A节点B节点几秒内先后故障、通过HA执行数据库服务从A节点向B节点手动切换三种场景,测试中观察到的现象及最终结果如下表所示:
镜像服务质 量超时时间 |
测试项 |
现象观察 |
最终结果 |
默认(8s) |
A节点故障 |
|
HA集群单节点故障 Mirror集群正常 |
A节点,B节点几秒内先后故障 |
|
HA集群故障不可用 Mirror集群报告Member Fail |
|
通过HA,执行数据库服务从A节点向B节点手动切换 |
|
HA集群正常 Mirror集群正常 |
|
调整为(80s) |
A节点故障 |
|
HA集群单节点故障 Mirror集群正常 |
A节点,B节点几秒内先后故障 |
|
HA集群故障不可用 Mirror集群报告Member Fail |
|
通过HA,执行数据库服务从A节点向B节点手动切换 |
|
HA集群正常 Mirror集群正常 |
测试结论:
- IRIS 数据库服务在Mirror 集群的Failover Member之间切换,在journal一致的前提下,只需要进行Mirror VIP漂移就可完成,而第三方HA集群切换则至少需要进行故障节点共享存储资源释放、接管节点的存储资源装载、接管节点数据库服务启动、HA Service IP漂移等一系列动作,故Mirror集群的内部切换要快于第三方HA集群的内部切换
- 可调整镜像服务质量超时时间,实现不同的切换效果,当镜像服务质量超时时间设置得长于HA的切换时间时,HA将先于Mirror切换,数据库服务中断时间相对长,切换逻辑相对简单。当镜像服务质量超时时间设置得短于HA的切换时间时,Mirror将先于HA切换,数据库服务中断时间短,切换逻辑相对复杂。
- IRIS中Mirror 集群的Failover节点数量为1-2个,可以通过第三方HA软件为Failover节点提供“热备”,提升IRIS数据库的可用性及业务连续性。