所选语种没有对应资源,请选择:

本站点使用Cookies,继续浏览表示您同意我们使用Cookies。Cookies和隐私政策>

提示

尊敬的用户,您的IE浏览器版本过低,为获取更好的浏览体验,请升级您的IE浏览器。

升级

FusionCloud 6.3.1 故障处理 06

评分并提供意见反馈 :
华为采用机器翻译与人工审校相结合的方式将此文档翻译成不同语言,希望能帮助您更容易理解此文档的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 华为对于翻译的准确性不承担任何责任,并建议您参考英文文档(已提供链接)。
RDS业务故障

RDS业务故障

对于业务场景常见故障,可以根据故障现象进一步分析产生原因,然后采取合理措施进行处理。

MySQL

MySQL参数修改后未生效
现象描述

用户在参数配置页面更改了默认的MySQL参数,但没有生效。

可能原因
  • 部分参数更新后需要重启,用户没有重启数据库。
  • 部分参数需要重新打开会话,用户没有关闭当前连接。
  • 参数修改不合理,导致MySQL故障。
  • 部分参数不能写进配置文件,会自动还原。
  • 实例故障。
定位思路

查看实例状态是否正常,充分了解要修改的参数配置特性,保证使用正确的值或方法进行修改,最后依据参数生效的需要,重启MySQL或重新打开会话。

处理步骤
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  1. 连接Gauss数据库,通过检索dbs_instance表,查找对应实例的状态。

    CORE=> Select name,status from dbs_instance where name='实例名';

    • 如果实例状态值为normal,则实例正常。
    • 如果实例状态值为abnormal,则实例故障,请先尝试修复实例。

  2. 检查重启数据库,或关闭当前连接重新打开一个会话。
  3. 查看MySQL官方网站,了解参数值的正确设置方法后重新配置。
  4. 以上步骤仍不能解决问题,请联系技术支持工程师协助解决。
RDS Console页面无法访问
现象描述

浏览器地址栏输入RDS Console地址,页面无法访问。

可能原因
  • Nginx服务器故障。
  • RDS Console服务异常。
定位思路

先确保Nginx服务器正常工作,再登录RDS Console所在虚拟机,确保RDS Console服务进程工作正常。

处理步骤
  1. 检查是否能ping通Nginx服务器。

    • 若无法ping通,说明Nginx服务器故障,请联系技术支持工程师协助解决。
    • 若ping通,继续执行步骤 2

  2. 使用PuTTY,登录newRDS-Console01节点和newRDS-Console02节点。

    默认帐号:dbs,默认密码:Changeme_123

  3. 执行以下命令,查看tomcat进程是否存在。

    ps -ef|grep tomcat

    回显类似如下信息,表示tomcat进程存在。
    dbs        1831      1  0 Jan16 ?        00:02:54 /opt/dbs/jre/bin/java -Djava.util.logging.config.file=/opt/dbs/tomcat/newrds-console/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/opt/dbs/tomcat/newrds-console/logs/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/dbs/tomcat/newrds-console/oom.log -Dorg.quartz.scheduler.skipUpdateCheck=true -Dorg.apache.catalina.connector.RECYCLE_FACADES=true -Dfile.encoding=UTF-8 -server -Xms2046m -Xmx2046m -Xmn1023m -XX:SurvivorRatio=10 -XX:MaxTenuringThreshold=15 -XX:NewRatio=2 -XX:+DisableExplicitGC -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true -classpath /opt/dbs/tomcat/newrds-console/bin/bootstrap.jar:/opt/dbs/tomcat/newrds-console/bin/tomcat-juli.jar -Dcatalina.base=/opt/dbs/tomcat/newrds-console -Dcatalina.home=/opt/dbs/tomcat/newrds-console -Djava.io.tmpdir=/opt/dbs/tomcat/newrds-console/temp org.apache.catalina.startup.Bootstrap start

  4. 执行以下命令重启tomcat进程。

    cd /opt/dbs/tomcat/newrds-console/bin/

    ./shutdown.sh

    ./startup.sh

    说明:

    如果./shutdown.sh无法停止tomcat,则执行如下命令。

    pid=$(ps -ef | grep tomcat | grep -v grep | awk '{print $2}')

    kill -9 $pid

  5. 执行以下命令启动进程。

    cd /opt/dbs/tomcat/newrds-console/bin/

    ./startup.sh

  6. 进程启动后,再次执行ps -ef | grep tomcat检查进程是否启动成功。
  7. 在newRDS-Console02节点上执行步骤 3步骤 6
实例列表不显示用户实例
现象描述

用户可以查看实例列表页面,但实例列表内不显示用户的实例。

可能原因

newRDS-Service的tomcat服务不正常。

定位思路

登录newRDS-Service所在虚拟机,确保tomcat服务进程正常工作。

处理步骤
  1. 使用PuTTY,登录newRDS-Service01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,查看tomcat进程是否存在。

    ps -ef|grep tomcat

    回显类似如下信息,表示tomcat进程存在。
    [dbs@dbs_mysqlmgnt2 mysql]$ ps -ef|grep tomcatdbs      120700      1  2 Sep21 ?        01:13:49 /opt/dbs/jre/bin/java -Djava.util.logging.config.file=/opt/dbs/tomcat/mysql-instancemanager/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/opt/dbs/tomcat/mysql-instancemanager/logs/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/dbs/tomcat/mysql-instancemanager/oom.log -Dorg.quartz.scheduler.skipUpdateCheck=true -Dfile.encoding=UTF-8 -server -Xms4094m -Xmx4094m -Xmn2047m -XX:SurvivorRatio=10 -XX:MaxTenuringThreshold=15 -XX:NewRatio=2 -XX:+DisableExplicitGC -classpath /opt/dbs/tomcat/mysql-instancemanager/bin/bootstrap.jar:/opt/dbs/tomcat/mysql-instancemanager/bin/tomcat-juli.jar -Dcatalina.base=/opt/dbs/tomcat/mysql-instancemanager -Dcatalina.home=/opt/dbs/tomcat/mysql-instancemanager -Djava.io.tmpdir=/opt/dbs/tomcat/mysql-instancemanager/temp org.apache.catalina.startup.Bootstrap start

  3. 执行以下命令重启tomcat进程。

    cd /opt/dbs/tomcat/mysql-instancemanager/bin/

    ./shutdown.sh

    ./startup.sh

    说明:

    如果./shutdown.sh无法停止tomcat,则执行如下命令。

    pid=$(ps -ef | grep tomcat | grep -v grep | awk '{print $2}')

    kill -9 $pid

  4. 执行以下命令启动进程。

    cd /opt/dbs/tomcat/mysql-instancemanager/bin/

    ./startup.sh

  5. 执行ps -ef |grep tomcat查看tomcat进程是否存在。
  6. 在newRDS-Service02节点执行步骤 2步骤 5,检查服务状态。
执行删除命令无效
现象描述

界面提示删除命令下达成功,但1000s后实例仍没有删除。

可能原因
  • newRDSService服务不正常。
  • 删除前期检查失败。
  • 调用备份恢复、资源管理失败。
定位思路
  • 登录newRDSService所在虚拟机,确保newRDSService服务进程正常工作。
  • 登录数据库,定位错误原因(在哪个Task失败)。
  • 登录newRDSService所在虚拟机,查看日志,定位详细错误原因。
