reids持久化，集群如何持久化和恢复数据，高可用持久化

最新推荐文章于 2021-12-06 21:25:24 发布

科氏加速度

最新推荐文章于 2021-12-06 21:25:24 发布

阅读量344

点赞数

分类专栏： redis

本文链接：https://blog.csdn.net/u014203449/article/details/81043875

版权

redis 专栏收录该内容

9 篇文章 1 订阅

订阅专栏

1redis持久化的一些概念

各种方式的优缺点

转载 http://doc.redisfans.com/topic/persistence.html#id13点击打开链接

但在我们目前的线上环境中，由于数据都设置有过期时间，采用AOF的方式会不太实用，过于频繁的写操作会使AOF文件增长到异常的庞大，大大超过了我们实际的数据量，这也会导致在进行数据恢复时耗用大量的时间。
因此，可以在Slave上仅开启Snapshot来进行本地化，同时可以考虑将save中的频率调高一些或者调用一个计划任务来进行定期bgsave的快照存储，来尽可能的保障本地化数据的完整性。
在这样的架构下，如果仅仅是Master挂掉，Slave完整，数据恢复可达到100%。
如果Master与Slave同时挂掉的话，数据的恢复也可以达到一个可接受的程度。

2持久化设置：开启、禁用、存储位置

转载：https://www.cnblogs.com/luotianshuai/p/4969379.html 点击打开链接

默认Redis是开启的RDB模式的持久化的看下面配置文件：

vim /etc/redis/6379.conf

=============================================================

################################ SNAPSHOTTING ################################

#

# Save the DB on disk:

#

# save <seconds> <changes>

#

# Will save the DB if both the given number of seconds and the given

# number of write operations against the DB occurred.

#

# In the example below the behaviour will be to save:

# after 900 sec (15 min) if at least 1 key changed

# after 300 sec (5 min) if at least 10 keys changed

# after 60 sec if at least 10000 keys changed

#

# Note: you can disable saving completely by commenting out all "save" lines.

#

# It is also possible to remove all the previously configured save

# points by adding a save directive with a single empty string argument

# like in the following example:

#

# save ""

save 900 1

save 300 10

save 60 10000

================================================================

上面3个save 是或的关系

# save <seconds> <changes> ###格式！

解释：

# after 900 sec (15 min) if at least 1 key changed

# after 300 sec (5 min) if at least 10 keys changed

# after 60 sec if at least 10000 keys changed

900 sec内有1个key发生了改变就做一次快照

或 300sec 内有10个keys发生了改变做一次快照

或60 sec内 10000 keys发生了改变做一次快照

快照原理：

forker出一个进程，是当前进程的一个副本相当于子进程，不会影响你当前运行的进程。

当子进程写的时候会有一个临时的文件，当子进程写完之后会把这个

临时的文件move替换老的文件，所以这个rdb的文件任何时间都是一个完整的可用的副本！

你写的时候不会影响RDB这个文件，因为forker出的子进程正在写的是一个临时文件！

但是如果如果故障了，你这个保存的时间是你开始快照那一刻那个时间，你快照到快照完毕那一段时间的数据就丢失了！

如果想禁用持久化把这三行删了就行了

save 900 1

save 300 10

save 60 10000

1、快照保存在那里呢？

# The filename where to dump the DB

dbfilename dump.rdb #如果你启用了多个快照名称，可以使用端口好来定义比如：dump_6379.rdb

# Note that you must specify a directory here, not a file name.

dir ./ #不仅仅是RDB模式下的DB存放在这个目录AOF模式下也是存放在这个目录的，建议存放在你指定的地方！

比如：

dir /opt/redis/

比如我上面指定了：

# The filename where to dump the DB

dbfilename dump_6379.rdb

# Note that you must specify a directory here, not a file name.

dir /opt/redis/

2、手动在Redis中保存

127.0.0.1:6379> SET key 1

OK

