【TDengine 使用环境】
生产环境 /测试/ Poc/预生产环境
【TDengine 版本】3.3.8.8
【操作系统以及版本】arm ubuntu20.4
【部署方式】docker部署
【集群节点数】1
【集群副本数】1
【描述业务影响】taosd无法正常启动
【问题复现路径/shan】设备异常断电重启后出现
【遇到的问题：问题现象及影响】taosd无法正常启动
报错vgId:2, failed to validate checksum of wal entry header, offse: 1438684, file:/var/lib/taos/vnode/vnode2/wal/00000000000000000.log
【资源配置】
taos.cfg中已经配置walDeleteOnCorruption 1
【报错完整截图】
临时处理：
建库时指定WAL_LEVEL 2 WAL_FSYNC_PERIOD 3000
加上定时flush database <db_name> 会使WAL目录始终处于小文件状态，若不定时flush则是默认到100M自动flush到tsdb目录
这种处理有什么风险性？
WAL有两种控制大小方式，一是按时间 ，由参数WAL_RETENTION_PERIOD控制；二是按大小，由参数 WAL_RETENTION_SIZE控制。建议你用 WAL_RETENTION_SIZE控制大小。
WAL_LEVEL不能控制WAL的保留大小。
WAL_RETENTION_SIZE是128K 但WAL目录会涨到几十M 而且官网文档上描述WAL_RETENTION是为了数据订阅消费 这个和WAL目录大小限制强关联么
先得理解WAL是什么，WAL是数据库redo日志。订阅只是使用了redo日志。
WAL的大小不影响订阅消费，只影响订阅的起始时间，WAL保留的时间越长，订阅可以消费到的历史数据周期越长。
订阅的部分正在了解，不过现状是WAL文件导致断电重启时启动失败，想寻求是否有配置来避免这个问题
目前只能walDeleteOnCorruption 1来缓解，主机异常导致的WAL损坏，不能完全避免。
我在1楼贴的处理是否可用呢，是否有什么风险
设置WAL_LEVEL 2 WAL_FSYNC_PERIOD 3000是指每3秒即将文件系统缓存同步写入WAL数据文件，默认1是异步同步，由系统内置参数控制。
flush database是指将内存数据强制落盘。
所以以上设置并不能控制WAL的大小。WAL的大小只与单位时间写入的数据量有关。
修改WAL_LEVEL为2，会加重磁盘IO，如果数据量大，会影响写入效率。
