下面簡單討論幾個Redis常見資料"丟失"現象,以及怎麼規避;
- Redis儲存的應用場景,資料丟失是不能接受的;
- 因為Redis的持久化特性,資料還原很難保證一致性,因rdb全備和aof重寫備份,RPO不能像MySQL這樣保證恢復到故障操作的前一個事務。
- 快取的應用場景,如果大量快取資料丟失,往往導致後端儲存元件”打死“,應用程式雪崩的情況。
- 程式bug或人為誤操作。
- 因客戶端緩衝區記憶體使用過大,導致大量鍵被LRU淘汰。
- 主庫故障後自動重啟,可能導致資料丟失。
- 網路分割槽的問題,可能導致短時間的寫入資料丟失。
- 主從複製資料不一致,發生故障切換後,出現資料丟失。
- 大量過期鍵,同時被淘汰清理。
- 程式bug誤刪除資料;
- DBA/RD誤操作執行flushall/flushdb這類命令。
這類問題的預防和監控
- 重新命名危險命令:keys(程度大批量誤刪除,很多通過keys獲取鍵後再刪除),flushall,flushdb
- 細化幾個重要的監控項:
- 例項當前的鍵個數(dbsize/info), 當大量鍵丟失時,可通過此項歷史監控圖,定位發生的時間範圍。
- 各類刪除命令的執行數監控:cmdtats_flushall, cmdstats_flushdb,cmdstat_del。
- 對應時間範圍,確認具體是什麼操作。
因客戶端緩衝區的記憶體大小很難限制,它們消耗的記憶體數會計算在used_memory內;如果使用不當,導致緩衝區記憶體使用過大,達到maxmemory限制;(快取場景)會導致大量的鍵被淘汰,最壞會把所有鍵清理,緩衝無鍵可淘汰,寫入失敗。相當於整個緩衝失效,對業務影響較大。
- 業務容量規劃時把緩衝正常消耗計算在內,合理高大maxmemory的限制;
每個例項最好可預留幾百M(大小根據客戶端連線數和key的使用有關,根據大小叢集合理調整)。
- 對輸出緩衝區設定合理limit;如normal設定10MB, SLAVE設定1GB等。 如果複製因slave執行緒輸出緩衝區反覆同步,需臨時調大slave client-output-buffer,要同時調大maxmemory限制。
- 主要監控
- 監控記憶體使用大小 used_memory。
- 監控兩個buffer的使用量client_longest_output_list和client_biggest_input_buf。
- 監控鍵的LRU驅逐數量:evicted_keys。
這種故障發生,極有可能資料全部丟失。
問題發生的現象:時間點T1,主庫故障關閉了,因設定有自動重啟的守護程式,時間點T2主庫被重新拉起,因(T2-T1)時間間隔過小,未達到Redis叢集或哨兵的主從切換判斷時長;這樣從庫發現主庫runid變了或斷開過,會全量同步主庫rdb清理,並清理自己的資料。而為保障效能,Redis主庫往往不做資料持久化設定,那麼時間點T2啟動的主庫,很有可能是個空例項(或很久前的rdb檔案)。這種問題發生時間間隔,一般小於1分鐘,可能監控告警無法感知到。
這類總是的預防和監控:
- 強烈反對Redis粗暴地設定自動重啟。
- 這種監控鍵個數的變化,快取命中率,同時ELK型別準實時監控redis日誌變化並告警。
這種問題出現丟失資料都很少,網路分割槽時,Redis叢集或哨兵在判斷故障切換的時間視窗,這段時間寫入到原主庫的資料,5秒~15秒的寫入量。
主從資料出現不一致,發生故障切換,從庫提升為主後,導致資料丟失的情況。
這類情況不是真正的“資料丟失”,只是定期主動清理Redis堆積的過期鍵,會導致Redis的鍵個數(dbsize)出現陡降(最大能達20%)。業務方常誤以為有資料丟失。
這時可通過監控過期鍵淘汰的數量:expireed_keys的增長量,與dbsize鍵總數減少資料量是否相等。
- 同步回寫即SAVE命令,主程式直接向磁碟迴寫資料。在資料大的情況下會導致系統假死很長時間,所以一般不是推薦的。
- 非同步回寫即BGSAVE命令,主程式fork後,複製自身並通過這個新的程式回寫磁碟,回寫結束後新程式自行關閉。由於這樣做不需要主程式阻塞,系統不會假死,一般預設會採用這個方法。
然後執行sysctl -p
- 如果 vm.overcommit_memory = 1,直接放行
- vm.overcommit_memory = 0:則比較 此次請求分配的虛擬記憶體大小和系統當前空閒的實體記憶體加上swap,決定是否放行。
- vm.overcommit_memory= 2:則會比較程式所有已分配的虛擬記憶體加上此次請求分配的虛擬記憶體和系統當前的空閒實體記憶體加上swap,決定是否放行。
1)對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一次
由於在使用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上的如下配置:
# vim /opt/redis/etc/redis_6379.conf
#save 900 1 #禁用Snapshot #save 300 10 #save 60 10000 appendonly no #禁用AOF
接著,修改Slave上的如下配置:
# 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 #啟動新的日誌重寫過程的最小值
# /etc/init.d/redis start
redis 127.0.0.1:6379> CONFIG GET save 1) "save" 2) ""
# 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
接著執行該指令碼
# chmod 755 redis-cli-generate.temp.sh # ./redis-cli-generate.temp.sh
在資料的生成過程中,可以很清楚的看到Master上僅在第一次做Slave同步時建立了dump.rdb檔案,之後就通過增量傳輸命令的方式給Slave了。
dump.rdb檔案沒有再增大。
# 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檔案。
# 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程式,模擬災難。
# 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上覆制資料檔案:
# tar cvf /home/kevin/data.tar * appendonly.aof dump.rdb
將data.tar上傳到Master上,嘗試恢復資料:可以看到Master目錄下有一個初始化Slave的資料檔案,很小,將其刪除。
#ls -l total 4 -rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb # rm -f dump.rdb
然後解壓縮資料檔案:
# tar xf /home/kevin/data.tar # 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
# /etc/init.d/redis start
檢視資料是否恢復:
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 192.168.10.10 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
實際上,當Redis伺服器掛掉時,重啟時將按照以下優先順序恢復資料到記憶體:
a)如果只配置AOF,重啟時載入AOF檔案恢復資料;
b)如果同時 配置了RDB和AOF,啟動是隻載入AOF檔案恢復資料;
c)如果只配置RDB,啟動是將載入dump檔案恢復資料。
也就是說,AOF的優先順序要高於RDB,這也很好理解,因為AOF本身對資料的完整性保障要高於RDB。