处理步骤
  1. 使用PuTTY,登录newRDS-Service01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,查看tomcat进程是否存在。

    ps -ef|grep tomcat

    回显类似如下信息,表示tomcat进程存在。
    [dbs@dbs_mysqlmgnt2 mysql]$ ps -ef|grep tomcatdbs      120700      1  2 Sep21 ?        01:13:49 /opt/dbs/jre/bin/java -Djava.util.logging.config.file=/opt/dbs/tomcat/mysql-instancemanager/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/opt/dbs/tomcat/mysql-instancemanager/logs/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/dbs/tomcat/mysql-instancemanager/oom.log -Dorg.quartz.scheduler.skipUpdateCheck=true -Dfile.encoding=UTF-8 -server -Xms4094m -Xmx4094m -Xmn2047m -XX:SurvivorRatio=10 -XX:MaxTenuringThreshold=15 -XX:NewRatio=2 -XX:+DisableExplicitGC -classpath /opt/dbs/tomcat/mysql-instancemanager/bin/bootstrap.jar:/opt/dbs/tomcat/mysql-instancemanager/bin/tomcat-juli.jar -Dcatalina.base=/opt/dbs/tomcat/mysql-instancemanager -Dcatalina.home=/opt/dbs/tomcat/mysql-instancemanager -Djava.io.tmpdir=/opt/dbs/tomcat/mysql-instancemanager/temp org.apache.catalina.startup.Bootstrap start

  3. 执行以下命令重启tomcat进程。

    cd /opt/dbs/tomcat/mysql-instancemanager/bin/

    ./shutdown.sh

    ./startup.sh

    说明:

    如果./shutdown.sh无法停止tomcat,则执行如下命令。

    pid=$(ps -ef | grep tomcat | grep -v grep | awk '{print $2}')

    kill -9 $pid

  4. 执行以下命令启动进程。

    cd /opt/dbs/tomcat/mysql-instancemanager/bin/

    ./startup.sh

  5. 执行ps -ef |grep tomcat查看tomcat进程是否存在。
  6. 在newRDS-Service02节点执行步骤 2步骤 5,检查服务状态。
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  1. 查看任务执行状态。

    • 查询dbs_action表,查看任务执行情况,#####处用实例id代替。
      CORE=> select * from dbs_action where instanceId = '###########';
      • 如果status字段为'OK_TO_RUN',表示还在执行删除。
      • 如果status字段为'DELETED',表示任务已经结束,可能失败。
    • 查询dbs_metering_usagerecord表,查看计费停止信息是否正常录入。
      CORE=> select * from dbs_metering_usagerecord where instance_id = '###########' and module ~ 'DelInst' order by created_at desc;
      • 如果计费信息不正常,说明删除前期检查失败,没有下发删除任务,此时需要按步骤 12检查日志。
      • 如果计费信息正常,运维人员可以登录资源租户账号,手动删除用户的虚拟机、备份、网络等信息。
    • 查询dbs_alarm和dbs_alarm_log表,查看是否有告警信息。
      • alarm_name表明失败的任务类型(例如删除任务失败,变更规格任务失败);
      • cause字段详细说明了失败的Task名称和发生原因;
      • location_info字段详细记录了错误信息。
      CORE=> select * from dbs_alarm where location_info ~ '###########';
      CORE=> select * from dbs_alarm_log where location_info ~ '###########';

    常见的错误包括执行删除备份和策略任务失败,调用资源管理失败,等待资源管理删除实例失败等,需要进一步定位信息,执行步骤 12

  2. 登录newRDSService虚拟机,查看实例管理日志。

    • 查看info日志,首先跟踪实例id,然后根据下发删除的时间,在日志中取得workflowId,随后跟踪workflowId即可,在日志中可以回溯该任务的执行流程。
    • 查看error日志,获取到实例id和workflowId以后,可以快速定位到错误原因。如果要更进一步了解错误详情,需要登录备份恢复服务或是资源管理服务所在机器查看日志。

HA实例无法主备倒换
现象描述

主机故障,但是备机没有自动切换成主机。

可能原因

备机故障,主节点I/O过于频繁,备节点I/O慢等。

定位思路

备机查看show slave status\G的Seconds_Behind_Master是否为比较小的值,比如120以内,或者Last_IO_Error、Last_SQL_Error是否有错误信息。

处理步骤
  1. 查看备机状态,如果备机故障,会无法倒换。例如备机已经宕机、备机的数据库进程已经终止。
  2. 登录备机节点,检查备机系统环境,如磁盘空间是否足够,内存使用情况。
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  1. 以实例ID为查询条件,通过表dbs_instance_ha获取字段ha_monitor_id的值。再以ha_monitor_id为查询条件,在表dbs_ha_monitor中查询监控该实例的HAMonitor所在的服务节点IP,查询sql如下:

    select c.ip from core.dbs_ha_monitor c where c.id = (select a.ha_monitor_id from core.dbs_instance_ha a where a.instance_id = '实例ID')

    检查ha-monitor服务是否正常运行,是否能ping通实例。

  2. 检查agent进程是否被其他进程反复停止,可以通过agent的日志查看。

    less /home/Ruby/log/agent.log

  3. 检查agent目录是否有被删除或更改过。建议删除目录前先停掉HA相关进程或删除后要重启一次进程才可以。
  4. 登录备机数据库查看show slave status\G的Seconds_Behind_Master是否为比较小的值,比如120以内,或者Last_IO_Error、Last_SQL_Error是否有错误信息。根据错误信息处理。
  5. 如上述操作无法解决,请联系技术支持工程师协助解决。
备注

HA实例主备倒换通常在一分钟之内完成,无需手动干预,但倒换时间会受到是否有大量主备未同步数据的影响。

在大压力数据写入的场景下,主机数据未完全同步备机时,主机故障时不会立刻触发主备倒换,此时业务恢复时间可能较长,需要等待主备机之间数据同步。可以连接备机数据库,执行“show slave status”查看业务恢复时间过长是否由主备数据未同步造成。

HA恢复主备关系失败
现象描述

HAMonitor没有正常恢复实例,实例依然可用,但是主备关系不正确,不能进行数据同步。

可能原因

主备HAagent进程异常,异常实例无法升主。

定位思路

查看实例上HAagent进程,根据日志进行排查。

解决方法
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  1. 以实例ID为查询条件,通过表dbs_instance_ha获取字段ha_monitor_id的值。再以ha_monitor_id为查询条件,在表dbs_ha_monitor中查询监控该实例的HAMonitor所在的服务节点IP,查询sql如下:

    select c.ip from core.dbs_ha_monitor c where c.id = (select a.ha_monitor_id from core.dbs_instance_ha a where a.instance_id = '实例ID')

    检查ha-monitor服务是否正常运行,是否能ping通实例。

  2. 通过步骤 5查询出来的ip,登录ha-monitor服务节点,跳转到ha-monitor日志路径下。通过OC平台上该告警的发生时间和实例ID检索实例故障日志信息。
  3. 分别登录主备机数据库查看show slave status\G的信息,Last_IO_Error、Last_SQL_Error是否有错误信息。记录错误信息。
  4. 请联系技术支持工程师协助解决。
无法进行PITR按时间点恢复
现象描述

实例已经设置自动备份策略,在页面恢复按钮为灰色。

