Updating the Distributed DDNS Data Node and database cluster - Adaptive Applications - BlueCat Gateway - 21.3

BlueCat Distributed DDNS Administration Guide

Locale
English
Product name
BlueCat Gateway
Version
21.3

Updating the Distributed DDNS Data Node database cluster allows you to take advantage of new features, while maintaining support of your DDNS Database Node database cluster software. Performing a rolling update can be time consuming, depending on the size of the database and the number of nodes that exist in the cluster. During the database update, the cluster operates at a reduced capacity while nodes update.

Before you begin

BlueCat recommends performing a database backup of the cluster before proceeding to update the database. For more information on performing a database backup, refer to Configuring Auto Backup service.

You must redirect client connections from the Service Node to another Data Node while the Data Node is updating. To redirect client connections from the Service Node to another Data Node, modify the /var/lib/docker/volumes/ddns_config/_data/mariadb.yaml file on the Distributed DDNS Service Node so that the IP address of the Data Node is the last node to be updated.

To redirect Service Node client connections
  1. Log in to the console of the BDDS of the Service Node in the cluster.
  2. Modify the /var/lib/docker/volumes/ddns_config/_data/mariadb.yaml file so that the host IP address points to another Data Node in the cluster. This Data Node should be the last node to be updated.
  3. Restart the DDNS service container by running:
    docker restart <ddns_container_name>

You must also redirect client connections from the Distributed DDNS Application Node to another Data Node while the Data Node is updating. To redirect client connections from the Application Node to another Data Node, modify the /root/gwdata/app/mariadb.yaml file on the Distributed DDNS Application Node so that the IP address of the Data Node is the last node to be updated.

Additionally, you must redirect the client connections from the Distributed DDNS Application Node to another Data Node.

To redirect the Application Node client connections
  1. Log in to the console of the BDDS of the Application Node in the cluster.
  2. Modify the /root/gwdata/app/mariadb.yaml file so that the host IP address points to another Data Node in the cluster.
  3. Log in to the Address Manager user interface.
  4. From the configuration drop-down menu, select a configuration.
  5. Select the Servers tab. Tabs remember the page you last worked on, so select the tab again to ensure you're on the Configuration information page.
  6. Under Servers, click the name of a BDDS where the Application Node is deployed. The Details tab for the server opens.
  7. Click the Diagnostics tab.
  8. From the Actions menu, select Restart Gateway Container and click Execute.

Once you click Execute, Address Manager confirms that the container restart command is issued. To verify the container status, select the BlueCat Gateway service configuration and navigate to the bottom of the page. If the Status field displays STOPPED, Gateway Service is enabled but the container is stopped.

Performing a rolling update of the database cluster

  1. Log in to the console of the BDDS of the first node in the cluster.
  2. Load the Distributed DDNS Data Node image using the following command:
    docker load -i <node_tar_file>

    If you do not have the image saved locally, you can use the docker pull command to pull the image from Quay.

  3. If this is the last node to be updated, redirect all client connections to other nodes in the database cluster before you continue. (See Before you begin.)
  4. Stop and remove the old Distributed DDNS Data Node container from the BDDS by running the following commands:
    docker stop <node1_name>
    docker rm <node1_name>
    Attention: Ensure that you do not remove any Docker volumes created by the old Distributed DDNS Data Node container. Verify that the daemon-config, mariadb-config, mariadb-data, mariadb-backup, and dbssl-config volumes are still available on the BDDS by running the following command:
    docker volume ls
  5. Deploy the updated Distributed DDNS Database image through the DDNS Application UI. For more information, refer to Deploying Distributed DDNS Data Nodes on a BDDS.
  6. Verify that the node has successfully joined the cluster and finished synchronizing by checking the Distributed DDNS Data Node container log using the following command:
    docker exec <node1_name> tail -f /var/log/mysql/mariadb.err

    The node must successfully join the cluster and synchronize before you proceed to update the remaining nodes in the cluster.

    You can also view the Distributed DDNS Database log information from the Distributed DDNS Application Node UI. For more information, refer to Database Node information.

Once the node has successfully installed the updated software, you can proceed to update the next node in the cluster.

After the upgrade

  • Check the log files on the Distributed DDNS Application Node to verify that the update was successful. In particular, check the log of the MariaCB service on the DDNS Application.

  • Check the status of the Auto Backup, Auto Scavenge, and Sync Data daemons on the updated Distributed DDNS Application Node. If the daemons do not start automatically on any database node, start them on any node in the cluster. The daemons only need to run on one of the Data Nodes in the cluster.

Performing a database schema update

Before you proceed to update the database schema, you must first update the database software. You can update the schema on any node of the database cluster. Once the schema has been updated on one node, the remaining nodes in the cluster receive the updated schema through database replication.
  1. Log in to the console of the BDDS of a node in the cluster.
  2. Check if a database schema update is available using the following command:
    docker exec <node_name> dbmigration --check-upgrade-path

    The command displays a list of available updates.

  3. Update the database schema using the following command:
    docker exec <node_name> dbmigration --upgrade-schema

    The command updates the database schema to the latest version that matches the database software installed on the nodes.

Once the database schema has been updated, the remaining nodes in the cluster install the updated schema through replication.