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/jira/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 · Fax +49 7161 304880-1 AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
