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

FusionCloud 6.3.1.1 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 System Troubleshooting

Database System Troubleshooting

Database system faults are caused by the exceptions of the database HA function. You can restore this function so that it can trigger database self-recovery.

The Slave Database Fails to Switch to Master

Problem Description

The master database is faulty and cannot respond to service requests, but the slave database cannot switch to master.

Possible Causes

Particular faults have occurred on the master database node, causing the slave database failing to switch to master. For example, the floating IP address cannot be unbound from the master database. As a result, it cannot be assigned to the slave database so that the slave database fails to switch to master.

Troubleshooting Method

Forcibly restart the VM on which the master database is deployed to release the floating IP address.

Procedure
  1. Run the following command to log in to a FusionSphere OpenStack controller node:

    ssh Username@IP address of a FusionSphere OpenStack controller node

    The default username is fsp and the default password is cnp200@HW.

  2. Run the following command and enter the password of user root as prompted to switch to user root (the default password is Cloud12#$):

    sudo su - root

  3. Import environment variables.
  4. Run the following command to query the UUID of the VM on which the master database is deployed:

    nova list --all-|grep 'IP address of the VM on which the master database is deployed'

    Figure 24-4 VM UUID

    The string in the red box is the VM UUID.

  5. Run the following command to forcibly restart the master database VM:

    nova reboot VM UUID –hard

    Replace the italic part with the actual VM UUID obtained in 4.

  6. Wait for 3 to 5 minutes, and log in to the slave database. Run the following commands to check whether the slave database is switched to master:

    source /etc/profile

    service gaussdb query

    Figure 24-5 Database status
    • If the command output is similar to the preceding figure, the slave database is successfully switched to master.
    • If the command output is different from the preceding figure, contact technical support to rectify the fault.

The Slave Database Cannot Be Started

Symptom

The slave database is faulty and cannot automatically restore.

Possible Causes

In normal cases, when the slave database is abnormal, it automatically synchronizes data from the master node for restoration. However, if the fault persists after two restorations due to network problems, the slave database node needs to be manually restored.

Troubleshooting Method

Manually synchronize data from the master database to the slave database.

Procedure
  1. Log in to the PUB-DB01 node using PuTTY.

    The default account is gaussdb. The default password is Huawei@123.

  2. Run the following command and enter the password of user root as prompted to switch to user root (the default password is Cloud12#$):

    sudo su - root

  3. Run the following command to view the database status and check whether the currently logged-in node is the slave one:

    service had query

    Information similar to that shown in Figure 24-6 is displayed, the node whose ROLE is active is the master database node. Otherwise, the node is the slave one.

    Figure 24-6 Database status

  4. Check whether the currently logged-in node is the slave database node based on the command output in 3.

    • If yes, go to 5.
    • If no, repeat 1 to 2 to log in to the PUB-DB02 node and go to 5.

  5. Run the following command to switch to user dbadmin:

    su dbadmin

  6. Run the following command to synchronize data from the master database:

    gs_ctl build

    Figure 24-7 Synchronizing data from the master database
    • If the command output is similar to the preceding figure, the slave database is successfully restored.
    • If the command output is different from the preceding figure, contact technical support to rectify the fault.

Translation
Download
Updated: 2019-06-10

Document ID: EDOC1100063248

Views: 22580

Downloads: 37

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