127.0.0.1:6379> SAVE

OK

下目录下面有没有修改：

-rw-r--r-- 1 root root 27 Oct 14 13:35 dump_6379.rdb 当前时间创建

在设置个key看下：

127.0.0.1:6379> SET key 2

OK

127.0.0.1:6379> SAVE

OK

-rw-r--r-- 1 root root 27 Oct 14 13:37 dump_6379.rdb

127.0.0.1:6379> BGSAVE

Background saving started

SAVE和BGSAVE有什么区别：SAVE 是阻塞的当你直接执行SAVE的时候他就不干活了，BGSAVE是在后台执行。forker一个子进程来进行SAVE！

SAVE的使用场景仅限于：当Redis需要迁移的时候，Redis没有数据写入并且可以停的时候使用！

测试添加一个：key然后停掉看看！不保存：

目前的key是：

127.0.0.1:6379> KEYS *

1) "key"

2) "key2"

3) "key3"

127.0.0.1:6379> SET key4 4

OK

杀掉，重启之后发现设置的key丢失了。

#所以当redis异常挂掉之后，没有SAVE收据！

3、启用了AOF后

给这个文件追加，把所有的命令都写到一个文件里面，你执行一个我写一个。

恢复的话在执行一遍不就行了吗！非常简单（但是恢复相对RDB模式回慢他相当于重新把AOF库里的记录重新往内存中写一边）

可以RDB和AOF同时使用！优点都占用了！但是也的根据业务来定！

开启方法：修改配置文件

appendonly yes #改为yes

appendfilename "appendonly.aof" #文件名

工作原理：

forker 一个子进程写到临时文件，写完之后就给父进程发一个信号，开始写到写完的这个过程还会有子进程给父进程发信号。先保存在内存里

但是他有个好的功能，重写，他会定时对aof进行重新，这样文件就会非常小！

测试：（他会根据Redis可识别的方式写入文件，不过大概人也能看懂）

16:50 [root@192.168.7.107]$ cat appendonly.aof

*2

$6

SELECT

$1

0

*3

$3

SET

$4

kye1

3如何实现高可用

转载：https://www.cnblogs.com/mdxdjh/articles/6853109.html点击打开链接

因为在进行快照的时候，fork出来进行dump操作的子进程会占用与父进程一样的内存，真正的copy-on-write，对性能的影响和内存的耗用都是比较大的。
目前，通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足，达到了数据可持久化。

方案：Redis搭建主从，master禁用RDB和AOF，slave启用RDB，master调用一个计划任务定期bgsave维护快照存储并通过scp传输到slave保存，保障master本地化数据完整性的同时也避免了开启持久化策略带来的性能损失; M/S切换使用哨兵。

master宕机：slave保存了完整的数据。
slive宕机：换一个实例同步master即可。
master和slave同时宕机：可以用slave的RDB备份还原。

4持久化和恢复过程

转载：https://www.cnblogs.com/zhaohaidong/p/6508276.html点击打开链接

使用Replication机制，结合使用rdb和aof方式，Master主节点负责读操作，Slave从节点负责写数据，选择
   Replication机制的其中一种方式，将数据保存在Slava节点，然后利用Slave从节点的rdb文件和aof文件去恢复被
   kill掉的Master节点。
   这种集群Master节点的配置文件的主要部分：
   |----------------------------------------------------------------------------------------------------------------------------------------
   |#save 900 1 #禁用Snapshot
   |#save 300 10
   |#save 60 10000
   |#appendonly no #禁用AOF
   |----------------------------------------------------------------------------------------------------------------------------------------
   Slave节点的配置文件的主要部分：
   |----------------------------------------------------------------------------------------------------------------------------------------
   |save 900 1 #启用Snapshot
   |save 300 10
   |save 60 10000
   |appendonly yes #启用AOF
   |appendfilename appendonly.aof #AOF文件的名称
   |# appendfsync always
   |appendfsync everysec #每秒钟强制写入磁盘一次
   |# appendfsync no
   |no-appendfsync-on-rewrite yes   #在日志重写时，不进行命令追加操作
   |auto-aof-rewrite-percentage 100 #自动启动新的日志重写过程
   |auto-aof-rewrite-min-size 64mb #启动新的日志重写过程的最小值
   |----------------------------------------------------------------------------------------------------------------------------------------
