Repair doesn’t have a mechanism to drop a table There are some race conditions in schema creation that can cause programmatic schema condition (especially when multiple instances of the app can race) to put things into a bad state.
If this is the problem, you’d want to inspect the cfid in the schema tables and compare it to the ID in the path to the files on disk. If those don’t match, you may need to carefully and slowly update the ID in the schema table, flush, stop the instance, rename the data directory, and start the instance again. This is going to be ugly and error prone and you need to be very careful or you may lose some data doing it - test in a lab first. -- Jeff Jirsa > On May 20, 2019, at 10:43 AM, Oliver Herrmann <o.herrmann...@gmail.com> wrote: > > That's unlikely. We run the repair job from crontab every week when no > application is connected to the cluster. We had the same error for another > table for more than 3 weeks until we recreated it: > > ERROR [AntiEntropyStage:1] 2019-04-13 16:00:18,397 > RepairMessageVerbHandler.java:177 - Table with id > 68795050-47be-11e9-99f8-07a8944f8d3d was dropped during prepare phase of > repair > ERROR [AntiEntropyStage:1] 2019-04-20 16:00:19,199 > RepairMessageVerbHandler.java:177 - Table with id > 68795050-47be-11e9-99f8-07a8944f8d3d was dropped during prepare phase of > repair > ERROR [AntiEntropyStage:1] 2019-04-27 16:00:19,682 > RepairMessageVerbHandler.java:177 - Table with id > 68795050-47be-11e9-99f8-07a8944f8d3d was dropped during prepare phase of > repair > > It looks as the repair is dropping the table. Is this possible? > >> Am Mo., 20. Mai 2019 um 18:20 Uhr schrieb Jeff Jirsa <jji...@gmail.com>: >> Someone issued a drop table statement? >> >> -- >> Jeff Jirsa >> >> >> > On May 20, 2019, at 9:14 AM, Oliver Herrmann <o.herrmann...@gmail.com> >> > wrote: >> > >> > Hi, >> > >> > while we were running 'nodetool repair -full -dcpar' on one node we got >> > the following error: >> > >> > ERROR [AntiEntropyStage:1] 2019-05-18 16:00:04,808 >> > RepairMessageVerbHandler.java:177 - Table with id >> > 5fb6b730-4ec3-11e9-b426-c3afc7dfebf6 was dropped during prepare phase of >> > repair >> > >> > It looks like the table was deleted on that node which led later to schema >> > disagreements when the table was recreated by an application. >> > >> > What could be the reason that the table was dropped during the repair? >> > >> > Thanks >> > Oliver >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: user-h...@cassandra.apache.org >>
