Databases provide various replication approaches, simplifying and speeding up the recovery after a database failure and in some cases allowing an automatic failover between database nodes.

For automatic failover, replication has to happen transparently, that is, the cluster of replication nodes has to behave exactly as a single database node. Mainly this requires that every change is persisted on either all database nodes or on a sufficient quorum before a transaction commits, ensuring that the change remains visible after a failover (synchronous replication). Consult the documentation of your database product to determine how it can be configured accordingly.

Even if your database product does not support synchronous replication, database replication can still be helpful as a way to automate and greatly speed up the backup/restore process. In such a case, the JDBC driver should not be configured for automatic failover, because the entries in the caches of the Content Server and its clients could become outdated. Instead, the Content Server and all of its clients should be restarted after a node in the database cluster does down. Solr instances should be refeeded. Replication Live Servers should be restarted if the Master Live Servers was affected.