可能原因
  • mysql-backupmanager服务无法SSH到实例
  • 实例无法连接OBS
  • 上传备份文件到OBS桶失败
  • 实例备份失败,无可恢复的备份文件
  • 数据量大、业务繁忙导致响应很慢
定位思路

先确保mysql-backupmanager服务可以ssh连接到实例,实例到OBS网络通信正常,然后分别登录mysql-backupmanager服务和实例查看相关日志,依据日志提示具体分析故障原因。

处理步骤
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  1. 通过检索CORE.DBS_INSTANCE表等,查找对应实例IP的信息。

    SELECT I.ID,N.ID,G.NAME,N.ROLE,C.IP,C.INTERNAL_VXLAN_IP

    FROM CORE.DBS_NODE N

    inner join CORE.DBS_PARENTSHIP P on P.ENTITY_ID = N.ID

    inner join CORE.DBS_INSTANCE I on I.ID = SPLIT_PART(P.PATH_FROM_ROOT, '/', 1)

    inner join CORE.DBS_GROUP G on G.ID = SPLIT_PART(P.PATH_FROM_ROOT, '/', 2)

    inner join CORE.DBS_RELATIONSHIP R on R.SOURCE_ENTITY_ID = N.ID

    inner join CORE.DBS_RELATIONSHIP_TYPE T on T.ID = R.TYPE_ID

    inner join CORE.DBS_NIC C on C.ID = R.TARGET_ENTITY_ID

    WHERE I.NAME = '实例名';

  2. 检查mysql-backupmanager服务是否能ping通实例。

    在mysql-backupmanager服务上ping查询到的manageIp。
    • 若无法ping通,说明mysql-backupmanager服务到实例网络不通,请先排查网络故障。
    • 若ping通,继续执行步骤 7

  3. 通过连接实例工具登录到实例,检查从实例到OBS是否能ping通。

    • 若无法ping通,说明实例到OBS网络不通,请先排查网络故障。
    • 若ping通,继续执行下一步。

  4. 查看gaussdb数据库,查看备份文件状态。

    1. 根据实例名称查找备份。
      SELECT ID, CREATED_AT, NAME, STATUS FROM CORE.DBS_BACKUP_INFO_DETAILS WHERE INSTANCE_NAME = '实例名';

      若备份文件状态(status)为Failed,请执行步骤 9

    2. 如果是多机部署,需要在多个backupmanager节点查找日志每个结果如下所示:
      图20-1 过滤结果

      查找最近的失败信息,然后筛选最近的日志信息,查看具体是在哪个步骤失败,处理解决相关问题。

  5. 备份动作主要有两个步骤,首先会对整个数据库进行备份,其次会将备份文件上传到OBS桶内。

    • 若日志提示上传文件到桶失败,请排查网络故障。
    • 若日志没有当前备份信息,不能通过日志定位问题原因,联系技术支持工程师协助解决。
      说明:

      如果实例业务繁忙或者并发大的情况下,自动备份任务可能会延迟自动执行或者备份较慢,请稍后再次查看日志。

复制快照失败
现象描述

页面下达复制快照命令成功,但快照管理页面新的快照文件失败。

可能原因
  • backupmanager服务无法连接到OBS。
  • OBS文件丢失。
定位思路
  • 确认网络通信是否正常。
  • 查看OBS桶原备份文件是否正常。
处理步骤
  1. 检查backupmanager服务是否能ping通OBS。

    • 若无法ping通,说明backupmanager服务到OBS网络不通,请先排查网络故障。
    • 若ping通,请继续执行以下步骤。

  2. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  3. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  4. 执行以下命令,切换至gausscore用户。

    su gausscore

  5. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  6. 连接到gaussdb数据库检查备份文件状态。

    select id,status from dbs_backup_info where name = '快照名'

    select file_name from dbs_backup_info_details where backup_id = '备份ID'

    说明:

    dbs_backup_info表的id是备份ID。

  7. 连接OBS桶查看备份文件是否存在。

    • 若不存在,请联系技术支持工程师协助解决。
    • 若存在,请再尝试一次复制。

快照还原实例失败
现象描述

用户在页面单击快照恢复后提示失败或还原失败。

可能原因
  • mysql-backupmanager无法SSH连接到实例。
  • 实例无法连接OBS。
  • 从OBS下载备份文件失败。
  • 实例恢复失败。
定位思路

查看实例状态是否正常。先确保mysql-backupmanager可以SSH到实例,实例到OBS网络通信正常,然后分别登录mysql-backupmanager和实例查看相关日志,依据日志提示信息具体分析故障原因。

处理步骤
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  1. 连接gaussdb数据库,通过检索core.dbs_instance表等联表查core.dbs_nic,查找对应实例的manageIp。

    SELECT I.ID,N.ID,G.NAME,N.ROLE,C.IP,C.INTERNAL_VXLAN_IP

    FROM CORE.DBS_NODE N

    inner join CORE.DBS_PARENTSHIP P on P.ENTITY_ID = N.ID

    inner join CORE.DBS_INSTANCE I on I.ID = SPLIT_PART(P.PATH_FROM_ROOT, '/', 1)

    inner join CORE.DBS_GROUP G on G.ID = SPLIT_PART(P.PATH_FROM_ROOT, '/', 2)

    inner join CORE.DBS_RELATIONSHIP R on R.SOURCE_ENTITY_ID = N.ID

    inner join CORE.DBS_RELATIONSHIP_TYPE T on T.ID = R.TYPE_ID

    inner join CORE.DBS_NIC C on C.ID = R.TARGET_ENTITY_ID

    WHERE I.NAME = '实例名';

  2. 检查mysql-backupmanager服务是否能ping通实例。

    在mysql-backupmanager服务上ping步骤 5中查询到manageIp。
    • 若无法ping通,说明mysql-backupmanager服务到实例网络不通,请先排查网络故障。
    • 若ping通,继续执行步骤 7

  3. 通过连接实例工具登录到实例,检查从实例到OBS是否能ping通。

    • 若无法ping通,说明实例到OBS网络不通,请先排查网络故障。
    • 若ping通,继续执行步骤 8

  4. 以core.dbs权限查看相应引擎的backupmanager后台日志。

    1. 连接到GaussDB,通过实例ID检索core.dbs_restore_schedule,查找到恢复失败的记录,找到对应的工作流ID(workflow_id)。
      select id from core.dbs_instance where name = '实例名' 
      select id,name,status,workflow_id from core.dbs_restore_schedule where instance_id = '实例名' order by created_at desc;
    2. 根据工作流ID查找备份该实例记录。

      登录mysql-backupmanager节点所在的Linux服务器,执行如下命令对backupmanager的后台日志按照实例名称进行过滤。

      cd ../../opt/core.dbs/tomcat/mysql-backupmanager/logs/backup-mysql/

      grep "工作流ID" backup-mysql.project.log*

      说明:
      • 实例ID为core.dbs_instance表的id。
      • 工作流ID为8.a中查出的workflow_id。
    3. 如果是多机部署,需要在多个backupmanager节点查找日志每个结果如下所示:
      图20-2 过滤结果

      若日志提示下载备份文件失败,请排查网络故障。

数据库端口变更失败
现象描述

用户数据库端口变更失败。

