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