Cassandra 备份与恢复

Launchpad蓝图

https://blueprints.launchpad.net/trove/+spec/cassandra-backup-restore

问题描述

目前 Cassandra 数据存储不支持任何备份/恢复策略。

提议的变更

补丁集将使用 Cassandra 2.1 的 Nodetool 1 工具实现单个实例的完整备份/恢复3。

配置

以下 Cassandra 配置选项将被更新

  • 备份/恢复命名空间

  • backup_strategy

数据库

无

公共 API

无

公共 API 安全

无

Python API

无

CLI (python-troveclient)

完成之后，以下 Trove CLI 命令将完全适用于 Cassandra

  • backup-create

  • backup-delete

  • backup-list

  • create –backup

内部 API

无

Guest Agent

我们正在使用节点快照实现完整备份，具体过程如 Nodetool 手册中所述 2。Nodetool 可以对一个或多个 keyspace 进行快照。可以通过将快照目录中的所有 *.db 文件移动到相应的 keyspace 并覆盖任何现有文件来恢复快照。

在创建快照时，Cassandra 会开始将所有更改保存到新的数据文件中，同时保持旧文件在快照创建时的状态。数据存储必须有足够的容量来容纳备份操作期间所有更改的积压，直到快照被清理为止。

备份以 (TAR) 归档文件的形式流式传输到和从远程存储。现在我们概述创建和恢复此类归档文件的通用过程。

将使用唯一的备份 ID 作为快照名称，以避免并发备份之间的冲突。

备份过程

  1. 确保数据库已启动并正在运行。

  2. 清除与创建的快照名称相同的任何现有快照 (nodetool clearsnapshot)。

  3. 对所有 keyspace 进行快照 (nodetool snapshot)。

  4. 从快照目录中收集所有 *.db 文件。

  5. 将快照文件打包成单个 TAR 归档文件（根据需要进行压缩和/或加密），同时将输出流式传输到数据库_备份容器下的 Swift 存储。

    转换路径，以便可以通过将归档文件直接提取到现有数据目录来简单地恢复备份。这是为了确保我们始终可以恢复旧备份，即使标准访客代理数据目录发生更改也是如此。

  6. 如 (1) 中所述，清除创建的快照。

恢复过程

  1. 如果数据库正在运行，请停止数据库并清除 system keyspace 中生成的所有文件。

  2. 创建一个新的数据目录。

  3. 从存储读取备份，将其解包到数据目录。

  4. 将恢复文件的所有权更新为 Cassandra 用户。

其他注意事项

实例创建为单节点集群。因此，恢复的实例也应属于其自身的集群。原始集群名称属性必须重置为与恢复实例的新唯一 ID 匹配。这是为了确保恢复的实例是新单节点集群的一部分，而不是与原始节点或其他从同一备份恢复的实例形成一个集群。集群名称存储在数据库中，并且必须与配置值匹配。否则 Cassandra 将无法启动。

通用的 ‘cluster_name’ 重置过程是

  1. 更新 system keyspace 表中的名称。

  2. 更新配置文件中的名称。

  3. 重新启动服务。

存储在 system keyspace 中的 ‘superuser’ (“root”) 密码需要在启动恢复的数据之前重置。

通用的密码重置过程是

  1. 禁用用户身份验证和远程访问。

  2. 重新启动服务。

  3. 更新 ‘system_auth.credentials’ 表中的密码。

  4. 重新启用身份验证并使主机可访问。

  5. 重新启动服务。

备选方案

无

实现

负责人

Petr Malik <pmalik@tesora.com>

里程碑

Liberty-1

工作项

  1. 实现重置集群名称和超级用户密码所需的功能。

  2. 实现备份/恢复 API 调用。

升级影响

无

依赖项

补丁集将在 blueprints 中实现的功能基础上构建：cassandra-database-user-functions 4 和 cassandra-configuration-groups 5

测试

将添加单元测试以验证已实现的功能和非平凡的代码路径。我们不将功能测试作为此补丁集的一部分来实现。

文档影响

数据存储文档应更新以反映启用的功能。另请注意新的配置选项 - 备份/恢复命名空间和 Cassandra 数据存储的备份策略。