EC2图像从AMI备份还原后，无尽损坏的Sstable
Cassandra版本3.11.4，在System.log中显示了许多损坏的Sstable文件，服务重新启动后，我们尝试使用AMI备份来还原EC2服务器，但是损坏的消息也显示了，我们尝试了所有内容，无论Nodetool scrub，sstablescrub，sstablescrub，sstablescrub，sstablescrub，删除损坏的文件然后维修，似乎损坏的文件不会停止出现。
以前有人遇到过吗？任何帮助都将非常感谢。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不能仅仅通过从AMI备份中恢复来恢复Cassandra节点，因为与运行时相比，它将具有不同的数据库状态。
如果您的数据存储在EBS上，则可以替换EC2实例，然后将EBS安装到相同的Cassandra
data/目录中，因此节点将以在EBS卷上持续存在的同一状态开始。如果您无法使用上述方法，则需要使用
repents_addressoption 。干杯!You can't simply restore a Cassandra node by recovering from an AMI backup because it will have a different database state compared to when it was running.
If your data is stored on EBS, you can replace the EC2 instance then mount the EBS to the same Cassandra
data/directory so the node will start in the same state that is persisted on the EBS volume.If the above method isn't available to you, you will need to replace the node "with itself" using the
replace_addressoption documented here. Cheers!