【TDengine 使用环境】
测试环境
【TDengine 版本】
3.3.7.5、3.3.8.4
【操作系统以及版本】
Ubuntu22.04
【部署方式】容器/非容器部署
Docker
【集群节点数】
非集群
【描述业务影响】
我们生产环境经常会遇到设备断电，在之前使用3.2.3.0版本未出现过断电重启TDengine数据异常问题，现在由于需要使用双主键的特性，不得不升级到3.3.0.0以上版本，但是看起来似乎3.3.x.x版本后只要断电重启，就容易出现wal文件异常问题，导致重启后数据库无法正常使用。
【问题复现路径/shan】做过哪些操作出现的问题
设备断电
【遇到的问题：问题现象及影响】
设备断电重启后TDengine容器异常，无法连接数据库
【资源配置】
【报错完整截图】（不要大段的粘贴报错代码，论坛直接看报错代码不直观）
wal warn vgid:5 fialed to validate checksum of wal entry header, ....
我们生产环境意外断电经常也是 wal 损坏 ，也是被这个问题折磨疯了 
，最麻烦的点是主要是没办法自动恢复要人工干预
是的，也是通过删除WAL文件吗？请问你们使用的是什么版本。
我们之前使用3230版本并不会出现这个问题
同样出现这个问题，希望能帮忙解决这个问题
之前做过掉电测试，wal 有概率损坏，是由于即使我们调用了fsync ，但是由于操作系统的优化，仍然会导致数据丢失一部分。如果是单副本的话，数据丢失是无法避免的。
我们目前在开发一个启动参数可以在启动时删除损坏的 wal 文件，但同时也会造成一些数据丢失。您有什么好的建议，也可以提给我们。
目前我们生产环境也只能人工手动删除 ，由于不能自动重启 导致丢了半个月数据 。
大佬 能否舍弃部分性能 直接写入 ，只要断电能够重启就行 如何进行配置
目前 wal 等级是什么？1 or 2?
目前采用的是默认值 wal = 1
感谢大佬的回复。
我们可以接受数据上的丢失换来程序的稳定性，当然了只是丢失数据而不是丢失表结构，有出现过删除wal文件后超级表丢失的情况
开到2会好些。具体的可以去看下官网。
您说的对，就是因为我们的 wal 同时保存了数据和表结构的修改。如果跳过某一条损坏的 wal 可能会发生级联的写入错误，所以如果想快速启动，删除整个 wal 目录是最有效的。
这部分我们在考虑优化，减少数据丢失，但是改造比较大，一时半会儿还做不完。
ALTER DATABASE sss WAL_LEVEL 2 WAL_FSYNC_PERIOD 0;
大佬 请问一下如果改成这样是不是就不会产生wal 直接落盘 ，性能上可能会差很很多是这样吗
还是会产生 wal 只不过每次写入 wal 都会调用一次 fsync 性能差很多。
大佬 那有什么办法能保证断电 wal 不损坏吗 ，只求断电能够自动恢复 … 
可以接收数据丢失吗？
嗯 能够接受数据丢失一部分
稍后的版本会开放一个选项，开启后，可以自动恢复。
好的 感谢，大佬回复
