Deployment Options
<< Overview Of Replication - TOC - Setting Up Replication Environment Options >>
Active-Standby Replication
In active –standby configuration, application performs database operations only on active instance. If the active CSQL instance goes down for any reason, then application shall access the standby CSQL instance for performing database operations. This mechanism is called as fail over. CSQL keeps data at standby instance same as active database instance so that application can fail over to standby instance in sub seconds.
Fig 1-5. Active-Standby Replication
All the database operations such as INSERT, UPDATE, and DELETE on tables at active instance are applied transparently on standby database tables. CSQL can be configured either synchronously or asynchronously to apply these database operations on standby instance. For real time application, which require high throughput for modification operations, it makes sense to use asynchronous configuration. In asynchronous mode, execution returns immediately after it is performed at the active instance providing high throughput. Later CSQL replicator process makes sure that database operations at active instance are applied at standby instance without affecting the transactional behavior. When the active sites resumes its operations, application can choose between either of the instances to make it active or standby based on its requirement.
Active-Active Replication
In active –active configuration, application performs database operations on both the active instances. If any CSQL instance goes down for any reason, then application accesses the other CSQL instance for performing database operations. CSQL keeps data at both active instances same to provide sub seconds fail over.
All the database operations such as INSERT, UPDATE, and DELETE on tables at CSQL instance1 are applied transparently on database tables of CSQL instance2.
Fig-1.6 Active – Active Replication
If any CSQL instance goes down for any reason, the other instance preserves all the database operations that need to be applied (for updates which happen when the peer instance is down) and applies it when the instance which went down resume its operation.
If CSQL instances are connected using synchronous mode, when one instance goes down for some reason, it automatically changes to asynchronous configuration to preserve update logs for the other instance. Once this transition happens, application can reconnect and resume operations on it. The configuration can be changed to synchronous after the instance, which went down resumes its operation.
Load Balancing Cluster for Read
Most of the real time applications and high traffic web sites are read intensive. These applications shall distribute the query load to multiple instances to improve the throughput. In the above configuration, one instance is used for performing both read and write operations and other instances (CSQL Instance2 and CSQL Instance3) are used to distribute the load for read operations.
Fig 1-7. Load Balancing for Read
This deployment model is useful if your application has real time transaction requirement as well as near real time reporting requirements for different components. For example in SMS gateway application, the component which initiates the SMS sending process and stores the information in database requires real time performance and another component (reporting) which provides statistics and reports on the SMS application requires near real time performance. The former requires real time performance as it directly affects the total number of SMS sent / sec and the later require near real time performance where reporting web interface should display results within few seconds.
Balancing Cluster for Read/Write
This deployment option suites application which has mixed read /write load where performance improvement is required for both read and read/write transactions. This is achieved by employing two clusters; one, which allows both the operations and another, which allows, only read operations. Read/Write cluster can be configured either in synchronous or asynchronous mode based on the application requirement for freshness of the data.
Fig 1-8. Balancing Cluster for Read/Write
For example online charging (pre-paid billing) application does read/write transaction to retrieve and update the credit balance during the call for every minute (based on the pulse rate). This requires real time performance as the charging in done online during the call itself. These types of applications can employ the above deployment model for increasing their throughput.
Load Balancing Cluster with Distributor
This deployment model is well suited for application, which are Write intensive. Transaction logs when propagated to other sites, (CSQL Instance3 to CSQL Instance5) in quorum takes some CPU time, which may affect the throughput of the CSQL instance1 when there are large number of destination instances in the “Read cluster”.
Fig 1-9. Load Balancing Cluster with Distributor
To overcome this and provide high throughput for application accessing CSQL Instance1, the application can use another instance (called Distributor), CSQL Instance2 to propagate transaction to all the sites in the “Read Cluster” on behalf of the source site. Multiple distributors can also be employed to scale the number of CSQL instances in the “Read cluster”.
Load Balancing Cluster with Distributed data
This deployment model is well suited for application, which are distributed in nature but requires centralized management like banks and Visitor location Register (Telecom IN application). Instead of replicate the complete centralized database to all instances, application shall replicate data which belong to that particular zone or region it serves.
Fig 1-10. Load Balancing Cluster with Distributed Data
Telecom service providers divide the entire region they service into multiple zones (For example, state-wise) and keep records pertaining to that zone in the local data center rather than the remote centralized data center. This improves the performance of the application by multifold as it does not go over WAN for each database access.
In the above diagram, CSQL Instance1 stores only records for zone1 and replicates all the transactions that affect zone1 records to centralized database either in synchronous and asynchronous mode. CSQL Instance2 stores only records for zone2 and replicates all the transactions that affect zone2 records to centralized database.
The centralized database contains records up to date data for all the zones. This makes data management lot easier.
DBMS available in the market provide poor support for this configuration and puts more burdens on the application to replicate and manage data.
<< Overview Of Replication - TOC - Setting Up Replication Environment Options >>