修改归档日志的删除策略,会引起OBSERVER服务异常停止

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!

环境:通过rpm方式安装的5.7.25-OceanBase_CE-v4.6.0.0

操作步骤1:启动observer
[admin@rac2 arch]$ /home/admin/oceanbase/bin/observer -I 192.168.1.172 -P 2882 -p 2881 -z zone1 -d /data/oceanbase/store/obcluster -r ‘192.168.1.172:2882:2881’ -c 1 -n obcluster -o “memory_limit=12G,system_memory=4G,datafile_size=10G,log_disk_size=12G,cpu_count=8”
/home/admin/oceanbase/bin/observer -I 192.168.1.172 -P 2882 -p 2881 -z zone1 -d /data/oceanbase/store/obcluster -r 192.168.1.172:2882:2881 -c 1 -n obcluster -o memory_limit=12G,system_memory=4G,datafile_size=10G,log_disk_size=12G,cpu_count=8
local_ip: 192.168.1.172
rpc port: 2882
mysql port: 2881
zone: zone1
data_dir: /data/oceanbase/store/obcluster
rs list: 192.168.1.172:2882:2881
cluster id: 1
appname: obcluster
optstr: memory_limit=12G,system_memory=4G,datafile_size=10G,log_disk_size=12G,cpu_count=8
[admin@rac2 arch]$
[admin@rac2 arch]$ ps -ef|grep observer
admin 12766 1 99 10:41 ? 00:01:12 /home/admin/oceanbase/bin/observer -I 192.168.1.172 -P 2882 -p 2881 -z zone1 -d /data/oceanbase/store/obcluster -r 192.168.1.172:2882:2881 -c 1 -n obcluster -o memory_limit=12G,system_memory=4G,datafile_size=10G,log_disk_size=12G,cpu_count=8
admin 13744 11804 0 10:42 pts/0 00:00:00 grep --color=auto observer

操作步骤2:
查看删除策略、修改删除策略
[admin@rac2 ~]$ obclient -h 127.0.0.1 -P 2881 -u root@perf_tenant -p -A -Doceanbase
Enter password:
Welcome to the OceanBase. Commands end with ; or \g.
Your OceanBase connection id is 3221511394
Server version: OceanBase_CE 4.6.0.0 (r100000162026071511-ac29b5f39774cb025f12641014f48820dc0be70a) (Built Jul 15 2026 11:56:19)

Copyright (c) 2000, 2018, OceanBase and/or its affiliates. All rights reserved.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

obclient(root@perf_tenant)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_BACKUP_DELETE_POLICY;
±------------±----------------+
| POLICY_NAME | RECOVERY_WINDOW |
±------------±----------------+
| log_only | 3d |
±------------±----------------+
1 row in set (0.001 sec)

obclient(root@perf_tenant)[oceanbase]> ALTER SYSTEM DROP DELETE BACKUP POLICY ‘log_only’;
Query OK, 0 rows affected (0.024 sec)

调整为1d
obclient(root@perf_tenant)[oceanbase]> ALTER SYSTEM ADD DELETE BACKUP POLICY ‘log_only’ RECOVERY_WINDOW ‘1d’;
Query OK, 0 rows affected (0.065 sec)

obclient(root@perf_tenant)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_BACKUP_DELETE_POLICY;
ERROR 2013 (HY000): Lost connection to MySQL server during query
obclient(root@perf_tenant)[oceanbase]>

3、此时observer的服务进程已经停止

根据您的描述,OceanBase修改归档日志删除策略后导致observer服务异常停止的问题,我们建议您使用obdiag工具来进行诊断。首先,通过obdiag收集与归档日志相关的日志信息可以帮助定位问题所在。同时,考虑到问题发生在调整特定配置之后,直接分析该场景下可能存在的错误也是必要的。

日志采集场景: 日志归档问题
日志采集命令: obdiag gather scene run --scene=observer.log_archive

执行上述命令将帮助收集关于日志归档操作期间的日志文件及系统状态信息。这一步对于理解observer为何会在更改归档日志策略后停止至关重要。

为了更有效地解决这个问题,请提供以下额外的信息:

  1. 在修改归档日志删除策略前后,是否有记录任何警告或错误消息?这些消息通常可以为问题诊断提供线索。
  2. 修改前后的具体配置参数值是什么样的?特别是那些涉及归档保留策略的参数设置。
  3. 是否存在其他同时运行的操作可能影响了系统的稳定性?
  4. 服务器资源使用情况(如CPU、内存和磁盘空间)在出现问题之前是否有异常?
  5. observer停止时,操作系统级别的日志(例如/var/log/messages等)中是否记录了相关信息?

请按指导步骤运行给定的日志采集命令,并准备上述询问所需的数据。这样我们可以基于更多的背景信息来深入调查此问题。

附上敏捷诊断工具 obdiag 使用帮助链接

能把当时操作的observer.log发一下么 时间要对的上。如果日志轮询了 把轮询的带日期日志发一下

observer.rar (2.3 MB)
rootservice.zip (3.4 MB)

您好!附件中是observer.log和rootservice.log的日志

重新登录后,查询的删除策略.txt (5.4 KB)

sysctl -a | grep pattern 这个信息查看一下 看看配置的文件下 是否有core dump文件
这个也查看
ulimit -an

[admin@rac2 log]$ sysctl -a | grep pattern
sysctl: permission denied on key ‘fs.protected_hardlinks’
sysctl: permission denied on key ‘fs.protected_symlinks’
sysctl: permission denied on key ‘kernel.cad_pid’
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h
sysctl: permission denied on key ‘kernel.usermodehelper.bset’
sysctl: permission denied on key ‘kernel.usermodehelper.inheritable’
sysctl: permission denied on key ‘net.core.bpf_jit_harden’
sysctl: permission denied on key ‘net.core.bpf_jit_kallsyms’
sysctl: permission denied on key ‘net.ipv4.tcp_fastopen_key’
sysctl: permission denied on key ‘net.ipv6.conf.all.stable_secret’
sysctl: permission denied on key ‘net.ipv6.conf.default.stable_secret’
sysctl: permission denied on key ‘net.ipv6.conf.ens33.stable_secret’
sysctl: permission denied on key ‘net.ipv6.conf.ens34.stable_secret’
sysctl: permission denied on key ‘net.ipv6.conf.lo.stable_secret’
sysctl: permission denied on key ‘net.ipv6.conf.virbr0.stable_secret’
sysctl: permission denied on key ‘net.ipv6.conf.virbr0-nic.stable_secret’
sysctl: permission denied on key ‘vm.mmap_rnd_bits’
sysctl: permission denied on key ‘vm.mmap_rnd_compat_bits’
[admin@rac2 log]$ ulimit -an
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 79537
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 16384
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[admin@rac2 log]$

root用户设置一下这个
ulimit -c unlimited
看看这个里面有core dump文件没有
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h

执行一下 输出到txt文件里
addr2line -pCfe bin/observer 0x2d1b4b28 0x2c9cd8e1 0x7f2ab0c9f62f 0x14f5898d 0x14f45d3e 0x14f42c96 0x14f88bd0 0x14f7d3cc 0x14f30f86 0x2c8baa91 0x2c8addb6 0x2c8ad780 0x2c8c2407 0x7f2ab0c97ea4 0x7f2ab09c096c

ob460备份恢复,确实有问题 是个已知的bug 建议使用5.01版本