info 지속성 정보 보기
redis-cli info persistence#
loading: 서버가 지속성 파일을 로드하고 있는지 여부
rdb_changes_since_last_save: 마지막으로 rdb 파일이 성공적으로 생성되었을 때 작성한 개인 명령 번호, 즉 지속되지 않는 쓰기 명령 수
rdb_bgsave_in_progress: 서버가 RDB 파일을 생성하는지 여부
rdb_last_save_time: 마지막으로 성공한 RDB 파일 생성의 타임스탬프. 현재 timestamp -rdb_last_save_time = 몇 초 동안 RDB 파일이 성공적으로 생성되지 않은 수 : rdb_last_bgsave_status : 최신 rdb 지속성이 성공했는지 여부는 성공했는지 여부 #rdb_last_bgsave_time_sec : rdb 파일 _bgsave_sec를 성공적으로 생성하는 데 걸렸습니다. 서버가 rdb 파일을 생성하는 경우 이 필드는 현재 생성 작업에 걸린 시간(초)을 기록합니다.
rdb_last_cow_size: RDB 프로세스 동안 하위 프로세스와 비교하여 상위 프로세스에서 수행된 수정 횟수(읽기 포함) 버퍼, 쓰기 버퍼, 데이터 수정 등).
aof_enabled: aof 활성화 여부
aof_rewrite_in_progress: aof의 다시 쓰기 작업이 진행 중인지 식별합니다.
aof_rewrite_scheduled: 작업 계획 다시 쓰기, 클라이언트가 bgrewriteaof 명령을 보낼 때, 현재 다시 쓰기 하위 프로세스가 실행 중인 경우 , 클라이언트가 요청한 bgrewriteaof는 예약된 작업이 되며, aof 하위 프로세스가 끝난 후에 다시 쓰기가 실행됩니다
aof_last_rewrite_time_sec: 최신 aof rewrite에 소요된 시간
aof_current_rewrite_time_sec: 다시 쓰기 작업이 다음과 같은 경우 진행 중, 사용된 시간을 초 단위로 기록합니다
aof_last_write_status: 마지막 aof 쓰기 상태
aof_last_cow_size: 작업 중에 하위 프로세스와 비교하여 상위 프로세스에서 수행된 수정 횟수 AOF 프로세스(읽기 버퍼, 쓰기 버퍼, 데이터 수정 등 포함)
appendfsync에는 Always, Everysec 및 No의 세 가지 옵션이 있습니다.
1 Always를 선택하면 서버는 이벤트가 실행될 때마다 AOF 버퍼의 내용을 하드 디스크의 AOF 파일에 강제로 씁니다. redis write 명령을 실행할 때마다 이 명령을 AOF 파일에 기록하는 것으로 생각할 수 있습니다. 이는 데이터 지속성의 무결성을 보장하지만 효율성은 가장 느리지만 가장 안전합니다. 2. 서버는 쓰기 작업(예: set, sadd, rpush)을 수행하고 별도의 AOF 버퍼 끝에 명령을 추가하고 AOF 버퍼를 AOF 파일에 쓴 다음 매초마다 파일 동기화를 수행합니다. 실제로 메모리 버퍼의 AOF 캐시 데이터를 AOF 파일에 기록합니다. 이 모드는 효율성을 고려하고 데이터의 무결성을 보장합니다. 서버가 다운되더라도 redis 데이터베이스는 수정된 후 1초 내에만 손실됩니다. 3.appendfsync를 no로 구성하면 redis 데이터베이스의 데이터가 손실되더라도 이를 받아들일 수 있으며 각 쓰기 명령을 AOF 버퍼 끝에 추가한 다음 파일에 쓸 것입니다. 파일 동기화가 수행될 때 AOF 파일에 실제로 데이터를 쓰는 것은 시스템 자체에 의해 결정됩니다. 즉, 메모리 버퍼의 공간이 채워지거나 설정된 시간 제한을 초과하면 시스템이 자동으로 동기화합니다. 이 모드는 가장 효율적이지만 데이터에 있어서 가장 안전하지 않습니다. Redis의 데이터가 mysql과 같은 백엔드 데이터베이스에서 가져오고 언제든지 검색할 수 있거나 중요하지 않은 데이터인 경우 이 모드로 설정하는 것을 고려해 보세요.위 내용은 Redis가 지속적인지 확인의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!