持久化过程：
   在确认主节点Master已经失效的前提下，打包（tar）Slaver结点的rdb和aof文件；将其上传到Master节点下的文
   件夹，同时删除Master目录下初始化Slave的数据文件；然后解压刚才上传的tar包；最后再次启动被kill的Master

节点，至此，Maste节点的数据白恢复。

5案例

单实例：

Redis数据备份

实例

127.0.0.1:6379> bgsave
OK
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "D:\\software\\Redis"
127.0.0.1:6379>
src/redis-cli -p 6379 shutdown
src/redis-server redis.conf
src/redis-server redis.windows.conf
$ src/redis-cli
127.0.0.1:6379> keys *
1) "k1"
2) "k2"
3) "k3"
4) "k4"
5) "k5"

这里为什么用bgsave而不使用save,请参考文章：

redis 持久化详解,RDB是什么？

Redis恢复数据

1、获取redis备份目录

以上命令 CONFIG GET dir 输出的 redis 备份目录为 /usr/local/redis/bin。

2、停止redis服务

src是redis安装目录

3、拷贝redis备份文件（dump.rdb）到 /usr/local/redis/bin目录下

4、重新启动redis服务

linux

windows

5、查看是否redis恢复数据

集群：

转载：https://www.cnblogs.com/linguoguo/p/5430468.html 点击打开链接

既然持久化的数据的作用是用于重启后的数据恢复，那么我们就非常有必要进行一次这样的灾难恢复模拟了。
据称如果数据要做持久化又想保证稳定性，则建议留空一半的物理内存。因为在进行快照的时候，fork出来进行dump操作的子进程会占用与父进程一样的内存，真正的copy-on-write，对性能的影响和内存的耗用都是比较大的。
目前，通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足，达到了数据可持久化。
即Master上Snapshot和AOF都不做，来保证Master的读写性能，而Slave上则同时开启Snapshot和AOF来进行持久化，保证数据的安全性。

首先，修改Master上的如下配置：
$ sudo vim /opt/redis/etc/redis_6379.conf

#save 900 1 #禁用Snapshot
#save 300 10
#save 60 10000

appendonly no #禁用AOF

接着，修改Slave上的如下配置：
$ sudo vim /opt/redis/etc/redis_6379.conf

save 900 1 #启用Snapshot
save 300 10
save 60 10000

appendonly yes #启用AOF
appendfilename appendonly.aof #AOF文件的名称
# appendfsync always
appendfsync everysec #每秒钟强制写入磁盘一次
# appendfsync no  

no-appendfsync-on-rewrite yes   #在日志重写时，不进行命令追加操作
auto-aof-rewrite-percentage 100 #自动启动新的日志重写过程
auto-aof-rewrite-min-size 64mb  #启动新的日志重写过程的最小值

分别启动Master与Slave
$ /etc/init.d/redis start

启动完成后在Master中确认未启动Snapshot参数
redis 127.0.0.1:6379> CONFIG GET save
1) "save"
2) ""

然后通过以下脚本在Master中生成25万条数据：
dongguo@redis:/opt/redis/data/6379$ cat redis-cli-generate.temp.sh

#!/bin/bash

REDISCLI="redis-cli -a slavepass -n 1 SET"
ID=1