可能原因
  • newRDS-Service无法通过SSH连接到实例。
  • 用户提交的数据库端口被占用。
定位思路
  • 检查newRDS-Service是否可通过SSH连接到实例。
  • 检查用户提交的数据库端口是否被临时占用。
  • 登录newRDS-Service所在虚拟机,查看日志,定位详细错误原因。
处理步骤
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  1. 连接到gaussdb数据库,查找对应实例的manageIp。

    CORE=>SELECT INTERNAL_VXLAN_IP FROM DBS_NIC WHERE ID in(

    SELECT TARGET_ENTITY_ID FROM DBS_RELATIONSHIP

    INNER JOIN DBS_RELATIONSHIP_TYPE

    ON DBS_RELATIONSHIP.TYPE_ID = DBS_RELATIONSHIP_TYPE.ID

    AND DBS_RELATIONSHIP_TYPE.NAME = 'MANAGE_NIC_IS'

    AND DBS_RELATIONSHIP.SOURCE_ENTITY_ID = '节点ID');

  2. 检查RDSService是否能ping通实例。

    在RDSService上ping步骤 5中查询到manageIp。
    • 若无法ping通,说明RDSService到实例网络不通,请先排查网络故障。
    • 若可ping通,说明RDSService到实例网络可以联通,请执行步骤 7

  3. 使用该端口号,重新执行端口变更。

    • 若变更成功,说明所需变更端口被临时占用,导致变更失败。
    • 若仍然变更失败,请执行步骤 8

  4. 登录RDSService虚拟机,查看实例管理日志。

    • 连接gaussdb数据库,根据实例名检索dbs_instance表,查找instance id

      CORE=>SELECT ID FROM DBS_INSTANCE WHERE NAME = '实例名';

    • 查看info日志,首先根据实例id,然后根据下发动作的时间,在日志中取得workflowId。
    • 查看error日志,根据查找到实例id和workflowId快速定位到错误原因。
    • 请联系技术支持工程师协助解决。

数据库密码重置失败
现象描述

数据库密码重置失败。

可能原因
  • 密码校验不通过。
  • RDSService无法通过SSH连接到实例。
  • 密码重置发生在备份之后,执行恢复的时候,恢复成旧密码。
  • 主机密码重置成功,但新密码还未同步到备机,这时发生主备倒换,密码被设置为旧密码。
定位思路
  • 检查密码是否符合规范。
  • 检查RDSService是否可通过SSH连接到实例。
  • 密码重置之后是否执行了恢复操作。
  • 密码重置过程中是否发生了主备倒换。
处理步骤
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  5. 连接到gaussdb数据库,查找对应实例的manageIp。

    CORE=>SELECT INTERNAL_VXLAN_IP FROM DBS_NIC WHERE ID in(

    SELECT TARGET_ENTITY_ID FROM DBS_RELATIONSHIP

    INNER JOIN DBS_RELATIONSHIP_TYPE

    ON DBS_RELATIONSHIP.TYPE_ID = DBS_RELATIONSHIP_TYPE.ID

    AND DBS_RELATIONSHIP_TYPE.NAME = 'MANAGE_NIC_IS'

    AND DBS_RELATIONSHIP.SOURCE_ENTITY_ID = '节点ID');

  1. 检查RDSService是否能ping通实例。

    在RDSService上ping步骤 5中查询到manageIp。
    • 若无法ping通,说明RDSService到实例网络不通,请先排查网络故障。
    • 若可ping通,说明RDSService到实例网络可以联通,请执行步骤 7

  1. 在Console页面,重新执行“重置密码”。
数据库重启失败
现象描述

数据库重启失败。

可能原因
  • RDSService无法通过SSH连接到实例。
  • 实例处于故障状态,agent无法将数据库拉起。
定位思路
  • 检查RDSService是否可通过SSH连接到实例。
  • 登录节点,检查Mysql进程状态。
处理步骤
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  5. 连接到gaussdb数据库,查找对应实例的manageIp。

    CORE=>SELECT INTERNAL_VXLAN_IP FROM DBS_NIC WHERE ID in(

    SELECT TARGET_ENTITY_ID FROM DBS_RELATIONSHIP

    INNER JOIN DBS_RELATIONSHIP_TYPE

    ON DBS_RELATIONSHIP.TYPE_ID = DBS_RELATIONSHIP_TYPE.ID

    AND DBS_RELATIONSHIP_TYPE.NAME = 'MANAGE_NIC_IS'

    AND DBS_RELATIONSHIP.SOURCE_ENTITY_ID = '节点ID');

  1. 检查RDSService是否能ping通实例。

    在RDSService上ping步骤 5中查询到manageIp。
    • 若无法ping通,说明RDSService到实例网络不通,请先排查网络故障。
    • 若可ping通,说明RDSService到实例网络可以联通,请执行步骤 7

  1. 在Console页面,重新执行“重启”命令。

    若重启仍然失败,请联系技术支持工程师协助解决。

ERROR 1114 (The table 'test' is full)的处理方法
故障现象

无法向表中插入数据。

