redis復制有可能碰到的問題匯總

更新時間：2022年04月03日 10:56:02 作者：站在巨人的肩上Z

這篇文章主要介紹了redis復制有可能碰到的問題匯總,本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下

使用salveof命令之后，長時間看不到數(shù)據(jù)同步，以為復制功能失效了，或配置錯了。其實不用擔心，有兩種方法可以確定是否正在建立復制。

在創(chuàng)建redis復制是，一開始可能會發(fā)現(xiàn)slave長時間不開始同步數(shù)據(jù)，可能數(shù)據(jù)量太大，導致了master在dump數(shù)據(jù)慢，此時可以在master上執(zhí)行top -p ${pgrep -d,redis-sever}命令，就可以看到dump的過程。

[root@img1_u ~]# top -p $(pgrep -d, redis-server)
top - 14:06:24 up 54 days,  6:13,  1 user,  load average: 1.18, 1.32, 1.20
Tasks:   2 total,   1 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 15.2%us,  1.7%sy,  0.6%ni, 81.9%id,  0.2%wa,  0.0%hi,  0.4%si,  0.0%st
Mem:  24542176k total, 22771848k used,  1770328k free,  2245720k buffers
Swap:   524280k total,        0k used,   524280k free,  4369452k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21619 root      20   0 5654m 5.4g  388 R 99.9 23.0   0:23.70 redis-server
 1663 root      20   0 5654m 5.4g 1068 S 15.3 23.0   5042:31 redis-server

redis-server是單進程的，現(xiàn)在通過top命令查看已經(jīng)有2個進程，因為之前提到的，redis在建立復制的時候，會在主服務上執(zhí)行bgsave命令，fork一個子進程，dump出RDB文件。master dump完畢，然后再將快照文件傳給slave.

方法二：通過rdb_bgsave_in_progress標識

進入master的redis-cli

127.0.0.1:6381> info Persistence
# Persistence
loading:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0  ##這個表示沒有
rdb_last_save_time:1648953406
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:311296
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0

如果rdb_bgsave_in_progress為1，那么master正在進行bgsave命令。同時rdb_current_bgsave_time_sec顯示bgsave命令已經(jīng)執(zhí)行的時間。由于master服務器上默認不開啟RDB和AOF日志，如果rdb_bgsave_in_progress為1，那么就可以肯定由于復制原因發(fā)送一個bgsave指令dump出RDB文件。

補充：下面看下redis主從復制的一些特點

Redis主從同步策略

主從剛剛連接的時候，進行全量同步；全同步結束后，進行增量同步。當然，如果有需要，slave 在任何時候都可以發(fā)起全量同步。redis 策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。

需要注意：如果多個Slave斷線了，需重啟時，因為只要Slave啟動，就會發(fā)送sync請求和主機全量同步，當多個同時出現(xiàn)的時候，可能會導致Master IO劇增宕機。

Redis主從復制的配置十分簡單，它可以使從服務器是主服務器的完全拷貝。需要清楚知道Redis主從復制的幾點重要內(nèi)容：
1）Redis使用異步復制。但從Redis 2.8開始，從服務器會周期性的應答從復制流中處理的數(shù)據(jù)量。
2）一個主服務器可以有多個從服務器。
3）從服務器也可以接受其他從服務器的連接。除了多個從服務器連接到一個主服務器之外，多個從服務器也可以連接到一個從服務器上，形成一個圖狀結構。
4）Redis主從復制不阻塞主服務器端。也就是說當若干個從服務器在進行初始同步時，主服務器仍然可以處理請求。
5）主從復制也不阻塞從服務器端。當從服務器進行初始同步時，它使用舊版本的數(shù)據(jù)來應對查詢請求，假設你在redis.conf配置文件是這么配置的。否則的話，你可以配置當復制流關閉時讓從服務器給客戶端返回一個錯誤。但是當初始同步完成后，需刪除舊數(shù)據(jù)集和加載新的數(shù)據(jù)集，在這個短暫時間內(nèi)，從服務器會阻塞連接進來的請求。
6）主從復制可以用來增強擴展性，使用多個從服務器來處理只讀的請求（比如，繁重的排序操作可以放到從服務器去做），也可以簡單的用來做數(shù)據(jù)冗余。
7）使用主從復制可以為主服務器免除把數(shù)據(jù)寫入磁盤的消耗：在主服務器的redis.conf文件中配置“避免保存”（注釋掉所有“保存“命令），然后連接一個配置為“進行保存”的從服務器即可。但是這個配置要確保主服務器不會自動重啟（要獲得更多信息請閱讀下一段）

主從復制的一些特點：

1）采用異步復制；
2）一個主redis可以含有多個從redis；
3）每個從redis可以接收來自其他從redis服務器的連接；
4）主從復制對于主redis服務器來說是非阻塞的，這意味著當從服務器在進行主從復制同步過程中，主redis仍然可以處理外界的訪問請求；
5）主從復制對于從redis服務器來說也是非阻塞的，這意味著，即使從redis在進行主從復制過程中也可以接受外界的查詢請求，只不過這時候從redis返回的是以前老的數(shù)據(jù)，如果你不想這樣，那么在啟動redis時，可以在配置文件中進行設置，那么從redis在復制同步過程中來自外界的查詢請求都會返回錯誤給客戶端；（雖然說主從復制過程中對于從redis是非阻塞的，但是當從redis從主redis同步過來最新的數(shù)據(jù)后還需要將新數(shù)據(jù)加載到內(nèi)存中，在加載到內(nèi)存的過程中是阻塞的，在這段時間內(nèi)的請求將會被阻，但是即使對于大數(shù)據(jù)集，加載到內(nèi)存的時間也是比較多的）；
6）主從復制提高了redis服務的擴展性，避免單個redis服務器的讀寫訪問壓力過大的問題，同時也可以給為數(shù)據(jù)備份及冗余提供一種解決方案；
7）為了編碼主redis服務器寫磁盤壓力帶來的開銷，可以配置讓主redis不在將數(shù)據(jù)持久化到磁盤，而是通過連接讓一個配置的從redis服務器及時的將相關數(shù)據(jù)持久化到磁盤，不過這樣會存在一個問題，就是主redis服務器一旦重啟，因為主redis服務器數(shù)據(jù)為空，這時候通過主從同步可能導致從redis服務器上的數(shù)據(jù)也被清空；

到此這篇關于redis復制有可能碰到的問題匯總的文章就介紹到這了,更多相關redis復制問題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: