Bug 50147

Critical

GemStone/S 64 Bit

3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6

Hot standby: freeOopsList issue 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.

There is a risk of corruption if, after the first failOverToSlave, a second failOverToSlave is executed, making stone A the master again, and stone B the slave. Internal testing detected a case where the Stone's transient freeOops list contained oops of committed objects; this doesn't effect the slave, but becomes a problem when Stone A is again in normal mode and can commit.

Workaround

To avoid issues, after the Stone A first executes failOverToSlave, but before Stone A executes commitRestore to become the new-new master, the Stone A needs to be stopped and restarted. The stone restart refreshes the transient symbol list.


Last updated: 10/28/22