<< Introduction - TOC - Overview Of Replication >>
CSQL Replication prevents your business from losing significant revenue and damaging your business’s reputation by ensuring that your mission-critical data is highly available. Sharing corporate data is an important aspect of day-to-day business operations. Data replication generates and manages multiple copies of data at two or more sites, which allows an enterprise to share corporate data throughout its organization.
CSQL Replication plays a key role in the disaster recovery process, providing recovery of mission-critical data for applications at an alternate site. As the number of data-intensive and externally accessed applications increases, so does the need for high availability and greater amounts of data. This requires IT organizations to understand and classify each application’s availability and recovery requirements.
Defining application requirements is an essential step in creating a successful business recovery strategy. Two variables to consider when developing a recovery strategy are acceptable levels of downtime and freshness of data. CSQL replication addresses the needs for continuous availability and data consistency.
This section introduces the following information:
CSQL Provides two types of data replication: Synchronous and Asynchronous and the data which replicated is transactional level data that has been committed at the source site.
In case of synchronous mode, source instance (where transaction originates) transaction commits returns only after the transaction is committed at source instance and other destination instances in the quorum (group of CSQL instances taking part in the replication process). That means the data to be replicated is updated immediately when the source data is updated.

Fig-1.1 Synchronous Mode Replication
In Figure1-1, The transaction committed at Instance-1, will commit the data at Instance- 2 and Instance-3.
Synchronous data replication might be appropriate for applications that require immediate data synchronization. However, synchronous data replication requires that all hardware components and networks in the replication system be available at all times. It is difficult to guarantee the constant availability of all devices in a replication system, because hardware components and networks do fail at times. An alternative type of data replication is asynchronous data replication.
In case of asynchronous mode, source site transaction commit will return immediately after the transaction is committed at the source site and before returning from commit, transaction logs are generated and sent to the Replicator. The Replicator process takes care of applying these transactions at destination sites in the quorum.

Fig-1.2 Asynchronous Data Replication
However, the data eventually synchronizes to the same value at all sites. The major benefit of this type of data replication is that if a particular database server fails, the replication process can continue and the original transaction is not directly affected by replication. Asynchronous replication is the most common type of data replication in open-system environments because it protects against the system and network failures.
The most frequently used data-replication capture mechanism is log based.
Log-based data-capture systems operate as part of the normal database-logging process and add minimum overhead to the system. The most efficient and cost-effective data replication is an asynchronous replication that uses a log-based transaction-capture mechanism.

Fig-1.3 Log-Based Data Capture
CSQL Replication products use the following key elements to successfully replicate data throughout an open-system enterprise:
CSQL supports replication at multiple granular levels. Database level replication, replicates all the tables in the database whereas table level replication allows applications to choose what tables to replicate in the quorum. Refer “Load Balancing Cluster with distributed data” for more information.
Transactions are applied at destination sites in two modes namely, Synchronous and Asynchronous. The mode between two replicating sites need not be same. For example for two sites (site1 and site2 in replication quorum), site1 can propagate transactions to site2 in synchronous mode and site2 can propagate transactions to site1 in asynchronous mode or may not propagate transactions to site1.
In case of multi site cluster, application can choose the transaction propagation mode between each and every site in the quorum. Lets say you have four sites namely site1, site2, site3 and site4 in the quorum. Site1 and site2 can be connected using synchronous mode and site1 and site3 can be connected using asynchronous mode.

Fig-1.4 Both Sync and Async Mode Replication
A replication system must not burden the source site, must use networks and all resources efficiently.
CSQL Replication uses an efficiently, log-based transaction-capture mechanism that is integrated in the database architecture.
Replication can operate in a LAN, WAN, or combined LAN/WAN configuration across TCP/IP network protocols. CSQL Replication uses the standard database server communication facility to establish network connectivity among the replicated database servers involved in replication.
CSQL Provides sub second fail over as all transactions is applied at all the sites in the quorum. CSQL Replication provides continuous availability during planned maintenance operations such as software or hardware upgrade with no data loss.
A replication system must be reliable and must not expose business operations to computer system failures.
CSQL replication implemented asynchronous mode data replication. Asynchronous replication ensures that network and destination database server outages are tolerated. Replication also uses a delivery mechanism that stores data locally and then sends the data to the destination server in separate transactions. In the event of a database server or network failure, the local database server can continue to service the local users, which provides a high degree of fault tolerance.
CSQL Replication can be deployed as load balancing cluster with many sites to improve the throughput of the application. Transaction logs can be propagated by mediator components called ‘distributors’ whose job is to propagate transaction on behalf of the source site to the other entire destination site, reducing the load on the source site.
CSQL Replication supports intelligent load balancing techniques where subset of records is replicated rather than the complete table at every site. This mode is called as distributed replication, where each site contains records belonging to their zone and a centralized server, which contains the complete table for all zones. For more information refer “Load Balancing Cluster with distributed data” deployment option.
When a site goes down for any reason (planned maintenance, crash, or disaster), all the other sites in the quorum retains all the transactions at their local site till the site which went down resumes its operation. When the site comes back, it receives transaction updates from all the sites (transactions which happened when this site was down) and gets sync with all the other sites in quorum. This recovery is automatic and does not require any manual intervention.
And when a site goes down connected with its destination site using synchronous mode transaction propagation, the mode is automatically switched to asynchronous thereby avoiding transactions to fail. (Otherwise all transaction fails due to transaction executionfailure at destination site, which is down). This makes sure that no transaction fails because of site failure. When the down site resumes its operations, the mode shall be switched back to synchronous.
A replication system must protect data integrity. CSQL Replication employs transaction consistent replication, if transaction fails at any destination site connected using synchronous propagation mode, the transactions fails at the source site also. This ensures that two parallel conflicting transactions (For example, deducting balance from account) running in two different sites to fail and ensure consistency of data across sites in the quorum.
For asynchronous mode propagation, transaction conflicts at destination site are detected and logged into file so that the administrator can resolve conflicts. Conflict resolution could be additive, subtractive or replaceable based on the data on which conflict occurred. For Example in case of conflicting deposit, conflict resolution is additive whereas for withdrawal, it is subtractive.
CSQL Replication provides tools to check for consistency between sites connected in asynchronous mode to assist application for maintaining data consistency across quorum. If update conflicts occur, CSQL Replication provides built-in automatic conflict detection and resolution.
Administrators must be able to easily manage all the distributed components of the replication system from a single point of control. CSQL Replication system does not impose model or methodology restrictions on the enterprise. A replication system should allow replications based on specific business and application requirements.
CSQL Enterprise Replication supports the following replication models:
Replication provides expert operating modes to the user. The expert mode supports all ownership models. CSQL replication does not restrict the user for Operating Modes.
CSQL Replication is simple to use and requires minimal setup to get the data replicated. Requires no changes to application and minimal administration as CSQL has inbuilt selfhealing mechanisms to tolerate faults of individual sites in the quorum.
Load balancing database operations on multiple servers improves throughput by multifold. Most of the real time applications are read intensive and by employing cluster with multiple CSQL instances, load can be distributed among all of them to improve the overall database throughput.
Transactions originating at source site can be applied on destination sites either Synchronously or Asynchronously. The former provides high consistency and the later provides high throughput. In case of asynchronous mode, the data will be available at the destination sites after few seconds.
CSQL supports clusters up to 16 updateable CSQL instances, each propagating updates either in synchronous and asynchronous modes to other sites. There is no limit on the total number of read only CSQL instances in the quorum.
<< Introduction - TOC - Overview Of Replication >>