Repstance is an entirely new real-time data propagation product for homogeneous and heterogeneous environments that supports various replication topologies. It is available in two versions: “Repstance” and “Repstance Advanced Edition”.
“Repstance” supports Oracle, MS SQL Server (with the ability to enable CDC) as a Source Database and Oracle, MS SQL Server as a Target Database.
“Repstance Advanced Edition” is an extended version of “Repstance”, which in additional supports PostgreSQL, MySQL, Snowflake, Aurora (PostgreSQL, MySQL) as a Target Database.
Repstance includes the functionality to support DML and DDL operations, both of which can be automatically included in the replication stream and if desired uses of sophisticated transformation abilities. Fast initial data loading and the ability to synchronize data from any desired timestamp.
Repstance supports Multi-Master replication in all forms of topology with ability the to ignore data produced by itself (loopback control), thus providing "True" Bi/Multi-Directional replication, therefore ensuring all instances are equal and continuously synchronized, any changes made in one node will be propagated (replicated) into the other nodes.
Flexible third-party product integration (APIs, CLI, custom integration). Ability to easily configure and monitor replication process using either Web UI or CLI tool.
The Repstance Service is delivered via a “Virtual Machine Image”, which is Linux based instance with preconfigured Repstance software. It is available in the both AWS and Azure marketplaces. Repstance Server can also be deployed out off the cloud infrastructure. Please reach out Repstance support at firstname.lastname@example.org for the details.
Repstance has to have access to both Source and Target Databases, in addition it needs a set of minimal Database Objects to function. This functionality is added during the “Prepare Database” stage (see chapter 7.1 Prepare Source and Target Databases or 8.2.1 Database Configuration in case of using Web UI).
Repstance uses the running Daemon process to “Multi-task” – that is to say, by using “threads” within the Daemon it is capable of running Multiple Capture and Apply Processes concurrently.
Both of the Processes, while they depend on each other to supply or insert the necessary data they, nonetheless, run as independent threads.
The Capture Process is the means by which the data to be transferred is extracted from the Source Database. It puts this information into locally stored Trail Files, which the Apply Processes can use. The data from a single Capture Process can therefore be used by many Apply Processes and, as a result, this data can therefore be propagated into multiple Target Databases.
The data extracted by the Capture Process is written to these Trail Files in the same sequential order as the transactions occurred in the Source Database, which in turn allows the Apply Process to insert this data into the Target Database in the same order they were executed in the Source Database. This means that both Source and Target Databases will be synchronized, that is to say, in a “Consistent State”.
The Capture Process does not need to have a running or configured Apply Process as it will quite simply continue extracting data using the criteria supplied, conversely the Apply Process only needs valid Trail Files from a Capture Process to consume.
Both Capture and Apply Processes insert Checkpoints in the form of LSN/SCN – this in turn means that there is the possibility for Repstance to be restarted from any specified point in the circumstances where any unexpected event occurs that may lead to data loss. This provides a robust form of data security and ensures that the data is, again, always “Consistent”.
The diagram below demonstrates the flow of data from Source to Target Databases.