轉(zhuǎn)載自?http://www.cnblogs.com/hs8888/p/5520495.html

Redis的數(shù)據(jù)回寫機(jī)制

Redis的數(shù)據(jù)回寫機(jī)制分同步和異步兩種，

同步回寫即SAVE命令，主進(jìn)程直接向磁盤回寫數(shù)據(jù)。在數(shù)據(jù)大的情況下會(huì)導(dǎo)致系統(tǒng)假死很長(zhǎng)時(shí)間，所以一般不是推薦的。

異步回寫即BGSAVE命令，主進(jìn)程fork后，復(fù)制自身并通過這個(gè)新的進(jìn)程回寫磁盤，回寫結(jié)束后新進(jìn)程自行關(guān)閉。由于這樣做不需要主進(jìn)程阻塞，系統(tǒng)不會(huì)假死，一般默認(rèn)會(huì)采用這個(gè)方法。

個(gè) 人感覺方法２采用fork主進(jìn)程的方式很拙劣，但似乎是唯一的方法。內(nèi)存中的熱數(shù)據(jù)隨時(shí)可能修改，要在磁盤上保存某個(gè)時(shí)間的內(nèi)存鏡像必須要凍結(jié)。凍結(jié)就會(huì) 導(dǎo)致假死。 fork一個(gè)新的進(jìn)程之后等于復(fù)制了當(dāng)時(shí)的一個(gè)內(nèi)存鏡像，這樣主進(jìn)程上就不需要凍結(jié)，只要子進(jìn)程上操作就可以了。

在小內(nèi)存的 進(jìn)程上做一個(gè)fork,不需要太多資源，但當(dāng)這個(gè)進(jìn)程的內(nèi)存空間以Ｇ為單位時(shí)，fork就成為一件很恐怖的操作。何況在16G內(nèi)存的主機(jī)上fork 14G內(nèi)存的進(jìn)程呢？肯定會(huì)報(bào)內(nèi)存無法分配的。更可氣的是，越是改動(dòng)頻繁的主機(jī)上fork也越頻繁，fork操作本身的代價(jià)恐怕也不會(huì)比假死好多少。

找到原因之后，直接修改/etc/sysctl.conf內(nèi)核參數(shù)vm.overcommit_memory= 1

sysctl -p

Linux內(nèi)核會(huì)根據(jù)參數(shù)vm.overcommit_memory參數(shù)的設(shè)置決定是否放行。

?如果 vm.overcommit_memory = 1，直接放行

vm.overcommit_memory = 0：則比較 此次請(qǐng)求分配的虛擬內(nèi)存大小和系統(tǒng)當(dāng)前空閑的物理內(nèi)存加上swap，決定是否放行。

vm.overcommit_memory= 2：則會(huì)比較進(jìn)程所有已分配的虛擬內(nèi)存加上此次請(qǐng)求分配的虛擬內(nèi)存和系統(tǒng)當(dāng)前的空閑物理內(nèi)存加上swap，決定是否放行。

Redis持久化實(shí)踐及災(zāi)難恢復(fù)模擬

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

一、對(duì)Redis持久化的探討與理解

目前Redis持久化的方式有兩種： RDB 和 AOF

首先，我們應(yīng)該明確持久化的數(shù)據(jù)有什么用，答案是用于重啟后的數(shù)據(jù)恢復(fù)。
Redis是一個(gè)內(nèi)存數(shù)據(jù)庫，無論是RDB還是AOF，都只是其保證數(shù)據(jù)恢復(fù)的措施。
所以Redis在利用RDB和AOF進(jìn)行恢復(fù)的時(shí)候，都會(huì)讀取RDB或AOF文件，重新加載到內(nèi)存中。

RDB就是Snapshot快照存儲(chǔ)，是默認(rèn)的持久化方式。
可理解為半持久化模式，即按照一定的策略周期性的將數(shù)據(jù)保存到磁盤。
對(duì)應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb，通過配置文件中的save參數(shù)來定義快照的周期。
下面是默認(rèn)的快照設(shè)置：

save 900 1 #當(dāng)有一條Keys數(shù)據(jù)被改變時(shí)，900秒刷新到Disk一次 save 300 10 #當(dāng)有10條Keys數(shù)據(jù)被改變時(shí)，300秒刷新到Disk一次 save 60 10000 #當(dāng)有10000條Keys數(shù)據(jù)被改變時(shí)，60秒刷新到Disk一次

