存储快照

你只管努力， ——剩下的交给时光。 首先我们带着问题来学习 1、什么是Redis？为什么要用它？用它有什么好处？ Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦 可持久化的日志型、Key-Value数据库 ，并提供多种语言的API。它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets) 等类型。以上标红为Redis常用数据类型。 2、Redis的安装 安装教程 Windows安装 在 https://github.com/MSOpenTech/redis/releases 地址下载后解压，打开命令行进入解压目录运行 redis-server.exe redis.conf（省略则使用默认） 出现下图服务就已经启动成功了 Linux安装 在https://redis.io/地址下载最新版 解压：$ tar -xzf redis-4.0.11.tar.gz 进入解压后目录：$ cd redis-4.0.11 编译：$ make 进入src目录启动服务器：$ cd src $ ./redis-server 配置 Redis 的配置文件位于 Redis 安装目录下，文件名为 redis.conf。 可以通过 CONFIG

持久化机制 1. Redis的持久化机制 1.1 RDB持久化 1.2 AOF 2. redis.conf 其他笔记资料 1. Redis的持久化机制 1.1 RDB持久化 指定时间间隔内将内存的 数据集快照 写入磁盘 如果已经存在这个数据库，下一次加载的时候就很快 设置相关的 redis.conf （ daemonize yes ; 快照压缩文件的目录 dir /var/redis ; 以及快照的频率） 启动redis-server,并打开其他的会话窗口，此时、/var/redis并没有快照文件 利用 ./bin/redis-benchmark -n 100000 利用测试进程， 在再另一会话窗口下的/var/redis下面发现 dump.rdb 快照文件 关闭服务端redis进程 kill -9 进程号 查看redis当前是否存在该进程 ps -ef | grep redis 是一种持久化的机制，就是服务器关闭后在启动，操作的内容是不会消失的。但是是一定时间间隔内才可能会快照记录，可能会导致某些数据的丢失 。 1.2 AOF 以 日志的形式记录 服务器所处理的每一个 写操作 ，在redis服务器启动之初会读取该文件来重新构建数据库。 更加保证了数据不会丢失。因为他的每一次操作都有记录。 rdb持久化模式可能会导致部分的数据丢失，rdb与aof可以一起同时存在

转自： http://www.cnblogs.com/zhoujinyi/archive/2013/05/26/3098508.html 一、对Redis持久化的探讨与理解 redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持两种持久化方式，一种是 Snapshot（RDB）<二进制文件> 也是默认方式，另一种是Append only file（AOF）的方式。具体的理论说明请见 这里 。 我们应该明确持久化的数据有什么用，答案是用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以Redis在利用RDB和AOF进行恢复的时候，都会读取RDB或AOF文件，重新加载到内存中。 RDB 就是Snapshot快照存储，是默认的持久化方式。即按照一定的策略周期性的将数据保存到磁盘。对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。Redis支持将当前数据的快照存成一个数据文件的持久化机制。而一个持续写入的数据库如何生成快照呢。Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。 Client

恰当地设定 Redis 服务器参数，才能保证服务器正确、高性能、安全地运转。通过这些参数，我们还能了解 Redis 服务器内部运转的机制和细节。同时，主从复制和 Redis 集群的部署也要掌握相关配置项。 作者： 王克锋 出处： https://kefeng.wang/2017/08/12/redis-config/ 版权： 自由转载-非商用-非衍生-保持署名 ，转载请标明作者和出处。 1 配置概述 官方文档： Redis 配置 ， redis.conf 1.1 配置项格式 格式： keyword argument1 argument2 ... argumentN 例子： slaveof 127.0.0.1 6379 一个参数名称，后跟1至多个参数值，名称与各值之间以空格分隔。 如果单个值内包含空格，该值必须以双引号界定。 1.2 容量值的形式 有三种格式，单位里的字母大小写无关，比如 kb/kB/Kb/KB 是一样的。 没有单位：单位为字节，比如 4096 表示 4096 字节 无b单位： 1k =1000 字节， 1m =1000x1000 字节， 1g =1000x1000x1000 字节 带b单位： 1kb =1024 字节， 1mb =1024x1024 字节， 1gb =1024x1024x1024 字节 1.3 参数传递方式 服务启动命令行： redis-server

