Description:
A standby replica is an additional database node that maintains a copy of the primary database and can be used when the primary node becomes unavailable. Deploying at least one standby node in a separate failure domain helps reduce the risk of database downtime caused by a single node or infrastructure failure.
Utho Managed Databases support primary-standby replication and automatic failover for supported database engines. Utho also provides APIs to retrieve individual database nodes and manage replica nodes.
Rationale:
A database with only one node has a single point of failure. Having a standby node provides another node that can take over when the primary node becomes unavailable.
Deploying the standby in a different failure domain provides additional protection against failures affecting the primary node's infrastructure location.
Impact:
A standby node consumes additional database resources.
Additional resources may increase the cost of the database deployment.
Database replication must remain healthy between the primary and standby nodes.
The standby should be placed in a different failure domain from the primary node where the platform supports this configuration.
Default Value:
Utho Managed Databases support primary-standby replication with automatic failover for supported database services. The database configuration should be reviewed to ensure that at least one standby node is present and that the nodes are distributed across separate failure domains where supported.
Pre-requisites:
A Utho account with permission to manage Managed Databases.
Access to the Utho Console.
A Utho Managed Database cluster.
Permission to view database cluster nodes.
Knowledge of the required failure domains for the database deployment.
Remediation
Test Plan
Using the Utho Console
Sign in to the Utho Console using an account with appropriate permissions.
Navigate to Database.
Locate the Managed Database cluster that you want to verify.
Click Manage for the selected database cluster.
Open the Node section.
Review the nodes associated with the database cluster.
Identify the Primary database node.
Verify that at least one standby/replica node is present.
Review the location or failure-domain information for the primary and standby nodes.
Verify that the standby node is deployed in a different failure domain from the primary node.
If the database has no standby node or the standby is located in the same failure domain as the primary node, follow the Implementation Steps to remediate the issue.
Using the Utho API
Retrieve the database cluster details.
curl -s \
-H "Authorization: Bearer $UTHO_API_TOKEN" \
https://api.utho.com/v2/databases/<cluster-id>
Retrieve the details of the database nodes.
curl -s \
-H "Authorization: Bearer $UTHO_API_TOKEN" \
https://api.utho.com/v2/databases/<cluster-id>/<cloud-id>
Review the returned node information and verify that the cluster has at least one standby/replica node and that the primary and standby nodes are deployed across different failure domains where the API exposes that information. Utho documents the cluster-detail and individual-node API endpoints.
Implementation Steps:
Using the Utho Console
Sign in to the Utho Console using an account with appropriate permissions.
Navigate to Database.
Locate the Managed Database cluster that requires remediation.
Click Manage for the selected database cluster.
Open the Node section.
Review the existing database nodes.
If no standby/replica node is present, add a replica/standby node to the database cluster.
Select a failure domain different from the primary node when the Utho configuration provides a failure-domain selection.
Complete the replica/standby node deployment.
Using the Utho API
If a standby/replica node is not present, Utho provides an API operation to add a replica node:
curl -X POST \
-H "Authorization: Bearer $UTHO_API_TOKEN" \
-H "Content-Type: application/json" \
https://api.utho.com/v2/databases/<cluster-id>/replica
Utho documents POST /databases/{clusterid}/replica for adding a replica node.
After adding the replica, retrieve the cluster and node details again:
curl -s \
-H "Authorization: Bearer $UTHO_API_TOKEN" \
https://api.utho.com/v2/databases/<cluster-id>
Verify that the standby/replica node is present and that the primary and standby nodes are distributed across different failure domains where this information is available through the API.
Note: Utho's public API documentation confirms the replica-node operation but does not document a specific request parameter for selecting a failure domain for the replica. Do not invent a failure_domain parameter. If the API does not expose failure-domain placement, perform that part of the validation and placement through the Utho Console or the Utho-supported configuration method.
Backout Plan:
Sign in to the Utho Console using an account with appropriate permissions.
Navigate to Database.
Locate the affected Managed Database cluster.
Click Manage for the selected database cluster.
Open the Node section.
Identify the standby/replica node that was added during remediation.
Verify that the node is not required for the database's current availability configuration.
Remove the standby/replica node if it is no longer required.
Verify that the database cluster continues to operate normally after the node is removed.
If using the Utho API, Utho documents the replica-node deletion operation:
curl -X DELETE \
-H "Authorization: Bearer $UTHO_API_TOKEN" \
https://api.utho.com/v2/databases/<cluster-id>/replica/<cloud-id>
Utho documents DELETE /databases/{clusterid}/replica/{cloudid} for deleting a replica node.
References: