redis复制问题
站在巨人的肩上Z 人气:0使用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服务器上的数据也被清空;
加载全部内容