Cassandra 备份 - 1 - 节点镜像恢复

2024-06-02 17:18
文章标签 镜像 恢复 节点 备份 cassandra

本文主要是介绍Cassandra 备份 - 1 - 节点镜像恢复，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

 

之前比较关注如何使用Cassandra，但是真正想大规模使用前提还是需要搞清楚备份机制，确保数据安全。
本文主要内容来自文档 "Cassandra2.2"的翻译。最后部分为真实操作案例。
这里假设你已经了解了Cassandra的压缩、墓碑、数据一致性。
原始文档链接：http://docs.datastax.com/en/cassandra/2.2/cassandra/operations/opsBackupRestore.html

备份和数据恢复

关于镜像

Cassandra 通过直接保存所有在data目录中的磁盘数据文件（SSTable file）的镜像来备份数据。当系统还在线的时候，你可以保存所有的keyspace数据或者单个keyspace数据，或者某一张表的数据。

使用并行的ssh工具，比如pssh，你可以给整个集群做镜像。这提供一种最终一致性备份。虽然没有一个节点可以在镜像制作过程中保证他和备份节点数据的一致性，Cassandra内置一致性机制会使用一个恢复镜像恢复一致性。

当整个系统范围内的镜像都已经完成，你可以开启每个节点的增量备份，它将备份那些最后一次镜像后有改变的数据：每次SSTable 刷新，一个硬链接被复制到 data目录的/backups 子目录中（provided JNA is enabled）

如果允许JNA,镜像将只是建立一个硬链接。否则io将由于文件被从一个地方拷贝到另一处而增长，将明显降低效率。

如何得到一份镜像

通过 nodetool snapshot指令来获取每个节点的镜像。如果要获取全局的镜像，使用并行ssh工具运行这个指令，比如pssh。
镜像首先将所有内存数据刷新到磁盘中，然后给keyspace中的每个SSTable创建硬链接。你需要在每个节点上有足够的空间来容纳生成的镜像文件。单一镜像需要很小的空间。然而镜像会导致你的磁盘使用量随时间快速增长，因为镜像需要留着那些被删除的过期数据。当镜像制作完成。如果你需要的话，你可以将备份文件移动到其他位置，或者就放在那。

注意：Cassandra只能在table schema存在的情况下恢复数据，所以建议你同样备份一下schema（也就是system.schema_*系列的表）.

操作过程

运行nodetool snapshot指令，需要指定hostname，JMX端口，keyspace名称。比如：

 $ nodetool -h localhost -p 7199 snapshot mykeyspace

结果

snapshot被创建在(原文)目录中，每个s镜像都包含多个包含镜像当时数据的.db文件。
镜像的路径可能是:
使用安装包：/var/lib/cassandra/data/mykeyspace/users-081a1500136111e482d09318a3b15cc2/snapshots/1406227071618/mykeyspace-users-ka-1-Data.db
使用tar包: install_location/data/data/mykeyspace/users-081a1500136111e482d09318a3b15cc2/snapshots/1406227071618/mykeyspace-users-ka-1-Data.db

增量备份

当增量备份被开启（默认关闭），Cassandra 将硬链接每个刷新过的（flushed）的在keyspace数据目录中的SStable到备份目录中。这允许保存备份的偏移量而不是整个镜像。同时，增量备份将和镜像一起提供可靠的最新的备份机制。
和镜像一样，Cassandra 并不会自动清理增量备份文件。DataStax建议配置一个程序在新的镜像生成后，清理增量备份文件。

操作过程

编辑cassandra.yaml 配置文件，将incremental_backups 设置为true，你需要在每个节点都进行此操作

从镜像中恢复

从镜像中还原keyspace需要所有的table的镜像文件，如果使用增量备份，任何在镜像后创建的增量备份文件都是必须的。

正常来说，在从镜像还原之前，你需要清空(truncate)table. 如果备份发生在删除之前，而你在删除后还原数据没有先清空，你无法得到原始的数据(行)。在压缩后，墓碑存档在和原始数据不同的SSTable中，所以当还原包含着原始数据的SSTable但是没有移除墓碑，数据依旧表现出被删除状态（虽然它还在那）。

Cassandra 仅能再table schema存在的情况下备份镜像。如果你没有备份schema，你可以做下面的任何一种工作。

方法1：

  1. 还原镜像，按照下面的方法
  2. 重新创建schema

方法2 ：

  1. 重建schema
  2. 还原镜像
  3. 执行nodetool refresh