Redis的RDB文件不會(huì)壞掉，因?yàn)槠鋵懖僮魇窃谝粋€(gè)新進(jìn)程中進(jìn)行的。
當(dāng)生成一個(gè)新的RDB文件時(shí)，Redis生成的子進(jìn)程會(huì)先將數(shù)據(jù)寫到一個(gè)臨時(shí)文件中，然后通過原子性rename系統(tǒng)調(diào)用將臨時(shí)文件重命名為RDB文件。
這樣在任何時(shí)候出現(xiàn)故障，Redis的RDB文件都總是可用的。

同時(shí)，Redis的RDB文件也是Redis主從同步內(nèi)部實(shí)現(xiàn)中的一環(huán)。
第一次Slave向Master同步的實(shí)現(xiàn)是：
Slave向Master發(fā)出同步請(qǐng)求，Master先dump出rdb文件，然后將rdb文件全量傳輸給slave，然后Master把緩存的命令轉(zhuǎn)發(fā)給Slave，初次同步完成。
第二次以及以后的同步實(shí)現(xiàn)是：
Master將變量的快照直接實(shí)時(shí)依次發(fā)送給各個(gè)Slave。
但不管什么原因?qū)е耂lave和Master斷開重連都會(huì)重復(fù)以上兩個(gè)步驟的過程。
Redis的主從復(fù)制是建立在內(nèi)存快照的持久化基礎(chǔ)上的，只要有Slave就一定會(huì)有內(nèi)存快照發(fā)生。

可以很明顯的看到，RDB有它的不足，就是一旦數(shù)據(jù)庫出現(xiàn)問題，那么我們的RDB文件中保存的數(shù)據(jù)并不是全新的。
從上次RDB文件生成到Redis停機(jī)這段時(shí)間的數(shù)據(jù)全部丟掉了。

AOF(Append-Only File)比RDB方式有更好的持久化性。
由于在使用AOF持久化方式時(shí)，Redis會(huì)將每一個(gè)收到的寫命令都通過Write函數(shù)追加到文件中，類似于MySQL的binlog。
當(dāng)Redis重啟是會(huì)通過重新執(zhí)行文件中保存的寫命令來在內(nèi)存中重建整個(gè)數(shù)據(jù)庫的內(nèi)容。
對(duì)應(yīng)的設(shè)置參數(shù)為：
$ vim /opt/redis/etc/redis_6379.conf

appendonly yes #啟用AOF持久化方式 appendfilename appendonly.aof #AOF文件的名稱，默認(rèn)為appendonly.aof # appendfsync always #每次收到寫命令就立即強(qiáng)制寫入磁盤，是最有保證的完全的持久化，但速度也是最慢的，一般不推薦使用。 appendfsync everysec #每秒鐘強(qiáng)制寫入磁盤一次，在性能和持久化方面做了很好的折中，是受推薦的方式。 # appendfsync no #完全依賴OS的寫入，一般為30秒左右一次，性能最好但是持久化最沒有保證，不被推薦。

AOF的完全持久化方式同時(shí)也帶來了另一個(gè)問題，持久化文件會(huì)變得越來越大。
比如我們調(diào)用INCR test命令100次，文件中就必須保存全部的100條命令，但其實(shí)99條都是多余的。
因?yàn)橐謴?fù)數(shù)據(jù)庫的狀態(tài)其實(shí)文件中保存一條SET test 100就夠了。
為了壓縮AOF的持久化文件，Redis提供了bgrewriteaof命令。
收到此命令后Redis將使用與快照類似的方式將內(nèi)存中的數(shù)據(jù)以命令的方式保存到臨時(shí)文件中，最后替換原來的文件，以此來實(shí)現(xiàn)控制AOF文件的增長(zhǎng)。
由于是模擬快照的過程，因此在重寫AOF文件時(shí)并沒有讀取舊的AOF文件，而是將整個(gè)內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個(gè)新的AOF文件。
對(duì)應(yīng)的設(shè)置參數(shù)為:
$ vim /opt/redis/etc/redis_6379.conf

no-appendfsync-on-rewrite yes #在日志重寫時(shí)，不進(jìn)行命令追加操作，而只是將其放在緩沖區(qū)里，避免與命令的追加造成DISK IO上的沖突。 auto-aof-rewrite-percentage 100 #當(dāng)前AOF文件大小是上次日志重寫得到AOF文件大小的二倍時(shí)，自動(dòng)啟動(dòng)新的日志重寫過程。 auto-aof-rewrite-min-size 64mb #當(dāng)前AOF文件啟動(dòng)新的日志重寫過程的最小值，避免剛剛啟動(dòng)Reids時(shí)由于文件尺寸較小導(dǎo)致頻繁的重寫。

