GridDB集群同步出现SYNC_LOG_NOT_FOUND ERROR 20021的解决咨询

问题描述 #

使用GridDB管理5节点分布式集群，节点间数据同步时频繁触发20021 SYNC_LOG_NOT_FOUND ERROR。错误提示该问题由checkpoint执行时删除同步所需日志或数据文件导致，集群虽会自动重试，但同步耗时显著增加。

环境配置 #

Operating System: Ubuntu 20.04
Python Version: 3.8
GridDB Version: 4.5
Cluster Size: 5 nodes
Checkpoint Interval: Default setting
Data Retention Settings: Not explicitly configured

测试用Python代码 #

from griddb_python import StoreFactory, GSException

def configure_cluster():
    try:
        factory = StoreFactory.get_default()
        gridstore = factory.get_store({
            "host": "239.0.0.1",
            "port": 41999,
            "cluster_name": "defaultCluster",
            "username": "admin",
            "password": "admin"
        })

        # Retrieve container for synchronization
        container = gridstore.get_container("containerName")
        if container is None:
            raise Exception("Container not found")

        # Synchronize data across the cluster
        data = container.get(1)
        print(f"Data retrieved: {data}")

        # Perform an update to test sync
        container.put(2, {"id": 2, "value": "newValue"})
        print("Data updated across cluster")

    except GSException as e:
        print(f"Error during cluster sync operation: {e.what()}")
        raise

if __name__ == "__main__":
    configure_cluster()

问题解答 #

1. 如何优化checkpoint配置以减少该错误的频繁出现 #

• 延长checkpoint执行间隔：修改gridstore.conf中的/checkpoint/interval参数，默认通常为15分钟，可调整为30分钟或更长（根据业务写负载灵活调整），给节点足够时间完成同步后再清理日志。
• 设置定时checkpoint：通过/checkpoint/schedule配置指定checkpoint在业务低峰时段执行（如凌晨），避开同步压力大的时段，减少日志被意外删除的概率。
• 启用增量checkpoint：GridDB 4.5支持增量checkpoint，设置/checkpoint/type为INCREMENTAL，仅写入变更数据，减少日志生成量与删除频率，同时缩短checkpoint执行时间。

2. 调整配置中的/dataStore/retainedFileCount是否有助于缓解此问题 #

是，该参数控制GridDB保留的WAL（预写日志）文件数量，默认值可能不足以覆盖慢节点的同步周期。当节点同步速度跟不上checkpoint的日志清理节奏时，就会触发SYNC_LOG_NOT_FOUND ERROR。

• 建议将/dataStore/retainedFileCount从默认的10调整为30-50（根据磁盘空间容量调整），确保慢节点有足够时间完成同步后再删除旧日志。
• 修改后需重启集群节点生效，同时要监控磁盘使用率，避免日志堆积占用过多空间。

3. GridDB集群同步与复制的最佳实践，以避免同步延迟 #

• 合理设置复制因子：根据集群节点数设置replicaCount（5节点集群推荐设为2或3），平衡数据冗余与同步压力。
• 监控同步状态：使用gs_stat工具定期查看节点的syncDelay指标，及时发现同步滞后的节点，排查网络带宽不足、磁盘IO瓶颈等问题。
• 优化网络环境：确保节点间网络低延迟、高带宽，跨机房部署时优先使用专线；关闭不必要的防火墙规则，减少通信损耗。
• 批量操作优化：将频繁的单条读写操作改为批量put/get，降低同步日志生成频率，减轻节点同步压力。
• 分片负载均衡：对容器进行合理分片，将同步负载分散到多个节点，避免单节点承担过多同步任务。

4. 同类问题的解决经验分享 #

• 某电商集群因业务高峰写量突增，默认checkpoint间隔过短导致频繁触发20021错误，调整checkpoint间隔至45分钟，同时将retainedFileCount设为40，错误频率降低90%以上，同步耗时减少60%。
• 部分用户因节点磁盘IO性能差异导致同步滞后，通过更换高性能SSD磁盘，配合增大retainedFileCount确保慢节点能追上同步进度，彻底解决了问题。
• 启用增量checkpoint后，不仅减少了日志删除频率，还大幅缩短了checkpoint执行时间，间接降低了同步日志被提前删除的概率，同步稳定性显著提升。

内容的提问来源于stack exchange，提问作者Samar Mohamed