你有很多方法可以还原数据：

  1. 使用sstableloader 工具

  2. 拷贝镜像的SSTable文件到/data/keyspace/table_name-uuid目录中，然后用JConsole 在各个column family 中调用JMX方法loadNewSSTables()在column family MBean，你可以使用nodetool refresh 代替调用loadNewSSTables()

    data目录位置依赖于你的安装或者配置方式，默认是下面两种。
    1. Package installations: /var/lib/cassandra/data
    2. Tarball installations: install_location/data/data

  3. 使用Node Restart Method 下面将会介绍。

如果还原一个节点，你需要首先关闭节点。如果还原整个集群，你需要关闭所有节点，还原镜像数据，然后再次启动所有节点。
注意：还原镜像数据将导致正在还原的节点，CPU和IO临时增加。

译者注：这边可能文档没有更新完整，前面有提到需要truncate table，在关闭节点前先执行一次。

  1. 关闭节点

  2. 清理所有commitlog中的文件

    这是为了防止commitlog重放导致数据更新，这可能导致还原到某个固定时间点的目标失败。

  3. 清理有*.db文件在data_directory/keyspace_name/keyspace_name-keyspace_name目录中，但是不要删除镜像和备份子目录。
  4. 确定最近的镜像数据目录

  5. 将数据拷贝内容到这个目录

    data_directory/keyspace_name/talbe_name-UUID

  6. 如果你采用了增量备份，复制这里的所有数据

    data_driectory/keyspace_name/table_name-UUID/backups

  7. 粘贴到

    data_directory/keyspace_name/table_name-UUID中

  8. 重启节点

    这会导致暂时性的io增长和占有大量CPU资源。

  9. 执行nodetool repair

实际操作记录 （Node Restart Method）

集群简介

4个节点，分别为
192.168.1.2
192.168.1.3
192.168.1.4
192.168.1.5
之后就不写完整ip 用节点2 节点3 节点4 节点5

Cassandra 版本2.1.7

创建备份测试用的数据

登录负载最低的节点2，创建一个keyspace

/* 创建tshop的keyspace */
CREATE KEYSPACE tshop WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '2'} ;
use tshop;/* 创建一张user表 */CREATE TABLE user (uid int PRIMARY KEY,group_id int,nick varchar
) WITH compaction = { 'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'};/* 写入一些数据 */
insert into user (uid,group_id,nick) values(1,1,'kevin');
insert into user (uid,group_id,nick) values(2,1,'luxi');
insert into user (uid,group_id,nick) values(3,1,'happy');
insert into user (uid,group_id,nick) values(4,1,'豆沙柚子');
insert into user (uid,group_id,nick) values(5,1,'五仁月饼');

备份所有节点数据：

$ bin/nodetool -h 192.168.1.2 snapshot tshop
$ bin/nodetool -h 192.168.1.3 snapshot tshop
$ bin/nodetool -h 192.168.1.4 snapshot tshop
$ bin/nodetool -h 192.168.1.5 snapshot tshop

备份完成后会显示一个时间邮戳，这就是备份目录的名字，也方便还原时判定备份的时间。

/* 删除数据，假设是一次意外事故 */
delete from user where uid in (1,2,3,4,5);

关闭来自前端的请求，因为数据恢复的过程中，集群不得不关闭。

清空user表，前面有提到原因。

>truncate user;

关闭集群的所有节点

清理commitlog 避免有未提交数据的破坏

把数据目录下的*.db文件删除

把备份目录中的*.db文件放到数据目录中

重启所有节点

在每个节点上执行nodetool repair

$ bin/nodetool -h 192.168.1.2 repair tshop
$ bin/nodetool -h 192.168.1.3 repair tshop
$ bin/nodetool -h 192.168.1.4 repair tshop
$ bin/nodetool -h 192.168.1.5 repair tshop

结果

之前丢失的user数据全部还原成功

实际操作案例（增量备份）

增量备份的数据体积更小，但是备份时间似乎不好控制，先试一下。

首先基于上面一个案例，开启增量备份。

如果有安装OpsCenter 就直接改，否则需要到每个节点上去开启这个配置。

incremental_backups: true

继续往数据库写入数据

