Clog 滑动窗口（Sliding Window) 满主要分为下面两种情况：
| Clog 滑动窗口满掉场景 | 后果及关键日志 |
|---|---|
| Leader 分区的 Clog 滑动窗口满 | Leader 分区无法再继续分配 log_id给事务层,并且会在 observer.log 中打印 submit log error.*\\-4023 消息。如果 Leader 的 Clog 滑动窗口出现满掉且持续没有自动缓解掉的情况，会导致事务提交无法再将请求放入到 Clog 滑动窗口，导致事务的响应时间（RT）这整体升高的问题。 |
| Follower 分区的 Clog 滑动窗口满 | Follower 分区会暂停接收 Leader 发过来的 Clog，并且会在 observer.log 中打印 check_can_receive_log, now can not recieve log 消息，直至有 Clog 从窗口中滑出。如果长时间的 Follower 节点滑动窗口满掉且没有自动缓解，会影响多数派的 Clog 提交，进而会影响事务提交。如影响了少数派的 Clog 提交，会导致 Follower 节点的 Clog 一直落后。如果 Follower 的 Clog 持续落后那么在其他少数派副本出现故障的时候，会影响该副本不能被有限选举为 Leader 副本。 |
从整体上来说，如果 Clog 滑动窗口满了，会影响 Clog 的持久化的推进。这种情况下，应用端会感受到 slow trans 或者"锁等待"（日志中会出现 -6005 和 lock_for_write conflict.*\-4023）等问题，性能也会受到明显影响。分析的思路有如下几种:
- 分析 Clog 提交写入是否大幅的增长变化，比如系统新上线一个高并发的跑批场景，对 Clog 滑动窗口的并发压力非常大，那么需要先从业务逻辑检查高并发的跑批是否是业务需要的，如果业务允许，可以尝试降低并发测试问题进行缓解。这通常是比较安全且最快得到优化效果的一条路径。
- 如果业务并发并没有突然的激增，但是遇到了该问题，需要诊断 Clog 滑动窗口的滑出是否有瓶颈，比如遇到 Follower 由于转储慢内存不足，日志回放不进内存，有可能导致 Clog 滑动窗口满掉，如果遇到该种场景，需要联系 OceanBase 数据库技术支持进行分析。
- 如果业务并发的提高是必须的，可以选择通过参数
clog_max_unconfirmed_log_count适量调高 Clog 滑动窗口。但是请注意调高 Clog 滑动窗口会导致有更大的内存分配给滑动窗口，并且如果是本身 Clog 的滑出卡主或者并发量过于大，调大clog_max_unconfirmed_log_count有可能只是推迟了问题发生的位点而没有完全的消除瓶颈。 - 打开 Clog 聚合开关：可以通过设置
_clog_aggregation_buffer_amount参数打开 Clog 聚合功能，这个参数定义了用来实现 Clog 聚合的 Buffer 个数，每个 Buffer 的大小是 64KB。 打开 Clog 聚合功能后会将多条 Clog 按规则聚合，优化 Clog 的处理过程。 - 拆分热点分区 由于所有的滑动窗口大小都是以分区为单位设置的，显然数据的热点越集中就越容易把滑动窗口撑满，因此将数据的热点打散到多个表或者分区，可以有效降低滑动窗口满的概率。除了我们经常关注的主表热点分区之外，还要特别关注“全局”索引的热点情况，包括：
- 全局“非分区”索引，索引数据集中在一个分区上；
- 分区键不合适的全局分区索引，比如索引键上的 NDV 过小，或者有严重的数据倾斜（某些键值的记录数过多），也会导致索引数据集中在少量甚至一个分区上。
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