while(($ID<50001))
do
  INSTANCE_NAME="i-2-$ID-VM"
  UUID=`cat /proc/sys/kernel/random/uuid`
  PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`\
  CREATED=`date "+%Y-%m-%d %H:%M:%S"`

  $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME"
  $REDISCLI vm_instance:$ID:uuid "$UUID"
  $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS"
  $REDISCLI vm_instance:$ID:created "$CREATED"

  $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID"

  ID=$(($ID+1))
done

dongguo@redis:/opt/redis/data/6379$ ./redis-cli-generate.temp.sh

在数据的生成过程中，可以很清楚的看到Master上仅在第一次做Slave同步时创建了dump.rdb文件，之后就通过增量传输命令的方式给Slave了。
dump.rdb文件没有再增大。
dongguo@redis:/opt/redis/data/6379$ ls -lh
total 4.0K
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb

而Slave上则可以看到dump.rdb文件和AOF文件在不断的增大，并且AOF文件的增长速度明显大于dump.rdb文件。
dongguo@redis-slave:/opt/redis/data/6379$ ls -lh
total 24M
-rw-r--r-- 1 root root 15M Sep 27 12:06 appendonly.aof
-rw-r--r-- 1 root root 9.2M Sep 27 12:06 dump.rdb

等待数据插入完成以后，首先确认当前的数据量。
redis 127.0.0.1:6379> info

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:27623
run_id:e00757f7b2d6885fa9811540df9dfed39430b642
uptime_in_seconds:1541
uptime_in_days:0
lru_clock:650187
used_cpu_sys:69.28
used_cpu_user:7.67
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
connected_clients:1
connected_slaves:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33055824
used_memory_human:31.52M
used_memory_rss:34717696
used_memory_peak:33055800
used_memory_peak_human:31.52M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:0
changes_since_last_save:250000
bgsave_in_progress:0
last_save_time:1348677645
bgrewriteaof_in_progress:0
total_connections_received:250007
total_commands_processed:750019
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:246
vm_enabled:0
role:master
slave0:10.6.1.144,6379,online
db1:keys=250000,expires=0

当前的数据量为25万条key，占用内存31.52M。

然后我们直接Kill掉Master的Redis进程，模拟灾难。
dongguo@redis:/opt/redis/data/6379$ sudo killall -9 redis-server

我们到Slave中查看状态：
redis 127.0.0.1:6379> info

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:13003
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
uptime_in_seconds:1627
uptime_in_days:0
lru_clock:654181
used_cpu_sys:29.69
used_cpu_user:1.21
used_cpu_sys_children:1.70
used_cpu_user_children:1.23
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33047696
used_memory_human:31.52M
used_memory_rss:34775040
used_memory_peak:33064400
used_memory_peak_human:31.53M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:1
changes_since_last_save:3308
bgsave_in_progress:0
last_save_time:1348718951
bgrewriteaof_in_progress:0
total_connections_received:4
total_commands_processed:250308
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:694
vm_enabled:0
role:slave
aof_current_size:17908619
aof_base_size:16787337
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
master_host:10.6.1.143
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
master_link_down_since_seconds:25
slave_priority:100
db1:keys=250000,expires=0

可以看到master_link_status的状态已经是down了，Master已经不可访问了。
而此时，Slave依然运行良好，并且保留有AOF与RDB文件。

下面我们将通过Slave上保存好的AOF与RDB文件来恢复Master上的数据。

首先，将Slave上的同步状态取消，避免主库在未完成数据恢复前就重启，进而直接覆盖掉从库上的数据，导致所有的数据丢失。
redis 127.0.0.1:6379> SLAVEOF NO ONE
OK

确认一下已经没有了master相关的配置信息：
redis 127.0.0.1:6379> INFO

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:13003
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
uptime_in_seconds:1961
uptime_in_days:0
lru_clock:654215
used_cpu_sys:29.98
used_cpu_user:1.22
used_cpu_sys_children:1.76
used_cpu_user_children:1.42
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33047696
used_memory_human:31.52M
used_memory_rss:34779136
used_memory_peak:33064400
used_memory_peak_human:31.53M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:1
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1348719252
bgrewriteaof_in_progress:0
total_connections_received:4
total_commands_processed:250311
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:1119
vm_enabled:0
role:master
aof_current_size:17908619
aof_base_size:16787337
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
db1:keys=250000,expires=0

在Slave上复制数据文件：
dongguo@redis-slave:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *
appendonly.aof
dump.rdb

将data.tar上传到Master上，尝试恢复数据:
可以看到Master目录下有一个初始化Slave的数据文件，很小，将其删除。
dongguo@redis:/opt/redis/data/6379$ ls -l
total 4
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
dongguo@redis:/opt/redis/data/6379$ sudo rm -f dump.rdb

然后解压缩数据文件：
dongguo@redis:/opt/redis/data/6379$ sudo tar xf /home/dongguo/data.tar
dongguo@redis:/opt/redis/data/6379$ ls -lh
total 29M
-rw-r--r-- 1 root root 18M Sep 27 01:22 appendonly.aof
-rw-r--r-- 1 root root 12M Sep 27 01:22 dump.rdb

启动Master上的Redis；
dongguo@redis:/opt/redis/data/6379$ sudo /etc/init.d/redis start
Starting Redis server...

查看数据是否恢复：
redis 127.0.0.1:6379> INFO

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:16959
run_id:6e5ba6c053583414e75353b283597ea404494926
uptime_in_seconds:22
uptime_in_days:0
lru_clock:650292
used_cpu_sys:0.18
used_cpu_user:0.20
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33047216
used_memory_human:31.52M
used_memory_rss:34623488
used_memory_peak:33047192
used_memory_peak_human:31.52M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:0
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1348680180
bgrewriteaof_in_progress:0
total_connections_received:1
total_commands_processed:1
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
vm_enabled:0
role:master
db1:keys=250000,expires=0

可以看到25万条数据已经完整恢复到了Master上。

此时，可以放心的恢复Slave的同步设置了。
redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379
OK

查看同步状态：
redis 127.0.0.1:6379> INFO

redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:13003
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
uptime_in_seconds:2652
uptime_in_days:0
lru_clock:654284
used_cpu_sys:30.01
used_cpu_user:2.12
used_cpu_sys_children:1.76
used_cpu_user_children:1.42
connected_clients:2
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33056288
used_memory_human:31.52M
used_memory_rss:34766848
used_memory_peak:33064400
used_memory_peak_human:31.53M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:1
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1348719252
bgrewriteaof_in_progress:1
total_connections_received:6
total_commands_processed:250313
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:12217
vm_enabled:0
role:slave
aof_current_size:17908619
aof_base_size:16787337
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
master_host:10.6.1.143
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_priority:100
db1:keys=250000,expires=0

master_link_status显示为up，同步状态正常。

在此次恢复的过程中，我们同时复制了AOF与RDB文件，那么到底是哪一个文件完成了数据的恢复呢？
实际上，当Redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存：
1. 如果只配置AOF,重启时加载AOF文件恢复数据；
2. 如果同时配置了RDB和AOF,启动是只加载AOF文件恢复数据;
3. 如果只配置RDB,启动是将加载dump文件恢复数据。

也就是说，AOF的优先级要高于RDB，这也很好理解，因为AOF本身对数据的完整性保障要高于RDB。

在此次的案例中，我们通过在Slave上启用了AOF与RDB来保障了数据，并恢复了Master。

科氏加速度

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
reids持久化，集群如何持久化和恢复数据，高可用持久化

1redis持久化的一些概念各种方式的优缺点转载 http://doc.redisfans.com/topic/persistence.html#id13点击打开链接但在我们目前的线上环境中，由于数据都设置有过期时间，采用AOF的方式会不太实用，过于频繁的写操作会使AOF文件增长到异常的庞大，大大超过了我们实际的数据量，这也会导致在进行数据恢复时耗用大量的时间。因此，可以在Slave...
复制链接

扫一扫