gs_ctl 建立一主一备关系时有警告信息，能够建立成功。但断电重启后备库启动失败

我来答

Mcqmyxh

2023-12-15

mogdb

对Mogdb 3.0.3 使用 gs_ctl build -D /dir -b full -M standby 进行主备建立时，日志有告警信息如下：

[gs_ctl]: exists illegal characters backup_label, dn_6001

[gs_ctl]: receiving and unpacking files...

    [gs_ctl]: exists illegal characters pg_hba.conf.bak, dn_6001 ,
    [gs_ctl]: exists illegal characters pg_snapshots/, dn_6001 ,
    [gs_ctl]: exists illegal characters postmaster.pid.lock, dn_6001 ,
    [gs_ctl]: exists illegal characters pg_serial/, dn_6001

[gs_ctl]: exists illegal characters pg_xlog/, dn_6001

[gs_ctl]: exists illegal characters pg_multixact/, dn_6001

[gs_ctl]: exists illegal characters pg_multixact/members/, dn_6001 ,

[gs_ctl]: exists illegal characters pg_errorinfo/, dn_6001 ,

[gs_ctl]: exists illegal characters base/16014/15446, dn_6001 ,

[gs_ctl]: exists illegal characters base/16019/15456, dn_6001 ,

[gs_ctl]: exists illegal characters global/15440_fsm, dn_6001 ,

[gs_ctl]: exists illegal characters global/15747, dn_6001 ,
[gs_ctl]: exists illegal characters global/15819, dn_6001 ,

日志我摘抄了其中一部分，看日志意思应该是主备建立后备库觉得这些从主库同步来的数据文件(mogdb主库进程启动时指定的数据目录)不合法，但opengauss在执行如上命令时不会有这些警告信息。

告警信息不影响最终备份的结果，最终可以完成。但在备库断电后，备库再次重新启动后就会失败，日志如下：

[2023-12-11 09:08:17.389][1631][][gs_ctl]: gs_ctl started,datadir is /backup/db
[2023-12-11 09:08:17.678][1631][][gs_ctl]: waiting for server to start...
.0 LOG: [Alarm Module]can not read GAUSS_WARNING_TYPE env.
0 LOG: [Alarm Module]Host Name: 5432
0 LOG: [Alarm Module]Host IP: 0.0.21.56
0 LOG: [Alarm Module]Get ENV GS_CLUSTER_NAME failed!
0 WARNING: failed to open feature control file, please check whether it exists: FileName=gaussdb.version, Errno=2, Errmessage=No such file or directory.
0 WARNING: failed to parse feature control file: gaussdb.version.

0 WARNING: Failed to load the product control file, so gaussdb cannot distinguish product version.
The core dump path from /proc/sys/kernel/core_pattern is an invalid directory:|/usr/lib/systemd/
2023-12-11 09:08:17.808 65766101.1 [unknown] 140497251760320 [unknown] 0 dn_6001 DB010 0 [REDO] LOG: Recovery parallelism, cpu count = 4, max = 4, actual = 4
2023-12-11 09:08:17.808 65766101.1 [unknown] 140497251760320 [unknown] 0 dn_6001 DB010 0 [REDO] LOG: ConfigRecoveryParallelism, true_max_recovery_parallelism:4, max_recovery_parallelism:4
Failed to read gaussdb.state: 0Failed to set gaussdb.state with UNKNOWN_STATE[2023-12-11 09:08:18.679][1631][][gs_ctl]: waitpid 1673 failed, exitstatus is 256, ret is 2
[2023-12-11 09:08:18.679][1631][][gs_ctl]: stopped waiting
[2023-12-11 09:08:18.679][1631][][gs_ctl]: could not start server

我来答

添加附件

问题补充

3条回答

默认

最新

Mjwlan

根据提供的日志信息，这里有两个问题需要解决：

"exists illegal characters"警告：在主备建立时，备库检测到一些从主库同步过来的数据文件名不合法。这可能是因为文件名中包含了对于数据库命名不允许的特殊字符或格式。这些警告并不会影响最终的备份结果，但可能会导致后续启动备库的问题。
备库启动失败：断电重启后，备库无法成功启动。从日志中可以看到几个问题，如警告信息中提到的无法读取和解析控制文件、无法加载产品版本等。这些问题可能是由于断电导致的数据文件损坏或目录结构错误引起的。

针对这些问题，以下是一些可能的解决方法：

针对警告信息中的非法字符：检查主库的数据文件名是否符合数据库命名规范，并确保文件名不包含任何特殊字符或格式。如果有不符合规范的文件名，可以尝试修改文件名，然后重新进行主备建立。
针对备库启动失败的问题：首先，确认断电前备库的数据文件是否完整且没有损坏。如果发现数据文件损坏，可以尝试使用备份还原的方式来修复数据文件。另外，也可以尝试删除备库的数据目录并重新初始化备库，然后重新进行主备建立。

如果上述方法无效或无法解决问题，建议查看更详细的错误日志或联系数据库供应商的技术支持团队以获取进一步的帮助和指导。他们可能能够提供更具体的解决方案来解决备库启动失败的问题。