使用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-serverredis-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服务器上的数据也被清空；
到此这篇关于redis复制有可能碰到的问题汇总的文章就介绍到这了,更多相关redis复制问题内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！