insert into user (uid,group_id,nick) values(6,1,'昵称1');
insert into user (uid,group_id,nick) values(7,1,'昵称2');
insert into user (uid,group_id,nick) values(8,1,'昵称3');
insert into user (uid,group_id,nick) values(9,1,'昵称4');
insert into user (uid,group_id,nick) values(10,1,'昵称5');
insert into user (uid,group_id,nick) values(11,1,'昵称6');
insert into user (uid,group_id,nick) values(12,1,'昵称7');
/* 如果有新数据写入，执行flush操作，可以让增量备份作一次备份，但是这并不是总是有效果，有可能当时没有写入数据，不过也意味着距离上次备份不需要再备份新的数据了 */
$ bin/nodetool -h 192.168.1.2 flush tshop
$ bin/nodetool -h 192.168.1.3 flush tshop
$ bin/nodetool -h 192.168.1.4 flush tshop
$ bin/nodetool -h 192.168.1.5 flush tshop

这时候，目录中多了一个backup的目录。

/* 再一次 删除数据，假设是一次意外事故 */
delete from user where uid in (3,4,5,6,7);

我观察了一下backup目录文件，会有多组文件，所谓多组就是这些文件名可能非常相似，只有中间一个数字差别.

$ ls backup-rw-rw-r-- 1 cassandra cassandra   43 Sep  3 18:39 tshop-user-ka-2-CompressionInfo.db
-rw-rw-r-- 1 cassandra cassandra  138 Sep  3 18:39 tshop-user-ka-2-Data.db
-rw-rw-r-- 1 cassandra cassandra    9 Sep  3 18:39 tshop-user-ka-2-Digest.sha1
-rw-rw-r-- 1 cassandra cassandra   16 Sep  3 18:39 tshop-user-ka-2-Filter.db
-rw-rw-r-- 1 cassandra cassandra   54 Sep  3 18:39 tshop-user-ka-2-Index.db
-rw-rw-r-- 1 cassandra cassandra 4442 Sep  3 18:39 tshop-user-ka-2-Statistics.db
-rw-rw-r-- 1 cassandra cassandra   80 Sep  3 18:39 tshop-user-ka-2-Summary.db
-rw-rw-r-- 1 cassandra cassandra   91 Sep  3 18:39 tshop-user-ka-2-TOC.txt-rw-rw-r-- 1 cassandra cassandra   43 Sep  3 18:44 tshop-user-ka-4-CompressionInfo.db
-rw-rw-r-- 1 cassandra cassandra  138 Sep  3 18:44 tshop-user-ka-4-Data.db
-rw-rw-r-- 1 cassandra cassandra    9 Sep  3 18:44 tshop-user-ka-4-Digest.sha1
-rw-rw-r-- 1 cassandra cassandra   16 Sep  3 18:44 tshop-user-ka-4-Filter.db
-rw-rw-r-- 1 cassandra cassandra   54 Sep  3 18:44 tshop-user-ka-4-Index.db
-rw-rw-r-- 1 cassandra cassandra 4442 Sep  3 18:44 tshop-user-ka-4-Statistics.db
-rw-rw-r-- 1 cassandra cassandra   80 Sep  3 18:44 tshop-user-ka-4-Summary.db
-rw-rw-r-- 1 cassandra cassandra   91 Sep  3 18:44 tshop-user-ka-4-TOC.txt

显然有 “2” 组 和 “4” 组，时间一前一后，如果想恢复到18:39分，那么，就别吧“4”组的数据放到数据目录中。这个数字的变化我暂时没有找到一个解释，是不是随着flush操作次数增加而增大？（测试结果是这样的）但是还原操作后，这个数字似乎会回到一个比较小的值。所以用数字判断数据前后应该不靠谱，文件生成时间会靠谱一些，但是反复还原操作后，备份也会混乱。

周期性镜像备份还是不可替代，增量备份可以作为一种粒度更小的时间控制的补充。例如每天一个镜像，最后一个镜像后，开始保留增量。保留最新增量的方法就是在镜像制作完成后，删除所有当前增量备份，这样就是最新了，但是这两个操作间的数据又怎么办？

其他操作和之前镜像还原完全相同。

结果

数据全部还原

这篇关于Cassandra 备份 - 1 - 节点镜像恢复的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1024594。

相关文章

docker 重命名镜像的实现方法

docker 重命名镜像的实现方法

《docker重命名镜像的实现方法》在Docker中无法直接重命名镜像,但可通过添加新标签、删除旧镜像后重新拉取/构建,或在DockerCompose中修改配置文件实现名称变更,感兴趣的可以了解一下... 目录使用标签（Tagging）删除旧的php镜像并重新拉取或构建使用docker Compose在Do
阅读更多...
linux配置podman阿里云容器镜像加速器详解

