问题现象
在 OceanBase 数据库 V4.x 版本集群中执行全量备份（ALTER SYSTEM BACKUP DATABASE），目标介质为对象存储（S3-compatible Object Storage）。
备份速度： 始终维持在 ≈ 300 MB/s，远低于集群到存储之间的千兆/万兆带宽理论上限值。
分区数较少且数据量也较少（单库约 10000 个分区）。将备份并发度从默认
2提升到16后，整体吞吐有提升，但继续增加并发去后，整体吞吐无明显提升。从 observer.log 中可见大量耗时日志信息，如下。
[T1008_BACKUP_DA][errcode=0] access object storage cost too much time: pwrite ... cost_ts=379461 µs统计：平均写 10 MB 数据 ≈ 400 ms。
关键信息
| 分类 | 关键信息 | 说明 |
|---|---|---|
| 参数 | ha_low_thread_score = 16 | 手动调高后无效 |
| 日志 | access object storage cost too much time | 单次写 10 MB 延迟 300–600 ms |
| 指标 | backup_write_speed* ≈ 300 MB/s | 明显低于带宽能力 |
| 环境 | MinIO 或其他 S3 兼容的对象存储 | 小对象写入延迟高 |
问题原因
Backup 文件聚合机制。 OceanBase 数据库 V4.x 版本中备份框架依旧先将分区数据聚合到到一定的
buffer size后然后落盘。数据量过少且分区数量过少时，提升备份并发度亦难以线性增加写线程。介质写入 RTT 过高。
日志提示
access object storage cost too much time，说明对象存储后端写入延迟过大。经测试小对象（≈10 MB）写入延迟 300–600 ms，成为性能瓶颈。
结论： 在此场景中，备份介质 IO 性能问题，而非 OceanBase 端并发度决定整体吞吐。
问题的风险及影响
备份窗口延长： 300 MB/s 备份 10 TB 数据需 ≈ 9 h，易与业务峰值重叠。
恢复点暴露增大：
RPO/RTO难以满足严格SLA。资源浪费： 过度并发占用 OBServer 线程与网络，收益微弱。
适用版本
OceanBase 数据库 V4.x 版本。
解决方法
| 步骤 | 操作 | 目标 |
|---|---|---|
| 1 | 切换高性能介质： 将备份目标改为高性能对象存储桶 | 立刻提升写入吞吐 |
| 2 | 调整 backup_data_file_size（V4.x 版本中新增）： 适当减小备份文件聚合大小 | 在分区数和数据量较小情况下能增加并发度来提升备份性能 |
规避方式（长期）
| 方式 | 具体措施 | 效果 |
|---|---|---|
| 升级存储 | 使用SSD / 高性能对象存储桶；验证 10 MB 写 RTT <= 50 ms | 吞吐可提升至 >= 1 GB/s |
