Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Administering Failovers in a Distributed Environment

    This topic describes how to administer application and database server failovers in a distributed environment.

    Administering Failovers Using the Setup-failover Script

    Use the setup-failover.sh script to administer failovers.

    When the primary and secondary application and database servers are running correctly, use the setup-failover.sh script and specify the switchover option on the secondary server to switch it to be the primary:

    # /u/wandl/util/adminTools/setup-failover.sh switchover

    If the primary servers has failed, use the setup-failover.sh script and specify the survivor option on the secondary server to make it run as a standalone server:

    # /u/wandl/util/adminTools/setup-failover.sh survivor

    After you make the survivor server run as a standalone, when the server that was previously failed comes back online, use the setup-failover.sh script and specify the recover option on the surviving primary server to synchronize data with the recovered server, and configure the recovered server to run as the secondary.

    # /u/wandl/util/adminTools/setup-failover.sh recover

    Note: Servers must be shut down using the stop-all.sh script before using the setup-failover.sh script.

    Example Failovers In a Distributed Environment

    Use the following example procedure to understand how to administer failovers in a distributed environment.

    In this example, the initial states of the servers are:

    • ServerA—The primary application server. The IP address is represented as aaa.aaa.aaa.aaa.
    • ServerB—The backup application server. The IP address is represented as bbb.bbb.bbb.bbb.
    • ServerC—The primary database server. The IP address is represented as ccc.ccc.ccc.ccc.
    • ServerD—The backup database server. The IP address is represented as ddd.ddd.ddd.ddd.

    To administer failovers in a distributed environment:

    1. To display the current state, run the following script on the primary application server:
      ServerA# /u/wandl/util/adminTools/set-ip-all.sh
      Current IP settings:
      1.) Local (Primary Application Server) IP: aaa.aaa.aaa.aaa
      2.) Backup Application Server IP: bbb.bbb.bbb.bbb
      3.) Primary Distributed Database IP: ccc.ccc.ccc.ccc
      4.) Backup Distributed Database IP: ddd.ddd.ddd.ddd
      5.) Viewer Server IP: < if applicable >
      6.) Remote Collection Servers: < if applicable >
      7.) Data Collector Servers: < if applicable >
      Numbers of Data Collector: < if applicable >
      
    2. To verify the current state, run the following script on the secondary application server:
      ServerB# /u/wandl/util/adminTools/set-ip-all.sh
      Current IP settings:
      Current IP settings:
      1.) Local (Primary Application Server) IP: bbb.bbb.bbb.bbb
      2.) Backup Application Server IP: aaa.aaa.aaa.aaa
      3.) Primary Distributed Database IP: ddd.ddd.ddd.ddd
      4.) Backup Distributed Database IP: ccc.ccc.ccc.ccc
      5.) Viewer Server IP: < if applicable >
      6.) Remote Collection Servers: < if applicable >
      7.) Data Collector Servers: < if applicable >
      Numbers of Data Collector: < if applicable >
      
    3. If ServerA fails, use the following three scripts on ServerB to shut down the server, configure it to run as a standalone server, and then start the server:
      ServerB# /u/wandl/util/adminTools/stop-all.sh
      ServerB# /u/wandl/util/adminTools/setup-failover.sh survivor
      ServerB# /u/wandl/util/adminTools/start-all.sh

      At this point:

      • ServerA is failed.
      • ServerB is the standalone application server.
      • ServerC is the current backup database server.
      • ServerD is the current primary database server.
    4. If after ServerB is configured to run as a standalone server, ServerA comes back online, use the following three scripts on ServerB to shut down the service, configure the recovered server to run as the secondary, and synchronize data from the survivor ServerB to recovered ServerA:
      ServerB# /u/wandl/util/adminTools/stop-all.sh
      ServerB# /u/wandl/util/adminTools/setup-failover.sh recover
      ServerB# /u/wandl/util/adminTools/start-all.sh

      At this point:

      • ServerA is the current backup application server.
      • ServerB is the current primary application server.
      • ServerC is the current backup database server.
      • ServerD is the current primary database server.
    5. If after ServerA, ServerB, ServerC, and ServerD are stable for a period of time and you want to restore the original state, use the following three scripts on the appropriate server to shut down the service, and configure ServerA to run as the primary:
      ServerB# /u/wandl/util/adminTools/stop-all.sh
      ServerA# /u/wandl/util/adminTools/setup-failover.sh switchover
      ServerA# /u/wandl/util/adminTools/start-all.sh

      At this point:

      • ServerA is the current primary application server.
      • ServerB is the current backup application server.
      • ServerC is the current primary database server.
      • ServerD is the current backup database server.

    Modified: 2016-11-08