OceanBase 数据库的 Redo 日志有两个主要作用：
- 宕机恢复
- 多副本数据一致性
与大多数主流数据库相同，OceanBase 数据库遵循 WAL（write-ahead logging）原则，在事务提交前将 Redo 日志持久化，保证事务的原子性和持久性（ ACID 中的 "A" 和"D"）。如果 observer 进程退出或所在的服务器宕机，重启 OBServer 会扫描并回放本地的 Redo 日志用于恢复数据。宕机时未持久化的数据会随着 Redo 日志的回放而重新产生。
OceanBase 数据库采用 Multi-Paxos 协议在多个副本间同步 Redo 日志。对于事务层来说，一次 Redo 日志的写入只有同步到多数派副本上时才能认为成功。而事务的提交需要所有 Redo 日志都成功写入。最终，所有副本都会收到相同的一段 Redo 日志并回放出数据。这就保证了一个成功提交的事务的修改最终会在所有副本上生效并保持一致。Redo 日志在多个副本上的持久化使得 OceanBase 数据库可以提供更强的容灾能力。
OceanBase 数据库的 Redo 日志文件包含如下两种类型：
- Clog
- ilog
全称 Commit log，用于记录 Redo 日志的日志内容，位于 store/clog 目录下，文件编号从 1 开始并连续递增，文件 ID 不会复用，单个日志文件的大小为 64 MB。这些日志文件记录数据库中的数据所做的更改操作，提供数据持久性保证。
全称 index log，用于记录相同分区相同 Log ID 的已经形成多数派日志的 Commit log 的位置信息。位于 store/ilog 目录下，文件编号从 1 开始并连续递增，文件 ID 不会复用，单个日志文件的大小非定长。这个目录下的日志文件是 Clog 的索引，本质上是对日志管理的一种优化，ilog 文件删除不会影响数据持久性，但可能会影响系统的恢复时间。 ilog 文件和 Clog 文件没有对应关系，由于 ilog 针对单条日志记录的内容会比 Clog 少很多，因此一般场景下 ilog 文件数目也比 Clog 文件数目少很多。
OceanBase 数据库的日志回收策略中对用户可见的配置项有 2 个：
- clog_disk_usage_limit_percentage
该配置项用于控制 Clog 或 ilog 磁盘空间的使用上限，默认值为 95 ，表示允许 Clog 或 ilog 使用的磁盘空间占总磁盘空间的百分比。这是一个刚性的限制，超过此值后该 OBServer 不再允许任何新事务的写入，同时不允许接收其他 OBServer 同步的日志。对外表现是所有访问此 OBServer 的读写事务报 "transaction needs rollback" 的错误。
- clog_disk_utilization_threshold
该配置项用于控制 Clog 或 ilog 磁盘的复用下限。在系统工作正常时，Clog 或 ilog 会在此水位开始复用最老的日志文件，默认值是 Clog 或 ilog 独立磁盘空间的 80%，不可修改。因此，正常运行的情况下，Clog 或 ilog 磁盘空间占用不会超过 80%，超过则会报 "clog disk is almost full" 的错误，提醒 DBA 处理。
