Can we use tombstone_gc = {'mode': 'repair'} for GSI tables?

ScyllaDB
, ,
1

I have two questions here about tombstone_gc = {‘mode’: ‘repair’} for GSI tables.

  1. I am not sure whether tombstone_gc = {‘mode’: ‘repair’} is supported for GSI tables or not.
  2. How can I ensure that the tombstone_gc mode has been changed for GSI tables? I’ve noticed that system_schema.tables displays data of extensions column in a wrong unclear byte format #10309 provides a method to check the tombstone_gc mode for base table. But it might not be useful for GSI tables.
2

AFAIK, tombstone_gc = {'mode': 'repair'} should work with any table, that can be repaired and the materialized view that is backing the GSI certainly can be repaired.

@nyh are you aware of any potential gotchas around this?

3

Yes, a materialized view is a normal table under the hood, but one cannot modify it by ALTER TABLE and you need to do ALTER MATERIALIZED VIEW. I believe, but did not test myself that you can modify this tombstone_gc with ALTER MATERIALIZED VIEW. I also believe (but didn’t test) that if you already have a base table with tombstone_gc and later create a view, this view will inherit this setting. But both beliefs should be tested (I’ll do this later).

Beyond that, there is a separate question of whether users should repair view tables. My view (sorry for the pun) is that they should - they should repair base tables and then view tables. There are known rare inconsistencies (“ghost rows”) that may arise from repairing view tables, but I think the benefits of such repair - including tombstone GC - greatly outweigh the risks. But this is still an open discussion.

CC @Konstantin_Osipov @Yaniv_Kaul

1 Like
4

We’ve recently added (via [Backport 5.2] schema: add scylla specific options to schema description by Jadw1 · Pull Request #16786 · scylladb/scylladb · GitHub ) a reasonable way to see tombstone_gc for tables.

5

I wrote a test and confirmed (on latest ScyllaDB master) that:

  1. The tombstone_gc option can be set on a materialized view either when it’s first created with CREATE MATERIALIZED VIEW or when later with ALTER MATERIALIZED VIEW

  2. The current setting is correctly printed with the “DESC ” statement. This is the new server-side describe statement, that replaced the older statement that used to live in CQL (and didn’t support tombstone_gc or other non-standard options).

  3. The gc_mode set on a base table is not inherited by its views - you need to set it separately for each view (again, while creating the view or later). I don’t know if this is a bug or a feature, but it shouldn’t cause any problems once you know you need to set it per view separately.

1 Like
6

Thanks very much for your reply. However, I am still confused about the rare inconsistencies (“ghost rows”) which may arise from repairing view tables. Can you give me some specific examples or issues about this?

7

Can you give me some specific examples or issues about “ghost rows” which arise from repairing view tables? Thanks! @nyh

8

When I enabled the gc_mode=repair function of the base table and view table, there was a phenomenon of missing certain attributes in the records of my view table. During this period, the cluster is scheduling repairs normally. Under what circumstances does this phenomenon occur and is it related to function gc_mode=repair ? Thanks!