Cassandra backup and recovery related series of incremental backups Introduction

This article will be on the backup module associated with cassandra resumed series introduction, probably including: incremental backups; snapshot; nodetool related (refresh, rebuild_index, etc.), here will give priority to introduce incremental_backups;

Note

This series of code using version cassandra-3.11;

incremental backups

Incremental backup by definition is an incremental backup, probably can be understood as the backup data cassandra added.

Open incremental backups

incremental backups is off by default, there are two ways to open the incremental backups:

• There in the conf directory of cassandra.yaml profile of cassandra inside incremental_backups such a configuration item, the configuration item default is false; you can choose to read true, but the need to restart the process, after all, is the need to re-load the configuration item;

• When you cluster process has started, but do not want to restart the cluster, you can select the bin directory below nodetool tool, select enablebackup command to; because we see through the code variable associated with incremental_backups is volatile so this operation is to take effect , but this command can take effect in a node, if you want to operate a cluster, you need to execute concurrently on each node;

  public volatile boolean incremental_backups = false;

When we turn incremental backups feature, whenever a new flush of data from memory to disk memtable, will play on the new generation of sstable a hardlink;

public void maybeIncrementallyBackup(final Iterable<SSTableReader> sstables)
    {
        if (!DatabaseDescriptor.isIncrementalBackupsEnabled())
            return;// 如果没有开启就跳过，开启就对sstable相应的磁盘文件打hardlink

        for (SSTableReader sstable : sstables)
        {
            File backupsDir = Directories.getBackupsDirectory(sstable.descriptor);
            sstable.createLinks(FileUtils.getCanonicalPath(backupsDir));
        }
    }

In addition, bootstrap added, decommission reduced, move other operations resulting in consistent hash ring changes, caused by the operation of data migration, data will be delayed when generating the hard link, here is my new node to the cluster later , corresponding to the new node keyspace the following table directory backups to drag data;

[root@Cassandra8c32GTest006 backups]# ll /data/data1/keyspace1/standard1-93263960883911e99a9ae16f3def2644/backups/
total 4324
-rw-r--r-- 2 root root     256 Jun 20 10:19 na-11-big-CRC.db
-rw-r--r-- 2 root root 4094625 Jun 20 10:19 na-11-big-Data.db
-rw-r--r-- 2 root root      10 Jun 20 10:19 na-11-big-Digest.crc32
-rw-r--r-- 2 root root    5536 Jun 20 10:19 na-11-big-Filter.db
-rw-r--r-- 2 root root  293888 Jun 20 10:19 na-11-big-Index.db
-rw-r--r-- 2 root root   10264 Jun 20 10:19 na-11-big-Statistics.db
-rw-r--r-- 2 root root    3132 Jun 20 10:19 na-11-big-Summary.db
-rw-r--r-- 2 root root      80 Jun 20 10:19 na-11-big-TOC.txt

In the following specific backups directory is a corresponding need to do sstable incremental backup files. We can direct backup of this file can; of course, the backup is completed files need to manually perform the removal, otherwise the files will not be cleaned up and cause problems take up storage space.

Nail group:

micro-channel public number: