OceanBase 数据库风险排查指南

本文介绍了 OceanBase 数据库日常检查涉及的系统配置项、系统变量、物理配置、环境配置以及集群和服务器状态。

适用版本

OceanBase 所有版本

系统配置项

检查集群级别的以下配置项：

• minor_freeze_times：该配置项不可配置为 0，对于不同的集群该配置项的值会有差异，为避免频繁合并，可能会配置为 100 或更大的值。OceanBase V2.2.X 及后续版本中新增的 major_compact_trigger 配置项用于控制 L0 层转储的次数，与 minor_freeze_times 是等价的。

• merge_thread_count：该配置项默认为 0，表示自适应服务器的硬件规格。对于 64C 的服务器，推荐配置为 10。如果集群需要加快合并速度，可以将改配置项设置为较大的值，但不能超过 50。 特别地，对于 Docker 环境，如果一台服务器上部署两个 Docker，建议将该配置项设置为 5。

• minor_merge_concurrency：该配置项默认为 0，表示自适应服务器的硬件规格。对于 64C 的服务器，推荐配置为 10。但由于 Minor Merge 可能造成业务抖动，此时可以将该配置项设置为更小的值。

• memstore_limit_percentage：该配置项默认值为 50，一般不需要修改。

• freeze_trigger_percentage：该配置项默认值为 70，如果集群中有 OBServer 内存使用过大，可以将该配置项设置为较小的值，但这也意味着转储会更加频繁。

• system_memory：OceanBase 数据库 V2.1.X 及后续版本中表示为 Server 租户（租户 id 为 500 的租户）预留的内存，默认为 30 GB，对于生产环境，建议将配置项设置为 50 GB 或以上。 对于历史库等磁盘使用量大的业务，宏块的元数据会占用几十 GB 的存储空间，因此这种场景下建议将该配置项设置为 60 GB。

• system_memory_limit：OceanBase 数据库 V1.4.X 及 V2.0 版本中表示为 Server 租户留的内存的百分比，因此对于不同规格的服务器，Server 租户的内存可能不同。该配置项在 OceanBase 数据库后续的版本中已经废弃。

• memory_limit_percentage：表示 observer 进程可以使用的内存上限，默认为 80。表示将操作系统剩余的 20% 内存预留给了操作系统。对于大内存机器，这个配置可以调整为 90 或 95。

• max_stale_time_for_weak_consistency：表示备集群允许落后的时间，默认是 5s。如果存在日志不同步的场景（异常恢复），或者业务可以接受更大的数据延迟，可以将该配置项修改为 1m 或更大的值。

• syslog_io_bandwidth_limit：表示写入 observer.log 日志每秒的流量限制，推荐配置为 30M 或更低。如果物理服务器 observer.log 日志所在的磁盘 I/O 性能较差，可以将该配置项修改为为 1M，避免业务抖动。

• sys_bkgd_io_high_percentage 与 sys_bkgd_io_low_percentage：为避免转储和合并的 I/O 流会影响业务请求，OceanBase 数据库对 I/O 进行了限速，这两个配置项的默认值分别是 90 与 70，一般不建议修改。转储与合并慢的场景，可以按需要对这两个配置项进行调整。

• enable_merge_by_turn：大部分场景保持默认值 TRUE 即可，表示开启在不同 Zone 的轮转合并，避免合并时的 RT（Response Time）变高。对于外部业务，可以将该配置项设置为 FALSE，表示不同的 Zone 同时进行合并。

• enable_manual_merge：默认为 FALSE，表示定时或内存达到阈值后自动触发合并。将该配置项修改为 TRUE 的集群表示合并不会自动触发，开启手动合并。在进行故障排查时，可以关闭自动合并。

• trace_log_slow_query_watermark：该配置项默认值为 100ms，在压力大时导致产生大量日志，会影响数据库的性能，一般场景下建议配置为 1s。

• large_query_threshold：执行时间大于该配置项指定值的查询会被 OceanBase 数据库认为是大查询，默认为 100ms，一般场景下建议配置为 5s。

• resource_hard_limit 与 resource_soft_limit：一般场景下建议保持默认值 100。

系统变量

检查以下系统变量：

• ob_timestamp_service：是否开启 GTS（Global TimeStamp，全局时间戳），不推荐将该配置项修改为 LTS（Local TimeStamp，本地时间戳）。

