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

Reminder

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

upgrade

HUAWEI CLOUD Stack 6.5.0 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).
Database Startup Failure Caused by Database File Damage

Database Startup Failure Caused by Database File Damage

Symptom

The slave database instance fails to be started, the error code is 101, and the master database instance is running properly.

Possible Causes

Files in the slave database instance are damaged.

Solution

The processing method for the Gauss database is as follows:

  1. Use PuTTY to log in to the node where the abnormal slave instance is located.

    Default account: paas; default password: QAZ2wsx@123!

  2. Run the following commands to query information about the abnormal slave instance:

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

    ./dbsvc_adm -cmd query-db-instance -type gauss

    DBInstanceId                                      ClassId  InstNumber                       Tenant      IP             Port   State  DBType  Version            Role    Rpl Status  MasterID                         GuardMode  DataCheckSum  isSSL 
    AutoTestServer-10_247_197_58-22@10_247_197_61-22  primary  AutoTestServer-10_247_197_58-22  fst-manage  10.247.197.58  32086  Up     gauss   V100R003C20SPC113  Master  Normal      --                               --         954399251     off 
    AutoTestServer-10_247_197_58-22@10_247_197_61-22  primary  AutoTestServer-10_247_197_61-22  fst-manage  10.247.197.61  32086  Up     gauss   V100R003C20SPC113  Slave   Abnormal      AutoTestServer-10_247_197_58-22  --         954399251     off

  3. Run the following command and enter the password of the root user to switch to the root user:

    su - root

    Default password: QAZ2wsx@123!

  4. Run the following command to switch to the dbuser user:

    su dbuser

  5. Run the following command to go to the log directory of the abnormal slave database instance:

    cd /opt/gauss/data/AutoTestServer-10_247_197_61-22/pg_log/

    AutoTestServer-10_247_197_61-22 indicates the name of the abnormal slave instance, that is, the value of the slave instance in the InstNumber column queried in 2.

  6. Run the following command to check the database files:

    ll

    total 3124 
    -rw------- 1 dbuser dbgroup 3171347 May  6 15:03 gaussdb-2019-05-06_111401.log
    -rw------- 1 dbuser dbgroup    8282 May  6 11:17 gs_ctl-current.log 
    -rw------- 1 dbuser dbgroup    2286 May  6 11:14 gs_guc-current.log 
    -rw------- 1 dbuser dbgroup       8 May  6 11:17 syslog_label

  7. Run the following commands to check whether the database logs contain illegible characters:

    vi gs_ctl-current.log

    vi gaussdb-2019-05-06_111401.log

    • If illegible characters exist, perform the subsequent operations.
    • If no, contact technical support for assistance.

  8. Run the following command to import environment variables:

    . ~/appgsdb.bashrc

  9. Run the following command to restore the slave instance:

    /opt/gauss/app/bin/gs_ctl -D /opt/gauss/data/AutoTestServer-10_247_197_61-22 build

  10. Check whether the slave instance is running properly based on 1 to 2.

    • If yes, the fault has been rectified.
    • If no, contact technical support for assistance.

The processing method for the Redis database is as follows:

  1. Use PuTTY to log in to the node where the abnormal slave instance is located.

    Default account: paas; default password: QAZ2wsx@123!

  2. Run the following commands to query information about the abnormal slave instance:

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

    ./dbsvc_adm -cmd query-db-instance -type redis

    DBInstanceId                                      ClassId  InstNumber                       Tenant      IP             Port   State  DBType  Version            Role    Rpl Status  MasterID                         GuardMode  DataCheckSum  isSSL 
     
    atsrdb-10_247_197_58-16@10_247_197_61-16          primary  atsrdb-10_247_197_58-16          fst-manage  10.247.197.58  26520  Up     redis   4.0.11             Master  Normal      --                               --         --            off 
    atsrdb-10_247_197_58-16@10_247_197_61-16          primary  atsrdb-10_247_197_61-16          fst-manage  10.247.197.61  26520  Up     redis   4.0.11             Slave   Abnormal      atsrdb-10_247_197_58-16          --         --            off

  3. Run the following command and enter the password of the root user to switch to the root user:

    su - root

    Default password: QAZ2wsx@123!

  4. Run the following command to switch to the dbuser user:

    su dbuser

  5. Run the following command to go to the log directory of the abnormal slave database instance:

    cd /opt/redis/data/atsrdb-10_247_197_61-16/

    atsrdb-10_247_197_61-16 indicates the name of the abnormal slave instance, that is, the value of the slave instance in the InstNumber column queried in 2.

  6. Run the following command to check the database files:

    ll

    total 1936 
    -rw------- 1 dbuser dbgroup    2295 May  6 06:14 atsrdb-10_247_197_61-16.log 
    -rw-r----- 1 dbuser dbgroup 1920084 May  6 15:51 atsrdb-10_247_197_61-16-login.log 
    -rw------- 1 dbuser dbgroup       6 May  6 06:14 atsrdb-10_247_197_61-16.pid 
    -rw------- 1 dbuser dbgroup     176 May  6 06:14 atsrdb-10_247_197_61-16.rdb 
    -rw------- 1 dbuser dbgroup   31313 May  6 06:14 redis_commom.conf 
    -rw------- 1 dbuser dbgroup     847 May  6 06:14 redis.conf 
    -rw------- 1 dbuser dbgroup       1 May  6 06:14 redis_paramgroup.conf

  7. Use the vi editor to check whether the database startup logs contain illegible characters.

    vi atsrdb-10_247_197_61-16.log

    • If illegible characters exist, perform the subsequent operations.
    • If no, contact technical support for assistance.

  8. Use the vi editor to check whether illegible characters exist in the redis.conf, redis_commom.conf, and redis_paramgroup.conf configuration files.

    vi redis.conf

    maxmemory 1024mb 
    include /opt/redis/data/atsrdb-10_247_197_61-16/redis_paramgroup.conf 
    ^@^@^@^@^@^@
    • If there are illegible characters, delete the illegible characters and check whether the configuration files are different from those of the master instance.
      • If yes, contact technical support for assistance.
      • If no, save the configuration files. After 3 minutes, perform 9.
    • If no illegible character exists, contact technical support for assistance.

  9. Check whether the slave instance is running properly based on 1 to 2.

    • If yes, the fault has been rectified.
    • If no, contact technical support for assistance.

Translation
Download
Updated: 2019-06-01

Document ID: EDOC1100062375

Views: 2023

Downloads: 12

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