[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
// Copyright (c) 2013, Facebook, Inc. All rights reserved.
|
|
|
|
// This source code is licensed under the BSD-style license found in the
|
|
|
|
// LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
// of patent rights can be found in the PATENTS file in the same directory.
|
|
|
|
//
|
|
|
|
// Copyright (c) 2011 The LevelDB Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file. See the AUTHORS file for names of contributors.
|
|
|
|
|
|
|
|
#pragma once
|
2014-05-03 02:08:55 +02:00
|
|
|
#ifndef ROCKSDB_LITE
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
|
2014-05-03 02:08:55 +02:00
|
|
|
#define __STDC_FORMAT_MACROS
|
|
|
|
#include <inttypes.h>
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
#include <string>
|
|
|
|
#include <map>
|
|
|
|
#include <vector>
|
|
|
|
|
2014-05-03 02:08:55 +02:00
|
|
|
#include "utilities/stackable_db.h"
|
|
|
|
#include "rocksdb/env.h"
|
|
|
|
#include "rocksdb/status.h"
|
|
|
|
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
namespace rocksdb {
|
|
|
|
|
|
|
|
struct BackupableDBOptions {
|
|
|
|
// Where to keep the backup files. Has to be different than dbname_
|
|
|
|
// Best to set this to dbname_ + "/backups"
|
|
|
|
// Required
|
|
|
|
std::string backup_dir;
|
|
|
|
|
|
|
|
// Backup Env object. It will be used for backup file I/O. If it's
|
|
|
|
// nullptr, backups will be written out using DBs Env. If it's
|
|
|
|
// non-nullptr, backup's I/O will be performed using this object.
|
|
|
|
// If you want to have backups on HDFS, use HDFS Env here!
|
|
|
|
// Default: nullptr
|
|
|
|
Env* backup_env;
|
|
|
|
|
2014-01-09 21:24:28 +01:00
|
|
|
// If share_table_files == true, backup will assume that table files with
|
|
|
|
// same name have the same contents. This enables incremental backups and
|
|
|
|
// avoids unnecessary data copies.
|
|
|
|
// If share_table_files == false, each backup will be on its own and will
|
|
|
|
// not share any data with other backups.
|
|
|
|
// default: true
|
|
|
|
bool share_table_files;
|
|
|
|
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
// Backup info and error messages will be written to info_log
|
|
|
|
// if non-nullptr.
|
|
|
|
// Default: nullptr
|
|
|
|
Logger* info_log;
|
|
|
|
|
|
|
|
// If sync == true, we can guarantee you'll get consistent backup even
|
|
|
|
// on a machine crash/reboot. Backup process is slower with sync enabled.
|
|
|
|
// If sync == false, we don't guarantee anything on machine reboot. However,
|
|
|
|
// chances are some of the backups are consistent.
|
|
|
|
// Default: true
|
|
|
|
bool sync;
|
|
|
|
|
|
|
|
// If true, it will delete whatever backups there are already
|
|
|
|
// Default: false
|
|
|
|
bool destroy_old_data;
|
|
|
|
|
2014-03-17 23:39:23 +01:00
|
|
|
// If false, we won't backup log files. This option can be useful for backing
|
|
|
|
// up in-memory databases where log file are persisted, but table files are in
|
|
|
|
// memory.
|
|
|
|
// Default: true
|
|
|
|
bool backup_log_files;
|
|
|
|
|
2014-03-24 19:38:44 +01:00
|
|
|
// Max bytes that can be transferred in a second during backup.
|
|
|
|
// If 0, go as fast as you can
|
|
|
|
// Default: 0
|
|
|
|
uint64_t backup_rate_limit;
|
|
|
|
|
|
|
|
// Max bytes that can be transferred in a second during restore.
|
|
|
|
// If 0, go as fast as you can
|
|
|
|
// Default: 0
|
|
|
|
uint64_t restore_rate_limit;
|
|
|
|
|
2014-05-03 02:08:55 +02:00
|
|
|
// Only used if share_table_files is set to true. If true, will consider that
|
|
|
|
// backups can come from different databases, hence a sst is not uniquely
|
|
|
|
// identifed by its name, but by the triple (file name, crc32, file length)
|
|
|
|
// Default: false
|
|
|
|
// Note: this is an experimental option, and you'll need to set it manually
|
|
|
|
// *turn it on only if you know what you're doing*
|
|
|
|
bool share_files_with_checksum;
|
|
|
|
|
2014-03-10 20:09:54 +01:00
|
|
|
void Dump(Logger* logger) const;
|
|
|
|
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
explicit BackupableDBOptions(const std::string& _backup_dir,
|
|
|
|
Env* _backup_env = nullptr,
|
2014-01-09 21:24:28 +01:00
|
|
|
bool _share_table_files = true,
|
2014-03-05 02:02:25 +01:00
|
|
|
Logger* _info_log = nullptr, bool _sync = true,
|
2014-03-17 23:39:23 +01:00
|
|
|
bool _destroy_old_data = false,
|
2014-03-24 19:38:44 +01:00
|
|
|
bool _backup_log_files = true,
|
|
|
|
uint64_t _backup_rate_limit = 0,
|
|
|
|
uint64_t _restore_rate_limit = 0)
|
2014-03-05 02:02:25 +01:00
|
|
|
: backup_dir(_backup_dir),
|
|
|
|
backup_env(_backup_env),
|
2014-03-10 22:42:03 +01:00
|
|
|
share_table_files(_share_table_files),
|
2014-03-05 02:02:25 +01:00
|
|
|
info_log(_info_log),
|
|
|
|
sync(_sync),
|
2014-03-17 23:39:23 +01:00
|
|
|
destroy_old_data(_destroy_old_data),
|
2014-03-24 19:38:44 +01:00
|
|
|
backup_log_files(_backup_log_files),
|
|
|
|
backup_rate_limit(_backup_rate_limit),
|
2014-05-03 02:08:55 +02:00
|
|
|
restore_rate_limit(_restore_rate_limit),
|
|
|
|
share_files_with_checksum(false) {
|
|
|
|
assert(share_table_files || !share_files_with_checksum);
|
|
|
|
}
|
2014-03-17 23:39:23 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct RestoreOptions {
|
|
|
|
// If true, restore won't overwrite the existing log files in wal_dir. It will
|
|
|
|
// also move all log files from archive directory to wal_dir. Use this option
|
|
|
|
// in combination with BackupableDBOptions::backup_log_files = false for
|
|
|
|
// persisting in-memory databases.
|
|
|
|
// Default: false
|
|
|
|
bool keep_log_files;
|
|
|
|
|
|
|
|
explicit RestoreOptions(bool _keep_log_files = false)
|
|
|
|
: keep_log_files(_keep_log_files) {}
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
typedef uint32_t BackupID;
|
|
|
|
|
|
|
|
struct BackupInfo {
|
|
|
|
BackupID backup_id;
|
|
|
|
int64_t timestamp;
|
|
|
|
uint64_t size;
|
|
|
|
|
|
|
|
BackupInfo() {}
|
|
|
|
BackupInfo(BackupID _backup_id, int64_t _timestamp, uint64_t _size)
|
|
|
|
: backup_id(_backup_id), timestamp(_timestamp), size(_size) {}
|
|
|
|
};
|
|
|
|
|
2014-04-25 21:49:29 +02:00
|
|
|
class BackupEngineReadOnly {
|
|
|
|
public:
|
|
|
|
virtual ~BackupEngineReadOnly() {}
|
|
|
|
|
|
|
|
static BackupEngineReadOnly* NewReadOnlyBackupEngine(
|
|
|
|
Env* db_env, const BackupableDBOptions& options);
|
|
|
|
|
|
|
|
// You can GetBackupInfo safely, even with other BackupEngine performing
|
|
|
|
// backups on the same directory
|
|
|
|
virtual void GetBackupInfo(std::vector<BackupInfo>* backup_info) = 0;
|
|
|
|
|
|
|
|
// Restoring DB from backup is NOT safe when there is another BackupEngine
|
|
|
|
// running that might call DeleteBackup() or PurgeOldBackups(). It is caller's
|
|
|
|
// responsibility to synchronize the operation, i.e. don't delete the backup
|
|
|
|
// when you're restoring from it
|
|
|
|
virtual Status RestoreDBFromBackup(
|
|
|
|
BackupID backup_id, const std::string& db_dir, const std::string& wal_dir,
|
|
|
|
const RestoreOptions& restore_options = RestoreOptions()) = 0;
|
|
|
|
virtual Status RestoreDBFromLatestBackup(
|
|
|
|
const std::string& db_dir, const std::string& wal_dir,
|
|
|
|
const RestoreOptions& restore_options = RestoreOptions()) = 0;
|
|
|
|
};
|
|
|
|
|
2014-01-28 20:26:07 +01:00
|
|
|
// Please see the documentation in BackupableDB and RestoreBackupableDB
|
|
|
|
class BackupEngine {
|
|
|
|
public:
|
|
|
|
virtual ~BackupEngine() {}
|
|
|
|
|
2014-01-29 01:01:53 +01:00
|
|
|
static BackupEngine* NewBackupEngine(Env* db_env,
|
|
|
|
const BackupableDBOptions& options);
|
|
|
|
|
2014-01-28 20:26:07 +01:00
|
|
|
virtual Status CreateNewBackup(DB* db, bool flush_before_backup = false) = 0;
|
|
|
|
virtual Status PurgeOldBackups(uint32_t num_backups_to_keep) = 0;
|
|
|
|
virtual Status DeleteBackup(BackupID backup_id) = 0;
|
|
|
|
virtual void StopBackup() = 0;
|
|
|
|
|
|
|
|
virtual void GetBackupInfo(std::vector<BackupInfo>* backup_info) = 0;
|
2014-03-17 23:39:23 +01:00
|
|
|
virtual Status RestoreDBFromBackup(
|
|
|
|
BackupID backup_id, const std::string& db_dir, const std::string& wal_dir,
|
|
|
|
const RestoreOptions& restore_options = RestoreOptions()) = 0;
|
|
|
|
virtual Status RestoreDBFromLatestBackup(
|
|
|
|
const std::string& db_dir, const std::string& wal_dir,
|
|
|
|
const RestoreOptions& restore_options = RestoreOptions()) = 0;
|
2014-01-28 20:26:07 +01:00
|
|
|
};
|
|
|
|
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
// Stack your DB with BackupableDB to be able to backup the DB
|
|
|
|
class BackupableDB : public StackableDB {
|
|
|
|
public:
|
|
|
|
// BackupableDBOptions have to be the same as the ones used in a previous
|
|
|
|
// incarnation of the DB
|
2013-12-11 05:49:28 +01:00
|
|
|
//
|
|
|
|
// BackupableDB ownes the pointer `DB* db` now. You should not delete it or
|
|
|
|
// use it after the invocation of BackupableDB
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
BackupableDB(DB* db, const BackupableDBOptions& options);
|
|
|
|
virtual ~BackupableDB();
|
|
|
|
|
|
|
|
// Captures the state of the database in the latest backup
|
|
|
|
// NOT a thread safe call
|
|
|
|
Status CreateNewBackup(bool flush_before_backup = false);
|
|
|
|
// Returns info about backups in backup_info
|
|
|
|
void GetBackupInfo(std::vector<BackupInfo>* backup_info);
|
|
|
|
// deletes old backups, keeping latest num_backups_to_keep alive
|
|
|
|
Status PurgeOldBackups(uint32_t num_backups_to_keep);
|
|
|
|
// deletes a specific backup
|
|
|
|
Status DeleteBackup(BackupID backup_id);
|
2014-01-09 21:24:28 +01:00
|
|
|
// Call this from another thread if you want to stop the backup
|
|
|
|
// that is currently happening. It will return immediatelly, will
|
|
|
|
// not wait for the backup to stop.
|
|
|
|
// The backup will stop ASAP and the call to CreateNewBackup will
|
|
|
|
// return Status::Incomplete(). It will not clean up after itself, but
|
|
|
|
// the state will remain consistent. The state will be cleaned up
|
|
|
|
// next time you create BackupableDB or RestoreBackupableDB.
|
|
|
|
void StopBackup();
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
|
|
|
|
private:
|
|
|
|
BackupEngine* backup_engine_;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Use this class to access information about backups and restore from them
|
|
|
|
class RestoreBackupableDB {
|
2014-03-05 02:02:25 +01:00
|
|
|
public:
|
|
|
|
RestoreBackupableDB(Env* db_env, const BackupableDBOptions& options);
|
|
|
|
~RestoreBackupableDB();
|
|
|
|
|
|
|
|
// Returns info about backups in backup_info
|
|
|
|
void GetBackupInfo(std::vector<BackupInfo>* backup_info);
|
|
|
|
|
|
|
|
// restore from backup with backup_id
|
|
|
|
// IMPORTANT -- if options_.share_table_files == true and you restore DB
|
|
|
|
// from some backup that is not the latest, and you start creating new
|
|
|
|
// backups from the new DB, they will probably fail
|
|
|
|
//
|
|
|
|
// Example: Let's say you have backups 1, 2, 3, 4, 5 and you restore 3.
|
|
|
|
// If you add new data to the DB and try creating a new backup now, the
|
|
|
|
// database will diverge from backups 4 and 5 and the new backup will fail.
|
|
|
|
// If you want to create new backup, you will first have to delete backups 4
|
|
|
|
// and 5.
|
|
|
|
Status RestoreDBFromBackup(BackupID backup_id, const std::string& db_dir,
|
2014-03-17 23:39:23 +01:00
|
|
|
const std::string& wal_dir,
|
|
|
|
const RestoreOptions& restore_options =
|
|
|
|
RestoreOptions());
|
2014-03-05 02:02:25 +01:00
|
|
|
|
|
|
|
// restore from the latest backup
|
|
|
|
Status RestoreDBFromLatestBackup(const std::string& db_dir,
|
2014-03-17 23:39:23 +01:00
|
|
|
const std::string& wal_dir,
|
|
|
|
const RestoreOptions& restore_options =
|
|
|
|
RestoreOptions());
|
2014-03-05 02:02:25 +01:00
|
|
|
// deletes old backups, keeping latest num_backups_to_keep alive
|
|
|
|
Status PurgeOldBackups(uint32_t num_backups_to_keep);
|
|
|
|
// deletes a specific backup
|
|
|
|
Status DeleteBackup(BackupID backup_id);
|
[RocksDB] BackupableDB
Summary:
In this diff I present you BackupableDB v1. You can easily use it to backup your DB and it will do incremental snapshots for you.
Let's first describe how you would use BackupableDB. It's inheriting StackableDB interface so you can easily construct it with your DB object -- it will add a method RollTheSnapshot() to the DB object. When you call RollTheSnapshot(), current snapshot of the DB will be stored in the backup dir. To restore, you can just call RestoreDBFromBackup() on a BackupableDB (which is a static method) and it will restore all files from the backup dir. In the next version, it will even support automatic backuping every X minutes.
There are multiple things you can configure:
1. backup_env and db_env can be different, which is awesome because then you can easily backup to HDFS or wherever you feel like.
2. sync - if true, it *guarantees* backup consistency on machine reboot
3. number of snapshots to keep - this will keep last N snapshots around if you want, for some reason, be able to restore from an earlier snapshot. All the backuping is done in incremental fashion - if we already have 00010.sst, we will not copy it again. *IMPORTANT* -- This is based on assumption that 00010.sst never changes - two files named 00010.sst from the same DB will always be exactly the same. Is this true? I always copy manifest, current and log files.
4. You can decide if you want to flush the memtables before you backup, or you're fine with backing up the log files -- either way, you get a complete and consistent view of the database at a time of backup.
5. More things you can find in BackupableDBOptions
Here is the directory structure I use:
backup_dir/CURRENT_SNAPSHOT - just 4 bytes holding the latest snapshot
0, 1, 2, ... - files containing serialized version of each snapshot - containing a list of files
files/*.sst - sst files shared between snapshots - if one snapshot references 00010.sst and another one needs to backup it from the DB, it will just reference the same file
files/ 0/, 1/, 2/, ... - snapshot directories containing private snapshot files - current, manifest and log files
All the files are ref counted and deleted immediatelly when they get out of scope.
Some other stuff in this diff:
1. Added GetEnv() method to the DB. Discussed with @haobo and we agreed that it seems right thing to do.
2. Fixed StackableDB interface. The way it was set up before, I was not able to implement BackupableDB.
Test Plan:
I have a unittest, but please don't look at this yet. I just hacked it up to help me with debugging. I will write a lot of good tests and update the diff.
Also, `make asan_check`
Reviewers: dhruba, haobo, emayanke
Reviewed By: dhruba
CC: leveldb, haobo
Differential Revision: https://reviews.facebook.net/D14295
2013-12-09 23:06:52 +01:00
|
|
|
|
|
|
|
private:
|
|
|
|
BackupEngine* backup_engine_;
|
|
|
|
};
|
|
|
|
|
2014-05-03 02:08:55 +02:00
|
|
|
} // namespace rocksdb
|
2014-04-15 22:39:26 +02:00
|
|
|
#endif // ROCKSDB_LITE
|