The need for application-level replication
Database products from Microsoft and other vendors include native support for database replication. This raises the question of whether another replication layer is required. Following are reasons to use the application-level replication provided by Bravura Security Fabric :
Native replication is very complex to configure in order to make its performance optimal for each application. The set of available configuration options depend heavily on the runtime behavior of the application using that database; this may even differ from table to table:
Should logical or physical replication be used? Physical replication operates at the level of disk blocks while logical operates at the level of some database objects (details below).
If logical replication is chosen, at what level of granularity should replication be configured? Options include record-level, column-level, table-level or transactional.
Should replication be synchronous (potentially making each instance of the application slower) or asynchronous (where there are short time intervals during which each instance has different, possibly inconsistent data)?
Should failed updates be queued up or discarded?
How can unique keys generated by the database itself be guaranteed to be consistent across replicas?
What should the topology connecting nodes be?
Can communication between replicated database nodes be encrypted, to protect against data snooping and injection by a man-in-the-middle attack?
Without a deep understanding of application behavior, database administrators cannot make appropriate decisions about these parameters and may configure a non-performant or unreliable database back end for an application.
In contrast to the above complexity, the database replication built into all Bravura Security products:
Is included at no extra cost.
Provides for encrypted communication between nodes out of the box.
Performs reasonably well on wide area networks (not just high-bandwidth, low-latency local area networks).
Can be very simple to configure, with a few settings on the product configuration web based interface. This is the case for both direct and shared schema replication. Even though hybrid topology is not very simple to understand and configure, requires complex maintenance steps, it still uses fewer network resources and is more adapted to the way Bravura Security Fabric works compared to native-database replication.
Is fault-tolerant, queuing up updates made during failed network communication or other node’s unavailability due to maintenance, until a peer application node becomes available again.
Is asynchronous by default, and replicates only business/application-relevant data, offering the best possible performance for any given network conditions.
Best practice
Since replication is so valuable to Bravura Security Fabric deployments in general and to Bravura Privilege in particular, Bravura Security strongly recommends that customers leverage the built-in replication capability and always deploy at least two database nodes (or when 100% uptime is required, at least three database nodes).
In the case of Bravura Privilege , Bravura Security further recommends that the database nodes be installed as far apart as possible – preferably in different data centers, located in different cities that are not likely to be affected by the same natural disaster at the same time.
If the arguments above are not enough to sway the database administration team, or if the customer company has a hard requirement to use existing database-native replication or clustering:
Setting up the replicated nodes at the different data centers using native database replica nodes will have to be done as if all nodes are in shared schema (since all application nodes will see the distributed database as the same one)
Some functionality may break (because native database replication places locks on various parts of he schema as the data is replicated)
Some product operations will be much slower (since stored procedures will have to wait for data to replicate as they run, and since ALL data changes will be replicated instead of only relevant data).