ODC不可用问题

OceanBase 技术问题
,
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OB or ODC
【 使用版本 】
ODC版本：4.3.3-1741091209000
META版本：4.2.2.1-101000012024030709
【问题描述】3月27号15：21 分 ODC访问慢，登不上去，故障时间持续大概20分钟，15：41分恢复。
【复现路径】问题出现前后相关操作

升级版本时间：2025年3月19号 从4.2.2 bp1 升级到现在的4.3.3

1、租户资源查看，租户资源太低可能导致ODC响应慢。

2、性能监控，查看CPU和内存使用情况

3、SQL诊断，是否有慢sq影响。

可以看到这条sql是在 创建migrate_schema_history 元数据表，但是目前看起来不太合理。

1、为什么ODC发起这条sql？ 因为升级是3月19 号升级的，如果在升级完成后有发起操作，可以理解，但是现在没有什么影响这个表的操作。

2、为什么占用这么高，按照这个语法，当前存在这个表的话，应该是直接跳过的，不应该耗费这么多资源。

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

#3

根因分析场景: SQL性能问题
根因分析命令: obdiag rca run --scene=sql_performance_issue
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

推荐使用 obdiag 工具进行根因分析和日志采集，并且将采集到的日志提供给我们以便确认问题所在。上述命令可以帮助您收集与SQL性能相关的诊断信息，同时尝试分析可能的性能瓶颈。

为了更好地帮助您定位问题，请您按照以下步骤操作：

  1. 执行上述日志采集命令，将生成的日志压缩包上传或发送给我们。
  2. 如果可能，请提供在问题发生期间执行的慢查询SQL语句及其执行计划。

另外，为了确定具体的问题，在此需要您提供一些信息：

  1. 在访问变慢和无法登录期间，是否有明显的系统资源（如CPU、内存、磁盘I/O）占用高峰？
  2. 是否有在该时间段内执行过大规模的数据操作（如导入、导出、更新等）？
  3. 最近是否对系统进行了任何升级或配置变更？如果有，请详细描述变更内容。
  4. 问题发生时，租户的资源池配置是否发生了变化？例如，内存或CPU核数的调整。
  5. 是否可以通过ODC或其他工具查看到具体的错误信息或警告日志？如果有，请一并提供。

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

#4

你这个图我都看不到呀。
麻烦发一下故障期间odc和ob的日志

#5

租户资源

image
image1920×1032 183 KB

性能监控
image
image1920×1032 189 KB

SQL诊断
image
image1920×1032 130 KB

image
image1920×1032 100 KB

慢sql：
CREATE TABLE IF NOT EXISTS migrate_schema_history (
install_rank BIGINT NOT NULL AUTO_INCREMENT COMMENT ‘install rank’,
version VARCHAR(64) DEFAULT NULL COMMENT ‘version’,
description VARCHAR(64) DEFAULT NULL COMMENT ‘description’,
type VARCHAR(64) DEFAULT NULL COMMENT ‘type, optional values: SQL/JDBC’,
script VARCHAR(64) DEFAULT NULL COMMENT ‘script name, sql file name or java class name’,
checksum VARCHAR(64) DEFAULT NULL COMMENT ‘sha1 checksum’,
installed_by VARCHAR(64) NULL DEFAULT NULL COMMENT ‘installed by user’,
installed_on DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘installed timestamp’,
execution_millis BIGINT NOT NULL DEFAULT 0 COMMENT ‘execution duration milliseconds’,
success BOOLEAN NOT NULL DEFAULT 0 COMMENT ‘is success: 1 success, 0 failed’,
PRIMARY KEY (install_rank)
)

#6

odc.7z (2.8 MB)
这个是ODC 日志。

#7

目前截图信息和odc日志已经更新，先看看这些吧，后续有需要我在去observer日志。

#8

根据您提供的截图信息和日志内容，以下是对问题的详细分析和可能的解决方案：

1. 问题概述

  • 现象描述：3月27日15:21分，ODC访问变慢，无法登录，持续约20分钟（至15:41恢复）。
  • 关键线索：
    • 慢SQL为CREATE TABLE IF NOT EXISTS migrate_schema_history。
    • 租户资源监控显示CPU和内存使用率在问题时间段内波动较大。
    • ODC日志已上传。

2. 问题分析

2.1 关于慢SQL CREATE TABLE IF NOT EXISTS migrate_schema_history

  • SQL语句功能：该SQL用于创建一个名为migrate_schema_history的元数据表，记录迁移历史信息。
  • 问题点：
    1. 为何ODC发起此SQL？
      • 根据ODC的功能设计，migrate_schema_history表可能是ODC内部用于记录迁移任务或版本升级的历史信息。尽管您提到升级发生在3月19日，但ODC可能会在某些场景下动态检查或重新创建该表（例如租户初始化、版本校验等）。
      • 如果该表已经存在，理论上SQL执行应非常快，但由于实际耗时较高，可能存在其他因素影响。
    2. 为何占用如此高的资源？
      • 即使表已存在，CREATE TABLE IF NOT EXISTS语句仍会触发元数据锁（MDL），可能导致阻塞。
      • 如果表结构复杂或涉及大量索引操作，也可能导致执行时间延长。
      • 另外，如果系统中存在其他高并发事务或锁竞争，也可能进一步放大该SQL的影响。