处理方法
  1. 执行以下命令,查看该表的元数据信息。

    mysql> select

    table_schema,table_name,table_type,engine,table_rows,concat(round(DATA_LENGTH/1024/1024,4),'M

    ') current_size from information_schema.tables where table_name='test';

    回显显示, 该表的存储引擎为MEMORY引擎,表的大小为16.0625MB。

  2. 执行以下命令,查看最大内存表的上限。

    mysql> show variables like 'max_heap_table_size';

    因为存储引擎为MEMORY的表的大小不能超过“max_heap_table_size”的参数值,所以会引发ERROR 1114 (The table 'test' is full )的错误。

    官网对“max_heap_table_size”参数解释为:“This variable sets the maximum size to which user-created MEMORY tables are permitted to grow. The value of the variable is used to calculate MEMORY table MAX_ROWS values. Setting this variable has no effect on any existing MEMORY table, unless the table is re-created with a statement such as CREATE TABLE or altered with ALTER TABLE or TRUNCATE TABLE. A server restart also sets the maximum size of existing MEMORY tables to the global max_heap_table_size value.”

    注意,对于已经存在的表,修改“max_heap_table_size”的参数值无效。所以,修改“max_heap_table_size”的参数值完成后还需执行后续操作。

  3. 执行以下命令,根据实际需要修改“max_heap_table_size”的参数值。以设置为64MB(即67108864)为例。

    mysql> set global max_heap_table_size='67108864';

    mysql> set global max_heap_table_size='67108864';
    Query OK, 0 rows affected (0.00 sec)
  4. 执行以下命令,查看“max_heap_table_size”的参数值是否已经修改完成。

    mysql> show variables like 'max_heap_table_size';

  5. 后续操作。
    • 方法一:
      1. 执行以下命令,创建临时表。

        mysql> use test

        mysql> use test
        Reading table information for completion of table and column names
        You can turn off this feature to get a quicker startup with –A
        
        mysql> create table test_temp like test;
        Query OK, 0 rows affected (0.01 sec)
      2. 执行以下命令,将原表数据插入临时表中。

        mysql> insert into test_temp select * from test;

        mysql> insert into test_temp select *  from test;
        Query OK, 63570 rows affected (0.18 sec)
        Records: 63570  Duplicates: 0  Warnings: 0
      3. 执行以下命令,调换表名称。

        mysql> alter table test rename to test_backup;

        mysql> alter table test rename to test_backup;
        Query OK, 0 rows affected (0.00 sec)
        mysql> alter table test_temp rename to test;
        Query OK, 0 rows affected (0.01 sec)
    • 方法二:执行以下命令,修改表引擎为innodb。

      alter table test engine innodb;

ERROR 1227 (mysqldump导入报错)的处理方法
故障现象

使用mysqldump将本地数据导出,再导入RDS MySQL时,导入过程中可能会遇到以下错误:

ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER privilege(s) for this operation

原因分析

出现该错误的原因为:MySQL导入用户的权限问题。

出于安全考虑,RDS MySQL的最高权限用户root没有super权限,当前自建用户也没有super权限。用户执行导入的sql语句中,包含需要super权限的语句后,导致报错。

如果源库开启了GTID特性,使用mysqldump导出数据时,由于没有添加选项“set-gtid-purged=OFF”,会导致导出的sql语句中存在以下需要super权限执行的语句。

SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED='18f9a804-343b-11e5-a21d-b083fed01601:1-2';
处理方法

方法一:

导出语句中添加选项“set-gtid-purged=OFF”后,重新导出sql文件,再导入sql文件即可。

mysqldump -uroot -p -h192.168.0.50 -P8635 --databases test --set-gtid-purged=OFF --master-data=2 --single-transaction --order-by-primary -r dump.sql

方法二:

使用source方式导入。使用这种方式时,即使权限问题报错,剩余sql语句仍可继续执行,不影响最终数据。

mysql>source /tmp/dump.sql

请注意确保sql文件的路径和权限正确。

MySQL中binglog导致磁盘空间已满,进而导致服务不可用、复制中断的处理方法
故障现象
  • MySQL主库可以登录,但是执行sql时进程挂起。

  • 备机的复制IO线程处在Connecting状态,落后主库718个日志。

故障排查
  • 计划进入日志目录查看错误日志,但是发现命令联想功能不可用,提示磁盘空间不足。

  • 验证是否由磁盘空间不足导致故障。如下图所示,磁盘空间已满。

故障原因

该测试环境中数据库目录大小只有100GB,压测的数据量较大,时间较长。产生的binlog过多,导致磁盘空间不足。未对主机磁盘进行监控,导致主库不可访问,备库复制IO线程异常。

处理方法
  1. 执行以下命令,查看备机状态。

    show slave status\G;

    回显说明,备机已经获取主机上标号在mysql-bin.004458及其之前的binlog。因此,可以在主机上清理mysql-bin.004458及其之前的binlog。

  2. 执行以下命令,删除部分日志并检查磁盘状况,使磁盘空间足以支持主库访问功能。

    rm -rf mysql-bin.003*

    df -h

  3. 登录数据库,执行以下命令查看数据库运行中的进程。

    show processlist;

    数据库已经可访问。

  4. 执行以下命令,删除mysql中清理无用的binlog。

    PURGE BINARY LOGS TO 'mysql-bin.004458';

  5. 登录备库,执行以下命令,查看数据复制状态,数据复制已经恢复,但是复制进程落后主库较多。
    show slave status\G;

注意事项
  • 该故障案例中测试环境中数据和日志目录就在同一个目录下。生产环境中数据库目录和日志目录建议分开。
  • 生产环境中请务必对mysql数据盘、日志盘和临时目标的剩余情况进行监控。超过阈值时,立即进行告警处理,避免此种低端错误导致服务不可用。
MySQL中join两表的连接列有索引的情况下,写操作被阻塞的原因和处理方法
模拟故障场景
  1. 分别执行以下命令,显示表结构。

    mysql> show create table t1\G

    mysql> show create table t2\G

  2. 分别执行以下命令,查看表数据。

    mysql> select * from t1;

    mysql> select * from t2;

  3. 执行以下命令,执行计划。

    mysql> explain select * from t2 join t1 on t1.c3 = t2.c3 where t2.c2 = 'guangdong'\G

    通过执行计划,t2.c2 ='guangdong'使用了索引,但是t1.c3 = t2.c3这个关联条件未使用t1.c3上的索引,所以导致需要对t1表进行全表扫描。

    由于执行计划最后出现了“warning”,尝试执行以下命令,查看“warning”详情。

    mysql> show warnings\G

    回显显示“convert(test.t1.c3 using utf8mb4)”,说明发生了字符集的转换。

    返回查看表的字符集发现:表t1字符集为“utf8”,表t2字符集为“utf8mb4”。字符集不同会导致t1全表扫描。

原因分析

根据执行计划分析如下:

MySQL中表和字段都可以单独设置字符集,如果字段未显示指定字符集,则默认为表的字符集。

表的字符集不一致,t2.c3字段是utf8mb4字符集,而t1.c3字段是utf8字符集,因此,需要进行字符集转换。t1.c3上面的索引仍然是utf8字符集,执行计划忽略了该索引,最终导致t1表只能选择全表扫描。t2表中符合where t2.c2= ‘guangdong’的值有几个,就会执行对t1表执行几次全表扫描,导致性能低下。

通过“warning”中的信息,可知t1.c3字段的字符集被mysql转换成了utf8mb4。在mysql中,字符集转换遵循由小到大的原则 ,utf8mb4是utf8的超集。

处理方法

处理方法为统一两张表join字段的字符集,将表t1的字符集整体转换为utf8mb4

说明:

alter table操作会阻塞写,所以请在业务低峰期进行操作。如果在生产环境操作,操作前建议先备份该表。大表的操作建议使用pt-online-schema-change在线修改字符集。

  1. 执行以下命令,转换表t1的字符集。

    mysql> alter table t1 convert to charset utf8mb4;

    Query OK, 9 rows affected (0.05 sec)
    Records: 9  Duplicates: 0  Warnings: 0
  2. 执行以下命令,执行计划。

    mysql> explain select * from t2 join t1 on t1.c3 =t2.c3 where t2.c2 = 'guangdong'\G

    回显显示,已经走了索引,故障已经解决。

MySQL中长查询所引发的连环阻塞的处理方法
故障现象
  • sql操作卡死,无任何结果返回。
  • mysql的物理备份无法完成。
原因分析

现象截图如下:

结果显示,id为111804586,执行时间为26114s的长查询阻塞了innobackupex备份的flush tables with read lock(FTWTL)操作。由于FTWTL操作需要关闭所表,但是id为111804586的长查询正在运行中,所以只能等待。这导致快照备份无法开始,并无法完成。

此时,FTWTL操作会给除了news_webpage外的所有表加上全局读锁,导致后来的所有dml操作都处于Waiting for global read lock的状态, 对表news_webpage的查询操作都处于Waiting for table flush的状态,所以sql无任何结果返回。

临时解决方法
  • 方案一:

    如果库中不存在用户自定义的MyISAM表,或者MyISAM表存在但表中数据量很小,可以执行以下命令终止故障样例中的长查询进程。

    kill 111804586;

  • 方案二:

    如果库中存在用户自定义的MyISAM表,但是表中数据库量较大,可以执行以下命令终止故障样例中的长查询和备份进程。

    kill 111804586;

    kill 111952866;

根本解决方法
  • 优化长查询进程,找出sql执行过长时间不结束的原因。尤其需要注意函数中是否存在死循环的逻辑错误。
  • 如果存在用户自定义的MyISAM表,建议转换为InnoDB表。
遇到大量“waiting for table level lock”如何处理?
故障现象

MyISAM表大量“waiting for table level lock”问题,使得链接数会被很快耗尽,数据查询超时,导致前端应用会报错。

可以通过以下命令查看session的状态。

show processlist

MyISAM引擎只支持表级锁,不支持行级锁。

对MyISAM表的读操作,不会阻塞其他session对同一张表的读请求,但会阻塞对同一表的写请求。对MyISAM表的写操作,则会阻塞其他用户对同一张表的读和写操作。MyISAM表的读操作与写操作之间,以及写操作之间为串行。当一个线程获得对一个表的写锁后,只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待,直到锁被释放为止。

处理方法

无论对MyISAM表进行读操作还是写操作,sql执行的时间越短,锁等待的时间就越少,因此处在“waiting for table level lock”的session就会越少。

因此解决该故障的过程实际上对sql优化的过程。处理步骤如下:

  1. 执行以下命令,确认表信息。

    mysql> select table_schema,table_name,table_type, engine from information_schema.tables where table_name='userinfo';

    回显显示,该表为MyISAM引擎表。

  2. 调整“key_buffer_size”的参数值。

    “key_buffer_size”参数用于控制MyISAM表索引缓存区大小。RDS中该参数的默认值为16MB,如果数据库中所有表都为MyISAM引擎,可以将“key_buffer_size”取值调整为服务器内存的1/4。这样数据库检索在内存中既可完成,大大提升效率。

  3. 优化sql语句。

    sql语句性能差,首先需要考虑索引问题。以下为索引缺失的案例,其他sql语句优化的措施不在这里展开描述。

    在该案例中,通过查看执行计划可知:检索一条数据需要扫描27万多行的数据(全表数据库小于30万行),token字段虽然有索引,但是选择性极差。

    mysql> explain

    -> SELECT * FROM 'userinfo' WHERE ( 'token' = 'rtbpjd1476262654' ) AND ( 'weid' = 'ohGDUjmosQl1JXWa7j91gpKUcgM' ) LIMIT 1;

  4. 执行以下命令,查看索引信息。

    mysql> show keys from userinfo;

    回显显示,weid列上没有索引。

  5. 执行以下命令,创建联合索引。

    create index idx_weid_token on userinfo(weid,token);

    说明:

    创建索引也会锁表,所以需要在业务低峰时段执行该操作。

  6. 执行以下命令,删除token字段上的索引。

    alter table userinfo drop index token;

  7. 执行以下命令,再次查看执行计划。

    mysql> explain

    -> SELECT * FROM 'userinfo' WHERE ( 'token' = 'rtbpjd1476262654' ) AND ( 'weid' = 'ohGDUjmosQl1JXWa7j91gpKUcgM' ) LIMIT 1;

    现在仅需扫描两行数据即可,执行时间从十几秒降低至几毫秒。

  8. 执行以下命令,查看session状态。

    mysql> show processlist;

  9. 按照所需查询字段完成相关字段的查询(请勿使用 select * 进行查询)。
  10. 由于InnoDB引擎支持事务和行级锁,并发能力更强。因此,不建议使用MyISAM引擎,如果为MyISAM表请修改为InnoDB表。执行以下命令,将MyISAM表修改为InnoDB表。

    mysql> alter table table_name engine innodb;

MySQL5.7 动态调整innodb_buffer_pool_size失败
故障现象

在MySQL5.7实例上调整“innodb_buffer_pool_size”参数值为5242880,故障报错为:ERROR 1231 (42000): Variable 'innodb_buffer_pool_size' can't be set to the value of '5242880'。故障截图如下:

故障原因

由于“innodb_buffer_pool_size”在小于1GB时,“innodb_buffer_pool_instances”取值会重置为1,以防止小实例个数过多导致性能问题。但是,由于“innodb_buffer_pool_instances”参数为只读参数,需要重启后修改,因此导致动态调整“innodb_buffer_pool_size”至5242880失败。

处理方法

修改“my.cnf”中的“innodb_buffer_pool_instances”参数并重启生效,即可修改成功。截图如下:

通常MySQL实例的内存大于等于2GB时,“innodb_buffer_pool_instances”取值默认为8,因此,一般不能动态调整“innodb_buffer_pool_size”至小于1GB。

“my.cnf”中“innodb_log_file_size”参数与实例当前值不一致导致xtrabackup备份失败。
故障现象

用户通过参数组修改配置文件中的“innodb_log_file_size”参数,导致配置文件中的该参数与实例当前值不匹配,引发实例备份失败。

故障现象截图如下:

故障原因

xtrabackup备份MySQL时,会检查“my.cnf”中的“innodb_log_file_size”参数与实例当前值是否一致。如果不一致,备份过程会失败并退出。

处理方法

修改配置文件中的“innodb_log_file_size”为实例当前值后,可以备份成功。

故障解决后备份成功截图如下:

PostgreSQL

PostgreSQL参数修改后未生效
现象描述

用户在参数配置页面更改了默认的PostgreSQL参数,但没有生效。

可能原因
  • 部分参数更新后需要重启,用户没有重启数据库。
  • 部分参数需要重新打开会话,用户没有关闭当前连接。
  • 参数修改不合理,导致PostgreSQL故障。
  • 部分参数不能写进配置文件,会自动还原。
  • 实例故障。
定位思路

查看实例状态是否正常后,充分了解要修改的参数配置特性,保证使用正确的值或方法进行修改,最后依据参数生效的需要,重启PostgreSQL或重新打开会话。

处理步骤
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  5. 连接Gauss数据库,通过检索dbs_instance表,查找对应实例的状态。

    CORE=>Select name,status from dbs_instance where name='实例名';

    • 如果实例状态值为normal,则实例正常。
    • 如果实例状态值为abnormal,则实例故障,请先尝试修复实例。

  6. 检查重启数据库,或关闭当前连接重新打开一个会话。
  7. 查看PostgreSQL官方网站,了解参数值的正确设置方法后重新配置。
  8. 以上步骤仍不能解决问题,请联系技术支持工程师协助解决。
OOM导致PostgreSQL进程被终止的处理方法
故障现象

PostgreSQL日志显示如下:

Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] Node 0 DMA free:15876kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:32kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] lowmem_reserve[]: 0 3360 15863 15863

