오랫동안 데이터 동기화를 보지 못하면 복제 기능이 잘못되었거나 구성이 잘못되었다고 오해할 수 있습니다. 걱정하지 마십시오. 복제가 설정되고 있는지 확인하는 방법에는 두 가지가 있습니다.
Redis 복제를 생성할 때 처음에는 슬레이브가 데이터 양이 너무 많아 데이터 덤프가 느려질 수 있습니다. master에서 top -p ${pgrep -d, redis-sever} 명령을 실행하면 덤프 프로세스를 볼 수 있습니다.
[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 명령을 실행하고 하위 프로세스를 포크하기 때문입니다. , 덤프 RDB 파일을 내보냅니다. 먼저 마스터 데이터베이스의 덤프를 완료한 후 스냅샷 파일을 슬레이브 데이터베이스로 전송합니다
방법 2: rdb_bgsave_in_progress 식별자를 통해 마스터의 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이면 다음을 의미합니다. 메인 서버가 백그라운드 저장 명령(bgsave)을 수행하고 있습니다. rdb_current_bgsave_time_sec는 bgsave 명령의 실행 시간을 나타냅니다. RDB 및 AOF 로그는 마스터 서버에서 기본적으로 활성화되지 않으므로 rdb_bgsave_in_progress가 1인 경우 복제 이유로 인해 RDB 파일을 덤프하기 위해 bgsave 명령을 보낼 수 있습니다.
위 내용은 Redis 복제에서 발생하는 문제는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!