You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stefan Miklosovic (Jira)" <ji...@apache.org> on 2025/06/04 14:16:00 UTC

[jira] [Updated] (CASSANDRA-19512) Add startup flag to load a local snapshot from disk

     [ https://issues.apache.org/jira/browse/CASSANDRA-19512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Miklosovic updated CASSANDRA-19512:
------------------------------------------
    Description: 
Add startup flag "cassandra.load_snapshot_unsafe=snapshot_id" that loads a snapshot with the specified ID into the sstable tracker in the initial startup phase.

The flag has the {{_unsafe}} suffix because it may cause data consistency issues if this is used incorrectly. For example, if a given snapshot is loaded in a single replica of a replicated keyspace, it may cause replicas to go out of sync. For this reason, this flag should only be accepted if the "allow_load_snapshot_unsafe" guardrail is enabled (it is disabled by default).

When the flag is detected during startup, snapshots with the given tag will be located. If no snapshot with the given tag exists, the startup should fail.

The snapshot loading mechanism should create a hard link to existing sstables into a staging area to ensure the existing data is secured. After this, it should replace the existing sstables with the snapshot data into the sstable tracker before proceeding normally with the startup.

  was:
Add startup flag "cassandra.load_snapshot_unsafe=snapshot_id" that loads a snapshot with the specified ID into the sstable tracker in the initial startup phase.

The flag has the {{_unsafe}} prefix because it may cause data consistency issues if this is used incorrectly. For example, if a given snapshot is loaded in a single replica of a replicated keyspace, it may cause replicas to go out of sync. For this reason, this flag should only be accepted if the "allow_load_snapshot_unsafe" guardrail is enabled (it is disabled by default).

When the flag is detected during startup, snapshots with the given tag will be located. If no snapshot with the given tag exists, the startup should fail.

The snapshot loading mechanism should create a hard link to existing sstables into a staging area to ensure the existing data is secured. After this, it should replace the existing sstables with the snapshot data into the sstable tracker before proceeding normally with the startup.


> Add startup flag to load a local snapshot from disk
> ---------------------------------------------------
>
>                 Key: CASSANDRA-19512
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-19512
>             Project: Apache Cassandra
>          Issue Type: Improvement
>          Components: Local/Snapshots
>            Reporter: Paulo Motta
>            Priority: Normal
>
> Add startup flag "cassandra.load_snapshot_unsafe=snapshot_id" that loads a snapshot with the specified ID into the sstable tracker in the initial startup phase.
> The flag has the {{_unsafe}} suffix because it may cause data consistency issues if this is used incorrectly. For example, if a given snapshot is loaded in a single replica of a replicated keyspace, it may cause replicas to go out of sync. For this reason, this flag should only be accepted if the "allow_load_snapshot_unsafe" guardrail is enabled (it is disabled by default).
> When the flag is detected during startup, snapshots with the given tag will be located. If no snapshot with the given tag exists, the startup should fail.
> The snapshot loading mechanism should create a hard link to existing sstables into a staging area to ensure the existing data is secured. After this, it should replace the existing sstables with the snapshot data into the sstable tracker before proceeding normally with the startup.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org