操作系统日志显示如下:

Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.334044] kbox catch oom event.
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] Mem-Info:
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] Node 0 DMA per-cpu:
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    0: hi:    0, btch:   1 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    1: hi:    0, btch:   1 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    2: hi:    0, btch:   1 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    3: hi:    0, btch:   1 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    4: hi:    0, btch:   1 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    5: hi:    0, btch:   1 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    6: hi:    0, btch:   1 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    7: hi:    0, btch:   1 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] Node 0 DMA32 per-cpu:
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    0: hi:  186, btch:  31 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    1: hi:  186, btch:  31 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    2: hi:  186, btch:  31 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    3: hi:  186, btch:  31 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    4: hi:  186, btch:  31 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    5: hi:  186, btch:  31 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    6: hi:  186, btch:  31 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    7: hi:  186, btch:  31 usd:   0
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] Node 0 Normal per-cpu:
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    0: hi:  186, btch:  31 usd: 178
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    1: hi:  186, btch:  31 usd: 171
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    2: hi:  186, btch:  31 usd: 113
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    3: hi:  186, btch:  31 usd:  76
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    4: hi:  186, btch:  31 usd: 181
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    5: hi:  186, btch:  31 usd: 201
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    6: hi:  186, btch:  31 usd: 169
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] CPU    7: hi:  186, btch:  31 usd: 166
Feb 27 12:15:39 DBS_GaussBase2 kernel: [469644.335022] active_anon:1840295 inactive_anon:339373 isolated_anon:6304
 active_file:11393 inactive_file:39907 isolated_file:72
 unevictable:20763 dirty:44366 writeback:0 unstable:0
 free:158473 slab_reclaimable:61741 slab_unreclaimable:51077
 mapped:102894 shmem:349617 pagetables:1483725 bounce:0
 free_cma:0

 active_file:11393 inactive_file:39907 isolated_file:72
 unevictable:20763 dirty:44366 writeback:0 unstable:0
 free:158473 slab_reclaimable:61741 slab_unreclaimable:51077
 mapped:102894 shmem:349617 pagetables:1483725 bounce:0
 free_cma:0

