从4.3.5升级到4.4.2后，经常出现sys租户队列超时告警，然后所有业务租户3副本CPU使用率开始暴涨

看着应该是死锁检测发出的语句 你看看关闭ocp是否能可以 你黑屏下也检查一下参数
SELECT name, value, scope, edit_level

FROM oceanbase.GV$OB_PARAMETERS

WHERE name = ‘_lcl_op_interval’;
ALTER SYSTEM SET _lcl_op_interval = ‘0ms’; 或者直接关闭 sys租户下

关闭ocp无效。 sys租户目前连接不上··· 关闭不了

手动依次重启了2台 sys租户的机器。 然后ocp中 这个集群能访问了。 关掉了死锁检测。然后对上面的sql限流0. 暂时恢复了。 后续再看看有没有同样的问题

66666

手动重启机器后， 备租户同步停滞了。 该怎么恢复
@论坛小助手

这个价值挺高。再次印证一个道理： 运维，别做第一个吃螃蟹的。

关闭死锁检测机制应该就可以了 不用限流sql了

我都等他发布2个月了才去升级的···

SELECT tenant_id, tenant_name, tenant_role, status, switchover_status,
protection_mode,
scn_to_timestamp(sync_scn) AS sync_time,
scn_to_timestamp(replayable_scn) AS replayable_time,
scn_to_timestamp(readable_scn) AS readable_time,
scn_to_timestamp(recovery_until_scn) AS recovery_until_time
FROM DBA_OB_TENANTS
WHERE tenant_name IN (’<主租户名>’, ‘<备租户名>’);
查看一下 主备租户信息 看看sync_scn是否推进 若在推进，只是追赶延迟，等待即可

目前也没有日志信息 从ocp上来看确实是死锁检测有问题 如果能提供一下日志就好了

私发你钉钉了

兄弟查一下信息 看看scn是否推进

备租户的信息 也查一下

– 备租户恢复源类型
SELECT * FROM DBA_OB_LOG_RESTORE_SOURCE WHERE tenant_id = <备租户ID>; 这个信息也查一下

SELECT ls_id, sync_status, err_code, comment,
scn_to_timestamp(sync_scn) AS sync_time
FROM V$OB_LS_LOG_RESTORE_STATUS
WHERE tenant_id = 1004
ORDER BY ls_id; 备库各日志流恢复状态（看有没有报错）

SELECT ls_id, sync_scn, scn_to_timestamp(sync_scn) AS sync_time
FROM __all_virtual_ls_recovery_stat
WHERE tenant_id = 1004
ORDER BY sync_scn ASC
LIMIT 10;

– 主租户 mengxuan
SELECT ls_id, svr_ip, end_scn, scn_to_timestamp(end_scn) AS end_time
FROM __all_virtual_log_stat
WHERE tenant_id = <主租户ID> AND role = ‘LEADER’
ORDER BY ls_id;

– 备租户 mxob_back
SELECT ls_id, svr_ip, end_scn, scn_to_timestamp(end_scn) AS end_time
FROM __all_virtual_log_stat
WHERE tenant_id = 1004 AND role = ‘LEADER’
ORDER BY ls_id;