GaussDB主备切换时间长问题分析

• 问题描述

客户反馈DN主备切换时间长，需要分析原因

• 分析思路

主备切换时间长，通常是因为各个别DN日志回放未完成导致，可根据日志实际进行分析。

• 分析过程

1.  查看cm_server主日志，确认cm_server下发升主命令的时间以及下发升主的DN。

cd $GAUSSLOG/cm/cm_server

vim cm_server-yyyy-mm-dd_******-current.log

− 2025-06-20 09:31:13.416(cm_server日志时间差8小时)，cm_server主收到上报的dn_6001(原主DN)状态异常，可搜索“ERROR”并根据时间点过滤。

− 2025-06-20 09:31:13.475(cm_server日志时间差8小时)，cm_server主分别下发Lock1锁命令，对dn_6004,dn_6003,dn_6002进行加锁，可搜索“Lock1 message has sent to instance”关键词。

2.查看dn_6002,dn_6003,dn_6004所在节点的cm_agent日志，确认是否收到cm_server下发的加锁命令。

cd $GAUSSLOG/cm/cm_agent

vim cm_agent-yyyy-mm-dd_******-current.log

− 2025-06-20 09:31:13.478 (cm_agent日志时间差8小时)，cm_agent对dn_6004加锁，但加锁失败，可搜索“set Lock1 to instance”关键词。

− 期间对dn_6003，dn_6002也在加锁，也是加锁失败，可搜索“set Lock1 to instance”关键词。

3. cm_agent加锁失败，进一步查看DN日志，确认DN在执行什么操作。

cd $GAUSSLOG/gs_log/dn_6004

vim gaussdb-yyyy-mm-dd_******.log

查看dn_6004日志，2025-06-20 17:31:13.477 dn_6004未完成回放，可根据时间点搜索。

dn_6002、dn_6003在同一时间点也是未完成回放，此处省略截图。

4. 继续查看DN运行日志，确认dn_6002,dn_6003,dn_6004在什么时间完成回放。

cd $GAUSSLOG/gs_log/dn_6004

vim gaussdb-yyyy-mm-dd_******.log

2025-06-20 17:32:31.517，dn_6004优先回放日志完成，可搜索“redo_done flag is:[true]”关键词。

dn_6002、dn_6003在同一时间点未完成回放，此处省略截图。

5. dn_6004优先完成回放，进一步查看cm_server主日志，确认是否下发升主命令以及下发时间。

cd $GAUSSLOG/cm/cm_server

vim cm_server-yyyy-mm-dd_******-current.log

2025-06-20 09:32:32.492(cm_server日志时间差8小时)，cm_server主下发dn_6004升主命令，可搜索“Failover message has sent to instance”关键词。

6. 查看dn_6004节点的cm_agent日志，确认是否收到dn_6004升主命令以及接收时间。

cd $GAUSSLOG/cm/cm_agent

vim cm_agent-yyyy-mm-dd_******-current.log

2025-06-20 09:32:32.492 (cm_agent日志时间差8小时)，cm_agent接受cm_server下发的命令，对dn_6004执行升主操作，可搜索“failover msg from cm_server”关键词。

7.查看dn_6004运行日志，确认是否开始升主以及时间点。

cd $GAUSSLOG/gs_log/dn_6004

vim gaussdb-yyyy-mm-dd_******.log

2025-06-20 17:32:32.529，dn_6004开始升主，可搜索“Instance to do failover”关键词。

8. 继续查看dn_6004运行日志，确认升主完成时间点。

cd $GAUSSLOG/gs_log/dn_6004

vim gaussdb-yyyy-mm-dd_******.log

2025-06-20 09:32:36.808，dn_6004开始接受新的连接，可搜索“database system is ready to accept connections”关键词。

9. 查看dn_6004所在节点的cm_agent日志，确认dn_6004解锁时间。

cd $GAUSSLOG/cm/cm_agent

vim cm_agent-yyyy-mm-dd_******-current.log

2025-06-20 09:32:39.510 (cm_agent日志时间差8小时)，cm_agent解锁dn_6004成功，可搜索“process_unlock_no_primary_command succeed”关键词。

• 根本原因

综上分析，得出主备切换时间长的原因为：

dn_6001故障以后，dn_6002,dn_6003,dn_6004日志均与主机存在差距，cm_server分别给dn_6002,dn_6003,dn_6004发下锁DN命令，由于DN回放未完成因此支持锁DN失败，直到2025-06-20 17:32:31.517，dn_6004优先回放完成，因此选择dn_6004升主。

dn_6004回放耗时：2025-06-20 09:31:13.478--2025-06-20 17:32:31.517，持续78s。

dn_6004升主耗时：2025-06-20 09:32:32.492--2025-06-20 17:32:39.655，持续7s。

因此，主备切换耗时长主要在于回放时间长，回放时间长是由于未开启流控，DN主备之间的RTO高。在升主时先要完成回放再执行升主操作。

• 解决方案

开启流控：gs_guc reload -Z datanode -N all -I all -c "recovery_time_target=60"

• 补充说明

流控原理说明：

在备机回放日志的能力跟不上主机时，通过在walsender线程中进行一定时间的sleep来降低日志发送速度，让备机来得及回放已接收的日志。也就是当备机接收日志或者回放日志的能力跟不上主机时，通过强制降低主机的业务性能，来保证主备机的日志差异在一定目标范围。

因此，开启流控，在主机业务压力过大时，会限制主机业务。

流控为主机业务压力与RTO两者之间的综合选择，需要根据实际业务特点慎重配置。

GaussDB关键日志目录介绍：

l   GaussDB日志路径为$GAUSSLOG目录

l   CN、DN运行日志路径：$GAUSSLOG/gs_log

l   cm_server运行日志：$GAUSSLOG/cm/cm_server

l   cm_agent运行日志：$GAUSSLOG/cm/cm_agent

l   升级、安装日志：$GAUSSLOG/om