Application level versus database-native
Some applications require a high performance backend database but not near-100% uptime. In these cases, it makes sense to construct a high-availability, high-capacity database cluster and share this cluster between many applications; this is also known as backend/database-native replication.
It is recommended to deploy an application in a geographically distributed architecture without having to configure multiple (expensive) database clusters – one per region; however, there are pros and cons with each type of replication.
The drawbacks of using a natively-replicated database or a cluster are:
If the cluster is damaged or becomes unreachable, then all of the applications that use it go off-line.
A cluster or any other form of database-level replication sends all data changes to its replicas.
Backups are critically important in a database cluster, since failures impact many applications.
Modern database server software from Microsoft and other vendors have poor isolation between logical instances. An overloaded or badly written application using one logical schema can consume too much session space, disk I/O and CPU, impacting the performance and availability of other applications that use the same cluster.
Application-level replication, on the other hand:
Eliminates any single point of failure, so is more fault tolerant.
Can be configured to provide total isolation between applications. A badly behaving database node with its own, private database server cannot adversely impact the data on other database nodes.
Can reduce network traffic and increase performance by only replicating the data that is important to exist on all replicas.
The main drawbacks of application-level replication are:
As a result of replication failures, the database nodes can fall out of sync; in application-level replication, the sync status has to be verified as part of regular database maintenance.
Applications have to be written with replication in mind. In particular, the process used to assign unique identifiers to new records has to be replication-aware.
More physical databases are deployed.
As mentioned above, more maintenance is needed to verify data synchronization, and decisions on what data to keep and what data can be left out of sync have to be made. This is actually a trade-off; in database-level replication data is lost on all nodes, and in application-level replication data is lost only on the database node where the error occurs.
Best practice
Since high availability is such an important design parameter for the Bravura Security Fabric in general and of Bravura Privilege in particular, Bravura Security strongly recommends that customers deploy a replicated architecture, rather than overburden an existing database cluster.