> Is it right to assume that we need to address this first in order to
implement 18102? If we leave it as it is and we implement vtable with
"unique snapshot name globally" in mind and we design that vtable like
that, until we fix this issue, snapshots would be overwritten on top of
each other if their names are same.

The vtable will just not include the timestamp in the primary key, since
all table snapshots will have the same timestamp. Currently it's not
possible to overwrite an existing snapshot if it already exists in a table.

On Tue, Mar 7, 2023 at 4:30 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> I agree too. Given the fact that the method checking the uniqueness of a
> snapshot name was implemented first, it seems to me that the second method
> which is not checking it just forgot to do that rather than intentionally
> doing it like that.
>
> Is it right to assume that we need to address this first in order to
> implement 18102? If we leave it as it is and we implement vtable with
> "unique snapshot name globally" in mind and we design that vtable like
> that, until we fix this issue, snapshots would be overwritten on top of
> each other if their names are same.
>
>
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageService.java#L4266
>
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageService.java#L4317
>
> ________________________________________
> From: Paulo Motta <pauloricard...@gmail.com>
> Sent: Monday, March 6, 2023 5:59
> To: Cassandra DEV
> Subject: [DISCUSS] Should separate snapshots with the same name be allowed
> in different tables?
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> Hi,
>
> It's possible to create a snapshot on a set of tables with the same name
> name/tag with:
> $ nodetool snapshot --kt-list ks.tb,system.local -t mysnapshot
> $ nodetool listsnapshots
> [..]
> mysnapshot  system  local  1.16 KiB  21.47 KiB    2023-03-02T13:19:13.757Z
> mysnapshot  ks      tb     1.02 KiB   6.08 KiB    2023-03-02T13:19:13.757Z
>
> It's also possible to create a snapshot with an existing name, as long as
> it's in a different table:
> $ nodetool snapshot --kt-list ks.tb2 -t mysnapshot
> $ nodetool listsnapshots
> [..]
> mysnapshot     ks       tb2        1.16 KiB  21.47 KiB
> 2023-03-02T13:19:42.140Z
> mysnapshot     ks       tb         1.02 KiB  6.08 KiB
>  2023-03-02T13:19:13.757Z
> mysnapshot     system   local      107 bytes 6.98 KiB
>  2023-03-02T13:19:13.757Z
>
> I found this a bit surprising, since I would expect a snapshot with the
> same name on different tables to represent the same logical snapshot taken
> at the same point-in-time.
>
> This affects the design of the snapshots virtual table schema on
> CASSANDRA-18102[1] because the timestamp needs to be included in the
> primary key to allow distinguishing between different snapshots with the
> same name, which seems a bit counter-intuitive.
>
> I think we should disallow creating a snapshot if another snapshot already
> exists with the same name in any other table, so snapshots with the same
> name on different tables are guaranteed to belong to the same logical
> point-in-time snapshot.
>
> Does anyone think it's useful to be able to create separate snapshots with
> the same names across different tables and we should retain this support?
>
> Let me know what do you think,
>
> Paulo
>
> [1] - https://issues.apache.org/jira/browse/CASSANDRA-18102
>
>

Reply via email to