2.2 租户资源监控

  • CPU和内存使用率：
    • 从性能监控图中可以看到，在15:21至15:41期间，租户CPU消耗和线程使用率均接近100%，表明系统负载较高。
    • 内存使用率也有所上升，但未达到瓶颈。
  • 可能原因：
    • 高并发事务或长时间运行的SQL可能导致CPU资源紧张。
    • 如果存在锁等待或死锁，也可能导致系统响应变慢。

2.3 ODC日志分析

  • 日志内容：
    • 从上传的odc.7z日志文件中，可以进一步分析ODC在问题时间段内的行为。
    • 建议重点关注以下内容：
      • ODC与OBServer之间的连接状态（是否出现超时或断连）。
      • 是否有异常堆栈信息或错误日志。
      • ODC内部线程池的状态（是否存在线程阻塞或堆积）。

3. 解决方案建议

3.1 短期措施

  1. 优化慢SQL：

    • 修改SQL逻辑，避免重复创建表。例如，先检查表是否存在再执行创建操作：
      SELECT COUNT(*) INTO @table_exists FROM information_schema.tables 
WHERE table_schema = 'odc_metadb' AND table_name = 'migrate_schema_history';

IF @table_exists = 0 THEN
    CREATE TABLE `migrate_schema_history` (
        `install_rank` BIGINT NOT NULL AUTO_INCREMENT COMMENT 'install rank',
        `version` VARCHAR(64) DEFAULT NULL COMMENT 'version',
        `description` VARCHAR(64) DEFAULT NULL COMMENT 'description',
        `type` VARCHAR(64) DEFAULT NULL COMMENT 'type, optional values: SQL/JDBC',
        `script` VARCHAR(64) DEFAULT NULL COMMENT 'script name, sql file name or java class name',
        `checksum` VARCHAR(64) DEFAULT NULL COMMENT 'sha1 checksum',
        `installed_by` VARCHAR(64) NULL DEFAULT NULL COMMENT 'installed by user',
        `installed_on` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'installed timestamp',
        `execution_millis` BIGINT NOT NULL DEFAULT 0 COMMENT 'execution duration milliseconds',
        `success` BOOLEAN NOT NULL DEFAULT 0 COMMENT 'is success: 1 success, 0 failed',
        PRIMARY KEY (`install_rank`)
    );
END IF;
    • 如果表已存在，直接跳过创建操作，减少元数据锁的影响。

  2. 监控系统资源：

    • 使用obdiag工具采集更详细的性能诊断信息：
      obdiag rca run --scene=sql_performance_issue
obdiag gather scene run --scene=observer.perf_sql
    • 分析采集到的日志，定位高负载的具体原因。

  3. 调整ODC配置：

    • 检查ODC的连接池配置，确保连接数和超时时间设置合理。
    • 如果ODC线程池出现阻塞，可适当增加线程数或优化任务调度逻辑。

3.2 长期措施

  1. 定期优化SQL：

    • 定期审查ODC生成的SQL语句，避免不必要的复杂操作。
    • 对高频SQL进行索引优化，减少执行时间。

  2. 加强监控和告警：

    • 在OCP中设置针对CPU、内存、锁等待等指标的告警规则，及时发现潜在问题。
    • 使用ODC内置的性能监控功能，跟踪SQL执行效率和系统负载。

  3. 升级版本：

    • 如果当前版本存在已知问题，建议升级到最新稳定版本（如4.3.4或更高版本），以获取性能改进和Bug修复。

4. 后续步骤

  • 进一步排查：
    • 如果问题仍未完全解决，请提供以下信息以便深入分析：
      • 问题发生期间的observer.log日志。
      • 更详细的ODC日志（包括堆栈信息和线程状态）。
      • 租户的完整SQL审计日志（可通过show full processlist或obdiag采集）。
  • 联系支持团队：
    • 如果需要更专业的技术支持，可联系OceanBase官方团队，提供上述日志和诊断信息。

希望以上分析和建议对您有所帮助！

详情请参考:

  1. DBCP 连接池连接 OceanBase 数据库示例程序
  2. oceanbase.CDB_OB_RECOVER_TABLE_JOB_HISTORY

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#9

您好，日志显示 3.27 下午 15:37 分左右，odc出现了一次 OOM 重启，15:38:31 有一条 create table if not exists migrate_schema_history 的慢 sql 记录。15:38:54 重启完成，服务恢复。

  1. odc 每次重启都会尝试初始化元数据库，但语句中加了 if not exists正常无影响。至于为何会造成 30s 的慢sql，需要内核排查。
    （参考： 为何占用如此高的资源？
  • 即使表已存在，CREATE TABLE IF NOT EXISTS语句仍会触发元数据锁（MDL），可能导致阻塞。
  • 如果表结构复杂或涉及大量索引操作，也可能导致执行时间延长。
  • 另外，如果系统中存在其他高并发事务或锁竞争，也可能进一步放大该SQL的影响）
  1. 看日志中，odc访问元数据库有大量的慢 sql 记录，建议升级一下元数据库规格，或者排查一下odc到元数据库的网络延迟是否过大。访问元数据库慢可能会导致 odc 的内存占用升高，最终导致 OOM
1 个赞