Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.4.3 |  CUBRID 9.0.0 | 

Detection of Replication Mismatch

Replication mismatch between replication nodes, indicating that data of the master node and the slave node is not identical, can be detected to some degree by the following process. However, please note that there is no more accurate way to detect a replication mismatch than by directly comparing the data of the master node to the data of the slave node. If it is determined that there has been a replication mismatch, you should rebuild the database of the master node to the slave node (see Rebuilding Replications.)

  • On the slave node, execute cubrid applyinfo to check the "Fail count" value. If the "Fail count" is 0, it can be determined that no transaction has failed in replication (see cubrid applyinfo.)
  • [nodeB]$ cubrid applyinfo -L /home/cubrid/DB/testdb_nodeA -r nodeA -a testdb

     

     *** Applied Info. ***

    Committed page                 : 1913 | 2904

    Insert count                   : 645

    Update count                   : 0

    Delete count                   : 0

    Schema count                   : 60

    Commit count                   : 15

    Fail count                     : 0

    ...

  • To check whether copying replication logs has been delayed or not on the slave node, execute cubrid applyinfo and compare the "Append LSA" value of "Copied Active Info." to the "Append LSA" value of "Active Info.". If there is a big difference between the two values, it means that delay has occurred while copying the replication logs to the slave node (see cubrid applyinfo.)
  • [nodeB]$ cubrid applyinfo -L /home/cubrid/DB/testdb_nodeA -r nodeA -a testdb

     

    ...

     

     *** Copied Active Info. ***

    DB name                        : testdb

    DB creation time               : 11:28:00.000 AM 12/17/2010  (1292552880)

    EOF LSA                        : 1913 | 2976

    Append LSA                     : 1913 | 2976

    HA server state                : active

     

     ***  Active Info. ***

    DB name                        : testdb

    DB creation time               : 11:28:00.000 AM 12/17/2010  (1292552880)

    EOF LSA                        : 1913 | 2976

    Append LSA                     : 1913 | 2976

    HA server state                : active

  • If a delay seems to occur when copying the replication logs, check whether the network line speed is slow, whether there is sufficient free disk space, disk I/O is normal, etc.
  • To check the delay in applying the replication log in the slave node, execute cubrid applyinfo and compare the "Committed page" value of "Applied Info." to the "EOF LSA" value of "Copied Active Info.". If there is a big difference between the two values, it means that a delay has occurred while applying the replication logs to the slave database (see cubrid applyinfo.)
  • [nodeB]$ cubrid applyinfo -L /home/cubrid/DB/testdb_nodeA -r nodeA -a testdb

     

     *** Applied Info. ***

    Committed page                 : 1913 | 2904

    Insert count                   : 645

    Update count                   : 0

    Delete count                   : 0

    Schema count                   : 60

    Commit count                   : 15

    Fail count                     : 0

     

     *** Copied Active Info. ***

    DB name                        : testdb

    DB creation time               : 11:28:00.000 AM 12/17/2010  (1292552880)

    EOF LSA                        : 1913 | 2976

    Append LSA                     : 1913 | 2976

    HA server state                : active

    ...

  • If the delay in applying the replication logs is too long, it may be due to a transaction with a long execution time. If the transaction is performed normally, a delay in applying the replication logs may normally occur. To determine whether it is normal or abnormal, continuously execute cubrid applyinfo and check whether applylogdb continuously applies replication logs to the slave node or not.
  • Check the error log message created by the copylogdb process and the applylogdb process (see the error message).
  • Compare the number of records on the master database table to that on the slave database table.