到底選擇什么呢？下面是來自官方的建議：
通常，如果你要想提供很高的數(shù)據(jù)保障性，那么建議你同時(shí)使用兩種持久化方式。
如果你可以接受災(zāi)難帶來的幾分鐘的數(shù)據(jù)丟失，那么你可以僅使用RDB。
很多用戶僅使用了AOF，但是我們建議，既然RDB可以時(shí)不時(shí)的給數(shù)據(jù)做個(gè)完整的快照，并且提供更快的重啟，所以最好還是也使用RDB。
因此，我們希望可以在未來（長(zhǎng)遠(yuǎn)計(jì)劃）統(tǒng)一AOF和RDB成一種持久化模式。

在數(shù)據(jù)恢復(fù)方面：
RDB的啟動(dòng)時(shí)間會(huì)更短，原因有兩個(gè)：
一是RDB文件中每一條數(shù)據(jù)只有一條記錄，不會(huì)像AOF日志那樣可能有一條數(shù)據(jù)的多次操作記錄。所以每條數(shù)據(jù)只需要寫一次就行了。
另一個(gè)原因是RDB文件的存儲(chǔ)格式和Redis數(shù)據(jù)在內(nèi)存中的編碼格式是一致的，不需要再進(jìn)行數(shù)據(jù)編碼工作，所以在CPU消耗上要遠(yuǎn)小于AOF日志的加載。

二、災(zāi)難恢復(fù)模擬
既然持久化的數(shù)據(jù)的作用是用于重啟后的數(shù)據(jù)恢復(fù)，那么我們就非常有必要進(jìn)行一次這樣的災(zāi)難恢復(fù)模擬了。
據(jù)稱如果數(shù)據(jù)要做持久化又想保證穩(wěn)定性，則建議留空一半的物理內(nèi)存。因?yàn)樵谶M(jìn)行快照的時(shí)候，fork出來進(jìn)行dump操作的子進(jìn)程會(huì)占用與父進(jìn)程一樣的內(nèi)存，真正的copy-on-write，對(duì)性能的影響和內(nèi)存的耗用都是比較大的。
目前，通常的設(shè)計(jì)思路是利用Replication機(jī)制來彌補(bǔ)aof、snapshot性能上的不足，達(dá)到了數(shù)據(jù)可持久化。
即Master上Snapshot和AOF都不做，來保證Master的讀寫性能，而Slave上則同時(shí)開啟Snapshot和AOF來進(jìn)行持久化，保證數(shù)據(jù)的安全性。

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

#save 900 1 #禁用Snapshot #save 300 10 #save 60 10000appendonly no #禁用AOF

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

save 900 1 #啟用Snapshot save 300 10 save 60 10000appendonly yes #啟用AOF appendfilename appendonly.aof #AOF文件的名稱 # appendfsync always appendfsync everysec #每秒鐘強(qiáng)制寫入磁盤一次 # appendfsync no no-appendfsync-on-rewrite yes #在日志重寫時(shí)，不進(jìn)行命令追加操作 auto-aof-rewrite-percentage 100 #自動(dòng)啟動(dòng)新的日志重寫過程 auto-aof-rewrite-min-size 64mb #啟動(dòng)新的日志重寫過程的最小值

分別啟動(dòng)Master與Slave
$ /etc/init.d/redis start

啟動(dòng)完成后在Master中確認(rèn)未啟動(dòng)Snapshot參數(shù)
redis 127.0.0.1:6379> CONFIG GET save
1) "save"
2) ""

然后通過以下腳本在Master中生成25萬條數(shù)據(jù)：
dongguo@redis:/opt/redis/data/6379$ cat redis-cli-generate.temp.sh

#!/bin/bashREDISCLI="redis-cli -a slavepass -n 1 SET" ID=1while(($ID<50001)) doINSTANCE_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

在數(shù)據(jù)的生成過程中，可以很清楚的看到Master上僅在第一次做Slave同步時(shí)創(chuàng)建了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文件的增長(zhǎng)速度明顯大于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

等待數(shù)據(jù)插入完成以后，首先確認(rèn)當(dāng)前的數(shù)據(jù)量。
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

