精华内容
下载资源
问答
  • redis数据丢失master宕机导致的数据丢失脑裂导致的数据丢失 master宕机导致的数据丢失 redis持久化 rdb和aof rdb介绍 每60秒如果有1000次写入则在内存里快照一份到磁盘里 每900秒如果有1次写入则在内存里快照一份到...

    master宕机导致的数据丢失

    redis持久化 rdb和aof
    rdb介绍
    每60秒如果有1000次写入则在内存里快照一份到磁盘里
    每900秒如果有1次写入则在内存里快照一份到磁盘里

    save 60 1000
    save 900 1

    AOF
    以日志写命令的方式持久化数据
    首先首先写入命令会写入os cache 中 每秒都会fsync磁盘中(默认设置)

    appendonly yes,可以打开AOF持久化机制

    在哨兵的架构中如果mater服务器挂机则会最多丢失1秒的数据(AOF持久化情况下)

    脑裂导致的数据丢失

    某个master所在机器突然脱离了正常的网络,跟其他slave机器不能连接,但是实际上master还运行着
    此时哨兵可能就会认为master宕机了,然后开启选举,将其他slave切换成了master
    这个时候,集群里就会有两个master,也就是所谓的脑裂
    此时虽然某个slave被切换成了master,但是可能client还没来得及切换到新的master,还继续写向旧master的数据可能也丢失了
    因此旧master再次恢复的时候,会被作为一个slave挂到新的master上去,自己的数据会清空,重新从新的master复制数据

    解决异步复制和脑裂导致的数据丢失

    min-slaves-to-write 1
    min-slaves-max-lag 10

    要求至少有1个slave,数据复制和同步的延迟不能超过10秒

    如果说一旦所有的slave,数据复制和同步的延迟都超过了10秒钟,那么这个时候,master就不会再接收任何请求了

    上面两个配置可以减少异步复制和脑裂导致的数据丢失

    (1)减少异步复制的数据丢失

    有了min-slaves-max-lag这个配置,就可以确保说,一旦slave复制数据和ack延时太长,就认为可能master宕机后损失的数据太多了,那么就拒绝写请求,这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内

    (2)减少脑裂的数据丢失

    如果一个master出现了脑裂,跟其他slave丢了连接,那么上面两个配置可以确保说,如果不能继续给指定数量的slave发送数据,而且slave超过10秒没有给自己ack消息,那么就直接拒绝客户端的写请求

    这样脑裂后的旧master就不会接受client的新数据,也就避免了数据丢失

    上面的配置就确保了,如果跟任何一个slave丢了连接,在10秒后发现没有slave给自己ack,那么就拒绝新的写请求

    因此在脑裂场景下,最多就丢失10秒的数据

    展开全文
  • redis数据丢失你怎么处理?

    千次阅读 2020-07-06 17:18:57
    1. 两种数据丢失的情况 主备切换的过程,可能导致数据丢失; 1.1. 异步复制导致的数据丢 因为master -> slave的复制是异步的,所以可能有部分数据还没复制到slave,master就宕机了,此时这些部分数据就...

    1. 两种数据丢失的情况

    主备切换的过程,可能导致数据丢失;

    1.1. 异步复制导致的数据丢

    redis数据丢失你怎么处理?

     

    因为master -> slave的复制是异步的,所以可能有部分数据还没复制到slave,master就宕机了,此时这些部分数据就丢失了

    1.2 脑裂导致的数据丢失

    redis数据丢失你怎么处理?

     

    脑裂就是说,某个maser 所在机器突然脱离了正常的网络,跟其他slave机器不能连接,但是实际上master还运行着,此时哨兵可能就会认为master 宕机了,然后开启选举,将其他slave切换成了master,这个时候,集群里面就会有2个master,也就是所谓的脑裂,此时虽然某个slave被切换成了master,但是可能client还没来得及切换到新的master,还继续写向旧master的数据可能也丢失了,因此master再次恢复的时候,会被作为一个slave挂到新的master 上去,自己的数据将会清空,重新从新的master 复制数据

    2. 解决异步复制和脑裂数据导致的数据丢失

       # redis.conf 配置
       Min-slaves-to-write 1 
       Min-slaves-max-lag 10
    

    上面这两个配置可以减少异步复制和脑裂导致的数据丢失

    ###2.1 减少异步复制的数据丢失

    有了min-slaves-max-lag这个配置,可以确保说,一旦slave复制数据和ack延迟太长,就认为可能master 宕机后损失的数据太多了,那么就拒绝写请求,这样可以吧master宕机时由于部分数据丢失。

    2.2 减少脑裂的数据丢失

    如果一个master出现了脑裂,跟其他slave丢了连接,那么上面这两个配置可以去确保说,如果不能继续给指定数量的slave发送数据,而且slave超过10秒没有给自己ack消息,那么就直接拒绝客户端的写请求,这样脑裂活的旧master就不会接受client的新数据,也就避免了数据丢失,上面配置确保了,如果跟任何一个slave丢了连接,在10秒后发现没有slave给自己ack,那么就拒绝新的写请求,因此脑裂场景下,最多丢失10秒的数据。

    展开全文
  • Redis数据丢失及解决方案

    千次阅读 2019-04-18 15:36:01
    Redis数据回写机制 Redis数据回写机制分同步和异步两种, 同步回写即SAVE命令,主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间,所以一般不是推荐的。 异步回写即BGSAVE命令,主进程fork...

    Redis的数据回写机制

    Redis的数据回写机制分同步和异步两种,

    1. 同步回写即SAVE命令,主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间,所以一般不是推荐的。
    2. 异步回写即BGSAVE命令,主进程fork后,复制自身并通过这个新的进程回写磁盘,回写结束后新进程自行关闭。由于这样做不需要主进程阻塞,系统不会假死,一般默认会采用这个方法。

    个人感觉方法2采用fork主进程的方式很拙劣,但似乎是唯一的方法。内存中的热数据随时可能修改,要在磁盘上保存某个时间的内存镜像必须要冻结。冻结就会导致假死。fork一个新的进程之后等于复制了当时的一个内存镜像,这样主进程上就不需要冻结,只要子进程上操作就可以了。

    在小内存的进程上做一个fork,不需要太多资源,但当这个进程的内存空间以G为单位时,fork就成为一件很恐怖的操作。何况在16G内存的主机上fork 14G内存的进程呢?肯定会报内存无法分配的。更可气的是,越是改动频繁的主机上fork也越频繁,fork操作本身的代价恐怕也不会比假死好多少。

    找到原因之后,直接修改/etc/sysctl.conf内核参数vm.overcommit_memory= 1

    sysctl -p

    Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。

    1.  如果 vm.overcommit_memory = 1,直接放行
    2. vm.overcommit_memory = 0:则比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上swap,决定是否放行。
    3. vm.overcommit_memory= 2:则会比较进程所有已分配的虚拟内存加上此次请求分配的虚拟内存和系统当前的空闲物理内存加上swap,决定是否放行。

     

    Redis持久化实践及灾难恢复模拟

     

    参考资料:
    Redis Persistence http://redis.io/topics/persistence
    Google Groups https://groups.google.com/forum/?fromgroups=#!forum/redis-db

    一、对Redis持久化的探讨与理解

    目前Redis持久化的方式有两种: RDB 和 AOF

    首先,我们应该明确持久化的数据有什么用,答案是用于重启后的数据恢复。
    Redis是一个内存数据库,无论是RDB还是AOF,都只是其保证数据恢复的措施。
    所以Redis在利用RDB和AOF进行恢复的时候,都会读取RDB或AOF文件,重新加载到内存中。

    RDB就是Snapshot快照存储,是默认的持久化方式。
    可理解为半持久化模式,即按照一定的策略周期性的将数据保存到磁盘。
    对应产生的数据文件为dump.rdb,通过配置文件中的save参数来定义快照的周期。
    下面是默认的快照设置:

    save 900 1    #当有一条Keys数据被改变时,900秒刷新到Disk一次
    save 300 10   #当有10条Keys数据被改变时,300秒刷新到Disk一次
    save 60 10000 #当有10000条Keys数据被改变时,60秒刷新到Disk一次
    

    Redis的RDB文件不会坏掉,因为其写操作是在一个新进程中进行的。
    当生成一个新的RDB文件时,Redis生成的子进程会先将数据写到一个临时文件中,然后通过原子性rename系统调用将临时文件重命名为RDB文件。
    这样在任何时候出现故障,Redis的RDB文件都总是可用的。

    同时,Redis的RDB文件也是Redis主从同步内部实现中的一环。
    第一次Slave向Master同步的实现是:
    Slave向Master发出同步请求,Master先dump出rdb文件,然后将rdb文件全量传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。
    第二次以及以后的同步实现是:
    Master将变量的快照直接实时依次发送给各个Slave。
    但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。
    Redis的主从复制是建立在内存快照的持久化基础上的,只要有Slave就一定会有内存快照发生。

    可以很明显的看到,RDB有它的不足,就是一旦数据库出现问题,那么我们的RDB文件中保存的数据并不是全新的。
    从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。

    AOF(Append-Only File)比RDB方式有更好的持久化性。
    由于在使用AOF持久化方式时,Redis会将每一个收到的写命令都通过Write函数追加到文件中,类似于MySQL的binlog。
    当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
    对应的设置参数为:
    $ vim /opt/redis/etc/redis_6379.conf

    appendonly yes       #启用AOF持久化方式
    appendfilename appendonly.aof #AOF文件的名称,默认为appendonly.aof
    # appendfsync always #每次收到写命令就立即强制写入磁盘,是最有保证的完全的持久化,但速度也是最慢的,一般不推荐使用。
    appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,是受推荐的方式。
    # appendfsync no     #完全依赖OS的写入,一般为30秒左右一次,性能最好但是持久化最没有保证,不被推荐。
    

    AOF的完全持久化方式同时也带来了另一个问题,持久化文件会变得越来越大。
    比如我们调用INCR test命令100次,文件中就必须保存全部的100条命令,但其实99条都是多余的。
    因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。
    为了压缩AOF的持久化文件,Redis提供了bgrewriteaof命令。
    收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中,最后替换原来的文件,以此来实现控制AOF文件的增长。
    由于是模拟快照的过程,因此在重写AOF文件时并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。
    对应的设置参数为:
    $ vim /opt/redis/etc/redis_6379.conf

    no-appendfsync-on-rewrite yes   #在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。
    auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。
    auto-aof-rewrite-min-size 64mb  #当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
    

    到底选择什么呢?下面是来自官方的建议:
    通常,如果你要想提供很高的数据保障性,那么建议你同时使用两种持久化方式。
    如果你可以接受灾难带来的几分钟的数据丢失,那么你可以仅使用RDB。
    很多用户仅使用了AOF,但是我们建议,既然RDB可以时不时的给数据做个完整的快照,并且提供更快的重启,所以最好还是也使用RDB。
    因此,我们希望可以在未来(长远计划)统一AOF和RDB成一种持久化模式。

    在数据恢复方面:
    RDB的启动时间会更短,原因有两个:
    一是RDB文件中每一条数据只有一条记录,不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。
    另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的,不需要再进行数据编码工作,所以在CPU消耗上要远小于AOF日志的加载。

    二、灾难恢复模拟
    既然持久化的数据的作用是用于重启后的数据恢复,那么我们就非常有必要进行一次这样的灾难恢复模拟了。
    据称如果数据要做持久化又想保证稳定性,则建议留空一半的物理内存。因为在进行快照的时候,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。

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

    文章转自:良玉的博客 [http://blog.uouo123.com]

    展开全文
  • redis数据丢失及解决

    千次阅读 2017-09-26 22:02:41
    Redis数据回写机制 Redis数据回写机制分同步和异步两种, 同步回写即SAVE命令,主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间,所以一般不是推荐的。异步回写即BGSAVE命令,主进程...

    Redis的数据回写机制

    Redis的数据回写机制分同步和异步两种,

    1. 同步回写即SAVE命令,主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间,所以一般不是推荐的。
    2. 异步回写即BGSAVE命令,主进程fork后,复制自身并通过这个新的进程回写磁盘,回写结束后新进程自行关闭。由于这样做不需要主进程阻塞,系统不会假死,一般默认会采用这个方法。

    个人感觉方法2采用fork主进程的方式很拙劣,但似乎是唯一的方法。内存中的热数据随时可能修改,要在磁盘上保存某个时间的内存镜像必须要冻结。冻结就会导致假死。fork一个新的进程之后等于复制了当时的一个内存镜像,这样主进程上就不需要冻结,只要子进程上操作就可以了。

    在小内存的进程上做一个fork,不需要太多资源,但当这个进程的内存空间以G为单位时,fork就成为一件很恐怖的操作。何况在16G内存的主机上fork 14G内存的进程呢?肯定会报内存无法分配的。更可气的是,越是改动频繁的主机上fork也越频繁,fork操作本身的代价恐怕也不会比假死好多少。

    找到原因之后,直接修改/etc/sysctl.conf内核参数vm.overcommit_memory= 1

    sysctl -p

    Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。

    1.  如果 vm.overcommit_memory = 1,直接放行
    2. vm.overcommit_memory = 0:则比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上swap,决定是否放行。
    3. vm.overcommit_memory= 2:则会比较进程所有已分配的虚拟内存加上此次请求分配的虚拟内存和系统当前的空闲物理内存加上swap,决定是否放行。

     

    Redis持久化实践及灾难恢复模拟

     

    参考资料:
    Redis Persistence http://redis.io/topics/persistence
    Google Groups https://groups.google.com/forum/?fromgroups=#!forum/redis-db

    一、对Redis持久化的探讨与理解

    目前Redis持久化的方式有两种: RDB 和 AOF

    首先,我们应该明确持久化的数据有什么用,答案是用于重启后的数据恢复。
    Redis是一个内存数据库,无论是RDB还是AOF,都只是其保证数据恢复的措施。
    所以Redis在利用RDB和AOF进行恢复的时候,都会读取RDB或AOF文件,重新加载到内存中。

    RDB就是Snapshot快照存储,是默认的持久化方式。
    可理解为半持久化模式,即按照一定的策略周期性的将数据保存到磁盘。
    对应产生的数据文件为dump.rdb,通过配置文件中的save参数来定义快照的周期。
    下面是默认的快照设置:

    save 900 1    #当有一条Keys数据被改变时,900秒刷新到Disk一次
    save 300 10   #当有10条Keys数据被改变时,300秒刷新到Disk一次
    save 60 10000 #当有10000条Keys数据被改变时,60秒刷新到Disk一次
    

    Redis的RDB文件不会坏掉,因为其写操作是在一个新进程中进行的。
    当生成一个新的RDB文件时,Redis生成的子进程会先将数据写到一个临时文件中,然后通过原子性rename系统调用将临时文件重命名为RDB文件。
    这样在任何时候出现故障,Redis的RDB文件都总是可用的。

    同时,Redis的RDB文件也是Redis主从同步内部实现中的一环。
    第一次Slave向Master同步的实现是:
    Slave向Master发出同步请求,Master先dump出rdb文件,然后将rdb文件全量传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。
    第二次以及以后的同步实现是:
    Master将变量的快照直接实时依次发送给各个Slave。
    但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。
    Redis的主从复制是建立在内存快照的持久化基础上的,只要有Slave就一定会有内存快照发生。

    可以很明显的看到,RDB有它的不足,就是一旦数据库出现问题,那么我们的RDB文件中保存的数据并不是全新的。
    从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。

    AOF(Append-Only File)比RDB方式有更好的持久化性。
    由于在使用AOF持久化方式时,Redis会将每一个收到的写命令都通过Write函数追加到文件中,类似于MySQL的binlog。
    当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
    对应的设置参数为:
    $ vim /opt/redis/etc/redis_6379.conf

    appendonly yes       #启用AOF持久化方式
    appendfilename appendonly.aof #AOF文件的名称,默认为appendonly.aof
    # appendfsync always #每次收到写命令就立即强制写入磁盘,是最有保证的完全的持久化,但速度也是最慢的,一般不推荐使用。
    appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,是受推荐的方式。
    # appendfsync no     #完全依赖OS的写入,一般为30秒左右一次,性能最好但是持久化最没有保证,不被推荐。
    

    AOF的完全持久化方式同时也带来了另一个问题,持久化文件会变得越来越大。
    比如我们调用INCR test命令100次,文件中就必须保存全部的100条命令,但其实99条都是多余的。
    因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。
    为了压缩AOF的持久化文件,Redis提供了bgrewriteaof命令。
    收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中,最后替换原来的文件,以此来实现控制AOF文件的增长。
    由于是模拟快照的过程,因此在重写AOF文件时并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。
    对应的设置参数为:
    $ vim /opt/redis/etc/redis_6379.conf

    no-appendfsync-on-rewrite yes   #在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。
    auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。
    auto-aof-rewrite-min-size 64mb  #当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
    

    到底选择什么呢?下面是来自官方的建议:
    通常,如果你要想提供很高的数据保障性,那么建议你同时使用两种持久化方式。
    如果你可以接受灾难带来的几分钟的数据丢失,那么你可以仅使用RDB。
    很多用户仅使用了AOF,但是我们建议,既然RDB可以时不时的给数据做个完整的快照,并且提供更快的重启,所以最好还是也使用RDB。
    因此,我们希望可以在未来(长远计划)统一AOF和RDB成一种持久化模式。

    在数据恢复方面:
    RDB的启动时间会更短,原因有两个:
    一是RDB文件中每一条数据只有一条记录,不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。
    另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的,不需要再进行数据编码工作,所以在CPU消耗上要远小于AOF日志的加载。

    二、灾难恢复模拟
    既然持久化的数据的作用是用于重启后的数据恢复,那么我们就非常有必要进行一次这样的灾难恢复模拟了。
    据称如果数据要做持久化又想保证稳定性,则建议留空一半的物理内存。因为在进行快照的时候,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。

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

    redis数据丢失及解决【转】

    展开全文
  • docker run -p 6379:6379 -d -v /windows盘符/指定的文件夹路径:/data redis:5.0 redis-server –appendonly yes 多看官方文档,里面有详细的说明 补充知识:docker 挂载进容器的文件修改后没有改变需要重启 今天...
  • Linux Redis 重启数据丢失解决方案,Linux重启后Redis数据丢失解决方 一、问题说明 在Linux系统中,Redis本来是有数据的,但在Linux系统重启后,Redis中的数据全部丢失。经过几次测试都一样,只有在Linux系统重启才...
  • 直接上解决方案: 1.找到 /etc/sysctl.conf vim /etc/sysctl.conf 2.在最后一行添加 vm.overcommit_memory = 1 3.wq保存,用sysctl -p 使配置生效 ...以后linux服务器在重启,redis数据就不会丢了。 ...
  • redis数据丢失问题的分析

    千次阅读 2017-07-19 10:41:26
    问题描述:是指系统宕机后,存储在内存中并且尚未写入磁盘的数据丢失掉。 解决方案:同时使用RDB 和 AOF两种持久化方式,redis/etc/redis_6379.conf文件配置如下: save 300 10 #当有10条Keys数据被改变时,300秒...
  • 解决Linux重启redis数据丢失

    千次阅读 2017-08-24 09:54:53
    在Linux系统中,Redis本来是有数据的,但在Linux系统重启后,Redis中的数据全部丢失。经过几次测试都一样,只有在Linux系统重启才会丢失Redis重启应该是没有问题的。这个问题只在Linux系统才存在,在Windows系统是...
  • Redis持久化策略(防止数据丢失) 首先,redis在内存中运行,如果redis服务器突然关闭,那么内存数据就会丢失。如何解决????? 解决方案: 可以定期将内存数据持久化到磁盘中. 持久化策略规则: 当redis正常运行时...
  • redis 日志 : 7464:C 23 Apr 11:23:14.195 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 7464:C 23 Apr 11:23:14.195 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=7464, just ...
  • linux服务器重启导致redis数据丢失

    万次阅读 2018-03-08 14:33:56
    1.需求分析 当linux服务器重启后,然后开启redis服务器,结果会发现redis之前存储的数据会部分丢失甚至全部丢失;...然后通过追加定位,才发现是redis中的数据丢失导致key不存在,最终致使定时任务无...
  • Redis 数据丢失” 问题

    千次阅读 2018-06-20 10:57:26
    Redis大部分应用场景是纯缓存服务,请求后端有Primary Storage的组件,如MySQL,HBase;...但现在Redis用作存储的业务场景变多,数据丢失对业务是致命的影响。本文简单讨论Redis常见数据”丢失“现象,以...
  • http://note.youdao.com/noteshare?id=665ae87106d1021330362d6fb0318e44
  • Redis大部分应用场景是纯缓存服务,请求后端有Primary Storage的组件,如MySQL,HBase;...但现在Redis用作存储的业务场景变多,数据丢失对业务是致命的影响。 下面简单讨论几个Redis常见数据"丢失"现...
  • 异步复制导致的数据丢失: 描述: 由于master到slave的数据同步是异步的,也就是说master有请求时,master先反馈给客户端,然后才会向slave同步数据。期间可能存在部分数据还没有同步到slave,master就宕机了,...
  • Redis重启数据丢失问题

    千次阅读 2019-03-04 15:23:44
    在Linux系统中,Redis本来是有数据的,但在Linux系统重启后,Redis中的数据全部丢失。经过几次测试都一样,只有在Linux系统重启才会丢失Redis重启应该是没有问题的。 这个问题只在Linux系统才存在,在Windows系统...
  • Redis数据丢失”问题

    万次阅读 2016-09-19 09:16:08
    from: ...Redis数据丢失”问题 发表于 2016-08-14 | 分类于 Redis  | 17条评论 
  • 1.由于网络故障导致的脑裂问题,还有个什么问题去了,明天再看。 2.主从模式、哨兵模式、redis cluster的优缺点,尤其是哨兵模式和redis cluster的一些细节上也要说。
  • 因为之前我启动redis服务器是直接进入redis目录下启动redis-server.exe这个文件的,这样的启动方式会导致redis服务器忽略配置文件中的配置(redis.windows.conf)。如果要避免,应该使用cmd到redis文件下,输入redis...
  • linux redis服务未重启 数据丢失。。。。。。。。。。。。。。。。。。。。。。。。。。。
  • 从哲学的角度看,只要绝对都是伪命题,使用Redis主从架构+Sentinal(哨兵)组件,绝对不能够完全保证数据不丢失,那么在那种情况下会出现数据丢失呢? 数据丢失场景分析-异步复制 我们都知道,Redis主从架构中,...
  • Linux Redis重启数据丢失解决办法

    千次阅读 2018-09-17 17:17:54
    https://blog.csdn.net/fenyuduanchangren/article/details/55261101 https://blog.csdn.net/qq_32351227/article/details/77523751
  • 最近在Win10系统下使用redis数据库,遇到一个问题,当redis服务器关闭后再开启,原本存在里面的数据丢失。 查找原因,原来是因为我启动redis服务器是直接进入redis目录下启动redis-server.exe这个文件的,这样的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 86,573
精华内容 34,629
关键字:

redis数据丢失

redis 订阅