Bug 50155

Critical

GemStone/S 64 Bit

3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6

Hot standby: commitsSuspended on Master after failOverToSlave and subsequent failOverToSlave back to former master

V3.6 introduced a new Hot standby feature, failOverToSlave, allowing a master (stone A) and slave (stone B) to switch rolls, with the former slave becoming the master, and the former master becoming the new slave. After the failover, stone B is the master and stone A is the slave.  Subsequently, the stoneB can failOverToSlave back to stoneA, making stone A the master again, and stone B the slave again.

However, the second commitRestore making stone A the master again leaves commits suspended on the master. The commits suspended status is set in the root page, to avoid inadvertently clearing status if the stone is restarted, and therefore is not cleared by a stone restart.

Workaround

After a second failOvertoSlave, which puts stoneA into normal mode, execute:

   System resumeCommits


This must be done each time the stone is restarted.


Last updated: 10/31/22