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.

Sign up for GitHub

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

Add a backup guide for the Scalar DB server #254

Merged
merged 3 commits into from
Jul 22, 2021
Merged

Add a backup guide for the Scalar DB server #254

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d35ef9a
Add a backup guide for the Scalar DB server
brfrn169 Jul 20, 2021
90ebf46
Apply suggestions from code review
brfrn169 Jul 21, 2021
1ef607a
Apply suggestions from code review
brfrn169 Jul 21, 2021
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
9 changes: 8 additions & 1 deletion docs/backup-restore.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ However, if the quorum of nodes of a cluster loses their data, we need a transac
The easiest way to take a transactionally-consistent backup for Scalar DB on Cassandra is to stop a cluster, take the snapshots of all the nodes of the cluster, and start the cluster. If you implement [scalar-admin](https://github.com/scalar-labs/scalar-admin) interface properly in your application, you can easily pause the application without losing on-going transactions.

To minimize mistakes when doing backup and restore operations, it is recommended to use [Cassy](https://github.com/scalar-labs/cassy).
Cassy is also itegrated with `scalar-admin` so it can issue a pause request to the application of a Cassandra cluster.
Cassy is also integrated with `scalar-admin` so it can issue a pause request to the application of a Cassandra cluster.
Please see [the doc](https://github.com/scalar-labs/cassy/blob/master/docs/getting-started.md#take-cluster-wide-consistent-backups) for more details.

## JDBC databases
Expand All @@ -23,3 +23,10 @@ One requirement for backup in Scalar DB on JDBC databases is that backups for al
That means that you need to create a consistent snapshot by dumping all tables in a single transaction.
For example, you can use `mysqldump` command with `--single-transaction` option in MySQL and `pg_dump` command in PostgreSQL to achieve that.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, Is this true even when we use ConsensusCommit?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for reviewing this!

Yes. mysqldump command with --single-transaction and pg_dump command can take a backup that's automatically recoverable to a transactionally-consistent state. So, it's true even when we use ConsensusCommit.

Or when you use Amazon RDS (Relational Database Service) or Azure Database for MySQL/PostgreSQL, you can restore to any point within the backup retention period with the automated backup feature, which satisfies the requirement.

## Scalar DB server

Since Scalar DB server implements [scalar-admin](https://github.com/scalar-labs/scalar-admin) interface, you can easily pause the server to stop accepting incoming requests and drain in-flight requests.
You can use paused duration and choose one of the following ways depending on the underlining database to make your databases transactionally-consistent even after restored.
* Take backups of your databases during the paused duration with snapshot feature.
* Restore to a point in the paused duration with point-in-time-restore (PITR) feature.