Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a backup and restore guide #148

Merged
merged 4 commits into from
Jan 26, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .circleci/config.yml
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@ jobs:
# We need to edit DEFAULT_CQLVER defined in the cqlsh script
# to connect to the server without --cqlversion command line option
command: |
curl -O https://bootstrap.pypa.io/get-pip.py
curl -O https://bootstrap.pypa.io/2.7/get-pip.py
sudo python get-pip.py
sudo pip install cqlsh
sudo sed -i "s/^DEFAULT_CQLVER = .*/DEFAULT_CQLVER = '3.4.4'/" /usr/local/bin/cqlsh
Expand Down
17 changes: 17 additions & 0 deletions docs/backup-restore.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# A Guide on How to Back up and Restore Databases Integrated with Scalar DB

Since Scalar DB provides transaction capability on top of non-transactional (possibly transactional) databases non-invasively, you need to take special care of backing up and restoring the databases in a transactionally-consistent way.
This document sets out some guidelines for backing up and restoring the databases that Scalar DB supports.

## Cassandra

Since Cassandra has a built-in replication mechanism, we don't always need a transactionally-consistent backup to recover a Cassandra cluster.

For example, if replication is properly set to 3 and only the data of one of the nodes in a cluster is lost, we don't need a transactionally-consistent backup because the node can be recovered with a normal (transactionally-inconsistent) snapshot and the repair mechanism.
However, if the quorum of nodes of a cluster loses their data, we need a transactionally-consistent backup to restore the cluster to a certain transactionally-consistent point.

The easiest way to take a transactionally-consistent backup for Scalar DB on Cassandra is to use [Cassy](https://github.com/scalar-labs/cassy).
Cassy takes snapshots of a Cassandra cluster after it pauses the application cluster to make the resulting snapshots transactionally-consistent.
Please see [the doc](https://github.com/scalar-labs/cassy/blob/master/docs/getting-started.md#take-cluster-wide-consistent-backups) for more details.

Note that we can simply use the snapshots when restoring a cluster because they are just snapshots of Cassandra. In any case, it is recommended to use Cassy for restoration as well to minimize operational mistakes.
1 change: 1 addition & 0 deletions docs/getting-started-with-scalardb.md
Original file line number Diff line number Diff line change
Expand Up @@ -280,3 +280,4 @@ These are just simple examples of how Scalar DB is used. For more information, p
* [Javadoc](https://scalar-labs.github.io/scalardb/javadoc/)
* [Database schema in Scalar DB](schema.md)
* [Schema tool](../tools/scalar-schema/README.md)
* [How to Back up and Restore](backup-restore.md)