2 Replies Latest reply: Jul 21, 2014 4:32 AM by neighbour RSS

    Failback of failed TimesTen

    neighbour

      What is the right procedure to recover the failed TimesTen?

      We have the situation:

      2 hosts, TimesTen on each host, master-master replication.

      Host1 is active, there are continuous inserts/deletes into TimesTen on this host. Host2 is backup.

      Host1 crashes (HDD is lost). Host2 becomes active, which means that continuous inserts/deletes are now working on host2.

      Host1 is recovered from new hardware, TimesTen is installed.

       

      What are the steps to recover TimesTen on host1, so it has actual data and in sync with TimesTen on host2, without interrupting inserts/deletes on host2?

       

      If the answer is "no way to recover, don't use master-master replication", then what shall be the right replication scheme for the deployment:

      Datacenter1: host1.1, host1.2 (active, there are inserts/deletes on these hosts)

      Datacenter2: host2.1, host2.2 (standby, no TimesTen transactions on these hosts)

      ?

        • 1. Re: Failback of failed TimesTen
          Chrisjenkins-Oracle

          I'm amazed that you are asking this question *after* you have had a disaster. This is the sort of thing you should have implemented and tested as part of deploying your system. Anyway, the answer is straightforward.

           

          On the failed machine, re-install TimesTen and configure it exactly the same as it was configured prior to the HDD failure (including the DSN in sys.odbc.ini). The run the ttRepAdmin -duplicate command, with the right parameters and options (be sure to use -setMasterRepStart for example) on the recovered machine and once this has completed start the rep agent for the database on that machine. After a while the databases will be in sync again. In order to minimise the time needed for re-sync you should issue a checkpoint command on the primary database before starting the duplicate operation.

           

          Chris

          • 2. Re: Failback of failed TimesTen
            neighbour

            Of course this was a theoretical disaster. I should've said "Let's assume we have the situation".

            Thanks, I will check your proposal.