Raima defines a database mirror as a byte-for-byte image of an original (primary) database. Hence, mirroring creates one or more additional copies of an RDM database. And rather than just copying files, the process involves copying transaction logs so that mirror copies are updated incrementally and synchronously.
The RDM runtime library processes transactions by putting modified sections of the database into a transaction log file. Each transaction is identified by number and in due time the transaction will be safely transferred from the log file to the database itself. Ordinarily, the log files will be deleted after all the transactions they contain are written to the database. When mirroring is active, the log files can be retained for a longer period of time. Then, upon request (from “subscribers”), individual transactions are copied to log files on one or more other computers, where they are written to the database files there, bringing those databases up to date with the original. The same process for performing safe updates of database files is used on both master and slave computers. Besides the pieces required for safe transfer of the log files, no additional software (meaning no additional complexity) is required. See the following figure.
Raima’s replication functionality provides a different angle on moving data, as compared to mirroring. Raima defines replication as an action-for-action movement of data, rather than byte-for-byte. Because of the replication of database actions, it is possible to aggregate data from multiple RDM master databases into a single database. It is also possible to represent the actions as commands to different types of database systems.
With action-for-action replication, changes in an RDM database are captured as a series of create, delete, and update operations. The runtime library creates this replication log when configured to do so. Each log contains the actions of one full transaction. The log is then transferred to the TFS which is in charge of administering all replication logs to replication clients. Replication clients receive the replication log files and convert them into the equivalent actions necessary for the local DBMS, which may be another Raima database (RDM Server or RDM), but more than likely is MySQL, SQL Server or Oracle. For the SQL DBMSs, the actions are converted into SQL.
Advanced Replication Options
Another difference between replication and mirroring is the ability to select which tables and columns (tables and columns) to replicate. A master database may have 20 tables, but a slave may only need 3 of the tables. And of those 3 tables, only half of the original columns are of interest. It is possible to specify which tables and which columns in a configuration file used by the runtime library. The replication logs are filled only with the data that is specified.
Replication logs may be configured, on a table-by-table basis, to contain pre-images, post-images, or no images. Each log entry also identifies by address the record being affected. Post-images are used for replication engines, which only care about the new values. Pre-images may be used by special purpose processors as they read the logs. If a search engine is being maintained, it will need to know the former value (to eliminate a search keyword) and add a new value. If no images are added to the replication log, then only identifiers of the records that have been modified are present. These may be used as notifications, where subscribers to the logs will be able to identify records that may need to be re-read by their process.