处理方法
  • 数据库侧:
    • 根据业务最大并发连接数,调整“max_connections”参数取值。
    • 根据“max_connections”参数及服务器的内存设置合适的“shared_buffer”和“work_mem”参数。
  • 应用侧:优化业务减少对数据库的操作、优化SQL、减少对内存的使用。
ERROR: current transaction is aborted, commands ignored until end of transaction block的解决方法
故障现象

在PostgreSQL日志里可能看到以下错误:

< 2018-03-23 09:16:08.092 CST >ERROR:  current transaction is aborted, commands ignored until end of transaction block

在java日志里可能看到以下错误:

org.postgresql.util.PSQLException: ERROR: 
current transaction is aborted, commands ignored until end of transaction block
故障原因

一个事务中有一个SQL语句执行失败,系统捕获到这个异常并忽略了该异常。之后,在同一个连接中,用同一个事务运行了另一个额外的SQL语句。PostgreSQL会阻止这种情况发生。

处理方法
  1. 在应用端打开自动提交功能。
  2. 在捕获异常后,回滚事务再重启事务。
信号量不足导致PostgreSQL重启失败的解决方法
故障现象

数据库启动时报错:

[2018-01-31 17:07:56.726 CST] postmaster 104630 LOG: Starting checkDataDir (postmaster.c:1073)
[2018-01-31 17:07:56.726 CST] postmaster 104630 LOG: Starting ChangeToDataDir (postmaster.c:1079)
[2018-01-31 17:07:56.726 CST] postmaster  104630 LOG: Starting CheckDateTokenTables (postmaster.c:1125)
[2018-01-31 17:07:56.726 CST] postmaster  104630 LOG: Starting CreateDataDirLockFile (postmaster.c:1156)
[2018-01-31 17:07:56.728 CST] postmaster  104630 LOG: Starting pgaudit_agent_init (postmaster.c:1177)
[2018-01-31 17:07:56.728 CST] postmaster  104630 LOG: Starting process_shared_preload_libraries (postmaster.c:1186)
[2018-01-31 17:07:56.735 CST] postmaster  104630 LOG: could not create IPv6 socket: 协议不支持的地址族 (pqcomm.c:494)
[2018-01-31 17:07:56.736 CST] postmaster  104630 LOG: Create TCP/IP socket for Psql "*":5432 success (postmaster.c:1240)
[2018-01-31 17:07:56.736 CST] postmaster  104630 LOG: Starting reset_shared (postmaster.c:1393)
[2018-01-31 17:07:56.854 CST] postmaster  104630 FATAL: could not create semaphores: 设备上没有空间 (pg_sema.c:123)
[2018-01-31 17:07:56.854 CST] postmaster  104630 DETAIL: Failed system call was semget(5432129, 17, 03600).
[2018-01-31 17:07:56.854 CST] postmaster  104630 HINT: This error does *not* mean that you have run out of disk space. It occurs when either the system limit for the maximum number of semaphore sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded. You need to raise the respective kernel parameter. Alternatively, reduce PostgreSQL's consumption of semaphores by reducing its max_connections parameter.
The PostgreSQL documentation contains more information about configuring your system for PostgreSQL.
[2018-01-31 17:07:56.884 CST] postmaster  104630 LOG: StreamDoUnlink sockpath =/tmp/.s.PGSQL.5432 (pqcomm.c:342)
[2018-01-31 17:07:56.884 CST] postmaster  104630 LOG: UnlinkLockFile socket_lock_file =/tmp/.s.PGSQL.5432.lock (miscinit.c:1232)
..............
postmaster.pid file does not exist after 15 seconds
stopped waiting
could not start server
处理方法

该故障产生是因为信号量相关的内核参数没有配置或者配置较小,可以按照实际规格做以下设定:kernel.sem=250 256000 32 1024。再执行sysctl -p即可。

PostgreSQL在drop表之后,出现对应文件还存在的情况的处理方法
故障现象

PostgreSQL在drop表之后,对应文件还存在。故障现象截图如下:

WFS=# SELECT OID,RELNAME FROM PG_CLASS WHERE RELNAME='WFS_SESSION';
 
  OID  |   RELNAME   
 
-------+-------------
 
 16472 | WFS_SESSION
 
(1 row)
 
 
WFS=# drop table wfs.wfs_session;
 
DROP TABLE
 
WFS=# vacuum full;
 
VACUUM
 
 
 
[gaussbase@dbs_gauss1 16396]$ ls -la 16472
-rw------- 1 gaussbase dbgrp 0 Jan 25 10:26 16472

处理方法

在drop表之后,需要执行checkpoint才会删除文件。

WFS=# checkpoint;
CHECKPOINT
 
[gaussbase@dbs_gauss1 16396]$ ls -la 16472
ls: cannot access 16472: No such file or directory
PostgreSQL锁等待的排查流程
故障现象

在PostgreSQL中,有时会发生有些SQL语言执行时间过长无法结束的情况。

