shard node的outage测试

shard node的路由方式有直接路由和代理路由,之前我们已经说过,由于我没有connection pool,我们只能来测试一下,在代理路由的情况下,连接shardcat的情况下,当shard node出现意外,连接在shardcat上的操作会发生什么问题。

这里我们要注意下,查询分如下几种情况:
1. 基于shard key的查询。
2. 不基于shard key的查询
3. multi shard的查询
4. 貌似基于shard key的查询。
(不喜欢看测试过程的,可以直接拖到文末看结果。^_^)

加载数据:

加载之后我的shard table,customers表的情况是:

所以我的查询语句就是:
1. 基于shard key的查询。
select CUSTID,FIRSTNAME,LASTNAME from customers where custid=’1′;
select CUSTID,FIRSTNAME,LASTNAME from customers where custid=’3′;

2. 不基于shard key的查询
select CUSTID,FIRSTNAME,LASTNAME from customers where PASSWD=’1000′;
select CUSTID,FIRSTNAME,LASTNAME from customers where PASSWD=’1002′;

3. multi shard的查询
select CUSTID,FIRSTNAME,LASTNAME from customers where custid in (‘1′,’3’);

4. 貌似基于shard key的查询。
select CUSTID,FIRSTNAME,LASTNAME from customers where custid=1;
select CUSTID,FIRSTNAME,LASTNAME from customers where custid=3;

我们通过一个循环语句来测试:



场景1:在没有dataguard FSFO保护的情况下,shard node 1 database crash。

–sh1 shutdown abort

我们看到,在sh1 shutdown abort之后,在shardcat上的查询,出现短暂的一次db link连接失败的报错后,后面就都是:
1. 基于shard key的查询。–访问sh1的操作失败,访问sh2的操作正常
2. 不基于shard key的查询。–无论访问sh1还是sh2,都失败
3. multi shard的查询 –访问失败
4. 貌似基于shard key的查询 –无论访问sh2还是sh2,都失败。

这里我们看出,貌似基于shard key的访问,如上面进行隐式转换的语句,看上去像基于shard key,其实还是不能正常访问到对应的shard node的。

我们再re-startup sh1

re-startup sh1之后,所有的访问都恢复正常。



场景2:在没有dataguard FSFO保护的情况下,shard node 1 主机 power down。

我们看到,在shard node 1 server power down之后,在shardcat上的查询,出现短暂的大约2分钟的hang,等待之后报错ORA-12543: TNS:destination host unreachable,再后面就和db shutdown abort的情况一下了:
1. 基于shard key的查询。–访问sh1的操作失败,访问sh2的操作正常
2. 不基于shard key的查询。–无论访问sh1还是sh2,都失败
3. multi shard的查询 –访问失败
4. 貌似基于shard key的查询 –无论访问sh2还是sh2,都失败。

–restart server之后,重启listener和db:



场景3:在dataguard FSFO保护的情况下,shard node 1 database crash。

我们可以看到,在50秒的时间,就完成了FSFO。在FSFO切换期间内:
1. 基于shard key的查询。–访问sh1的操作失败,访问sh2的操作正常
2. 不基于shard key的查询。–无论访问sh1还是sh2,都失败
3. multi shard的查询 –访问失败
4. 貌似基于shard key的查询 –无论访问sh2还是sh2,都失败。

等FSFO完,所有的操作就都恢复正常。

注意,FSFO完之后,数据库在broker中的状态变成需要reinstated:

我们现在来把sh1恢复成初始状态。
(1) 启动sh1数据库,注意,reinstate需要在standby上做,在sh1上做是会报错的。

(2) 在sh3上做reinstate,注意,做完reinstate之后,虽然不用re-create standby,但是sh3还是primary,sh1还是standby。另外,observer的状态还没有恢复。

(3) 我们先来恢复一下observer。在observer server上,也就是sh1上重置observer状态和重启observer进程:

(4) 我们把主备切换回来,sh1切回成主。注意切换过程,shard node会不可访问。

场景4:最后,我们来测试一下在FSFO保护的情况下,shard node 1 power down。

可以看到,当server的down的时候,被ovserver观察到,立马做主备切换。切换时间大约1分钟。 切换期间,行为和之前的一样:
1. 基于shard key的查询。–访问sh1的操作失败,访问sh2的操作正常
2. 不基于shard key的查询。–无论访问sh1还是sh2,都失败
3. multi shard的查询 –访问失败
4. 貌似基于shard key的查询 –无论访问sh2还是sh2,都失败

主机重启后,后续的操作也是类似的,启动listener,启动数据库,到sh3上做reinstate database sh1,再做switchover,再重启observer。

总结:
1. 在没有ADG+FSFO的高可用保护下,当shard node宕掉的时候,只有基于shard key的访问才能正常,其他的访问都不正常。需要等shard node重新启动后,才能恢复正常访问。
2. 在没有ADG+FSFO的高可用保护下,当shard node主机宕掉的时候,中间会hang两分钟左右的时间(因为TNS:Connect timeout),过了两分钟的停顿时间后,只有基于shard key的访问才能正常,其他的访问都不正常。需要等shard node重新启动后,才能恢复正常访问。
3. 在有ADG+FSFO的高可用保护下,当shard node宕掉的时候,只有基于shard key的访问才能正常,其他的访问都不正常。切换过程大约50秒,50秒之后,所有访问恢复正常访问。
4. 在有ADG+FSFO的高可用保护下,当shard node主机宕掉的时候,只有基于shard key的访问才能正常,其他的访问都不正常。切换过程大约50秒,50秒之后,所有访问恢复正常访问。

可以看到,有FSFO的保护,影响业务时间可以在一分钟以内。

另外,由于reinstate之后,还需要switchover,切换成本比较高,又是一次down库,所以如果有RAC,那么对业务的影响可以降至最低。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据