求助：数据手工维护后错误

[manuel76413]

因插入数据时，文件名多了路径部分，然后我自己调用rename接口做了全数据扫描和重命名。

现在问题是文件名正确了，但是这个数据库从此就无法插入新数据了，尽管在网页上添加文件显示成功，但是查找又不存在，编程插入也是显示成功，但是随后进行查询就没有该记录。

数据量超过1亿7千万条了，急求解决办法。。。

[donnie4w]

你好 @manuel76413
我确认一下

1. 你调用 rename 接口之前，其他操作都是没有问题的，对吗？
2. rename接口做了全数据扫描和重命名，是不是高并发进行的？
3. 旧数据无法访问，但是路径存在，能不能尝试把路径raname回去看一下？rename一部分即可

[manuel76413]

是的，做了批量高并发的rename，针对rename的目标名称已经存在的记录，进行了删除。
现在从网页看rename成功，都是符合要求的，然后测试插入新的单个文件，网页提示信息是成功，但是插入后，查询不到

[manuel76413]

你好 @manuel76413 我确认一下

1. 你调用 rename 接口之前，其他操作都是没有问题的，对吗？
   是的，rename之前，都是正确的
2. rename接口做了全数据扫描和重命名，是不是高并发进行的？
   是的因为数量太大，高并发进行的
3. 旧数据无法访问，但是路径存在，能不能尝试把路径raname回去看一下？rename一部分即可
   数据能访问，通过rename后的文件名，可以获取到数据。

问题是这个数据库再也无法插入新数据了

[donnie4w]

@manuel76413

好的。目前还不清楚是聚合文件错误还是leveldb文件错误，可以尝试一下：

1. 不知道你设置的聚合文件大小是多少。比如说你设置了1G，现在的文件可能还没有达到1G，比如目前的聚合文件大小是700M，你可以修改一下配置，比如修改为700M，让wfs重新生成一个新的聚合文件，看能不能解决问题，如果可以则说明应该是聚合文件错误了。如果不行，可能是leveldb文件错误。

2. leveldb文件错误，则需要导出元数据。这里有导出元数据的方法 https://tlnet.top/wfsdoc
   把元数据导出后，重新启动新的wfs服务，把聚合文件拷贝过去，把备份的元数据导入新的wfs服务。应该可以解决leveldb文件错误的问题。

[manuel76413]

我每个文件大部分在10KB~300KB，数量1亿多条，聚合文件大小设置的4GB。大量小文件处理很费时间，wfs已经很好，我不知道这是怎么个问题，leveldb有没有检查和repair的功能。数据量太大了，扫描一遍都很长时间

[donnie4w]

@manuel76413
现在要先定位是哪里出现问题，我想先排除inode用完和磁盘空间不足的问题，
按照leveldb的版本策略，你rename时，实际上新数据并不会马上覆盖旧数据，而是新增版本数据，所以在高并发写入情况下，这可能导致生成大量的小文件，数据也可能短期内激增；小文件会在后期合并；但是短期可能还会存在。你可以在wfsdb文件夹下查询到这些数据文件。
你可以先查询一下inode和磁盘的使用情况，排除系统资源问题。定位问题应该是出现在wfs本身，再解决是数据文件的问题或者是leveldb文件的问题。

[manuel76413]

找了个leveldb_viewer看数据，发现有问题自动修复，然而把数据搞没了，现在用wfs挂载上去，网页总数不显示，数据table不显示了。这下朝坏的方向了，这个leveldb_viewer会把我们wfsdb目录中的.ldb文件删除，现在只留下wfsfile文件夹中的聚合文件是没动过的，还能恢复吗？

[manuel76413]

@donnie4w 问下swf能升级吗，比如存储使用rocksdb

[donnie4w]

@manuel76413
所有的.ldb文件都被删除了？
元数据丢失的话，只有聚合文件就很难完整恢复，文件是可以从聚合文件中恢复出来的，只是它们的路径信息就丢失了，除非你还有其他地方记录了文件的信息，比如文件大小或文件指纹，可以通过文件大小或文件指纹来对应文件路径与文件数据。

前面有一些排查的建议，不知道你是否有排查。是否可以排除系统资源inode与磁盘的问题。
实际上换成rocksdb，在高并发修改数据时，同样可能出现类似的问题。高并发写入的情况下，如果写入速度超过了文件合并的处理能力，一样会导致大量的小文件积累。

建议对元数据进行增量备份，避免类似的问题发生。在https://tlnet.top/wfsdoc的数据导出中有相关的命令。

[manuel76413]

@donnie4w 感谢指导，本来想用网上找的leveldb_viewer看数据，结果把我wfsdb目录中.ldb文件全部删除，还写了新数据。现在估计不可逆了。我原数据采用磁盘分目录存储的，数据大小是1亿7千万条，重建有没有好的建议？最好能快速稳定的建好，并能用wfs管起来

[donnie4w]

@manuel76413
如果绕过接口可以快速的把原数据搬运到wfs中，这样会高效很多， 但是当前版本并没有提供相关的命令。
当前版本由于需要建立元数据与聚合文件的对应关系，数据存放到wfs还是需要走接口的。
通过你遇到的问题，当前版本在rename与delete时没有限制吞吐量，也是个问题。需要在新版本修正。

[manuel76413]

今天出现第2次不能插入新数据了，上次我没办法，后来重做了数据，
这次数据我直接写库的，也没有其他备份，有办法修复吗？

在使用了两个不同exe读写了数据库情况下，该问题可复现，导致不能再写入错误。。。
经检测leveldb数据库貌似好的，大概率就不能写入到wfsfile，使用碎片整理，无效！

[donnie4w]

你好@manuel76413
我了解一下：
你意思是你通过第三方工具读写了wfsdb中的ldb数据，导致数据无法再写入？
还是正常操作下，wfs自身bug导致无法再写入？
目前wfs能不能正常读数据？
不知道你是否事先备份了元数据？

[manuel76413]

是的，第三方工具读写了wfsdb中的数据，然后导致数据无法再写入
现在wfs能正常读数据，在web页面上操作写入小文件也报告成功，但是用search检查却没有找到实际插入的数据。
我小文件数据量太大，这次又忘记备份元数据了
我急求修复方法，让wfs能继续正确读写。有办法调试吗，解决这个偶发但能复现的拒绝写入的问题

[donnie4w]

@manuel76413
两次的问题发生的情况不同。
之前的情况无法定位是哪的问题；这次由于你直接操作了数据库文件，可能是leveldb的文件被修改导致。
我暂时没有想到快速修复的方法；我建议导出元数据，新建一个新的wfs服务，把元数据导出新服务，再把聚合文件夹wfsfile拷贝到新服务。
你的数据库庞大，导出2亿左右的数据可能时间会比较长，全量导出可能要预留出1-2小时左右的时间。

导出元数据

./linux107_wfs  -s export  -p   /usr/local/wfs1/wfsdata  -o   /usr/local/data/meta001

导入元数据

./linux107_wfs  -s import  -p   /usr/local/wfs2/wfsdata  -o  /usr/local/data/meta001