Upgrade Scenario 2 - Database on Separate Host

A less common configuration is one where the gateway resides on one host, while the MySQL Gateway database resides on another. In this configuration, you create a new virtual Gateway, upgrade the database, and then configure the new Gateway to point to the database.
gateway93
A less common configuration is one where the
Layer7 API Gateway
resides on one host, while the MySQL Gateway database resides on another. In this configuration, you create a new virtual Gateway, upgrade the database, and then configure the new Gateway to point to the database.
If your system is configured using the more common setup where the Gateway and database are together, use Upgrade Scenario 1 - Database with the Gateway instead.
expedited_scenario_2
expedited_scenario_2
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:
    • See the
      CA API Gateway Virtual Appliance Getting Started
      guide under "CA API Management Technical Documentation" in the Release Notes page under Gateway Version 9.3 documentation.
  2. (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.
  3. Purge audit events from the source Gateway. For more information, see "Delete Audit Events" in View Gateway Audit Events.
  4. Upgrade the MySQL Server to version 5.7.
Step 1: Stop All Nodes on Source Gateway
Perform the following steps on every node in the source Gateway cluster:
  1. Access the privileged shell.
  2. Stop the Gateway service:
    # service ssg stop
Step 2: Modify Permissions on the Database Host
Next, perform these permissions grants on the master database host:
  1. Start MySQL:
    # mysql -u root -p
  2. Run the following MySQL commands to modify the permissions for the Administrative Database User:
    CREATE USER '<ADU>'@'<HOSTNAME>' IDENTIFIED BY '<PASSWORD>';
    GRANT ALL ON <DBNAME>_testUpgrade.* TO '<ADU>'@'<HOSTNAME>' IDENTIFIED BY 'password' WITH GRANT OPTION;
    GRANT ALL ON <DBNAME>.* TO '<ADU>'@'<HOSTNAME>' IDENTIFIED BY '<PASSWORD>';
    GRANT ALL ON mysql.* TO '<ADU>'@'<HOSTNAME>' IDENTIFIED BY '<PASSWORD>';
    FLUSH PRIVILEGES;
    Where:
    • <ADU> is the Administrative Database Username. This should match the value that is entered in "Step 4: Upgrade the Database", in step 5.
    • <HOSTNAME> is the hostname of the Gateway primary node
    • <PASSWORD> is the password for the Administrative Database User. This should match the value that is entered in "Step 4: Upgrade the Database", in step 5.
    • <DBNAME> is the database name. This should match the value that is entered in "Step 4: Upgrade the Database", in step 5. (default
      ssg
      )
  3. Exit MySQL.
Step 3: Restart the Gateway
  1. Run the following on all destination Gateway nodes:
    # service ssg restart
Step 4: Upgrade the Database
Perform the following steps on the primary node in the destination Gateway cluster.
  1. Access the privileged shell.
  2. Start the Gateway service:
    # service ssg start
  3. Exit the privileged shell and return to the Gateway main menu.
  4. Select option
    2
    (Display CA API Gateway configuration menu) and then option
    1
    (Upgrade the CA API Gateway database).
  5. Complete the prompts that are presented:
    • Enter database host:
      Enter the master database host IP address.
    • Enter database port:
      Enter the port number (default
      3306
      ).
    • Enter database name:
      Enter the database name (default
      ssg
      ).
    • Enter database username:
      Enter the name of the user who has access to the database (default
      gateway
      ).
    • Enter database username password:
      Enter the password of the database user.
    • Perform upgrade
      : Enter
      yes
      .
    • Enter Administrative Database Username:
      Enter the username of the root MySQL user (default
      root
      ).
    • Enter Administrative Database Password:
      Enter the password for the root MySQL user.
Step 5: Configure the Destination Gateway
In this step, you configure the destination Gateway to use the newly upgraded database. Perform the following steps on each Gateway node.
  1. Access the Gateway main menu.
  2. Select option
    2
    (Display CA API Gateway configuration menu) and then option
    3
    (Configure the CA API Gateway).
  3. Complete the prompts that are displayed. For a description of each prompt, see Gateway Configuration Menu (Appliance).
    Tip:
    Option 3 mostly repeats all the prompts that are displayed when you used option 2 (Create a New CA API Gateway Database).
  4. Review the configuration summary carefully. If everything is in order, press
    Enter
    to complete the configuration.
Step 6: 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 7: Test Upgrade and Restore Privileges in MySQL Database
In "Step 2: Modify Permissions on the Database Host", "GRANT ALL" was used for expediency:
GRANT ALL ON mysql.* TO '<ADU>'@'<HOSTNAME>' IDENTIFIED BY '<PASSWORD>';
You can now restore the privileges to normal.
To restore the privileges:
  1. Start MySQL on the database host:
    # mysql -u root -p
  2. Run this command:
    REVOKE ALL ON mysql.* FROM '<ADU>'@'<HOSTNAME>';
    Where:
    • <ADU> is the Administrative Database Username, as entered in "Step 4: Upgrade the Database", in step 5.
    • <HOSTNAME> is the hostname of the Gateway primary node
  3. Exit MySQL.
Step 8: 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).