Redis进阶:Redis的持久化机制 Redis的持久化机制目前包括RBD和AOF两种方式。 RDB持久化 RDB持久化方式是在指定的时间间隔对数据进行快照存储。过期的键值不会被存储到快照中。如果恢复数据时数据已过期，会通过主动或被动清理策略进行删除。 优点：性能影响小，恢复速度快。与AOF相比，在回复大数据量时，速度更快。 缺点：save是阻塞式创建快照，如果数据大会影响其他命令的响应。 强行关闭或者出现故障的情况下 ，会存在数据丢失的情况。 //创建子线程异步将快照写入磁盘 bgsave //阻塞式存储快照，执行该命令时，不在响应其他指令 save // Redis.Config 可以对save配置进行调整。两个条件满足一个都会触发生成快照。 save 900 1 //900S内 至少1次写操作 触发 快照 save 300 10 //300S内 至少10次写操作 触发 快照 save 60 10000 //60S内 至少10000次写操作 触发 快照 AOF持久化 记录每次对服务器写的操作。服务器重启时会重新执行命令来恢复数据。AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大. 优点：安全 容灾 备份文件易读可修改。 缺点：备份文件占用空间大，恢复速度比RDB较慢。 开启： redis

对 https://arxiv.org/abs/1506.08603 （Lightweight Asynchronous Snapshots for Distributed Dataflows） 的翻译和自己理解。 前言 这边文章讲述的是flink的checkpoint（检查点）的原理，checkpoint是目前主流的分布式流式处理框架用于恢复失败作业而保证数据不丢失的常用方法，也是flink实现exactly-once的基础。 以checkpoint为基础，定期生成全局的状态快照（global stat snapshot），当出现作业失败，将集群状态恢复到上一个可用的global stat snapshot再开始继续计算，从而保证数据不丢失。 同时这个“checkpoint/snapshot”还必须尽可能不影响正常的流式计算过程，不能说在生成“checkpoint/snapshot”的时候，对整个集群的处理速度有很大影响，甚至停下来（文章中举了一个反例，叫Naiad，这个不了解），那么这种方案等同于不可用。 这篇文章就是介绍了一种轻量级异步快照，叫做ABS（Asynchronous Barrier Snapshotting）。Flink就是采用了这种方法。 定义 Flink把流式计算编译成任务的有向图，比如下图的最基础的wordcount任务图：总共有三个阶段：输入阶段

ceph中rbd的增量备份和恢复 ceph的文档地址： Ceph Documentation ​ 在调研OpenStack中虚机的备份和恢复时，发现OpenStack和ceph紧密结合，使用ceph做OpenStack的后端简直是不要太爽，于是调研了使用ceph中的块设备rbd来对虚机进行增量备份和恢复。以下是虚机备份和恢复的实验步骤： 1. 前言： ​ 快照 的功能一般是基于时间点做一个标记，然后在某些需要的时候，将状态恢复到标记的那个点，这个有一个前提是 底层的数据没有破坏 ，举个简单的例子， Vmware 里面对虚拟机做了一个快照，然后做了一些系统的操作，想恢复快照，前提是存储快照的存储系统没用破坏，一旦破坏了是无法恢复的。 ​ ceph也有快照功能，同样，在这里的快照是用来保存存储系统上的状态的，数据的快照能成功恢复的前提是存储系统是好的，而一旦存储系统坏了，快照同时会失效的，所以最好是能够将数据备份下来。本篇博客主要是调研使用ceph的rbd命令来对存储设备进行基于快照的增量备份。 2. ceph中rbd的常用命令： 2.1列出存储池 ceph osd pool ls 2.2 查看存储池的内容 rbd ls --pool pool_name 例子 rbd ls --pool volumes 2.3 打快照 rbd snap create {pool-name}/

