Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.2.1 |  CUBRID 8.3.0 |  CUBRID 8.3.1 | 

Direction for Replication

  • In most cases, changes in the master database are reflected on the slave database in real time. However, replication can be delayed due to long transactions which update a large amount of data at a time.
  • It is recommended, if possible, not to delete at least 5 - 10 transaction archive logs so that changed data can be read when replication is delayed.
  • If you replace a new slave database by using the repl_make_slavedb utility, you must delete log files such as the replication log and trail logs that were used for the previous replication configuration before you run the replication agent.
  • TIMESTAMP does not mean the time when replication is applied to the slave database, but is replicated with the same value as one of the master database.
  • If the master database stops due to a failure, the replication server and the replication agent replicates data changed prior to the failure to the slave system without stopping. However, if the slave database stops due to a failure, the replication agent also stops operation. Therefore, the replication agent will start manually after the slave database server restarts.
  • Be careful not to damage the replication log created during the replication, the first replication archive log and trail logs. If you don't specify the -ar option when you run the replication agent, it creates only the first replication archive log <master_db_name>.copy.ar0 without creating more. Replication archive logs are files that store transaction logs already reflected; they do not need to be kept because the replication agent does not use them any more. However, you must not to delete the first replication archive log because it will be needed for recovery in case of failure.
  • It is recommended not to modify data items in the distribution database connected manually.