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