【 使用环境 】生产环境
【 OB or 其他组件 】ob
【 使用版本 】4.3.3
【问题描述】
年后准备升级oceanbase集群。在生产实践中发现，大内存对于ob的运行效率会有较高的提升。预计部署一个1-1-1的 单机内存1T的集群。
期间产生了一个疑问，ocp的创建租户时，建议分配的日志盘大小为内存的3-4倍。这是为什么？ 如果我只分配 等于甚至小于内存大小的日志盘空间。 会有什么方面的影响
主要是一些长事务可能跨越的时间比较长，这部分的日志如果还在应用或者还未提交，无法自动清理，内存设计的大原因很可能是因为业务量大，可能qps和tps也高，日志产生的也多，如果日志盘很小有可能打爆，影响业务，如果业务量少，日志盘小点也没问题
2 个赞
我有几个集群都是内存256G，日志盘给600G~800G的样子。
有个1T内存的集群也是只给了1T日志盘。
这个取决于你集群的变更是否特别频繁，不是特别频繁就没关系。
可以看看当前日志保留了多久，到日志目录下看看最早的日志时间：
ls -lthr /data/log1/xxx/clog/log_pool/ |head -n10
OceanBase 数据库的 Redo 日志有两个主要作用：
宕机恢复
与大多数主流数据库相同，OceanBase 数据库遵循 WAL（write-ahead logging）原则，在事务提交前将 Redo 日志持久化，保证事务的原子性和持久性（ ACID 中的 “A” 和 “D”）。如果 observer 进程退出或所在的服务器宕机，重启 OBServer 会扫描并回放本地的 Redo 日志用于恢复数据。宕机时未持久化的数据会随着 Redo 日志的回放而重新产生。
多副本数据一致性
OceanBase 数据库采用 Multi-Paxos 协议在多个副本间同步 Redo 日志。对于事务层来说，一次 Redo 日志的写入只有同步到多数派副本上时才能认为成功。而事务的提交需要所有 Redo 日志都成功写入。最终，所有副本都会收到相同的一段 Redo 日志并回放出数据。这就保证了一个成功提交的事务的修改最终会在所有副本上生效并保持一致。Redo 日志在多个副本上的持久化使得 OceanBase 数据库可以提供更强的容灾能力。
Redo 日志：
https://www.oceanbase.com/docs/enterprise-oceanbase-database-cn-10000000000944810
5 个赞
这主要还是得看负载吧，内存配置为1T，系统实际使用的内存变化率如何，参考这个来设置具体的磁盘。
1 个赞
目前集群是512G内存的集群。 日志盘也是512G。 根据你提供的方法。查看到 最早日志时间在2个小时之前。
给memstore分配了15%的内存
查看集群的memstore合并大概30-60分钟转储一次。
当前集群已经正常运行3个月。
这个集群如果升级到1T内存。使用1T磁盘作为日志盘。如果只是避免长事务未提交，可能会导致日志盘被打爆，这样配置应该也是没有问题的
1 个赞
没必要这么机械去参考这个比例关系。
日志级别、是否压缩、归档时间都可能大幅度改变日志的空间占用。
观察三五天，看看磁盘空间每日增长，大概估一下就知道多少合适了。
咱说的好像不是一个东西。 你说的是observer服务日志吧。 我说的是业务日志