处理方法
  1. 故障发生后,请打开数据库日志到ALL Level,即打开所有日志记录。
    1. 以gaussdbcore或者gaussdbbase用户,进入到/opt/gaussdbcore/data或/opt/gaussdbbase/data目录。

      cd /opt/gaussdbcore/data

      或者

      cd /opt/gaussdbbase/data

    2. 执行以下命令,编辑“postgresql.conf”文件。

      vim postgresql.conf

    3. 记录“log_statement”参数取值,将该参数值修改为“all”。
    4. 执行以下命令保存。

      :wq!

    5. 执行以下命令,加载修改结果。

      gs_ctl reload

  2. 以数据库管理员用户登录数据库,执行以下SQL语句。

    SELECT blocked_locks.pid AS blocked_pid,

    blocked_activity.usename AS blocked_user,

    blocking_locks.pid AS blocking_pid,

    blocking_activity.usename AS blocking_user,

    blocked_activity.query AS blocked_statement,

    blocking_activity.query AS current_statement_in_blocking_process

    FROM pg_catalog.pg_locks blocked_locks

    JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid

    JOIN pg_catalog.pg_locks blocking_locks

    ON blocking_locks.locktype = blocked_locks.locktype

    AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE

    AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation

    AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page

    AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple

    AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid

    AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid

    AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid

    AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid

    AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid

    AND blocking_locks.pid != blocked_locks.pid

    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid

    WHERE NOT blocked_locks.GRANTED;

    查询结果类似如下:
    BLOCKED_PID | BLOCKED_USER | BLOCKING_PID | BLOCKING_USER | BLOCKED_STATEMENT | CURRENT_STATEMENT_IN_BLOCKING_PROCESS 
    -------------+--------------+--------------+---------------+------------------------------------------------------------+----------------------------------------------------------------------------------
    114211 | GAUSSDBA | 114217 | GAUSSDBA | SELECT * FROM DBS_ACTION WHERE INSTANCE_ID = $1 FOR UPDATE | SELECT * FROM DBS_ENDPOINT WHERE DBS_ENDPOINT.ID IN +
    | | | | | (SELECT DBS_RELATIONSHIP.TARGET_ENTITY_ID +
    | | | | | FROM DBS_RELATIONSHIP +
    | | | | | INNER JOIN DBS_RELATIONSHIP_TYPE +
    | | | | | ON DBS_RELATIONSHIP_TYPE.ID = DBS_RELATIONSHIP.TYPE_ID +
    | | | | | AND DBS_RELATIONSHIP_TYPE.NAME = 'BIND_ENDPOINT'+
    | | | | | AND DBS_RELATIONSHIP.SOURCE_ENTITY_ID = $1)

    回显说明,进程114217的事务阻塞了进程114211的事务。

  3. 查看“$PGDATA/pg_log”里的日志,查找所有进程号为114217并且执行的语句为commit或rollback对应的记录(本例中没有114217对应的rollback记录,所以只显示commit操作),如下所示。
    Line 249: Line 102774: [2017-12-20 22:01:57.164 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 253: Line 104921: [2017-12-20 22:02:08.481 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 258: Line 106572: [2017-12-20 22:02:17.171 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 302: Line 123074: [2017-12-20 22:03:47.215 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 311: Line 126123: [2017-12-20 22:03:57.164 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 318: Line 129293: [2017-12-20 22:04:17.162 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 333: Line 136107: [2017-12-20 22:04:47.170 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 334: Line 136213: [2017-12-20 22:04:47.177 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 340: Line 137580: [2017-12-20 22:04:57.173 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 344: Line 138829: [2017-12-20 22:05:07.162 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
  4. 根据3中的查询结果,查找Line 138829之后的所在进程为114217且对dbs_action进行update或delete操作的SQL语句。
    Line 138829: [2017-12-20 22:05:07.162 CST] postgres  114217 LOG: execute S_4: COMMIT (postgres.c:6326)
    Line 141308: [2017-12-20 22:05:16.888 CST] postgres  114217 LOG: execute <unnamed>: UPDATE DBS_ACTION SET status=$1, version = $2+1, updated_at = (now() at time zone 'utc') WHERE id = $3 AND version = $4 (postgres.c:6326)
    Line 141309: [2017-12-20 22:05:16.888 CST] postgres  114217 DETAIL: parameters: $1 = 'DELETED', $2 = '1', $3 = '50fa2cb5-1817-4050-8a92-f767cc8e1e50', $4 = '1'
    Line 141314: [2017-12-20 22:05:16.891 CST] postgres  114217 LOG: execute <unnamed>: UPDATE DBS_ACTION SET status=$1, version = $2+1, updated_at = (now() at time zone 'utc') WHERE id = $3 AND version = $4 (postgres.c:6326)
    Line 141315: [2017-12-20 22:05:16.891 CST] postgres  114217 DETAIL: parameters: $1 = 'DELETED', $2 = '0', $3 = 'd2ee9f6b-b8a1-442a-867e-15cde72154c3', $4 = '0'

    根据以上结果可以判断进程114217的Update dbs_action这个SQL语句没有提交或者回滚,导致进程114211被阻塞。根据这个结论可以对代码进行问题排查。

  5. 修改"postgresql.conf"中的“log_statement”值修改为1.c修改为"all"之前的取值。
  6. 执行以下命令保存。

    :wq!

  7. 执行以下命令,加载修改结果。

    gs_ctl reload

链接PostgreSQL异常的解决方法
故障现象
[gausscore@dbs_gauss1 pg_log]$ psql -p 8635 -q core -U core -W clouddb@123
 gsql: could not fork new process for connection: 无法分配内存

 could not fork new process for connection: 无法分配内存
 could not fork new process for connection: 无法分配内存

根据无法分配内存的现象完成以下几个方面的检查。

  1. 检查内存状态,发现内容足够,如下图所示。

  2. 查看GaussDB相关进程打开的文件句柄数。
    [root@dbs_gauss1 rds]#lsof | grep gausscore | wc -l
     16319
  3. 查看ulimit默认配置。

处理方法
  1. 执行以下命令,编辑“/etc/security/limits.conf”文件。

    vim /etc/security/limits.conf

  2. 在文件中增加以下内容。
    gausscore soft nproc 5500
    gausscore hard nproc 5500
    gausscore soft nofile 1000000
    gausscore hard nofile 1000000
  3. 按“Esc”执行以下命令,保存配置。

    :wq!

Microsoft SQL Server

Microsoft SQL Server参数修改后未生效
现象描述

用户在参数配置页面更改了默认的Microsoft SQL Server参数,但没有生效。

可能原因
  • 部分参数更新后需要重启,用户没有重启数据库。
  • 部分参数需要重新打开会话,用户没有关闭当前连接。
  • 参数修改不合理,导致Microsoft SQL Server故障。
  • 部分参数不能写进配置文件,会自动还原。
  • 实例故障。
定位思路

查看实例状态是否正常后,先充分了解要修改的Microsoft SQL Server参数的配置特性,保证使用正确的值或方法进行修改,最后依据参数生效的需要,重启Microsoft SQL Server或重新打开会话。

处理步骤
  1. 使用PuTTY,登录newRDS-Database01节点。

    默认帐号:dbs,默认密码:Changeme_123

  2. 执行以下命令,切换至root用户。

    su - root

    “root”的默认密码为“Cloud12#$”。

  3. 执行以下命令,切换至gausscore用户。

    su gausscore

  4. 执行以下命令,登录CORE数据库。

    gsql -p 端口号 -q 数据库名 -U CORE数据库用户名 -W CORE用户密码;

    例如,数据库用户名为core,端口号为8635,数据库用户密码为RDSDB@Remote123,则执行以下命令:

    gsql -p 8635 -q core -U core -W RDSDB@Remote123

  1. 连接Gauss数据库,通过检索dbs_instance表,查找对应实例的状态。

    Core=>Select name,status from dbs_instance where name='实例名';

    • 如果实例状态值为normal,则实例正常。
    • 如果实例状态值为abnormal,则实例故障,请先尝试修复实例。

  2. 检查重启数据库,或关闭当前连接重新打开一个会话。
  3. 查看Microsoft SQL Server官方网站,了解参数值的正确设置方法后重新配置。
  4. 以上步骤仍不能解决问题,请联系技术支持协助解决。
翻译
下载文档
更新时间:2019-08-19

文档编号:EDOC1100043088

浏览量:18436

下载量:439

平均得分:
本文档适用于这些产品
相关版本
相关文档
Share
上一页 下一页