No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


FusionCloud Troubleshooting Guide 02

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Checking the Database Instance Replication Status Is Alarm

Checking the Database Instance Replication Status Is Alarm


The node where the master database instance is located is normal, but the replication status of the node where the slave database instance is located is alarm.

Possible Causes

  • Network delay occurs.
  • The write operation workload on the master database is heavy.
  • The Transactions Per Second (TPS) is high or big transactions exceed the replication processing capability of the slave database.
  • The hardware configuration of the slave database server is low.

Troubleshooting Method

  1. Log in to the database node as user paas.
  2. Run the following commands to check the database replication status:

    cd /opt/paas/oss/manager/apps/DBAgent/bin

    sh dbsvc_adm -cmd query-db-instance | egrep "DBInstanceId|mysql.*Slave"

    For example:
    DBInstanceId                                             ClassId  Service Name                           Tenant  AzName         IP              Port   State  DBType  Version  Role    Rpl Status      MasterID                               GuardMode  DataCheckSum
    apmdbsvr-10_120_183_169-16@10_120_183_137-16             primary  apmdbsvr-10_120_183_137-16             manage  cn-global-1-a  32080  Up     mysql   5.6.38   Slave   Normal          apmdbsvr-10_120_183_169-16             --         199044602
    apmdbsvr-10_120_183_41-1@10_120_183_214-1                primary  apmdbsvr-10_120_183_214-1              om      az2    32081  Up     mysql   --       Slave   Delay(201)  --                                     --         --
    • The command output varies depending on the version of DataMgmtService. Pay attention only to the value of Rpl Status.

      If the value of Rpl Status is Normal, the database replication status is normal.

      If the value of Rpl Status is Delay(201), the database replication status is chasing, that is, the slave database is synchronizing data from the master database.

    • In this example, the replication status of the database instance apmdbsvr-10_120_183_41-1@10_120_183_214-1 is chasing.

  3. For the replication status error codes and troubleshooting methods, see Table 23-4.

    Table 23-4 Replication status error description and solution

    Error Code


    Possible Cause

    Troubleshooting Method


    The MySQL slave database instance synchronizes global transaction identifiers (GTIDs) from the master database instance with a delay.

    1. Heavy write operations in the database in a short period cause replication delay.
    2. 1000 or more GTIDs in the master database instance are not synchronized to the slave database instance.
    1. Check whether the alarm is cleared after a few minutes. If the alarm persists, contact the DBA for troubleshooting.
    2. Check whether a synchronization delay occurs. Check the GTID difference between master and slave databases.

Updated: 2019-06-10

Document ID: EDOC1100063248

Views: 22837

Downloads: 37

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Previous Next