2 Replies Latest reply on Feb 3, 2014 7:13 PM by Victor

    TimesTen Active Standby Pair: Standby Stuck at IDLE

    Victor

      I am having a standby TimesTen db that seems to be stuck at IDLE.  Any clues as to why that is?  I am attempting to following these instructions:

      Setting up an Active Master Database

       

      Let me provide some details.

       

      Here are the steps that I did.

       

      On the primary node I ran this

      create active standby pair repdb1_1122 on "tthost1", repdb2_1122 on "tthost2";

      NOTE:  I have tthost1 and tthost2 in my /etc/hosts file.

       

      I then ran the following command and got this output:

      Command> repschemes;

       

      Replication Scheme Active Standby:

       

        Master Store: REPDB1_1122 on TTHOST1

        Master Store: REPDB2_1122 on TTHOST2

       

        Excluded Tables:

          None

       

        Excluded Cache Groups:

          None

       

        Excluded sequences:

          None

       

        Store: REPDB1_1122 on TTHOST1

          Port: (auto)

          Log Fail Threshold: (none)

          Retry Timeout: 120 seconds

          Compress Traffic: Disabled

       

        Store: REPDB2_1122 on TTHOST2

          Port: (auto)

          Log Fail Threshold: (none)

          Retry Timeout: 120 seconds

          Compress Traffic: Disabled

       

      1 replication scheme found.

       

      I then ran the following on the primary node:

      call ttrepstateset ('active');

      call ttrepstateget;

       

      The above gave me the following output

      < ACTIVE, NO GRID >

      1 row found.

       

      I then started the replication on the primary node with this command:

      call ttrepstart;

       

      From the standby/secondary node I ran the following duplicate command

      ttrepadmin -duplicate -from repdb1_1122 -host "tthost1" -uid adm -pwd adm "dsn=repdb2_1122"

       

      Then on the secondary/standby node I ran

      ttisql

      connect "dsn=repdb2_1122;uid=adm;pwd=adm";

      call ttrepstart;

      call ttrepstateget;

       

      The output from the above commands is as follows:

      Command> connect "dsn=repdb2_1122;uid=adm;pwd=adm";

      Connection successful: DSN=repdb2_1122;UID=adm;DataStore=/tmp/repdb2_1122;DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;DRIVER=/home/timesten/TimesTen/tt1122/lib/libtten.so;PermSize=40;TempSize=32;TypeMode=0;

      (Default setting AutoCommit=1)

      Command> call ttrepstart;

      Command> call ttrepstateget;

      < IDLE, NO GRID >

      1 row found.

       

      Any idea on what I am doing wrong?  Any help is greatly appreciated!


      Let me know if there is any specific piece of info you would like me to share that I didn't include above.

       

      Thx,

      Victor

        • 1. Re: TimesTen Active Standby Pair: Standby Stuck at IDLE
          ChrisJenkins-Oracle

          Hi Victor,

           

          One of the common causes of this is that the system clocks are not adequately in sync between the two machines. TimesTen A/S pair replication requires the system clocks to be synchronised to an accuracy of < 250 ms difference. Check the message and error logs (<tt_install_dir>/info/ttmesg.log and <tt_install_dir>/info/tterrors.log>) for mesages complaining about clock skew.

           

          We'd recommend that you use NTP or similar to keep the clocks in sync.

           

          Chris

          • 2. Re: TimesTen Active Standby Pair: Standby Stuck at IDLE
            Victor

            Chris,

             

            Wow you nailed it.  That was the issue.  I completely forgot to look at the tterrors.log the problem was in clear sight...ugh.  Thank you so much.

             

            I have my TimesTen servers setup on Oracle Linux and I sync'd the clocks on both servers by doing

             

            yum install ntpdate

            ntpdate 0.rhel.pool.ntp.org 1.rhel.pool.ntp.org

            chkconfig ntpdate on

             

            Thanks,

            Victor

             

            Message was edited by: Victor updated the ntpdate command I used as well as added the "chkconfig ntpdate on" command