数据盘和日志盘部署同个路径，会有什么问题？

OceanBase 技术问题
#1

@论坛小助手 会造成容量资源不足吗？

2 个赞
#3

根据文档库中的信息，如果将数据盘和日志盘部署在同一个路径上，可能会引发以下问题：

1. 磁盘资源竞争

  • 数据盘（存储 SSTable）和日志盘（存储 CLOG，即事务日志）在同一块磁盘上时，由于磁盘硬件资源的竞争，可能导致以下风险：
    • 当事务日志（CLOG）空间利用率超过 [log_disk_utilization_threshold] 值（默认 80%）时会开始回收，超过 [log_disk_utilization_limit_threshold] 值（默认 95%）时节点会停止写入。
    • 在进行转储、合并等操作需要额外的 I/O 资源时，业务读写的 I/O 可能会互相影响，造成业务抖动。
    • 影响 obcdc 同步，导致同步数据变慢。
      （依据：片段标题《OceanBase 数据库性能的影响因素 → 资源分配 → 磁盘划分》）

2. 容量资源不足的风险

  • 如果数据盘和日志盘共用同一块磁盘，在 OceanBase 数据库 V4.0 版本中，系统会根据配置项 log_disk_size 和 log_disk_percentage 来分配日志盘空间。若未正确配置这些参数，可能会导致磁盘空间分配不合理，从而引发容量不足的问题。
  • 默认情况下，当数据和 CLOG 同盘时，数据占用磁盘的 60%，CLOG 占用磁盘的 30%。如果磁盘总空间较小或业务写入量较大，可能会迅速耗尽磁盘空间，进而导致系统无法正常运行。
    （依据：片段标题《BootStrap → 磁盘空间不足（错误码 -4290）》）

3. 性能下降

  • 数据盘和日志盘在同一路径下，I/O 操作会相互干扰。例如，事务日志的频繁写入可能与数据文件的读取操作争夺磁盘带宽，从而降低整体性能。

解决建议

为了避免上述问题，推荐如下策略：

  • 分开挂载磁盘：如果资源充足，建议分别挂载三块磁盘，并使用 SSD 存储，分别存放系统日志、事务日志和数据文件。
  • 合理配置磁盘空间：对于同盘部署的情况，需正确设置 log_disk_size 或 log_disk_percentage 参数，确保日志盘和数据盘的空间分配合理。
  • 开启日志限流功能：通过限制系统日志所能占用的磁盘 I/O 带宽上限，减少对业务的影响。示例代码如下：
    alter system set syslog_io_bandwidth_limit='10M';
  • 启用日志回收功能：通过设置最大文件数量来控制日志文件的增长。示例代码如下：
    alter system set enable_syslog_recycle = true;
alter system set max_syslog_file_count = 1000;

综上所述，数据盘和日志盘部署在同一个路径上确实可能导致容量资源不足以及性能下降等问题，因此建议尽量分开部署以优化系统性能和稳定性。

检索到的文档如下:

  1. OceanBase 数据库性能的影响因素
  2. 在您开始前
  3. 日志流和副本概述
  4. 内存管理概述
  5. BootStrap
  6. 配置磁盘数据文件的动态扩容
  7. 集群管理 FAQ
  8. OceanBase 数据库整体架构
  9. 转储
6 个赞
#4

为什么你可以艾特的？我之前想艾特不行 :face_holding_back_tears:

7 个赞
#5

我寻思，IO必然会受到很大影响，按之前Oracle的实践

6 个赞
#6

先不说太深入的东西，从表面上去想，一锅端了咋整？？

5 个赞
#7

应该是对硬件读写速率有影响

4 个赞
#8

测试环境是可以放一起的。
生产环境建议分开，在并发高的情况下，先由redo接住，之后才数据才落盘，数据整理。

4 个赞
#9

我一开始也不行，后面就可以了

1 个赞
#10

:clap: :clap: :clap:

1 个赞
#11

您的描述比较模糊，为了更好地帮助您，请提供更详细的背景信息或具体的操作场景。例如：

  1. 您提到的“一开始不行，后面可以了”是指哪方面的操作？是部署 OceanBase 集群、执行 SQL 语句、还是其他管理操作（如通过 OCP 或 obd 进行集群管理）？
  2. 是否遇到了具体的错误信息或异常现象？如果有，请提供相关的错误码或日志内容。
  3. 您的操作环境是什么？包括但不限于操作系统版本、OceanBase 的版本（社区版的具体版本号）、硬件配置等。
  4. 如果是 SQL 相关的问题，请提供执行的 SQL 语句以及表结构（如果涉及特定表）。

根据您目前的描述，可能的情况包括：

  • 网络问题：如果是集群初始化或者连接相关的问题，可能是由于网络不稳定导致初次尝试失败，后续重试时网络恢复正常。
  • 资源竞争：在高负载环境下，某些操作可能会因为资源不足而失败，但随着系统负载降低，后续尝试成功。
  • 缓存机制：某些查询或操作可能依赖于缓存（如 OBProxy 的缓存），首次执行时需要加载数据到内存中，因此较慢或失败，后续执行则更快。

如果您能提供更多细节，我可以基于文档库中的信息为您提供更准确的解答。如果当前信息不足以定位问题，建议参考文档片段《遇到问题如何向技术支持同学提问 → 重现步骤》中的建议，提供问题发生的详细步骤以便进一步分析。

如果暂时无法提供更多细节，也可以告诉我具体的操作类型（如部署、查询优化、错误排查等），我将根据已有信息尽量给出可能的解释。

具体信息可参考以下文档:

  1. 遇到问题如何向技术支持同学提问
  2. 连接次序
  3. 4000 ~ 4499
  4. enable_one_phase_commit
  5. 并行执行问题诊断
  6. Switchover 或 Failover 相关问题

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

#12

哈哈确实

#13

空间会不够用

#14

好的，感谢指导

1 个赞
#15

总有一天你会遇到抠门的客户，只给你200G的空间，部署一个测试环境给他做功能验证~~哈哈 :joy:

1 个赞
#16

确实哈哈

#17

其实可以理解为数据和日志同时往一块盘/一个分区里写，极端一些，数据并发量大了，会有IO争用，把磁盘io吃满了，就该吃内存缓存了，然后就会有等待事件啥的，所以，如果你用的是存储，IO能力强，会撑的久一些，单块磁盘能力差出问题就很早。

1 个赞
#18

学到了，感谢指导