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.
- Log in to the console of the BDDS of the Service Node in the cluster.
- 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.
- 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.
- Log in to the console of the BDDS of the Application Node in the cluster.
- Modify the /root/gwdata/app/mariadb.yaml file so that the host IP address points to another Data Node in the cluster.
- Log in to the Address Manager user interface.
- From the configuration drop-down menu, select a configuration.
- 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.
- Under Servers, click the name of a BDDS where the Application Node is deployed. The Details tab for the server opens.
- Click the Diagnostics tab.
- 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
- Log in to the console of the BDDS of the first node in the cluster.
- 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.
- 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.)
- 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
- 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.
- 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
- Log in to the console of the BDDS of a node in the cluster.
- 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.
- 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.