【问题详细描述】
问题场景：
1、从节点单文件达到2TB，达到了EXT3文件系统的限制，所以一直在报 write(), error= -27 （Invalid record）的错误，所以从节点的replay操作失败，一直不断的尝试之前的操作（INSERT）
2、这种情况下，做了一个dropCS()的操作，dropCS()成功了
3、分别连接主节点和从节点用SDB_SNAP_COLLECTIONSPACES去查，主节点上已经看不到对应的CS信息，但从节点上还能看到被删除的CS的信息
4、分别连接主节点和从节点的目录下查看数据文件，发现只有主节点的数据文件被删除了，从节点没有删除掉，并且还在报errno=27的错误
5、详细状态描述：
1）主节点上已经没有其它数据了，只剩SYSTEMP
2）第一个从节点上，还留有刚dropCS后的CS对应的文件，没有其它文件了
3）第二个从节点上，除了刚dropCS后的CS对应的文件，还有好多其它的文件，总大小大概600~700GB。
问题：
1、通过场景发现dropCS命令删除CS从节点是通过同步主节点日志删掉的，这里应该是一个异步删除？
2、现在如何解除这种卡死状态呢，从节点extend storage操作一直失败，如何跳出这种状态呢？
3、如果手工停掉从节点，删除CS对应的.data和.idx文件，然后启动从节点，可行吗？
【解决办法】
问题分析：
1、根据从节点一直在不断尝试之前的insert操作（因为达到ext3的限制，所以extend storage不成功）可以看出，从节点在同步主节点的insert操作，并卡死在这一步
2、当主节点dropCS后，而从节点没有真正的执行说明它们之间是异步执行的，通过日志同步，所以问题1是异步删除的
3、而从节点没有执行dropCS的原因就是因为在同步主节点在dropCS之前的insert的操作时一直不成功卡死在这步导致的
4、并且从详细状态中可以看出用户之前做过很多次dropCS操作，但是在第二个从节点上都没有执行成功，原因可能大致与本次dropCS相同
解决办法：
1、dropCS时从节点是通过同步日志异步删除
2、因为主节点上没有其他任何数据，所以可以直接按照下面执行：
1）停掉从节点
2）删除数据和日志文件（包括replication里的日志）
3）重启从节点
【参考链接】
错误码
常见错误处理指南
