RAC 单节点宕机后负载重新均衡问题的测试和研究
使用两个floating VIP , 如图所示。 floating VIP1 优先绑定db1 server 物理地址, 当db1 不可用时,漂移到db2 上。 floating VIP2 和floating VIP1 类似。(这里的漂移发生的条件和表现可能不正确, 需要恩良童鞋补充下). 客户端jboss 使用如下格式在datasource-<appName>.xml 中配置
? 
<xa-datasource-property name="URL">
jdbc:oracle:thin:@(description=(address_list=(load_balance=on)(failover=on)(address=(protocol=tcp)(host=floating vip1)(port=xxx))(address=(protocol=tcp)(host=floating vip2)(port=xxx)))(connect_data=(service_name=xxx)(failover_mode=(type=select)(method=basic))))
</xa-datasource-property>
方案2使用一个个floating VIP , 如图所示。 floating VIP 优先绑定RAC 中的两个db server 物理地址, 当任何一个db 不可用时, floating VIP从双IP 漂移到单IP, 在db 宕机恢复后, floating VIP 重新恢复绑定双IP。

那么客户端的db 连接配置如下
<xa-datasource-property name="URL">
jdbc:oracle:thin:@(description=(address=(protocol=tcp)(host=floating VIP)(port=xxx))(connect_data=(service_name=xxx)))
</xa-datasource-property>
方案比较测试比较测试的目的是为了验证floating VIP 是否能够解决我们线上的问题, 并且比较两种floating 方案的优劣
测试环境乘着WMS DB 升级RAC 的机会, 我们在测试环境终于等到一套环境可以用来玩RAC了。 目前RAC 是这样的(这里的IP都是隐去的真实的IP,用户名密码信息和floating VIP 域名)
- 物理IP 192.1.1.101 server 上有sid wms1, service name wms 的Oracle 实例物理IP 192.1.1.102 server 上有sid wms2, service name wms 的Oracle 实例wms1, wms2 共用同一个高速存储wms1, wms2 分配给应用的user/PWD 相同, 为 wms/wmspass我们使用wms-vip1.com, wms-vip1.com 和wms-vip.com 三个floating VIP
- 机器部署Jboss 并发布WMS ear 包在PC 机上使用Jmeter 脚本以160 个线程的并发无限循环发送请求到172.18.48.122, 请求的序列为
- Logon如果Logon 成功, List当前用户下的最多 50 个最新的Customer
- 软重启: 命令行shutdown Oracle 实例, 等20 分钟后启动Oracle 实例硬重启:命令行restart linux OS, 等linux 启动完毕, 15 分钟后启动Oracle 实例
<xa-datasource-property name="URL">
jdbc:Oracle:thin:@(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = wms-vip1.com)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = wms-vip2.com)(PORT = 1521))(LOAD_BALANCE = yes)(FAILOVER = yes)(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = wms)(FAILOVER_MODE=(TYPE = SELECT)(METHOD = BASIC)(RETIRES = 180)(DELAY = 15))))
</xa-datasource-property>?
- 在Jmeter 执行界面看到在Oracle RAC 中其中一个实例在Shutdown的瞬间有8 个错误, 通过后台日志, 可以看到的是 db connection cannot be open过了重启Shutdown 时间窗口以后再没有其他和DB相关的错误;在Oracle 实例Shutdown 前 oracle instance1 有31 个连接, Oracle instance2 有39 个连接;Shutdown instance1 以后 instance2 连接数到63 个, instance1 0个启动instance1 以后, instance2 连接数在大约15 分钟(可能需要的时间更少, 我们是在大约15 分钟后重新检查的)后降到35 个, instance 1 中连接数达到33个
- ?在Jmeter 执行界面可以看到大概有162 个错误(猜测是Jemter 执行160个线程正在被Jboss执行中的140个),? 查看后台日志如下错误类型
- Db connection 连接错误DB commit abort 错误其他还有若干拿到的DBconnection? 为Null 的错误
<xa-datasource-property name="URL">
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=wms-vip.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=wms)))
</xa-datasource-property>
- ?在Jmeter 执行界面看到在Oracle RAC 中其中一个实例在Shutdown的瞬间没有任何Http 请求返回错误在Oracle 实例上的压力分摊类似双VIP配置 下的Oracle 软重启
- 在Jmeter 执行界面可以看到大概有140 个错误(猜测是Jemter 执行160个线程正在被Jboss执行中的140个),? 查看后台日志如下错误类型
- Db connection 连接错误?DB commit abort 错误其他还有若干拿到的DBconnection? 为Null 的错误
从测试结果看,
- ?JBoss会自动重联到重启的instance达到平衡的时间应该在15分钟以内两种Floating VIP 方式在Oracle 实例硬重启的时候表现大体相同对Oracle 实例软重启情况下, 使用单一floating VIP在可用性上有更好的表现
????? 建议单一VIP 方式。对应用可以屏蔽掉很多的DB 的细节。
注意事项在RAC 环境中, 因为db 实例1 和实例2 的一定是使用不同的SID但是共用相同的service name,
所以我们这种db 连接的配置就不灵光了
<xa-datasource-property name="URL">jdbc:oracle:thin:@floating-IP:port:SID</xa-datasource-property>
必须使用类似下面的配置方式
<xa-datasource-property name="URL">
jdbc:oracle:thin:@(description=(address=(protocol=tcp)(host=floating VIP)(port=xxx))(connect_data=(service_name=xxx)))
</xa-datasource-property>
????? 希望注意下。