Cassandra restore

CassandraRestoreSpec defines the specification for a restore of a Cassandra backup.

apiVersion: db.orange.com/v2
kind: CassandraRestore
metadata:
name: restore-demo
spec:
cassandraCluster: cluster-demo
cassandraBackup: backup-demo
entities: k1.standard1

CassandraRestore#

FieldTypeDescriptionRequiredDefault
metadataObjectMetadatais metadata that all persisted resources must have, which includes all objects users must create.Nonil
specCassandraRestoreSpecdefines the desired state of CassandraRestore.Nonil
statusCassandraRestoreStatusdefines the observed state of CassandraRestore.Nonil

CassandraRestoreSpec#

FieldTypeDescriptionRequiredDefault
cassandraBackupstringName of the CassandraBackup to restoreYes-
cassandraClusterstringName of the CassandraCluster the restore belongs toYes-
cassandraDirectorystringDirectory of Cassandra where data folder resides. Defaults to /var/lib/cassandraNo-
datacenterstringCassandra DC name to restore to, a restore will truncate tables but restore only to this datacenter if specifiedNo-
concurrentConnectionint32Maximum number of threads used to download files from the cloud. Defaults to 10No-
entitiesstringDatabase entities to restore, it might be either only keyspaces or only tables prefixed by their respective keyspace, e.g. 'k1,k2' if one wants to backup whole keyspaces or 'ks1.t1,ks2.t2' if one wants to restore specific tables. These formats are mutually exclusive so 'k1,k2.t2' is invalid. An empty field will restore all keyspacesNo-
exactSchemaVersionbooleanWhen set a running node's schema version must match the snapshot's schema version. There might be cases when we want to restore a table for which its CQL schema has not changed but it has changed for other table / keyspace but a schema for that node has changed by doing that. Defaults to FalseNofalse
noDeleteTruncatesbooleanWhen set do not delete truncated SSTables after they've been restored during CLEANUP phase. Defaults to falseNofalse
schemaVersionstringVersion of the schema to restore from. Upon backup, a schema version is automatically appended to a snapshot name and its manifest is uploaded under that name. In case we have two snapshots having same name, we might distinguish between the two of them by using the schema version. If schema version is not specified, we expect a unique backup taken with respective snapshot name. This schema version has to match the version of a Cassandra node we are doing restore for (hence, by proxy, when global request mode is used, all nodes have to be on exact same schema version). Defaults to FalseNo-
secretstringName of Secret to use when accessing cloud storage providersNo-

CassandraRestoreStatus#

FieldTypeDescriptionRequiredDefault
conditionConditionBackRestCondition describes the observed state of a Restore at a certain pointNo-
coordinatorMemberstringName of the pod the restore operation is executed onNo-
idstringunique identifier of an operation, a random id is assigned to each operation after a request is submitted, from caller's perspective, an id is sent back as a response to his request so he can further query state of that operation, referencing id, by operations/{id} endpointNo-
progressstringProgress is a percentage, 100% means the operation is completed, either successfully or with errorsNo-
timeCompletedstringNo-
timeCreatedstringNo-
timeStartedstringNo-

Condition#

FieldTypeDescriptionRequiredDefault
failureCause[]itemsNonil
lastTransitionTimestringNo-
typestringNo-

Items#

FieldTypeDescriptionRequiredDefault
messagestringmessage explaining the errorNo-
sourcestringhostame of a node where this error has occurredNo-