LS数量异常问题处理

吉利蛋 · 2026 年6 月 23 日 11:50

【使用环境】生产环境
【 OB or 其他组件】OB
【使用版本】4.3.5
【问题描述】
obclient(root@sys)[oceanbase]> select a.TENANT_ID,b.tenant_name, a.LS_ID,a.SVR_IP,count(*) as ls_cnt from cdb_ob_tablet_replicas a join __all_tenant b on a.tenant_id=b.tenant_id and a.tenant_id = 1010 and a.LS_ID=1007 group by a.tenant_id, a.LS_ID, a.svr_ip;
±----------±------------±------±--------------±-------+
| TENANT_ID | tenant_name | LS_ID | SVR_IP | ls_cnt |
±----------±------------±------±--------------±-------+
| 1010 | rthub | 1007 | xxxx.34 | 1511 |
| 1010 | rthub | 1007 | xxxx.43 | 1511 |
| 1010 | rthub | 1007 | xxxx.56 | 1511 |
| 1010 | rthub | 1007 | xxxx.58 | 211412 |
±----------±------------±------±--------------±-------+
4 rows in set (0.755 sec)
发现有个租户的一个LS在一台不存在在集群中的机器（xx.58）中有21w个ls，应该是个元数据异常，如何处理

辞霜 · 2026 年6 月 23 日 14:24

隔段时间查询一下，多查几次看看这个LS ID是不是会变化。集群规模和详细版本提供一下

吉利蛋 · 2026 年6 月 23 日 14:31

select * from oceanbase.__all_virtual_tablet_meta_table where tenant_id = 1010 and ls_id = 1007 and svr_ip=‘192.168.81.58’
±----------±----------±------±--------------±---------±---------------------------±---------------------------±--------------------±----------±--------------±--------------------±-------+
| tenant_id | tablet_id | ls_id | svr_ip | svr_port | gmt_create | gmt_modified | compaction_scn | data_size | required_size | report_scn | status |
±----------±----------±------±--------------±---------±---------------------------±---------------------------±--------------------±----------±--------------±--------------------±-------+
| 1010 | 200006 | 1007 | 192.168.81.58 | 2882 | 2025-06-25 06:20:05.679780 | 2025-09-22 03:54:41.810476 | 1758477600404521001 | 642102 | 647168 | 1758477600404521001 | 0 |
±----------±----------±------±--------------±---------±---------------------------±---------------------------±--------------------±----------±--------------±--------------------±-------+
从gmt_modified看这个问题是去年9月份的，应该是个老黄历问题了，今天加了个巡检以后突然发现的，LS_ID应该是不会变了。
集群架构是7-7-7，这个rthub租户规模的话是每个zone分了5个unit，总和约5.5T

这个集群原本是有很多很多分区表的，这一堆LS_ID应该是以前分区表产生的，现在分区表都整合成单表了，这台机器也不知道什么时候下线的，可能是个什么遗留问题导致的，对集群访问、运维什么的倒是没有影响，昨天想起来加一个这方面的巡检才发现的问题

吉利蛋 · 2026 年6 月 23 日 14:33

ob版本是4.3.5.3

辞霜 · 2026 年6 月 23 日 15:18

select * from CDB_OB_LS where tenant_id=1010;

吉利蛋 · 2026 年6 月 23 日 15:21

obclient(root@sys)[oceanbase]> select * from CDB_OB_LS where tenant_id=1010;
±----------±------±-------±------------------±--------------±------------±--------------------±---------±--------------------±--------------------±-----+
| TENANT_ID | LS_ID | STATUS | PRIMARY_ZONE | UNIT_GROUP_ID | LS_GROUP_ID | CREATE_SCN | DROP_SCN | SYNC_SCN | READABLE_SCN | FLAG |
±----------±------±-------±------------------±--------------±------------±--------------------±---------±--------------------±--------------------±-----+
| 1010 | 1 | NORMAL | zone1;zone2;zone3 | 0 | 0 | NULL | NULL | 1782199270974647002 | 1782199270974647002 | |
| 1010 | 1004 | NORMAL | zone1;zone2;zone3 | 1014 | 1002 | 1750303612492130000 | NULL | 1782199270985421004 | 1782199270985420999 | |
| 1010 | 1007 | NORMAL | zone1;zone2;zone3 | 1015 | 1003 | 1750303612618757000 | NULL | 1782199271083275002 | 1782199271064006000 | |
| 1010 | 1444 | NORMAL | zone1;zone2;zone3 | 1020 | 1004 | 1754526376648620000 | NULL | 1782199271347109002 | 1782199271347109002 | |
| 1010 | 1445 | NORMAL | zone1;zone2;zone3 | 1021 | 1005 | 1754537229419473000 | NULL | 1782199270736438002 | 1782199270736438002 | |
| 1010 | 1451 | NORMAL | zone1;zone2;zone3 | 1026 | 1006 | 1755220316850042000 | NULL | 1782199271127861003 | 1782199271121506010 | |
±----------±------±-------±------------------±--------------±------------±--------------------±---------±--------------------±--------------------±-----+
6 rows in set (0.112 sec)

辞霜 · 2026 年6 月 23 日 15:22

– 1. .58 是否还在集群 server 列表

SELECT SVR_IP, SVR_PORT, STATUS, ZONE, START_SERVICE_TIME, STOP_TIME
FROM oceanbase.DBA_OB_SERVERS;