linux配置podman阿里云容器镜像加速器详解

《linux配置podman阿里云容器镜像加速器详解》本文指导如何配置Podman使用阿里云容器镜像加速器：登录阿里云获取专属加速地址,修改Podman配置文件并移除https://前缀,最后拉取镜像... 目录1.下载podman2.获取阿里云个人容器镜像加速器地址3.更改podman配置文件4.使用po
阅读更多...
Docker多阶段镜像构建与缓存利用性能优化实践指南

Docker多阶段镜像构建与缓存利用性能优化实践指南

《Docker多阶段镜像构建与缓存利用性能优化实践指南》这篇文章将从原理层面深入解析Docker多阶段构建与缓存机制,结合实际项目示例,说明如何有效利用构建缓存,组织镜像层次,最大化提升构建速度并减少... 目录一、技术背景与应用场景二、核心原理深入分析三、关键 dockerfile 解读3.1 Docke
阅读更多...
Python一次性将指定版本所有包上传PyPI镜像解决方案

Python一次性将指定版本所有包上传PyPI镜像解决方案

《Python一次性将指定版本所有包上传PyPI镜像解决方案》本文主要介绍了一个安全、完整、可离线部署的解决方案,用于一次性准备指定Python版本的所有包,然后导出到内网环境,感兴趣的小伙伴可以跟随... 目录为什么需要这个方案完整解决方案1. 项目目录结构2. 创建智能下载脚本3. 创建包清单生成脚本4
阅读更多...
Linux下MySQL数据库定时备份脚本与Crontab配置教学

Linux下MySQL数据库定时备份脚本与Crontab配置教学

《Linux下MySQL数据库定时备份脚本与Crontab配置教学》在生产环境中,数据库是核心资产之一,定期备份数据库可以有效防止意外数据丢失,本文将分享一份MySQL定时备份脚本,并讲解如何通过cr... 目录备份脚本详解脚本功能说明授权与可执行权限使用 Crontab 定时执行编辑 Crontab添加定
阅读更多...
Conda国内镜像源及配置过程

Conda国内镜像源及配置过程

《Conda国内镜像源及配置过程》文章介绍Conda镜像源使用方法,涵盖临时指定单个/多个源、永久配置及恢复默认设置,同时说明main（官方稳定）、free（逐渐弃用）、conda-forge（社区更... 目录一、Conda国内镜像源二、Conda临时使用镜像源指定单个源临时指定多个源创建环境时临时指定源
阅读更多...
MySQL容灾备份的实现方案

MySQL容灾备份的实现方案

《MySQL容灾备份的实现方案》进行MySQL的容灾备份是确保数据安全和业务连续性的关键步骤,容灾备份可以分为本地备份和远程备份,主要包括逻辑备份和物理备份两种方式,下面就来具体介绍一下... 目录一、逻辑备份1. 使用mysqldump进行逻辑备份1.1 全库备份1.2 单库备份1.3 单表备份2. 恢复
阅读更多...
Oracle数据库定时备份脚本方式(Linux)

Oracle数据库定时备份脚本方式(Linux)

《Oracle数据库定时备份脚本方式(Linux)》文章介绍Oracle数据库自动备份方案,包含主机备份传输与备机解压导入流程,强调需提前全量删除原库数据避免报错,并需配置无密传输、定时任务及验证脚本... 目录说明主机脚本备机上自动导库脚本整个自动备份oracle数据库的过程（建议全程用root用户）总结
阅读更多...
使用Python实现可恢复式多线程下载器

使用Python实现可恢复式多线程下载器

《使用Python实现可恢复式多线程下载器》在数字时代,大文件下载已成为日常操作,本文将手把手教你用Python打造专业级下载器,实现断点续传,多线程加速,速度限制等功能,感兴趣的小伙伴可以了解下... 目录一、智能续传：从崩溃边缘抢救进度二、多线程加速：榨干网络带宽三、速度控制：做网络的好邻居四、终端交互
阅读更多...
java实现docker镜像上传到harbor仓库的方式

java实现docker镜像上传到harbor仓库的方式

《java实现docker镜像上传到harbor仓库的方式》：本文主要介绍java实现docker镜像上传到harbor仓库的方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地... 目录1. 前 言2. 编写工具类2.1 引入依赖包2.2 使用当前服务器的docker环境推送镜像2.2
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2