當(dāng)前的數(shù)據(jù)量為25萬條key，占用內(nèi)存31.52M。

然后我們直接Kill掉Master的Redis進(jìn)程，模擬災(zāi)難。
dongguo@redis:/opt/redis/data/6379$ sudo killall -9 redis-server

我們到Slave中查看狀態(tài)：
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的狀態(tài)已經(jīng)是down了，Master已經(jīng)不可訪問了。
而此時(shí)，Slave依然運(yùn)行良好，并且保留有AOF與RDB文件。

下面我們將通過Slave上保存好的AOF與RDB文件來恢復(fù)Master上的數(shù)據(jù)。

首先，將Slave上的同步狀態(tài)取消，避免主庫在未完成數(shù)據(jù)恢復(fù)前就重啟，進(jìn)而直接覆蓋掉從庫上的數(shù)據(jù)，導(dǎo)致所有的數(shù)據(jù)丟失。
redis 127.0.0.1:6379> SLAVEOF NO ONE
OK

確認(rèn)一下已經(jīng)沒有了master相關(guān)的配置信息：
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上復(fù)制數(shù)據(jù)文件：
dongguo@redis-slave:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *
appendonly.aof
dump.rdb

將data.tar上傳到Master上，嘗試恢復(fù)數(shù)據(jù):
可以看到Master目錄下有一個(gè)初始化Slave的數(shù)據(jù)文件，很小，將其刪除。
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

然后解壓縮數(shù)據(jù)文件：
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

啟動(dòng)Master上的Redis；
dongguo@redis:/opt/redis/data/6379$ sudo /etc/init.d/redis start
Starting Redis server...

查看數(shù)據(jù)是否恢復(fù)：
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萬條數(shù)據(jù)已經(jīng)完整恢復(fù)到了Master上。

此時(shí)，可以放心的恢復(fù)Slave的同步設(shè)置了。
redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379
OK

查看同步狀態(tài)：
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，同步狀態(tài)正常。

在此次恢復(fù)的過程中，我們同時(shí)復(fù)制了AOF與RDB文件，那么到底是哪一個(gè)文件完成了數(shù)據(jù)的恢復(fù)呢？
實(shí)際上，當(dāng)Redis服務(wù)器掛掉時(shí)，重啟時(shí)將按照以下優(yōu)先級(jí)恢復(fù)數(shù)據(jù)到內(nèi)存：
1. 如果只配置AOF,重啟時(shí)加載AOF文件恢復(fù)數(shù)據(jù)；
2. 如果同時(shí) 配置了RDB和AOF,啟動(dòng)是只加載AOF文件恢復(fù)數(shù)據(jù);
3. 如果只配置RDB,啟動(dòng)是將加載dump文件恢復(fù)數(shù)據(jù)。

也就是說，AOF的優(yōu)先級(jí)要高于RDB，這也很好理解，因?yàn)锳OF本身對(duì)數(shù)據(jù)的完整性保障要高于RDB。

在此次的案例中，我們通過在Slave上啟用了AOF與RDB來保障了數(shù)據(jù)，并恢復(fù)了Master。

但在我們目前的線上環(huán)境中，由于數(shù)據(jù)都設(shè)置有過期時(shí)間，采用AOF的方式會(huì)不太實(shí)用，過于頻繁的寫操作會(huì)使AOF文件增長(zhǎng)到異常的龐大，大大超過了我們實(shí)際的數(shù)據(jù)量，這也會(huì)導(dǎo)致在進(jìn)行數(shù)據(jù)恢復(fù)時(shí)耗用大量的時(shí)間。
因此，可以在Slave上僅開啟Snapshot來進(jìn)行本地化，同時(shí)可以考慮將save中的頻率調(diào)高一些或者調(diào)用一個(gè)計(jì)劃任務(wù)來進(jìn)行定期bgsave的快照存儲(chǔ)，來盡可能的保障本地化數(shù)據(jù)的完整性。
在這樣的架構(gòu)下，如果僅僅是Master掛掉，Slave完整，數(shù)據(jù)恢復(fù)可達(dá)到100%。
如果Master與Slave同時(shí)掛掉的話，數(shù)據(jù)的恢復(fù)也可以達(dá)到一個(gè)可接受的程度。

走在通往夢(mèng)想國(guó)度的路上，加油！

總結(jié)

以上是生活随笔為你收集整理的Redis持久化-数据丢失及解决的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。