What exactly persists? I didn't really understand you, could you be more specific?
2017-01-23 15:40 GMT+01:00 Vinci <vi...@protonmail.com>: > Thanks for the response. > > After the MV failure and errors, MV was dropped and the table was > truncated. > Then I recreated the MV and Table from scratch which worked as expected. > > The huge sizes of sstables as I have mentioned are after that. Somehow it > still persists with same last modification timestamps. > > Not sure if i can safely rm these sstables or truncate system.batches on > that node. > > > -------- Original Message -------- > Subject: Re: Huge size of system.batches table after dropping an > incomplete Materialized View > Local Time: 22 January 2017 11:41 PM > UTC Time: 22 January 2017 18:11 > From: benjamin.r...@jaumo.com > To: user@cassandra.apache.org, Vinci <vi...@protonmail.com> > > I cannot tell you were these errors like "Attempting to mutate ..." come > from but under certain circumstances all view mutations are stored in > batches, so the batchlog can grow insanely large. I don't see why a repair > should help you in this situation. I guess what you want is to recreate the > table. > > 1. You should not repair MVs directly. The current design is to only > repairs the base table - though it's not properly documented. Repairing MVs > can create inconsistent states. Only repairing the base tables wont. > 2. A repair does only repair data and won't fix schema-issues > 3. A repair of a base table that contains an MV is incredibly slow if the > state is very inconsistent (which is probably the case in your situation) > > What to do? > - If you don't care about the data of the MV, you of course can delete all > SSTables (when CS is stopped) and all data will be gone. But I don't know > if it helps. > - If you are 100% sure that no other batch logs are going on, you could > also truncate the system.batches, otherwise your log may be flooded with > "non-existant table" things if the batch log is replayed. It is annoying > but should not harm anyone. > > => Start over, try to drop and create the MV. Watch out for logs referring > to schema changes and errors > > Side note: > I'd recommend not to use MVs (yet) if you don't have an "inside" > understanding of them or "know what you are doing". They can have a very > big impact on your cluster performance in some situations and are not > generally considered as stable yet. > > 2017-01-22 18:42 GMT+01:00 Vinci <vi...@protonmail.com>: > >> Hi there, >> >> Version :- Cassandra 3.0.7 >> >> I attempted to create a Materialized View on a certain table and it >> failed with never-ending WARN message "Mutation of <x> bytes is too >> large for the maximum size of <y>". >> >> "nodetool stop VIEW_BUILD" also did not help. >> >> That seems to be a result of https://issues.apache.org/j >> ira/browse/CASSANDRA-11670 which is fixed in newer versions. >> >> So I tried dropping the view and that generated error messages like >> following :- >> >> ERROR [CompactionExecutor:632] [Timestamp] Keyspace.java:475 - Attempting >> to mutate non-existant table 7c2e1c40-b82b-11e6-9d20-4b0190661423 >> (keyspace_name.view_name) >> >> I performed an incremental repair of the table on which view was created >> and a rolling restart to stop these errors. >> >> Now I see huge size of system.batches table on one of the nodes. It seems >> related to issues mentioned above since last modification timestamps of the >> sstable files inside system/batches is same as when I tried to drop the MV. >> >> Some insight and suggestions regarding it will be very helpful. I will >> like to know if i can safely truncate the table, rm the files or any other >> approach to clean it up? >> >> Thanks. >> > > > > -- > Benjamin Roth > Prokurist > > Jaumo GmbH · www.jaumo.com > Wehrstraße 46 · 73035 Göppingen · Germany > Phone +49 7161 304880-6 <07161%203048806> · Fax +49 7161 304880-1 > <07161%203048801> > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer > > > -- Benjamin Roth Prokurist Jaumo GmbH · www.jaumo.com Wehrstraße 46 · 73035 Göppingen · Germany Phone +49 7161 304880-6 · Fax +49 7161 304880-1 AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