1.快照 在VMware虚拟环境，做完Linux的基础优化和设置后，可以对Linux主机做一个快照，然后当做 模板机 永久保留。 以后再需要学习时，可以克隆一个新的机器使用，系统安装和优化时较为简单的操作，没必要多次重复操作。 2.克隆 克隆有两种方法： 链接克隆 链接克隆是对原始机的引用，所需的存储磁盘空间较少。但是，必须能够访问原始虚拟机才能运行 完整克隆 完整克隆是原始虚拟机当前状态的完整副本，此副本虚拟机完全独立，但需要较多的存储磁盘空间 链接克隆占用磁盘小，学习一般使用链接克隆机。 缺点是，模板机出问题，所有链接克隆机全部出问题。 VMware虚拟机安装好CentOS系统后，纯净的系统多克隆几份出来方便后期做试验。 克隆步骤很简单，克隆后出现的问题是 克隆后的网卡MAC地址和原系统MAC地址一样 ，在局域网内会有冲突，需要 更改克隆后的MAC地址 。 不过，在克隆虚拟机和使用的过程中也会遇到一些问题。 启动之后使用ifconfig，发现无IP地址，只有回环地址为127.0.0.1 考虑是否因为MAC/IP地址及主机名都与克隆前的源主机相同（源主机采用手动方式配置的IP）而产生此问题 修改IP地址和MAC地址后，执行重启命令后无效：/etc/init.d/network restart; ifup eth0 最终解决方法 ： 编辑网卡对应的eth0的配置文件: vi

查看zookeeper事务日志正确姿势 用vi打开发现乱码，查资料发现说是文件里是二进制。zoo.cfg中可以通过dataLogDir来配置zookeeper的事务日志的输出目录。但是这些日志文件是二进制的，无法通过普通的查看名单看。需要通过org.apache.zookeeper.server.LogFormatter。姿势如下 1.在Linux中 命令如下： java -cp :/ .. ./slf4j-api-1.7.2.jar:/ .. ./zookeeper-3.4.6.jar org.apache.zookeeper.server.LogFormatter / .. .dataLogDir/version-2/log.1 或 java -classpath :./slf4j-api-1.7.2.jar:./zookeeper-3.4.6.jar org.apache.zookeeper.server.LogFormatter log.1700000001 第二个命令 在window中 java -classpath ".;*" org.apache.zookeeper.server.LogFormatter log.1700000001 这是把所需jar和文件放到当前目录下的 补充知识 以log.****文件开头的是zookeeper的事务文件，每个文件大小是64m

zoo.cfg中可以通过dataLogDir来配置zookeeper的事务日志的输出目录。但是这些日志文件是二进制的，无法通过普通的查看名单看。需要通过org.apache.zookeeper.server.LogFormatter。 命令如下： java -cp :/usr/local/zookeeper/zookeeper/lib/slf4j-api-1.6.1.jar:/usr/local/zookeeper/zookeeper/zookeeper-3.4.11.jar org.apache.zookeeper.server.LogFormatter /usr/local/zookeeper/zookeeper/dataLogDir/version-2/log.1 以下转自： https://www.linuxidc.com/Linux/2016-03/129509.htm ZooKeeper日志与快照文件简单分析 有用过Zookeeper的都知道zoo.cfg配置文件中有dataDir配置项用于存储数据，不过可能有些人不太清楚这个目录具体存储的是那些数据，默认情况下这个目录是用于存储Log（事务日志）与Snapshot（快照）数据，但是Zookeeper还提供了一个用于Log存储目录的配置项dataLogDir而dataDir用于存储Snapshot数据