Lock-free Backups

Lock-free backups do not block INSERT, UPDATE, and DELETE operations at any point during a backup. They do not need to lock and wait for write queries. Lock-free backups are enabled by default

However, ALTER DATABASE and SNAPSHOT commands will not run while there is a backup job active on the relevant database. There is no difference between lock-free backup and the original locking backup with respect to the cluster operations lock. The backup takes the cluster operations lock for the entirety of the backup.

Lock-free backups are enabled when the lockfree_backup engine variable is set to ON and the disable_update_delete_distributed_transactions engine variable is set to OFF. The default values of lockfree_backup and disable_update_delete_distributed_transactions are ON and OFF, respectively.

Note

Lock-free backups cannot be made using BACKUP DATABASE ... WITH SPLIT PARTITIONS ....

Locking that Occurs if Lock-free Backups are Disabled

If lock-free backups are disabled and BACKUP DATABASE is run, the following applies before the backup starts:

  • The aggregator briefly blocks new queries from running across the cluster.

  • If there is a long-running write query executing, BACKUP DATABASE waits for the query to complete.

Once BACKUP DATABASE is running, queries against the cluster can proceed normally.

Commands Blocked by the BACKUP Process

  • ALTER DATABASE

  • DROP DATABASE

  • SNAPSHOT DATABASE

Commands Not Blocked by the BACKUP Process

  • CREATE TABLE (columnstore and rowstore)

  • ALTER TABLE (columnstore and rowstore)

  • DROP TABLE (columnstore and rowstore)

  • DELETE TABLE

  • INSERT TABLE

  • TRUNCATE TABLE (columnstore and rowstore)

  • CREATE INDEX

  • DROP INDEX (columnstore and rowstore)

  • CREATE VIEW

  • DROP VIEW

  • ANALYZE TABLE (columnstore and rowstore)

  • OPTIMIZE COLUMNSTORE TABLE

  • SHOW TABLE STATUS

  • SHOW DATABASE STATUS

  • OPTIMIZE ROWSTORE TABLE

Last modified: February 29, 2024

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined
  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined
  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
    cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
    --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
    --bundle undefined \
    --new-bundle-format -
    Verified OK