CA API Gateway 9.1

9.4 9.1

Upgrade Scenario 1 - Database with the Gateway

The most common upgrade scenario involves upgrading a gateway that includes a MySQL Gateway database on the same node. In this scenario, you create a new virtual instance of the latest Gateway version, and then move the database and supporting files over.
gateway92
The most common upgrade scenario involves upgrading a
CA API Gateway
 that includes a MySQL Gateway database on the same node. In this scenario, you create a new virtual instance of the latest Gateway version, and then move the database and supporting files over.
If your system is configured such that the database resides on a separate host, see Upgrade Scenario 2 - Database on Separate Host instead.
expedited_scenario_1
expedited_scenario_1
Workflow:
Before You Begin
  1. Set up a new Gateway with your destination version. Be sure to use the same passphrase for the cluster passphrase as the source Gateway.
    For more information about how to set up a new virtual appliance:
  2. If you are setting up a cluster of Gateways, set up replication first, then configure the first processing node, and then subsequent nodes. 
    For more information, see:
  3. (Optional) Save your audit events from the source Gateway. All audit events are discarded as part of this upgrade process. 
    For more information, see "Download Audit Events" in View Gateway Audit Events.
  4. Purge audit events from the source Gateway. For more information, see "Delete Audit Events" in View Gateway Audit Events. 
  5. If you are upgrading the database after Gateway patch installation, ensure that you either have the Administrative Database user (
    root)
     privileges or grant the user with similar privileges for successful upgrade.
Step 1: Export Database from Source Gateway
  1. Access the privileged shell on the source Gateway.
  2. Run the following command to export the Gateway database:
    # mysqldump ssg --routines > /home/ssgconfig/
    <source_Gateway>
    .sql
    Where 
    "<source_Gateway>"
     is any label that indicates the .sql file is the database from the source Gateway.  
  3. Copy the database from the source Gateway to the destination Gateway:
    # scp /home/ssgconfig/
    <source_Gateway>
    .sql ssgconfig@
    <destination_Gateway_Hostname>
    :~/
Step 2: Stop the Destination Gateway
Perform these steps on
every
 node on the destination Gateway:
  1. Access the privileged shell.
  2. Stop the node with this command:
    # service ssg stop
    The 'ssg' service must be stopped on all nodes, otherwise the upgrade is not successful.
Step 3: Import and Upgrade the Database on the Destination Gateway
Perform these steps on the primary node only:
  1. Access the privileged shell.
  2. Run the following commands:
    # mysqladmin drop ssg
    # mysqladmin create ssg
    # mysql ssg < /home/ssgconfig/
    <source_Gateway>
    .sql
    # service ssg start
    # exit
    You return to the Gateway main menu.
  3. Select option 
    2
     (Display CA API Gateway configuration menu) from the Gateway main menu.
  4. Select option 
    1
     (Upgrade the CA API Gateway database). Confirm the upgrade. Allow several minutes for the upgrade to complete.
Step 4: Restart the Gateway
After you have imported and upgraded the database, restart the Gateway cluster.
  1. Access the privileged shell again.
  2. Restart the Gateway by running this command on every node:
    # service ssg restart
Step 5: Install the License
  1. Start the Policy Manager and connect to your destination Gateway.
  2. Install?the license file.
Your destination Gateway is now operational.
Step 6: Post Upgrade Tasks
Some items cannot be brought over automatically in the expedited upgrade process. Manually complete the following tasks that apply to you:
  • Custom assertions:
     Any custom assertions that were present in your source Gateway must be reinstalled on the destination Gateway.
    For more information, see Install Purchased Custom Assertions.
  • Non-default assertions in your source Gateway:
     Certain assertion files are not be included in the upgrade. You must copy these files manually from the source Gateway to this directory on the destination Gateway:
    runtime/modules/assertions
    An example of non-default files is the.AAR files for modular assertions.
  • Copy .JAR files:
     You must copy all .JAR files from the source Gateway to these directories on the destination Gateway:
    /runtime/lib/ext
    /runtime/lib
    The .JAR files are required for some features to work (for example, JDBC or JMS).
  • Modify iptables:
    If the source Gateway had port redirects in the
    iptables
     file, you must reapply these manually on the destination Gateway.

Content feedback and comments