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 > >
