This article discusses the unexpected side-effects of recreating dropped tables with the same name and the workaround if it is necessary in your case to recreate tables.
Customers who have previously dropped a table and recreated it with the same name reported various issues including:
- old data not being deleted, i.e. data from previous version of the table reappeared in queries,
- read timeouts,
- table queries returned
- failed table compactions.
Recreating tables with the same name has been discouraged for a long time and is due to a known bug in [CASSANDRA-5202] that is not resolved until Apache Cassandra version 2.1.
The issue is that Cassandra keeps track of the table names internally even after the table is dropped. When a new table is created with the same name, Cassandra associates the table with the old reference ID and so continues to access the old SSTables on disk, e.g. returns deleted rows (tombstones) during reads.
The preferred way for dealing with this is to simply truncate the tables instead of dropping then recreating.
If you must re-use table names, then do so using these steps:
Step 1 - Run
nodetool flush -- <keyspace> <table> on all nodes.
Step 2 -
DROP the table.
Step 3 - Truncate the
system.hints table on all nodes to prevent replay failures.
Step 4 - Run
nodetool flush -- <keyspace> <table> on all nodes again.
Step 5 - On each node, ensure all SSTables relating to
<table> are removed from the filesystem, otherwise delete the files manually.
NOTE: By default, snapshots are created when tables are dropped or truncated. This will need to be cleaned out manually to reclaim disk space.
Step 6 - On each node, run
nodetool invalidatekeycache to remove all references to the dropped table.
Step 7 - Create the table as usual.
As above, simply truncate the tables instead of dropping then recreating them.
Otherwise, upgrade to a DataStax Enterprise version which has Cassandra 2.1.x or above.