High-Availability

Application-level High-Availability

Applications that communicate over networks and cloud services are subject to transient connection failures. You want to design your applications to retry connections when errors are caused by a temporary loss in connectivity to your deployment or to IBM Cloud.

Because Databases for DataStax is a managed service, regular updates and database maintenance occurs as part of normal operations. This maintenance can occasionally cause short intervals where your database is unavailable.

Your applications must be designed to handle temporary interruptions to the database, implement error handling for failed database commands, and implement retry logic to recover from a temporary interruption.

Several minutes of database unavailability or connection interruption are not expected. Open a support ticket with details if you have time periods longer than a minute with no connectivity so we can investigate.

Replication, keystores, and High-Availability

When you create the keyspace, it is up to you to define the number of replicas and strategy. Setting the value to NetworkTopologyStrategy and number of replicas matching your deployment, the distribution across zones occur automatically (except within single zone regions like Chennai, Oslo, Seoul where replication is contained to that single zone). You can read more about the replication strategies in the DataStax Enterprise documentation.

To help ensure availability of data, setting the replication factor that matches your deployment is necessary. When you create key spaces, make sure to set the replication factor to the number of nodes (or members) in your cluster. The following example shows this set to 3, where eu-gb is the region set based on the location of the formation in the CRN:

create keyspace if not exists ibm with replication = {'class' : 'NetworkTopologyStrategy', 'eu-gb' : 3};

Setting a replication factor of 1 results in your data becoming unavailable at times due to routine internal maintenance or other interruptions. To help ensure availability of data, it is recommended to set a replication factor of 3. NetworkTopologyStrategy attempts to place replicas on distinct racks because nodes in the same rack (or similar physical grouping) often fail at the same time due to power, cooling, or network issues.

For your IBM Cloud® Databases for DataStax deployment, the “data center” attribute equates to a region (for example, eu-gb) and the “rack” attribute reflects the actual IBM Cloud data center (for example, lon04/lon05). Setting a replication factor of 3 helps ensure that replicas are distributed across availability zones.

Using NetworkTopologyStrategy and setting a replication factor greater than 1 ensures that replicas are distributed across data centers in multi-zone regions.

Use IBM Cloud® Monitoring to monitor your deployment. Adjust either by manually scaling, or by using the autoscaling feature to ensure continued high availability.

High availability, disaster recovery, and SLA resources

Databases for DataStax deployments conform to the IBM Cloud Databases HA, DR, and SLA terms.