After I upgrade Cassandra from 3.11.13 to 4.0.7 in a 3 node Cassandra cluster. Most of tables in the keyspace used the existing table IDs and directories. But one table of this keyspace didn't use the existing table ID and directory of 3.11.13, a new table ID and directory was used after upgrade. I checked two table directories, there are data files in both these two table directories in all the 3 pods. Any idea about why this happen? How to avoid it or work around it?
3
-
Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.– Community BotCommented Mar 16, 2023 at 7:37
-
I'd be curious to know if that table name had any special characters in it; perhaps those are handled differently between the versions?– AaronCommented Mar 23, 2023 at 18:02
-
No special characters in the table name, only letters and "_".– jinguiyingCommented Apr 7, 2023 at 13:50
Add a comment
|
1 Answer
The symptoms you described indicate that someone tried to recreate the table so a newer version now exists.
Now I would expect that you would say "no one did it" but it happened, you just aren't aware of it.
It is possible to work out which version is newer from the table ID which is in fact a version 1 UUID meaning it's a UUID with a timestamp embedded in it.
For example, a directory name users-6140f420a4a411ea9212efde68e7dd4b has the UUID:
6140f420-a4a4-11ea-9212-efde68e7dd4b
You can extract the timestamp from this UUID easily by using any free UUID extractor/converter online. In this case, this UUID has the equivalent timestamp of:
02 June 2020 7:40:50 AM GMT
You can do the same for the new directory on your node and use the data to work out who could've done it.
In any case, you can force Cassandra to load the SSTables from the old directory by running the following command:
$ nodetool import ks_name table_name /full/path/to/ks_name/old_table_dir
Cheers!
answered Apr 13, 2023 at 11:08
