solidDB Help : Replication
  
Replication
Replicating data across multiple database instances is a powerful mechanism that enables you to scale a system to manage bigger data volumes and higher throughput.
solidDB provides three replication technologies:
▪ HotStandby (HSB) is targeted for high availability systems that need very fast failover and recovery functionality, using a 1+1 topology, see solidDB HotStandby.
▪ C Replicator (CREP) is an asynchronous mechanism to replicate write operations across any number of solidDB instances. The mechanism is based on reading entries from a transaction log and re-running the operations in one or more target databases as configured, see C Replicator.
▪ Advanced Replication uses built-in SQL extensions and is targeted for occasional or event-based asynchronous replication in N+M topologies, see Advanced Replication.
The following table compares the basic properties of HSB, CREP, and Advanced Replication. In addition to full replication solutions, the internal Log API in solidDB allows you to build proprietary replication mechanisms. For example, a proprietary mechanism might be the best solution for very specific and demanding requirements, or when replication to other brands of database is required.
 
Category
HSB
CREP
Advanced Replication
Intended use case
High availability and fault tolerance by database duplication. Retains high performance of a single solidDB server.
Permanently connected peer-to-peer network designed to retain high performance of a single solidDB server.
Loosely connected systems requiring transactional replication with low or moderate transaction loads.
Server count
Always 2
Any number
Any number
Cross-compatibility with other solidDB replication mechanisms
In Advanced Replication, master and replica databases can be a HSB pair.
All CREP databases can be one of a HSB pair.
All databases can be one of a HSB pair.
Do not use CREP and Advanced Replication to replicate to or from the same tables.
Master and replica databases can be a HSB pair.
Do not use CREP and Advanced Replication to replicate to or from the same tables.
Replication topology
2 nodes (primary and secondary)
Peer-to-peer network.
Hierarchical with multiple levels
Replication mechanism
One-directional. By default, synchronous replication of all write operations.
Reading write operations from transaction logs, re-executing selected transactions at specified nodes. Replication is possible in all directions by using the same mechanism.
Different mechanisms for moving data upward and downward in hierarchy. Transactions are propagated and re-executed upwards, updated rows are transferred downwards.
Conflict resolution
Not necessary, conflicts impossible.
Simple resolution rules by CREP module.
As the synchronization of databases is done by the application, conflict resolution must be done in the application by using stored procedures.
Support for different data in each server
Database instances are always exact copies of each other.
Full flexibility. All database instances can be subsets or supersets of each other. Replicated data is defined by replication partitions.
Tables or columns inside a replicated table can be excluded from replication.
Full flexibility. All database instances can be subsets or supersets of each other. Replicated data is defined by publications and saved statements.
Tables or columns inside a replicated table can be excluded from replication.
Application impacts
Application must handle errors caused by switches in server roles.
By default, the application is not aware of CREP. However, database schema must be aware of replication.
Application must be aware of Advanced Replication. Transactions to be propagated must be saved explicitly. Also, a separate replication control module is required to handle replication.
Additional architectural elements
A High Availability Controller (HAC) or Watchdog to monitor and control database instances (included with solidDB).
Replication must be configured and controlled in each target database.
A replication control module to control propagation and refresh of publications is not included in solidDB, and must be implemented at the application level.