# Ensure databases must deploy at least one read replica node across failure domains - Source: https://support.icompaas.com/support/solutions/articles/a_1786023048792230-ensure-databases-must-deploy-at-least-one-read-replica-node-across-failure-domains - Section: [Solutions](https://support.icompaas.com/support/solutions) › [Utho Cloud](https://support.icompaas.com/support/solutions/c_1786022244474917) › [Utho Checks](https://support.icompaas.com/support/solutions/folders/utho-checks) - Last updated: 2026-08-13 - Publisher: iCompaas, Inc. (https://www.icompaas.com) Description: A read replica is an additional database node that maintains a copy of the primary database and can be used to handle read operations. Deploying at least one read replica helps distribute read traffic and reduces the workload on the primary database. The read replica should be deployed in a different failure domain from the primary database so that a failure affecting the primary database's infrastructure does not affect both nodes at the same time. Rationale: A database with only a primary node depends on a single database node for all read and write operations. Adding a read replica helps distribute read traffic and provides an additional copy of the database. Placing the primary database and read replica in different failure domains reduces the possibility of both nodes being affected by the same infrastructure failure. Impact: - Adding a read replica requires additional database resources and may increase cost. - Data replication must be maintained between the primary database and read replica. - Applications may need to be configured to send read requests to the read replica. - Replication delay may cause the read replica to temporarily contain slightly older data than the primary database. Default Value: A read replica may not be automatically created with every Utho Managed Database deployment. The database configuration should be reviewed to ensure that at least one read replica exists and is deployed in a different failure domain where Utho supports failure-domain placement. Pre-requisites: - A Utho account with permission to manage databases. - Access to the Utho Console. - An existing Utho Managed Database. - Permission to view and manage database nodes and replicas. - Sufficient resources to create an additional database node. - Availability of a different failure domain for the read replica, where supported. Remediation Test Plan: Using the Utho Console 1. Sign in to the Utho Console using an account with appropriate permissions. 2. Navigate to Database. 3. Locate the Managed Database that you want to verify. 4. Click Manage for the selected database. 5. Navigate to the Nodes or Replica section. 6. Review the nodes associated with the database. 7. Identify the Primary database node. 8. Verify that at least one Read Replica node is available. 9. Review the location, zone, or failure-domain information for the Primary and Read Replica nodes, if this information is provided by Utho. 10. Verify that the Read Replica is deployed in a different failure domain from the Primary database. 11. If no Read Replica exists, or if the Read Replica is not distributed across a different failure domain, follow the Implementation Steps to remediate the issue. Using the Utho API Retrieve the database information using the Utho API. curl -s \\ \-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\ https://api.utho.com/v2/databases/ Review the returned database information and identify the Primary and Replica nodes. Verify that: - At least one Read Replica node exists. - The Read Replica is running and associated with the required database. - The Primary and Read Replica are in different failure domains if Utho exposes failure-domain information through the API. Implementation Steps: Using the Utho Console 1. Sign in to the Utho Console using an account with appropriate permissions. 2. Navigate to Database. 3. Locate the Managed Database that requires a Read Replica. 4. Click Manage for the selected database. 5. Navigate to the Nodes or Replica section. 6. Review the existing Primary and Replica nodes. 7. If no Read Replica exists, select the option to Add Replica. 8. Configure the required database node resources. 9. If Utho provides a Region, Zone, or Failure Domain selection, select a failure domain different from the Primary database. 10. Create the Read Replica. 11. Wait for the Read Replica to be created and synchronized with the Primary database. 12. Verify that the Read Replica is running successfully. 13. Verify that the Read Replica is deployed in a different failure domain from the Primary database, where Utho provides this capability. Using the Utho API Utho provides an API operation for adding a replica to a database cluster. curl -X POST \\ \-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\ \-H "Content-Type: application/json" \\ https://api.utho.com/v2/databases//replica After creating the replica, retrieve the database details again. curl -s \\ \-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\ https://api.utho.com/v2/databases/ Verify that the new Replica node has been added and is running. Note: Do not assume that Utho's replica API automatically means a dedicated read replica across failure domains. The exact replica type and failure-domain placement must be confirmed from the Utho database configuration/API response. If Utho does not provide failure-domain selection or information, that part of this check cannot be directly validated from the available configuration. Backout Plan: 1. Sign in to the Utho Console using an account with appropriate permissions. 2. Navigate to Database. 3. Locate the affected Managed Database. 4. Click Manage for the selected database. 5. Navigate to the Nodes or Replica section. 6. Identify the Read Replica that was added during the implementation. 7. Ensure that no application is currently dependent on the Read Replica for read operations. 8. Remove the newly created Read Replica. Using the Utho API If the newly created replica needs to be removed, use the documented replica deletion operation: curl -X DELETE \\ \-H "Authorization: Bearer $UTHO\_API\_TOKEN" \\ https://api.utho.com/v2/databases//replica/ Verify that the database continues to operate correctly after removing the replica. References: - [Utho Documentation](https://utho.com/docs/) - [Utho Managed Database](https://utho.com/managed-database) - [Utho REST API Documentation](https://utho.com/rest-api/) - [Utho API](https://utho.com/api/) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.