8110: Connection not permitted. This store may require Master Catchup

Question

hi Chris,
Pleasse help me.
I configure Timesten Active Stand by two node (test1 and test2) Return TwoSafe, with Cache Group Type: Asynchronous Writethrough global (Dynamic). That okie.
But when i using App (connect vi mode Client/Server) update to table that cache, duration time update i run command ((in node test2 - Standby)):
call ttrepstateset('active');
call ttRepStateSave('FAILED', 'sampledb_test1','test1');
But after that the IMDB in test1 can't connect and had error: 8110: Connection not permitted. This store may require Master Catchup
I test other schema, don't update to table cache and change role two server by run command:
call ttrepstateset('active');
call ttRepStateSave('FAILED', 'sampledb_test1','test1');
Show after that IMDB in test1 can connect and is Standby DB but have'nt grid and can't attach grid. I must detach grid in node test2 (is active) and attach grid in two node again.
Can you explain for me Why??? and have solution
Thanks.

Answer 1

Hi,
The main issue here is that a TimesTen A/S pair must be managed as a single entity. This means co-ordinating state changes at both nodes and making sure they are done correctly according to the procedures documented in the Timestne Replication Guide (which gives detailed procedures for failover, controlled switchover etc.).
Upgrading the standby (test2) to an active (which is what you are doing) should only be done when the current active has failed. In your case the current active (test1) has not actually failed - it is still alive and when the old standby (test2) switches to become an active you have a 'dual active' situation which is bad. TimesTen defends against this by blocking access to the old active until it has been properly recovered as the new standby. The exact symptoms that you see at the old active may differ depending on whether you are using return twosafe or asynchronous replication and whether there was any workload (and hence any in progress tranbsactions) running at the time you execute these commands.
I would strongly recommend that you studythe relevant sections in the TimesTen Replication Guide in order to understand the necessaqry sequence of operations needed for (a) a failover when the active has actually failed and (b) a controlled switchover when the active is still alive but you just want to reverse the active/standby roles. They are both more complex and involve more steps than your test scenario. I would strongly recommend use of Oracle Clusterware to manage all this automatically (see the Replication Guide);it results in a much simpler and more robust solution.
Chris