Yes, you are right about it, we are not facing any issues while restoring data in 3.11.4. This is only happening with 3.11.2
For backup we are using following steps 1) running nodetool snapshot command on all nodes at once 2) while cluster is backup mode we take the EBS snapshot backup of that volume 3) running the nodetool clearsnapshot for existing the backup mode. While restoring we are using the following steps 1) Creating volume from snapshot 2) Attaching those volume to DR instances 3) in cassandra.yaml we are passing the token range for each instance. On Mon, Dec 2, 2024 at 11:33 AM guo Maxwell <cclive1...@gmail.com> wrote: > Hello, > You mean 3.11.2 will have the problem of backup data loss, but 3.11.4 will > not have this problem, right? > > Can you provide the backup and recovery steps for these two versions? If > possible, it would be better to give a few examples. > For example, if three data a, b, and c are inserted, and a will be lost in > 3.11.2 but this situation will not happen again in 3.11.4. > > I believe more information can help us better understand and solve this > problem. > > Soyal Badkur <soyalbad...@gmail.com> 于2024年12月2日周一 13:43写道： > >> Hi Team, >> >> We are facing issues while restoring Cassandra backup from PROD servers >> to DR servers for Cassandra Version 3.11.2. When we try to read the data >> from both the environments to verify the data backups, we found that in DR >> environment data is not showing as accepted. We have to run the same query >> multiple times in CQLSH to find that data is present in the DR side but >> unable to do so while running the script. But in some cases we find that >> some of the data is lost in DR even though it is present in PROD, without >> any delete query run on PROD side or its TTL is expired(basically we are >> running the script from n-2 days to compare the data). >> >> When we do the same for another cluster which is in 3.11.4 Cassandra >> version we don't face any such issues. Please help us in fixing this issue. >> >> Do let us know if you need any more information from us. >> >> Regards, >> Soyal Badkur >> >