• ob_query_timeout：查询超时时间，建议保持默认值 10s。

• ob_trx_timeout：事务超时时间。建议保持默认值 100s。

• recyclebin：是否开启回收站功能，默认为 on 表示开启回收站。对于分区较多的环境，建议关闭回收站。

• explicit_defaults_for_timestamp：用于指定 Timestamp 数据类型在处理默认值和空值时是否启用非标准行为，该变量必须为 on。

• max_allowed_packet：用于设置最大网络包大小，建议设置为 4M 或 16M。

• ob_sql_work_area_percentage：用于 SQL 执行的租户内存百分比限制。如果有复杂 SQL 或 Batch SQL，有可能需要改大默认值 5，一般不建议修改。

• undo_retention：是否开启多版本转储。该配置项用于设置系统应保留的多版本数据范围，单位为秒，在转储时控制多版本数据的回收。在 OceanBase 数据库 V3.2.2 版本及以上，默认值为 1800；在 OceanBase 数据库 V3.2.2 版本以下，默认值为 0。有关该配置项的详细信息，参见 undo_retention。

  注意

  修改该参数会影响磁盘空间，请谨慎修改。

• _optimizer_adaptive_cursor_sharing：是否开启 ACS 自适应游标共享，不建议开启该变量。

• sys_unit_config：sys 租户内存规格，默认是 32G，不建议设置为更小的值。

物理机配置

物理机配置应满足以下条件：

• CPU 与内存大小：对于 OceanBase V2.2 及更早的版本，单机器不能低于 16C64G。

• Redo Log 与 SSTable 盘大小：Redo Log 盘的大小要保证能够容纳 MEMTable。

• observer.log 日志盘大小：不能与 Redo Log 所在的盘共用。

环境配置

物理机操作系统应检查以下内容：

• NTP 时钟同步。

• 网络重传率、丢包率为零。

• 磁盘 I/O Latency 是否过高。

• 关闭 HugePage 与 TransparentHugePage。

集群部署

检查集群的以下信息：

• 每个 Zone 都要有 sys 租户的副本，可以是 R 副本。

• 排查每个 Zone 合并一轮的时间，所有 Zone 合并完一轮总的时间，是否存在合并超时的情况。

• 是否有异地部署，可以通过查询 __all_zone 表中各 Zone 的 Region 信息设置是否正确，是否有跨城提交事务的租户。

• Zone 个数以及每个 Zone 中 OBServer 的个数。要求 Zone 的数量大于 3 台，每个 Zone 中至少有一台状态为 ACTIVE 的 OBServer。

• RootService 是否是独立部署，独立部署的往往是一个小规格的 docker，排查 CPU 曲线。

• 检查每个 OBServer 上租户个数，不建议超过 50。

• 租户的 CPU 与内存规格，小内存规格（5G甚至更低）的需要特别关注，CPU 至少为 0.5 或 1.0，租户可以创建的分区数是否已经达到内存上限。

• 每个 OBServer 上分区数，集群总的分区数。

  单台 OBServer 的分区数不能超过 50000，并且单个表中的分区数不能超过该兼容模式下最大的分区数。对于不同的兼容模式，分区表的上限如下表所示：

  兼容模式	分区上限
  MySQL 模式	8192
  Oracle 模式	65536

• 集群中表的个数与租户的表的个数。

  OceanBase 数据库中没有对租户与表的个数做出限制，但租户与表的数量越多，对数据库整体的性能影响越大。

• 租户的数据副本除了 F 副本，是否有 R 和 L 副本，有 R 和 L 副本的可以关注下它们的资源规格：

  • L 副本最少 2 GB。

  • F 与 R 副本最少 5 GB。

• 租户的 Primary Zone 设置不建议有同等优先级的，建议用分号区分优先级。

• 只有 OceanBase 数据库 V1.4 版本支持只读 Zone，不推荐使用该功能。

服务器状态

搜索 dump tenant 日志，查看是否有请求堆积、worker 泄漏等问题：

• 通过 top 命令查看 observer 进程使用的内存与 OBServer 自身的统计的是否一致

• 搜索 "tenant: 500" 看 Server 租户内存使用情况，是否跟虚拟表统计的不一致，其他租户内存使用情况的方法类似

• 通过 top 命令查看 CPU 使用率，包括系统态使用率，如果超过10%，说明机器存在问题。

• 机器负载情况。