After you upgrade the Distributed DDNS Application Node to v23.2.4, you can upgrade the Distributed DDNS Data Nodes in the database cluster and the Database Schema from the DDNS Deployment page. Updating the Distributed DDNS database cluster lets you take advantage of new features while maintaining support of your DDNS Data Node database cluster software.
You must upgrade the nodes and the schema in the following order:
Upgrade all Database nodes in the cluster.
Then, update the schema in one of the nodes in the cluster. Other nodes in the cluster will automatically inherit that schema.
You must upgrade all Database Nodes before updating the schema.
To view the list of BDDSes, go to the Distributed DDNS app from the Navigator and click the DDNS Deployment tab.
-
A green up arrow indicates that the version of the Database Node on that server is out of date and should be upgraded.
-
A blue up arrow indicates that the version of the Service Node on that server is out of date and should be upgraded.
-
: A grey "X" indicates that this Application Node cannot connect to that BDDS.
You cannot deploy a Distributed DDNS Service or a Distributed DDNS Database to a BDDS if that component was already deployed there.
You cannot deploy a Distributed DDNS Service to a BDDS if a DNS Service is currently deployed there.
After a fresh deployment, upgrade, or major configuration change in a Distributed DDNS system, the Distributed DDNS system needs time to synchronize its data among all database and service nodes. You can check the status in the database node's log messages. For more details, see Making sure that data is synchronized between Distributed DDNS nodes.
To upgrade Data Nodes in the database cluster
If your database nodes are connected to the internet, you can download the new docker image directly from quay.io. Otherwise, you can transfer the file to the machine as follows:
On a machine with an internet connection, run the following commands to download the new docker image and convert it to a transferrable file:
docker pull <Image name>
docker save <Image name> -o <Output file>
Transfer the file named
<Output file>
to the target machine and run the following command:docker load -i <Output file>
When you've transferred the docker image files (or if you'll be downloading directly from Quay), do the following procedure to perform a rolling upgrade:
-
Click the Switch DB button to see which Database Node the Application is connected to.
If this is the database node that you want to upgrade, first switch to another Database Node (select the IP address or URL of the other node from the list).
-
Click the database upgrade button (green circle with an up arrow) next to the database node that you want to upgrade.
The Upgrade Database Node window opens.
-
In the Authentication section, select either Password or SSH Key and provide the relevant authentication details.
-
Under Repository, enter the following:
-
In Image, enter the default URL for the database Docker image
-
If the DDNS image for the upgrade is located on Quay or a private repository, in User and Password, enter your Quay or local repository username and password.
You do not need to do this if you already transferred the docker image file to the machine.
-
-
When you're done, click Upgrade.
The system performs several validation checks throughout the upgrade process, displaying any reported errors and success messages.
Periodically, you will be asked to confirm the following information:- Check the current status of the Database Nodes in the database cluster, such as the total number of nodes and number of primary nodes.
- Check the external client connections to the Database Node and show all client IP addresses.
- Check the internal connections within the Database Node and display their process IDs.
-
When the upgrade completes, check the MariaDB service logs to make sure that the Database Node successfully joined the cluster and is properly synchronized with other databases in that cluster. For more details, see Configuring the MariaDB service.
-
If the node upgraded successfully and reconnected to the cluster, proceed to upgrade the next node in the cluster.
Check the log files on the Distributed DDNS Application Node to verify that the upgrade was successful for all Nodes. In particular, check the log of the MariaDB service on the DDNS Application.
Check the status of the Auto Backup, Auto Scavenge, and Sync Data daemons on the upgraded Distributed DDNS Application Node. If the daemons do not start automatically on any data node, start them on any node in the cluster. These daemons need be run only on one of the Data Nodes in the cluster.
Updating the database schema for the database cluster
You can update the schema on any node in the cluster. When the schema is updated on one node, the remaining nodes will receive the updated schema through database replication.
You must upgrade all Database Nodes on that cluster (as described above).
You must grant the
SUPER
privilege to theddns_admin
user on the Database Node that you want to update. If theddns_admin
user does not have this privilege, the database schema update will fail.To grant this privilege, you must be logged in as the root user on the BDDS with the Database Node. To log in as the root user:-
Open a bash session in the Database node container:
docker exec -it <container-name> bash
-
If you already changed the root password (as described in Changing the Distributed DDNS root password), you must log in using that new password:
Then, provide the password you configured for the root user. (If you have not yet changed the root password, the password will be blank.)mariadb -uroot -p --ssl
grant
command to apply theSUPER
privilege toddns_admin
:grant SUPER ON *.* TO 'ddns_admin'@'%' REQUIRE SSL ;
After granting this privilege, refresh the database list on the Deployment Tab. You should see a green schema update icon next to the chosen Database Node.
-
Click the green schema update icon (green page with an up arrow) next to the chosen Database Node. A window opens confirming the schema upgrade.
Click OK.
The database schema upgrade starts. After the schema update finishes, the remaining nodes in the cluster will also install the updated schema through database replication.