– 2. LS 1007 副本分布（关键）

SELECT TENANT_ID, LS_ID, SVR_IP, SVR_PORT, ZONE, ROLE, REPLICA_TYPE, MEMBER_LIST, LEARNER_LIST
FROM oceanbase.CDB_OB_LS_LOCATIONS
WHERE TENANT_ID = 1010 AND LS_ID = 1007;

– 3. 是否有容灾任务在跑

SELECT * FROM oceanbase.CDB_OB_LS_REPLICA_TASKS
WHERE TENANT_ID = 1010 AND LS_ID = 1007;

– 4. 租户 locality

SELECT TENANT_ID, TENANT_NAME, LOCALITY
FROM oceanbase.DBA_OB_TENANTS
WHERE TENANT_ID = 1010;

吉利蛋 · 2026 年6 月 23 日 15:28

.58是否还在
确认不在
副本分部
obclient(root@sys)[oceanbase]> SELECT TENANT_ID, LS_ID, SVR_IP, SVR_PORT, ZONE, ROLE, REPLICA_TYPE, MEMBER_LIST, LEARNER_LIST
→ FROM oceanbase.CDB_OB_LS_LOCATIONS
→ WHERE TENANT_ID = 1010 AND LS_ID = 1007;
±----------±------±--------------±---------±------±---------±-------------±------------------------------------------------------------------------------------------------------------±-------------+
| TENANT_ID | LS_ID | SVR_IP | SVR_PORT | ZONE | ROLE | REPLICA_TYPE | MEMBER_LIST | LEARNER_LIST |
±----------±------±--------------±---------±------±---------±-------------±------------------------------------------------------------------------------------------------------------±-------------+
| 1010 | 1007 | 192.168.81.34 | 2882 | zone1 | LEADER | FULL | 192.168.81.34:2882:1756527950006769,192.168.81.43:2882:1758493263268112,192.168.81.56:2882:1750817416580653 | |
| 1010 | 1007 | 192.168.81.43 | 2882 | zone2 | FOLLOWER | FULL | NULL | |
| 1010 | 1007 | 192.168.81.56 | 2882 | zone3 | FOLLOWER | FULL | NULL | |
±----------±------±--------------±---------±------±---------±-------------±------------------------------------------------------------------------------------------------------------±-------------+
是否有容灾任务在跑
没有
租户 locality
±----------±------------±--------------------------------------------+
| TENANT_ID | TENANT_NAME | LOCALITY |
±----------±------------±--------------------------------------------+
| 1010 | rthub | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 |
±----------±------------±--------------------------------------------+
1 row in set (0.025 sec)

辞霜 · 2026 年6 月 23 日 15:31

CDB_OB_LS_LOCATIONS没有58节点的LS，很古怪的问题了，RS日志发一份完整的看下

吉利蛋 · 2026 年6 月 23 日 15:47

拉了81.34节点上的，大佬看看，剩的日志只有2个，其余的应该是被自动清理掉了。
rootservice_81_34_logs.tar.gz (23.9 MB)

辞霜 · 2026 年6 月 23 日 15:48

该租户的1号日志流所在节点的observer日志也发一份

吉利蛋 · 2026 年6 月 23 日 15:56

1号日志流leader节点的rs日志有点多，24小时内有20来个日志，压缩了有274MB，传不上来。。。

辞霜 · 2026 年6 月 23 日 15:58

发一份完整的就行

吉利蛋 · 2026 年6 月 23 日 16:00

rootservice_81_49_logs2.tar.gz (18.5 MB)
搞了个最近2个日志的压缩包

wkk2025 · 2026 年6 月 23 日 16:26

顶一下

辞霜 · 2026 年6 月 23 日 17:23

SELECT SVR_IP, COUNT() cnt
FROM oceanbase.CDB_OB_TABLET_REPLICAS
WHERE TENANT_ID = 1010 AND LS_ID = 1007
GROUP BY SVR_IP;
49节点obsever日志查询下
grep -E “ObTenantTabletCleanupService|finish cleanup offline tablet|successfully cleaned up tablet|OfflnClnTSer” observer.log | tail -50

吉利蛋 · 2026 年6 月 23 日 17:32

obclient(root@sys)[(none)]> SELECT SVR_IP, COUNT(*) cnt
→ FROM oceanbase.CDB_OB_TABLET_REPLICAS
→ WHERE TENANT_ID = 1010 AND LS_ID = 1007
→ GROUP BY SVR_IP;
±--------------±-------+
| SVR_IP | cnt |
±--------------±-------+
| 192.168.81.34 | 1510 |
| 192.168.81.43 | 1510 |
| 192.168.81.56 | 1510 |
| 192.168.81.58 | 211412 |
±--------------±-------+
4 rows in set (0.469 sec)

grep -E “ObTenantTabletCleanupService|finish cleanup offline tablet|successfully cleaned up tablet|OfflnClnTSer” observer.log | tail -50
这个无结果

Area · 2026 年6 月 24 日 08:09

了解了解

辞霜 · 2026 年6 月 24 日 10:27

是个已知bug，435bp4修复了。
查询下这个表看看58节点是不是存在脏元数据__all_tablet_meta_table

AntTech_OXEPTD · 2026 年6 月 24 日 10:32

当无法解释的时候，一般就是BUG了。