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

在創建redis復制是，一開始可能會發現slave長時間不開始同步數據，可能數據量太大，導致了master在dump數據慢，此時可以在master上執行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是單進程的，現在通過top命令查看已經有2個進程，因為之前提到的，redis在建立復制的時候，會在主服務上執行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命令已經執行的時間。由于master服務器上默認不開啟RDB和AOF日志，如果rdb_bgsave_in_progress為1，那么就可以肯定由于復制原因發送一個bgsave指令dump出RDB文件。

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

Redis主從同步策略

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

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

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

主從復制的一些特點：

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