发布新帖
问题
· 三月 11, 2022

关于自动故障转移模式下备库离线对主库造成影响问题

#故障转移 #Caché

假如在自动故障转移模式下，镜像集群中两个镜像都是实时同步的Failover角色，当备库因为主机故障或者网络隔离等因素导致不可用，那么主库就收不到备库的ACKs，这个时候我看官方文档的解释是，主库会在Qos时间超时后，撤销备库日志传输的Active状态，那么在这个Qos时间段里（默认是8秒），主库是不会提交任何新的日志，那么遇到那些需要写或者更新的应用，应用会不会卡住8秒不动？ 这对一个医院系统来说也是致命的。

希望哪位大神能为我解答一下，谢谢

 

 

translate

If in the automatic failover mode, the two images in the mirror cluster are both real-time synchronous failover roles. 
When the standby database is unavailable due to host failure or network isolation, 
the master database will not receive the acks of the standby database. At this time, 
I see the explanation in the official document that the master database will revoke the active state of the log transmission 
of the standby database after the QoS time expires, In this QoS time period (8 seconds by default), the main database will not submit any new logs. 
Will the applications that need to be written or updated get stuck for 8 seconds? This is also fatal to a hospital system.

产品版本: Caché 2015.1
讨论 (8)2
登录或注册以继续
Weidong Li · 三月 11, 2022

不大清楚 2015.1 的机制，我们用的 2019.1。

在2019.1版本下，备库离线不会对主库造成任何影响，更不会带来应用卡住。如果在默认的时间（8s）内主库没有得到从库的ACK，另外一台会 force down，同时停止传输 mirror journal，恢复之后两边数据会追平，不用担心。

1 0
Hao Ma · 三月 13, 2022

理论上同步机制中，主库只有收到备库的ack才会完成一个写操作，也才会证实给客户端。如果备库8秒没证实，那么客户端是应该有8秒的'卡住‘的。 可以测试看看。可以设置成2秒看看， 如果没有存储快照造成的spike loading，2秒的设置也不应该造成不必要的切换。

0 0
jingwei lu · 三月 13, 2022

我也是这样觉得，官方文档原文解释就是，主库不会提交任何新的日志，这个日志应该指的就是有关于事务的日志，在这8秒内（Qos）对于一些只读的业务应该没影响吧，对于一些需要更新插入业务，可能会卡住吧。

还有就是如果是异步镜像，是不是就不存在这个Qos（8秒）问题？因为我觉得异步镜像是不是实时性要求是不是那么高，不需要备库实时的ACKs

0 0
Weidong Li · 三月 15, 2022

我们的 mirror 应该不是同步的吧，我之前做过测试，因为更新某些配置的原因，我直接 shutdown standby member，然后重启 standby，在这个过程中，没有收到 “卡住” 的报警。因为我们的 API 都有实时监控，外部调用方也有很多 API 监控，8s 的卡顿绝对会触发一堆警报的，实际上这个过程我们没收到任何报警 laugh

ps. 我们 API 的 QPS 其实不低的。

0 0
Louis Lu · 三月 16, 2022

“shutdown standby member“的操作应该与上面提到的"当备库因为主机故障或者网络隔离等因素导致不可用"是不一样的：

shutdown standby member是一个主动的将备机下线的过程，这个过程中，主机已经主动的将备机标注为“非激活”状态，这个时候主机不会等待备机的收到journal的信号，所以不会影响主机上的业务。

”当备库因为主机故障或者网络隔离等因素导致不可用“ 这个过程是一个被动不可预料的情况，这种情况下会有下面情况发生：
1. 在Qos规定的时间内，主机收到了备机的反馈信息，主机继续业务。


2a.在Qos规定时间内主机没有收到备机反馈信息，但是从仲裁服务收到冲裁服务仍能正常连接到备机的信息。会切换镜像状态监控模式为ISCAgent模式，业务访问主机不受影响。

null

2b. 在Qos规定时间内主机没有收到备机反馈信息，并且从仲裁服务也没有收到备机的情况，主机切换为ISCAgent监控模式，将备机置为trouble状态，主机继续承载业务。备机也会切换为ISCAgent监控模式，尝试重连主机。

null

3. 在Qos规定时间内主机没有收到备机反馈信息，也没有收到仲裁服务的信息。主机置为trouble状态。此时如果备机仍然保持和仲裁之间的连接，备机将会升级为主机，接管业务访问。当与原主机恢复连接后，会强制将原主机关机，以提醒管理员需要检查主机丢失连接的原因。

null

值得注意的是，IRIS/Caché 并不是直接将Journal的内容写入磁盘中的数据库文件中，Journal记录的是数据库的所有变化内容，而Write image journal(WIJ文件）则记录的是所有在内存中变化的但是还没有写到数据库的内容，写入磁盘的过程分两步，第一步将更新的内容从内存写入WIJ文件，WIJ标记准备写入磁盘的blocks 。第二步将标记的blocks写入磁盘，写完后，将第一步的标记清空。写入journal的过程是将journal buffer中记录的数据库内容的变化写入磁盘中的journal文件中。也就是说没有打开Journal功能的数据库文件依然是可以写入数据的（当然没有打开Journal功能是不能配置Mirror的）。

所以，说了那么多，对于终端用户基本上是感觉不到上面各种主备切换情况发生的。但是在系统终端是可以记录到的。

0 0
jingwei lu · 三月 13, 2022

你好，感谢你的解答，我还有两点问题：

你说的2019.1 是IRIS 数据平台么？  我看官网 Cache好像只有2018.1.6，之后就没了。

还有就是你说的，“另外一台会force down” 这个指的是备库被force down吧（如果备库还没有down也无法发送ACKs情况），而不是像oracle最大保护那样，主库会自杀吧？

0 0