REDIS 연구노트

이번 프로젝트에 REDIS 를 쓰기로 해서 어떤 놈인지 몇일 붙잡고 연구한 결과를 wiki 에 정리해보았다.

날짜	작성/수정	내용
2012-05-14	김광훈	주제 생성

아래 내용은 단순 번역 뿐 아니라 직접 연구 및 파악한 내용으로 경우에 따라 잘못된 내용이 있을 수도 있다.(무책임;)

참고사이트 http://redis.io/

연구에 사용한 Redis버전 : 2.4.12

 

REDIS 소개

• memory db
• no-sql db 로 기본적으로 key 와 value 쌍의 형태로 데이타를 메모리에 저장한다.
• 메모리에 저장된 내용을 지속시키기 위해 파일로 싱크 하는 기능을 제공한다.

Data Types

• redis 에는 5가지 데이타형이 존재하며, 이 5가지 데이타 형을 다루는 명령이 모두 다르다. 예를들어 string 형의 데이타를 저장하는 명령으로 저장한 key 는 hashes 형을 읽는 명령으로 읽을 수 없다.

Strings

• redis 의 가장 기본적인 데이타형 으로 key 에 하나의 값을 저장한다.
• string 이라고 해서 문자열만 저장할 수 있는게 아니라, 이진 데이타도 저장이 가능하다.(참고로 redis 에는 정수형, 실수형 이 따로 없다.)
• 한 key 에 넣을 수 있는 데이타의 최대 크기는 512 megabytes 이다.
• 이 데이타형의 값은 정수인 경우는 int 로 아니면 raw 로 encoding 된다.

Lists

• 배열이라 보면 된다.
• 한 key 에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다. (2^32 - 1)
• 이 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 linkedlist 아니면 ziplist 로 encoding 된다.

Sets

• 정렬되지 않은 집합 형 이다.
• 말 그대로 집합 이기 때문에 한 key 에 중복된 데이타는 존재하지 않는다. 즉, 동일한 key 에 "abcd" 라는 값을 두 번 추가해도 sets 상에 "abcd" 라는 값은 하나만 존재하게 된다.
• 이 데이타형의 중요한 장점은 요소의 추가, 제거 및 존재체크 시 소모되는 시간이, sets 에 포함된 요소의 수에 관계없이 일정하다는 것이다.
• 한 key 에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다. (2^32 - 1)
• 이 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 hashtable 아니면 intset 로 encoding 된다.

Hashes

• 암호화에서 설명한 그 hash 와는 전혀 상관 없다.
• 객체를 나타내는데 사용 가능한 데이타 형이다.
• 형태는 lists 와 비슷한데 "필드명", "필드값" 의 연속으로 이루어져 있다.
• redis 에서는 최대 100개 정도의 필드를 가지고 있는 hashes 형의 데이타를 저장할 때 매주 작은 메모리 공간을 사용하는 방법을 사용하고 있다.
  • 이 얘기는 메모리 상에 서로 다른 hash key 들이 동일한 필드명 을 공유하는 방법을 사용한다는 것일까?
• 한 key 에 포함할 수 있는 field-value 쌍의 최대 개수는 4,294,967,295 개이다. (2^32 - 1)
• 이 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 hashtable 아니면 zipmap 로 encoding 된다.

Sorted sets

• 일단 형태로만 보면 sets 의 각요소마다 score 라는 실수 값을 가지고 있는 형태이다.
• 요소들은 정렬된 형태로 보여지는데 이때 정렬하는 기준이 score 이다. (오름차순)
• sets 와 마찬가지로 동일한 key 에서 각 요소들의 값은 유일하다. 하지만, score 값은 중복될 수 있다.
• 요소의 추가, 제거, 업데이트는 매우 빠른 방법으로 진행되는데 이는 "요소의 개수의 로그" 에 비례하는 시간이 사용된다. 이런 특징으로 이 데이타 형은 다음과 같은 활용에 유용하다.
  • score 에 승수 를 넣는다던지 해서 랭킹 시스템 등에 사용하기 좋다.
  • 다른 데이타 형의 정렬을 위한 index 값으로 활용할 수 있다. 예를 들어 hashes 로 사용자 데이타를 저장하는데 나이에 따른 정렬이 필요하다 할 경우, sorted sets 에 요소의 값은 사용자ID 를 score 는 나이 값을 넣어주면 된다.
• sorted sets 는 가장 진보한 redis 데이타 형이라고 한다.
• 이 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 skiplist 아니면 ziplist 로 encoding 된다.

Expires

• redis 의 각 key 에는 만기시각을 설정해줄 수 있다. 이는 redis 명령 중 expire 명령으로 설정해줄 수 있다.
• 만기시각이 지난 key 는 자동적으로 메모리에서 제거된다.
• 메모리가 full 된 상태에서 LIMITS 설정에서 선택한 정책에 따라 만기시각이 지정되지 않거나 만기시각이 남은 key 라도 삭제될 경우가 있다.

Persistence (지속성)

• redis 는 메모리 기반 DB 이기 때문에 전원이 꺼지면 데이타가 모두 날라가게 된다. 이에 파일에 메모리상의 데이타를 저장해두고 redis 서버 실행시 다시 그 파일에서 데이타를 읽어와 메모리상에 올리는 기능을 제공하는데 이를 Persistence (지속성) 라고 한다.
• redis 는 RDB 와 AOF 의 두가지 지속성을 제공한다.
  • 두 가지 지속성은 하나만 선택해야 하는 것은 아니고 두 가지를 모두 사용 가능하다.
  • 두 가지 지속성을 모두 사용하도록 설정한 상태에서 redis-server 를 실행하면 AOF 를 이용해 메모리에 데이타를 올리게 된다.
  • 보통 두 가지 지속성을 다 쓰는게 좋다고 한다. 복구가 필요한 시점에 더 적합하고 안전한 방법을 선택해 복구 하면 될 듯 하다.

RDB

• 메모리상의 데이타를 모조리 파일로 덤프를 뜨게 된다.
• command 중 bgsave(비동기적) or save(동기적) 를 실행하면 이 지속성으로 파일을 쓰게할수 있다.
• 설정파일에서 SNAPSHOTTING 부분이 이 지속성과 관련된 부분이다.
• 저장 파일은 보통 .rdb 를 확장자로 쓴다.
• 프로세스
  1. redis 는 fork 로 자식 프로세스를 생성한다.
  2. 자식 프로세스는 임시 rdb 파일에 data 를 쓴다.
  3. 자식 프로세스가 임시 rdb 파일에 data 쓰기를 마치면, 임시 rdb 파일로 옛날 rdb 파일을 덮어 씌운다.
• 장점
  • 특정 시점의 백업 및 복구에 유리하다.
  • redis-server 디스크에 저장하는 시점까지 disk i/o 가 일어나지 않으므로 성능을 극대화 할수 있다.
  • AOF 에 비해 더 빨리 메모리 에 data 를 올리고 redis-server 를 시작 할수 있다.
• 단점
  • 사고 발생시 백업이 일어나는 시점들 사이에 일어나는 변경사항이 손실된다.
  • 백업시 fork() 로 자식 프로세스를 생성해서 백업 작업을 시행하는데 이때 데이타가 크다면 순간적으로 많은 cpu 부하가 발생할 수 있다.

AOF

• 실행한 명령들을 계속 파일에 추가해나가는 방식. mysql 의 바이너리로그 와 비슷하다고 볼 수 있다.
• command 중 BGREWRITEAOF 을 실행하면 이 지속성으로 파일을 쓰게할 수 있다.
• 설정파일에서 APPEND ONLY MODE 부분이 이 지속성과 관련된 부분이다.
• 저장 파일은 보통 .aof 를 확장자로 쓴다.
• AOF 는 설정파일에서 파일을 쓰는 시점에 대해 3가지 옵션을 제공하는데 보통 기본값인 everysec 를 사용하면 된다.(자세한 것은 설정파일의 appendfsync 부분 참고)
• Log rewriting
  • 쓰기 내용이 많아져서 불필요할정도로 aof 파일이 커진 경우 BGREWRITEOF 명령의 실행에 의해 데이타 내용을 살릴수 있는 짧은 명령을 쓰게 된다.
  • redis 2.2 버전에선 수동으로 BGREWRITEAOF 명령을 실행해야했지만, 2.4 버전 부터는 자동으로 실행된다고 한다. * 자세한내용은 설정파일을 확인하도록
• AOF 손상 확인 방법 : aof 파일을 쓰는 중 정전등의 문제로 파일이 손상될 수 있다. 이 때 redis-check-aof 툴로 복구가 가능하다.
  1. aof 파일을 복사한다.
  2. redis-check-aof --fix <aof복사본파일> 을 실행해 복사본 파일을 수정(복구)한다.
  3. (옵션사항)diff -u 명령으로 두 파일을 비교한다.
  4. 수정된 파일을 이용해 redis-server 를 다시 시작한다.
• 장점
  • 사고 발생시 손실되는 데이타가 최소화된다.
  • 정전등의 문제로 aof 파일에 문제가 생긴다 해도 redis-check-aof 로 aof 파일의 복구가 가능하다.
  • aof 파일은 포맷이 단순하여, 문제가 있는 쿼리만 삭제하고 복구에 사용한다던가 하는 작업이 가능하다.
• 단점
  • rdb 파일에 비해 보통 사이즈가 커지게 된다.
  • AOF 는 fsync 정책에 따라 RDB 보다 느릴수 있다.(아무래도 RDB 보다 쓰기가 많이 일어나게 되므로)
  • "과거에 우리(redis 개발진)는 aof 파일을 이용 동일한 data 로 복구하지 못하는 버그를 발견한적이 있는데, 아직 사용자들로부터 해당 버그가 발생한 경우를 보고 받은적은 없다." 라고 한다.

REDIS protocol specification

• redis 클라이언트와 서버간에 주고 받는 명령 및 응답의 규약 을 설명한다.
• 요청 프로토콜
  • AOF 파일의 포맷 역시 이 규약이 사용된다.
  • 간단하고, 컴퓨터에서 빠른 처리(파싱)이 가능하며, 사람이 충분히 이해할수 있는 쉬운 형태다
  • network layer 에서 client 에서 server 로 보내는 각 명령은 \r\n (CRLF) 로 끝나야 한다.
  • 형식 (아래서 < > 는 실제 입력하는게 아니라 키워드를 구분하기 위해 넣은 값임. 아래는 한 command 에 대한 포맷이다.

*<number of arguments><CR><LF>
$<number of bytes of argument 1><CR><LF>
<argument data><CR><LF>
$<number of bytes of argument 2><CR><LF>
<argument data><CR><LF>
...
$<number of bytes of argument N><CR><LF>
<argument data><CR><LF>
실제 형태는 아래와 같은 식이 된다.
*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n

• 응답
  • 첫 문자 : 응답문은 5가지 형태가 있는데, 5가지 형태에 따라 첫 문자가 다음과 같이 결정된다.
    • "+" status reply (한줄로 끝나는 응답인 경우)
    • "-" error reply (에러 메시지인 경우)
    • ":" integer reply (하나의 정수로 답하는 경우)
    • "$" bulk reply 인 경우. 요청 프로토콜 참고
    • "*" 여러줄의 bulk reply 인 경우. 요청 프로토콜 참고

pipe 입력

• 텍스트 파일안의 명령들을 pipe 를 이용 redis-cli 에보내고 싶을때 방법. 주로 텍스트 파일 상의 대량의 명령들을 효율적으로 실행할 때 사용한다.
• 텍스트 파일은 다음 예제 샘플 처럼 명령들을 쭉 써주면 되는데 중요한건 줄바꿈이 \r\n 로 되야 한다는 것이다.

set key0 value0
set key1 value1
set key2 value2
set key3 value3
set key4 value4

• redis 2.6-rc4 와 redis 2.4.14 이상 일때 redis-cli 에서 자체적으로 pipe 입력 기능을 지원한다.
  • cat data.txt | redis-cli --pipe
• 버전이 낮은 경우는 아래와 같이 편법으로 가능하지만, 실패코드 등을 알수 없다는 단점이 있음.
  • (cat data.txt; sleep 10) | nc localhost 6379 > /dev/null

설정파일

기본 설정

• daemonize no
  • redis 서버를 데몬으로 실행하려면 daemonize yes 로 바꿔줘야 한다.

• pidfile /var/run/redis.pid
  • 이 설정파일을 이용해 띄운 redis 서버 의 pid(process id) 가 위 경로에 텍스트 파일 형태로 저장된다. 이를 이용
    • kill -9 `cat /var/run/redis.pid`
  • 같은 식으로도 redis server 를 강제 종료 시킬수 있다.(사고 상황 테스트 등)
  • redis 서버를 여러개 띄울 수 있으니 경로에서 redis.pid 란 파일 이름 부분을 적당히 수정해 주자.

• port 6379
  • redis-server 는 기본적으로 6379 포트를 쓰도록 되어 있다. 위 부분을 수정하면 다른 포트 번호로 실행할 수 있다.

• bind 127.0.0.1
  • 샘플상태에서 위 줄은 주석처리 되어 있을 것이다. 랜카드가 하나인 환경이라면 그냥 주석 상태로 두면 된다.
  • 랜카드가 2개 이상인 경우 어느 랜카드(ip)에서 서버가 대기할지 설정해주면 된다.

• timeout 0
  • 클라이언트에서 서버에 접속할 때 timeout 값으로 초 단위다. 일단 0 으로 놔두고 환경에 따라 값을 바꿔주면 될듯.

• loglevel verbose
  • 남기는 로그의 단계 설정
  • debug > verbose > notice > warning 순으로 더 많은 정보를 남긴다(debug 가 가장많은 정보 남김).
  • 기본값인 verbose 정도로 하는게 적당하다.

• logfile stdout
  • 로그파일의 위치를 나타냄.
  • 기본값인 stdout 로 할 경우 표준출력으로 로그를 남기기되는데 만약 이 설정에서 데몬 모드로 서버 실행시 /dev/null 로 출력되어 로그는 어디에도 안 남게된다.
  • stdout 를 적당한 파일 경로로 수정해서 로그가 파일에 남도록 하는게 좋다. 다만 이 설정만으로는 로그 파일을 일자별로 못 만들고 통짜 파일 하나로 만들어야 한다.
  • 로그 파일을 날자별로 만드는 간한단 아이디어 (문득 떠오른건데 잘 될지는 해봐야 한다.)
    1. 설정한 로그파일의 경로가 /data/logs/redis/redis.log 라고 할때
    2. /data/logs/redis/redis.log 를 실제 파일로 만드는 것이 아니라 날자가 붙은 로그파일 의 심볼릭링크로 만든다. (ex: ln -s /data/logs/redis/redis_20120515.log /data/logs/redis/redis.log)
    3. crontab 을 이용 매일 0 시에 redis.log 의 심볼릭 링크의 원본 파일을 해당 날자가 붙은 로그파일로 바꿔버린다. 이때 심볼릭 파일이 유실되는 순간을 위해 다음과 같은 식으로 처리한다.
       • ln -s /data/logs/redis/redis_20120516.log /data/logs/redis/redis_tmp.log
       • mv /data/logs/redis/redis_tmp.log /data/logs/redis/redis.log

• databases 16
  • redis 는 select 명령으로 DB 를 변경할 수 있는데 이때 DB 는 문자로 된 이름을 가지는게 아니라 0 부터 시작하는 index 값을 가지게 된다.
  • 이 DB 를 최대 몇 개 가질수 있는지 설정해주는 부분이다. 16 이라면 0 ~ 15 까지의 DB 를 가지게 된다.
  • 따로 select 명령을 사용하지 않을 경우 0 번 DB 가 선택되며 만약 7번 DB 를 선택하려면 다음과 같이 명령을 실행하면 된다.
    • select 7

SNAPSHOTTING (RDB 지속성 설정)

• save 60 10000
  • redis 서버가 메모리의 내용을 rdb 파일로 자동으로 덤프 하는 시점과 관련된 설정이다.
  • 위 줄은 60초 동안 10000 건 이상의 keys 가 변경되었다면 메모리 상의 데이타를 모두 rdb 파일로 덤프 하라는 뜻 이다.
  • save <초> <변경된key수> 는 여러 줄로 설정 가능하다. 이를 이용 자동 rdb 덤프 정책을 설정해줄수 있다.
  • save <초> <변경된key수> 설정을 아예 안해줄 경우 서버는 rdb 파일로 덤프를 자동으로 뜨지 않게 된다.(클라이언트 단에서 bgsave 나 save 명령을 내려야 덤프를 뜨게 된다.)
  • rdb 파일로 덤프하는 것은 메모리의 내용을 통째로 파일로 복사하는 것으로 순간적인 부하를 주게 되므로 위 설정을 조절해줘야 한다.
  • 테스트나 개발시 덤프 파일이 빨리 써지는 것을 보려면 저 값을 줄이면 되고 (save 10 1 같은 식으로)
  • 실제 서비스에서는 너무 자주 동기화가 일어나게 되면 안된다.

• rdbcompression yes
  • rdb 파일로 덤프할 때 텍스트 부분을 압축하여 rdb 파일의 사이즈를 줄인다. 사용하지 않으려면 no 를 설정해준다.
  • 압축을 하는 만큼 약간의 부하가 걸리지만 요즘 장비의 성능에서는 허용할 만한 수준으로 가능하면 사용하는것이 좋다.(서비스가 커지면 덤프 파일 크기가 장난 아니게된다)
  • 시스템 부하가 걱정된다면 일단 yes 로 쓰다가 부하가 걸린다면 no 로 변경하는것이 좋을듯 하다.

• dbfilename dumb.rdb
  • 덤프할 때 rdb 파일의 경로.
  • 또한 redis 서버를 실행할 때 이 부분이 설정되어 있다면, 이 파일에 있는 내용을 메모리에 올리게 된다.
  • 설사 save 설정을 사용하지 않는 상태라 해도 이 줄은 사용이 가능하다. 즉 레플리카 셋을 구성했을 경우 다음과 같은 활용이 가능하다.
    1. 마스터노드 에서 쓴 내용이 슬레이브노드에 복제됨
    2. 슬레이브노드에서 save 를 통해 rgb 파일을 덤프함
    3. 마스터노드에서 서버를 다시 실행할 때 슬레이브노드에서 덤프한 rgb 파일을 이용 메모리 에 db 내용을 살림

• dir ./
  • dbfilename 로 설정해준 rdb 파일이 저장되는 디렉토리. 이걸 왜 분리시켜놨는지 모르겠다는 -_-;
  • 어쨓든 기본값은 서버를 실행한 경로에 rdb 파일이 남게 되어 있는데, 이대로 두지 말고 rdb 파일을 저장하는 디렉토리를 따로 만들어서 절대 경로로 써주도록 하자.

REPLICATION (레플리카 셋 구성 설정)

• 레플레카 셋과 관련, 마스터노드 쪽 설정파일에서는 SECURITY 영역의 requirepass 부분 설정 말고는 해줄게 없다.(물론 방화벽 설정은 다른 차원의 문제). 즉 아래 내용들은 모두 슬레이브노드 에서만 설정해주면 되는 부분이다.
• slaveof
  • 마스터노드의 ip 와 포트번호를 적어주면된다. 레플리카 셋을 구성하지 않거나 마스터노드라면 그냥 주석처리된 채로 두면 된다.
• masterauth <master-password>
  • 마스터노드의 설정파일에서 requirepass 부분이 설정되어 있는 경우, 슬레이브노드의 설정파일에선 이 부분에 마스터노드의 패스워드를 적어줘야 한다.
• slave-serve-stale-data yes
  • 마스터노드와의 연결이 끊겼을 경우 슬레이브노드로 들어오는 명령에 어떻게 대처할지 설정해주는 부분
    • yes : 슬레이브노드에서 읽기나 쓰기 명령을 모두 받고 처리해준다.
    • no : 슬레이브노드로 들어오는 모든 명령에 에러상태를 되돌려준다. 쉽게 말해 읽기 쓰기 모두 처리 안해준다.
• repl-ping-slave-period 10
  • 슬레이브노드에서는 주기적으로 마스터노드에 ping 명령을 날려 마스터노드와의 접속상태를 확인하는데 그 주기(초단위)를 설정하는 부분. 기본값은 10초 이다.
• repl-timeout 60
  • 이 값은 대량의 I/O 와 data 에 대한 timeout 을 설정해주는 부분인데, repl-ping-slave-period 값 보다 크게 설정해줘야 한다.
  • 단위는 초단위 이고 기본값은 60초 이다.

SECURITY (보안 관련 설정)

• requirepass foobared
  • 패스워드를 설정해주는 부분. foobared 를 원하는 패스워드로 변경하면 된다.
  • 패스워드를 사용하지 않으려면 이 줄을 주석 처리 하면된다.
  • 패스워드가 설정된 경우 redis 서버에 접속한 후에 다음 명령으로 인증을 받아야 명령 사용이 가능하다
    • auth <패스워드>
• rename-command CONFIG ""
  • redis 명령을 다른 이름으로 바꿔주거나 아예 사용을 못하도록 설정하는 부분이다.
  • 예를 들어 SET 라는 명령을 SET2 라고 변경하려면 다음과 같이 하고
    • rename-command SET "SET2"
  • CONFIG 라는 명령을 아예 못 쓰게 막으려면 다음과 같이 해준다.
    • rename-command CONFIG ""

LIMITS (접속 및 메모리 사용 설정)

• maxclients 128
  • redis 서버에서 클라이언트의 접속을 동시에 몇 개 까지 받아들일지 설정하는 부분.
  • 0 으로 할 경우 무제한으로 접속을 받아들인다.
  • 설정된 수를 초과하여 클라이언트 접속이 시도되는 경우 에러를 반환해준다.
• maxmemory
  • 서버에서 사용할 물리적 메모리 양을 결정한다. 이 메모리양에는 실제 데이타는 물론 각종 설정 상태를 기억하는 부분 까지 포함된다.
  • 그냥 숫자만 쓰면 바이트 단위가 되며, 다음과 같은 표기도 가능하다.
    • 1k : 1000 bytes
    • 1kb : 1024 bytes
    • 1m : 1000000 bytes
    • 1mb : 1024*1024 bytes
    • 1g : 1000000000 bytes
    • 1gb : 1024*1024*1024 bytes
• maxmemory-policy volatile-lru
  • maxmemory 에서 설정한 메모리 를 초과해서 데이타를 쓰려고 할 경우의 정책 설정 부분으로 아래와 같은 옵션이 있다.
    • volatile-lru : (기본값) 만기시각이 설정된 key 들 중에서 LRU algorithm 에 의해 key 를 골라 삭제
    • allkeys-lru : LRU algorithm 에 의해 key 를 골라 삭제
    • volatile-random : 만기시각이 설정된 key 들 중에서 랜덤하게 key 를 골라 삭제
    • allkeys-random : 랜덤하게 key 를 골라 삭제
    • volatile-ttl : 만기시각이 설정된 key 들 중에서 만기시각이 가장 가까운 key 를 골라 삭제
    • noeviction : 어떤 key 도 삭제하지 않고 error on write operations 를 돌려준다.
  • LRU algorithm : Least Recently Used 로 최근에 가장 적게 사용한 메모리 공간을 비워버리고 활용하는 오라클 메모리 관리 방법

• maxmemory-samples 3
  • LRU algorithm 이나 만기시각으로 key 를 골라낼때 정확하게 조건에 맞는 key 를 골라내는게 아니라, 효율을 위해 몇개인가 key 들을 선택해 그 중에 최근에 덜 사용한 key 를 골라내는 방식을 사용한다. 이때 그 몇개인가 골라내는 key 들의 수를 설정해주는 부분.
  • 내 예상으로는 값이 클 수록 더 빨리 버릴 키를 골라낼수 있을 것 같다. 정확히 확인하려면 엄청 많은 데이타를 메모리에 올려 메모리를 풀 상태로 만든 뒤 이 값이 1일 때와 큰값(10000000 정도?) 인 경우에 새 key 값이 설정되는 시간을 비교해야 알 수 있을거 같다.

APPEND ONLY MODE (AOF 지속성 설정)

• RDB 지속성 설정과는 달리, AOF 지속성 설정은 메모리->파일 쓰기 와 파일->메모리 읽기를 따로 설정할 수 없다.
• appendonly no
  • aof 모드를 쓸지 여부를 설정. 사용할 경우는 yes 로 바꿔준다.
• appendfilename /usr/local/redis/dump/master_appendonly.aof
  • aof 파일의 풀 경로. rdb 설정과는 달리 경로와 파일명을 따로 쓰지 않는다.
• appendfsync everysec
  • aof 파일에 쓰는 주기를 결정하는 설정. 다음과 같이 3가지가 있다.
    • always : 매 명령마다 파일에 쓴다. 이는 너무 잦은 I/O 로 시스템에 부하를 줄 수 있다.
    • everysec : 매 초마다 파일에 쓴다. 기본값이며 가장 무난하다.
    • no : 파일에 쓸 내용들을 OS 의 출력버퍼에 집어 넣고, 파일에 쓰는 시점은 OS 에 맡겨버린다.
  • 그냥 everysecond 쓰고 1초안에 손실되는 내용 포기하는게 갑 인듯 하다. always 는 성능에 문제를 줄 수 있다.
• no-appendfsync-on-rewrite no
  • redis 서버의 동작 중 디스크에 큰 파일을 쓰는 작업이 두가지 있는데 Log rewritng 과 bgsave 이다.
  • apendfsync 옵션으로 always 나 everysec 를 사용중인 상태에서 "Log rewritng" 이나 "bgsave" 를 하게 되면 서로 disk I/O 에 방해가 될 수 있게 된다.
  • 이를 방지하는 옵션이 이 설정인데 yes 로 할 경우 "Log rewritng" 이나 "bgsave" 을 하는 중에는 aof 파일에 쓰기를 하지 않게된다.
  • 지연 문제가 발생하지 않으면 그냥 기본값인 no 로 쓰고, 문제가 생기면 yes 를 쓰라고 한다.
  • yes 로 할경우 최악의 시나리오일때 30초 이상의 변경내용을 잃어버릴 수 있다고 한다.(보통은 사고가 발생해도 aof 지속성 사용시 1초 미만의 변경내용을 잃게된다)
• auto-aof-rewrite-percentage 100
  • 최근 Log rewriting 이 일어났을때 aof 파일 크기에 비해 현재 aof 파일 크기가 여기서 설정해준 % 보다 커야 Log rewriting 이 일어난다고 한다.
  • 이 설정에 앞서 최소한 aof 파일의 크기가 auto-aof-rewrite-min-size 에 설정해준 값보다는 큰게 우선조건이다.
  • 근데 여러가지로 테스트 해보았지만 이 수치가 어떻게 적용되는지 정확하게 모르겠다. 그냥 기본설정으로 써도 무리는 없을 듯.
  • Log rewritng 을 사용하지 않으려면 이 값을 0 으로 하면 된다.
• auto-aof-rewrite-min-size 64mb
  • Log rewriting 이 일어나기 위한 aof 파일의 최소 크기. 일단은 그냥 써보자

SLOW LOG

• 연구 안함
• slowlog-log-slower-than 10000
• slowlog-max-len 128

VIRTUAL MEMORY (가상메모리 설정)

• 연구 안함
• vm-enabled no
• vm-max-memory 0
• vm-page-size 32
• vm-pages 134217728
• vm-max-threads 4
• set-max-intset-entries 512

ADVANCED CONFIG

• string 형을 제외한 4개의 데이타형은 포함하고 있는 요소의 개수나, 가장 긴 요소의 길이에 따라 인코딩방식(key 의 값을 저장하는 방식)이 달라진다. 이에 관한 설정을 해주는 부분이다.
• hash-max-zipmap-entries 512
  • hash 에 포함된 필드의 종류가 이 값보다 크면 hashtable 로 아니면 zipmap 으로 encoding 된다.
• hash-max-zipmap-value 64
  • hash 에 포함된 필드의 값중 가장 긴 값의 길이가 이 값보다 크면 hashtable 로 아니면 zipmap 으로 encoding 된다.
• list-max-ziplist-entries 512
  • list 에 포함된 요소의 개수가 이 값보다 크면 linkedlist 로 아니면 ziplist 로 encoding 된다.
• list-max-ziplist-value 64
  • list 에 포함된 요소중 가장 긴 요소의 길이가 이 값보다 크면 linkedlist 로 아니면 ziplist 로 encoding 된다.
• set-max-intset-entries 512
  • set(집합 형) 에 포함된 요소의 개수가 이 값보다 크거나 정수가 아닌 요소가 하나라도 포함되어 있다면 hashtable 로 아니면 intset 으로 encoding 된다.
• zset-max-ziplist-entries 128
  • zset(정렬된집합 형) 에 포함된 요소의 개수가 이 값보다 크면 skiplist 로 아니면 ziplist 로 encoding 된다.
• zset-max-ziplist-value 64
  • zset(정렬된집합 형) 에 포함된 요소중 가장 긴 요소의 길이가 이 값보다 크면 skiplist 로 아니면 ziplist 로 encoding 된다.
• activerehashing yes
  • hash table 의 rehashing 을 돕기위해 CPU 시간 100 밀리초 마다 1 밀리초를 사용하도록 설정하는 옵션. 이라고 하는데 잘 모르겠다.
  • CPU 시간 1%을 이용해 메모리의 반환을 조금 더 빨리 해주도록 하는 옵션인거 같다. 일단 yes 로 두자.

INCLUDES

• 설정파일을 통짜로 하지 않고 여러 조각의 파일로 나누어 쓸 경우 include 를 사용한다.
• include /path/to/local.conf
  • 포함시킬 설정 파일의 경로

redis command

Keys 관련

DEL key [key ...]

• 설명 : key 들을 삭제해준다.
• 파라미터
  • key : 삭제할 key 들을 공백으로 구분해 써준다.
• 리턴값 : 실제로 삭제한 키들의 개수를 반환

DUMP key

• 설명 : redis 2.6.0. 이상부터 지원되는 명령. key 에 저장된 값을 redis 에서 사용하는 포맷으로 직렬화 시켜 출력해준다. 이 직렬화된 값은 RESTORE 명령으로 다시 원래 값으로 되돌릴 수 있다.
• 파라미터
  • key : 값을 직렬화 시킬 key
• 리턴값 : 직렬화된 값

EXISTS key

• 설명 : 메모리에 key 가 존재하는지 체크
• 파라미터
  • key : 체크할 key
• 리턴값 : key 가 존재하면 1, 아니면 0

EXPIRE key seconds

• 설명 : key 에 만기시각을 설정해준다.
• 파라미터
  • key : 만기시각을 설정해줄 key
  • seconds : 지금부터 몇 초후에 만기시킬지 값
• 리턴값 : 만기시각 설정에 성공하면 1, 실패하면 0

EXPIREAT key timestamp

• 설명 : key 에 만기시각을 설정해준다.
• 파라미터
  • key : 만기시각을 설정해줄 key
  • timestamp : 만기시킬 unixtimestamp
• 리턴값 : 만기시각 설정에 성공하면 1, 실패하면 0

KEYS pattern

• 설명
  • 패턴에 맞는 키를 찾아서 출력해준다.
  • 노트북 정도의 성능에서 100만개 키를 가진 DB 를 검색하는데 40밀리초 정도가 소요된다고 한다.(즉 충분히 빠르다)
  • 그렇다고 해도 이 명령을 서비스 상에서 사용하려면 극도로 주의해야 한다. 예상할 수 있겠지만 아주 큰 DB 에서 패턴에 맞는 key 들을 찾아내면 성능에 영향을 줄 수 있다.
  • 서비스 에서 key 들을 검색해야 하는 명령이 필요하다면 차라리 sets 등을 활용하는게 나을 것이다.
• 파라미터
  • pattern : key 를 검색할 패턴으로 아래 예들을 참고
    • h?llo matches hello, hallo and hxllo
    • h*llo matches hllo and heeeello
    • h[ae]llo matches hello and hallo, but not hillo
• 리턴값 : 찾은 key 들의 목록

MIGRATE host port key destination-db timeout

• 설명
  • 이 명령은 한 redis 서버 에서 다른 redis 서버로 한 key 를 옮기는 명령이다.
  • 2.6.0 부터 지원한다.
  • 내부적으로 다음과 같은 액션이 일어난다.
    • 출발지 redis 서버에서 DUMP+DEL
    • 목적지 redis 서버에서 RESTORE
• 파라미터
  • host : 목적지 redis 서버 host
  • port : 목적지 redis 서버 port 번호
  • key : 옮길 key
  • destination-db : 목적지 redis 서버 의 DB index
  • timeout : timeout
• 리턴값 : status reply 참고. 성공시는 OK 를 리턴한다.

MOVE key db

• 설명 : key 를 다른DB(다른 index의 DB) 로 옮긴다.
• 파라미터
  • key : 옮길 key
  • db : 목적지 DB 의 index
• 리턴값 : 옮기는데 성공하면 1, 아니면 0

OBJECT subcommand [arguments [arguments ...]]

• 설명 : key 와 관련된 redis 객체의 내부를 검사 해주는 명령. 이라고 되어 있는데 key 에 저장된 데이타에 대한 row 한 레벨의 정보 몇 가지를 확인하는 명령으로 보인다. 일단 이런 명령이 있다는 정도만 알아두면 될 듯.
• 파라미터 : subcommand 에 따라 용도가 다르다.
  • OBJECT REFCOUNT key : key 의 값을 참조하는 수를 구해준다는데 아직까진 1 밖에 못 본 상태.
  • OBJECT ENCODING key : key 의 값이 인코딩 방식.
    • Strings : raw or int
    • Lists : ziplist orlinkedlist
    • Sets : intset or hashtable
    • Hashes : zipmap or hashtable
    • Sorted Sets : ziplist or skiplist
  • OBJECT IDLETIME key : key 가 유휴 상태였던 시간. 아마 메모리상에서 읽히지 않았던 시간 같은데 정확한 내부 구현이나 값은 모르겠다.
• 리턴값 :

PERSIST key

• 설명 : 만기시각을 없애 버림
• 파라미터
  • key : 만기시각을 없앨 key
• 리턴값 : 성공하면 1, 아니면 0

PEXPIRE key milliseconds

• 설명 : key 에 만기시각을 밀리초 단위로 설정해준다.(2.6.0 이상 지원)
• 파라미터
  • key : 만기시각을 설정해줄 key
  • milliseconds : 지금부터 몇 밀리초후에 만기시킬지 값
• 리턴값 : 만기시각 설정에 성공하면 1, 실패하면 0

PEXPIREAT key milliseconds-timestamp

• 설명 : key 에 밀리초 단위로 만기시각을 설정해준다.(2.6.0 이상 지원)
• 파라미터
  • key : 만기시각을 설정해줄 key
  • milliseconds-timestamp : 만기시킬 unixtimestamp 의 밀리초 환산값
• 리턴값 : 만기시각 설정에 성공하면 1, 실패하면 0

PTTL key

• 설명 : 해당 key 가 만기되기까지 남은 밀리초 값(2.6.0 이상 지원)
• 파라미터
  • key : 체크할 key
• 리턴값 : 구한 밀리초 값. 못 구한경우 -1

RANDOMKEY

• 설명 : 현재 DB 에서 랜덤하게 key 를 하나 구해준다.
• 파라미터 : 없음
• 리턴값 : 구한경우 구한 key, 빈 DB 인 경우 nil

RENAME key newkey

• 설명 : key 이름을 변경해준다. 만약 newkey 가 이미 존재하는 key 라면 덮어씌워 버리게 된다.
• 파라미터
  • key : 원래 key 이름
  • newkey : 새 key 이름
• 리턴값 : 성공하면 OK, 실패하면 에러메시지

RENAMENX key newkey

• 설명 : key 이름을 변경해준다. 만약 newkey 가 이미 존재하는 key 라면 실패한다.
• 파라미터
  • key : 원래 key 이름
  • newkey : 새 key 이름
• 리턴값 : 성공시 1, 실패시 0

RESTORE key ttl serialized-value

• 설명 : DUMP 명령으로 구한 직렬화된 값을 다시 메모리 상에 올림
• 파라미터
  • key : 직렬화된 값을 복구해서 넣을 key 이름
  • ttl : 만기시각 초단위 값. 0으로 하면 만기시작 설정안함
  • serialized-value : DUMP 명령으로 구한 직렬화된 값
• 리턴값 : 성공하면 OK, 실패하면 에러메시지

SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern ...]] [ASC|DESC] [ALPHA] [STORE destination]

• 설명 : list, set, sorted set 형의 key 에 포함된 요소들을 파라미터들로 정해준 조건대로 정렬해서 보여준다.
• 파라미터
  • key : 요소들을 보여줄 key
  • [BY pattern] : (이 key 외의) 다른 key 값들을 이용해서 이 key 의 요소들을 정렬하고 싶을때 사용. 예를 들어
    • mylist 라는 list 형의 key 에 "kweok", "kim", "park", "jung", "lee" 라는 요소들이 있고
    • count_kim 이라는 string 형의 key 에 100 이라는 값이 있고
    • count_lee 이라는 string 형의 key 에 82 이라는 값이 있고
    • count_park 이라는 string 형의 key 에 55 이라는 값이 있고
    • count_jung 이라는 string 형의 key 에 47 이라는 값이 있을 때,
    • mylist 의 요소들을 count_* 에 해당하는 key 들의 값에의해 정렬하고 싶다면
    • sort mylist by count_* 라고 실행 해주면 된다.
    • 정렬안하기 : 정렬에 대한 오버헤드 없이 SORT 명령을 쓰기 위해서는 BY nosort 라고 해주면 된다.
  • [LIMIT offset count] : 정렬 결과에서 일부만 보고 싶을때 offset count 값을 넣어준다.
  • [GET pattern [GET pattern ...]] : 요소의 값 말고 해당 요소를 key 이름에 포함하고 있는 key 의 값을 출력하고 싶을때 사용. GET 은 여러 필드를 표현하기 위해 여러번 사용 가능한데, GET # 이라 할 경우 원래 요소의 값이 보여진다. 예를 들어
    • userids 라는 list 형의 key 에 "10", "17", "21", "22", "27" 이라는 요소들이 있고
    • string 형인 username_10, username_17, username_22 라는 key 들에 각각 "Huni Kim", "Suwon Lee", "James Park" 라는 값들이 있으며
    • string 형인 age_10, age_21, age_22, age_27 라는 key 들에 각각 34, 27, 16, 24 라는 값들이 있다면
    • sort userids get # get username_* get age_* 같이 실행하면 다음과 같이 구해진다.
      1. "10" <-- userids 의 첫번째 요소
      2. "Huni Kim" <-- username_10 의 값
      3. "34" <-- age_10 의 값
      4. "17"" <-- userids 의 두번째 요소
      5. "Suwon Lee" <-- username_17 의 값
      6. (nil) <-- age_17 의 값
      7. "21"" <-- userids 의 세번째 요소
      8. (nil) <-- username_21 의 값
      9. "27" <-- age_21 의 값
      10. "22"" <-- userids 의 네번째 요소
      11. "James Park" <-- username_22 의 값
      12. "16" <-- age_22 의 값
      13. "27"" <-- userids 의 다섯번째 요소
      14. (nil) <-- username_27 의 값
      15. "24" <-- age_27 의 값
  • [ASC|DESC] : 정렬결과를 오름차순으로 보려면 ASC(기본값), 내림차순으로 보려면 DESC 를 넣어준다.
  • [ALPHA] : 정렬은 기본적으로 수(정수 와 실수) 기준으로 하게 되며 수가 아닌경우 0 으로 처리 된다. 이때 문자열 기준으로 정렬하고 싶으면 ALPHA 를 포함시키면 된다.
  • [STORE destination] : 정렬 결과를 출력하지 않고 destination 로 정해준 key 에 넣어준다.
• 리턴값 :

TTL key

• 설명 : 해당 key 가 만기되기까지 남은 초 값
• 파라미터
  • key : 체크할 key
• 리턴값 : 구한 초 단위값. 못 구한경우 -1

TYPE key

• 설명 : 해당 key 의 데이타 형을 구해준다.
• 파라미터
  • key : 데이타형을 구할 key
• 리턴값 : key 의 데이타 형을 구한 경우 "string", "list", "set", "zset" or "hash". 못 구한 경우 "none"

Strings Data Type 관련

APPEND key value

• key 의 값 뒤에 value 를 추가해준다.

SETRANGE key offset value

• key 에 저장된 문자열의 offset 부분부터 value 값을 덮어 씌워버린다.

GETRANGE key start end

• key 에 저장된 문자열의 start ~ end 범위의 부분 문자열을 구해준다.(substring 이라는 함수와 비슷하다.)

STRLEN key

• key 에 저장된 문자열의 길이를 구해준다.

DECR key

• key 에 저장된 정수 값에서 정수 1을 빼준다.

DECRBY key decrement

• key 에 저장된 정수 값에서 정수 decrement을 빼준다.

INCR key

• key 에 저장된 정수 값에 1을 더해준다.

INCRBY key increment

• key 에 저장된 정수 값에 정수 increment 를 더해준다.

INCRBYFLOAT key increment

• key 에 저장된 실수 값에 increment 를 더해준다. (2.6.0 이상 지원)

SET key value

• key 에 value 를 저장한다.

SETNX key value

• key 에 value 를 저장한다. 단 key 에 이미 값이 저장되어 있는 경우 실패한다.

SETEX key seconds value

• key 에 value 를 저장하면서 만기시각을 seconds 초 후로 설정한다.

PSETEX key milliseconds value

• key 에 value 를 저장하면서 만기시각을 milliseconds 밀리초 후로 설정한다. (2.6.0 이상 지원)

MSET key value [key value ...]

• 복수개의 key 들에 각각의 value 를 저장해준다.

MSETNX key value [key value ...]

• 복수개의 key 들에 각각의 value 를 저장해준다. 단 나열한 key 중에 이미 값이 저장되어 있는 key 가 하나라도 있다면 모든 set 은 실패한다.

GETSET key value

• key 에 value 를 저장하고, 원래 있던 값을 구해준다.

GET key

• key 의 값을 구해준다.

MGET key [key ...]

• 복수개의 key 들의 값들을 구해준다.

SETBIT key offset value

• key 의 offset 번째 비트에 value(0 or 1) 을 셋해준다.
• offset 과 해당하는 bit 의 값의 관계이다.

offset	0	1	2	3	4	5	6	7	8	9	10	...
bit값(10)	128	64	32	16	8	4	2	1	128	64	32	...
key value	\x80	\x40	\x20	\x10	\x08	\x04	\x02	\x01	\x00\x80	\x00\x40	\x00\x20	...

GETBIT key offset

• SETBIT 명령으로 값이 정해진 key 의 offset 번째 bit 값(0 or 1) 을 구해준다. 자세한건 SETBIT 명령 참고

Hashes Data Type 관련

Lists Data Type 관련

Sets Data Type 관련

Sorted Sets Data Type 관련

Pub/Sub 관련

• 이기능은 대화방 이나 메신저를 만들때 사용하는 부분 같다.(예상임)
• 다음과 같은 테스트를 해보았다.
  • 동일한 redis 서버에 3개의 클라이언트를 접속 시켰다. 편의상 1번 2번 3번 클라이언트라 칭하겠다.
  • 1번 클라이언트에는 subscribe ch1 ch2 ch3 이라는 명령을 실행했다. (ch1, ch2, ch3 이라는 채널에서 들어오는 메시지를 기다리란 뜻)
  • 2번 클라이언트에는 subscribe ch1 ch4 라는 명령을 실행했다. (ch1, ch4 라는 채널에서 들어오는 메시지를 기다리란 뜻)
  • 3번 클라이언트에서 publish ch1 "hi hi hi" 라고 하자 1번, 2번 클라이언트에 "hi hi hi" 라는 메시지가 떴다.
  • 3번 클라이언트에서 publish ch2 "hello~" 라고 하자 1번 클라이언트에만 "hello~" 라는 메시지가 떴다.
  • 3번 클라이언트에서 publish ch3 "world" 라고 하자 1번 클라이언트에만 "world" 라는 메시지가 떴다.
  • 3번 클라이언트에서 publish ch4 "good !!" 라고 하자 2번 클라이언트에만 "good !!" 라는 메시지가 떴다.
• redis-cli 에서는 subscribe 나 psubscribe 실행한 후에 더이상 명령을 입력받지 않게 되므로 unsubscribe 나 punsubsribe 를 어떻게 입력하는가 하는 의문이 들 수 있다. telnet 등으로 해당 redis 서버에 접속해서 subscribe 명령을 입력해보면 listen 상태가 되어서도 unsubscribe 명령이 입력가능한 것을 확인할 수 있다.

SUBSCRIBE channel [channel ...]

• 나열한 channel 들에 해당하는 채널들로 들어오는 메시지를 대기(listen) 하는 명령.

PSUBSCRIBE pattern [pattern ...]

• 나열한 pattern 들에 일치하는 채널들로 들어오는 메시지를 대기(listen) 하는 명령.

PUBLISH channel message

• channel 이라는 채널에 message 를 메시지로 보낸다. channel 에 해당하는 채널에서 listen 중인 클라이언트 들 모두에게 메시지가 전달된다.

UNSUBSCRIBE [channel [channel ...]]

• channel 들 에서의 listen 을 취소한다.

PUNSUBSCRIBE [pattern [pattern ...]]

• pattern 에 매칭되는 채널 들에서의 listen 을 취소한다.

Transactions 관련

• redis 에서 제공하는 트랜잭션은 좀 쓰기가 애매하다.
  • 일단 트랜잭션 에 대한 롤백이 되지 않는다.
  • 트랜잭션 실행 중에 어떤 명령이 실패해도 뒤에 명령들은 그대로 실행이 되어버린다.

MULTI

• 트랜잭션의 준비를 알리는 명령. MULTI 명령 후에 입력한 명령 들은 EXEC 명령이 실행되기 전까지 실행되지 않고 큐에 쌓인다.

EXEC

• 트랜잭션을 실행시키는 명령. MULTI 명령 후에 입력한 명령들은 EXEC 명령이 실행되면 차례대로 실행된다.

DISCARD

• MULTI 명령 후, EXEC 실행전에 이 명령을 실행하면 큐에 쌓인 명령들을 지워버린다. MULTI 역시 실행안한 상태가 된다.

WATCH key [key ...]

• ????

UNWATCH

• watch 중인 key 들의 watch 를 취소함.

Scripting 관련

• Lua Script 를 실행해주는 명령 들인데 redis 2.6.0 에서부터 지원한다.

Connection 관련

AUTH password

• 접속한 redis 서버에 패스워드가 걸려있는 경우, 이 명령으로 인증을 받아야 명령 사용이 가능하다.
• 패스워드 설정은 설정파일의 requirepass 부분을 변경해주면 된다.

ECHO message

• message 를 그대로 출력해준다. 접속이 정상적으로 되었는지 등을 확인할 때 사용.

PING

• 접속상태를 확인하게 입력해보는 명령. 정상적으로 접속되어있다면 PONG 이라는 문자열을 출력해준다.

QUIT

• redis 서버와의 접속을 끊는다.

SELECT index

• 사용할 DB 의 index 를 선택한다. index 의 시작은 0 이며, 따로 SELECT 명령을 사용하지 않을 경우 0 번 DB 가 선택되어 있게 된다.
• DB 의 index 로 사용가능한 최대 값은 설정파일의 databases 부분의 값을 변경하면 된다.

Server 관련

SAVE

• 동기적으로 RDB 파일을 쓰게한다.

BGSAVE

• 비동기적으로 RDB 파일을 쓰게한다.

BGREWRITEAOF

• 비동기적으로 AOF 파일을 쓰게한다.

CONFIG GET parameter

• 설정 parameter 의 값을 보여준다.
• parameter 에 패턴도 입력이 가능하다. 즉 CONFIG GET * 라고 실행하면 모든 설정값들을 확인할 수 있다.

CONFIG SET parameter value

• 설정 parameter 의 값을 value 로 설정한다.

CONFIG RESETSTAT

• INFO 명령에 의해 구해진 통계를 재설정 하는 명령. 이라는데 뭐에 쓰는건지 모르겠다.

DEBUG OBJECT key

• key 의 디버깅 정보를 보여주는데, 문서에 보면 클라이언트 단에서 사용하면 안된다고 되어 있다(그럼 왜 만들어둔거야;) 이 명령 대신 OBJECT 명령을 사용하라고 한다.

DEBUG SEGFAULT

• 잘못된 메모리 접근을 통해 접속해 있는 redis 서버를 crash 시켜 버린다.
• 말그대로 접속해 있는 redis 서버를 죽여버리게 된다. 서버 프로세스가 kill 되어버린다.
• 버그 상황을 테스트 하기 위해 제공되는 명령으로 당연히 서비스 중인 서버에 사용하면 안된다.

MONITOR

• 접속한 redis 서버에 들어오는 모든 명령들을 실시간으로 확인할 수 있게 된다.

INFO

• 현재 redis 서버의 정보 및 통계 를 알려준다.
• 메모리 사용량, redis 서버 작동시간, key 들에 대한 정보, 최근 파일 동기화(지속성) 관련 정보 등을 알 수 있다.
• 모니터링 툴을 만든다면 이 명령 결과를 이용해야 할 것이다.

LASTSAVE

• 마지막으로 save 나 bgsave 가 일어난 시각을 unix timestamp 값으로 알려준다.
• 즉 RDB 지속성 에 의해 파일 쓰기가 일어난 최근 시각을 알려주는 명령

DBSIZE

• 현재 사용중인(select 명령으로 선택된) DB 에 저장되어 있는 모든 key 의 개수를 알려준다.

FLUSHALL

• 모든(select 된것만이 아니라) database 에서 모든 key 를 삭제해버린다.
• 당연한 얘기지만 사용에 주의하자

FLUSHDB

• 현재 select 된 DB 의 모든 key 들을 삭제해버린다.

SHUTDOWN [NOSAVE] [SAVE]

• 데이타 손실 없이 redis 서버를 안전하게 종료시킨다. 구체적으로 다음과 같은 일이 일어난다.
  1. 모든 클라이언트를 stop 시킨다.
  2. (설정파일에 save 설정이 한 줄 이라도 있다면)RDB 파일을 쓴다.
  3. (설정파일에 aof 사용이 활성화 되어 있다면)AOF 파일을 쓴다.
  4. redis 서버를 종료시킨다.
• 문서에는 NOSAVE 나 SAVE 를 파라미터로 쓸수 있다고 되어 있는데, redis-cli 상에서 써보면 파라미터 개수 자체가 안 맞다면서 에러가 난다. 어쨓든 문서상에 설명은 다음과 같다.
  • SHUTDOWN NOSAVE : 설정파일에 RDB 나 AOF 설정이 어떻게 되어있던간에 디스크에 쓰는 과정 생략하고 종료해버린다.
  • SHUTDOWN SAVE : 설정파일에 save 설정이 전혀 없더라도(물론 dbfilename 설정은 되어 있어야하겠지?) RDB 파일 쓰기를 하고 종료한다.

SLAVEOF host port

• 현재 접속한 redis 서버를 다른 redis 서버(host 와 port 로)의 (레플리카셋의)slave 로 만든다.
• 만약 이미 다른 master node 의 slave node 로 있는 서버에서 이 명령을 실행하면, 옛날 master node 와의 연결은 끊어지고 새로 입력한 node 를 master 로 삼게 된다.
• SLAVEOF 명령은 현재 연결되어 있는 master node 와의 연결을 끊는데도 사용할 수 있는데 다음처럼 실행하면 된다.
  • SLAVEOF NO ONE

SLOWLOG subcommand [argument]

• 확인못함

SYNC

• 복제에 사용되는 내부 명령어(즉 건들필요 없단 건데, 그럼 뭐하러 외부에 꺼내놨나 --;)

TIME

• 현재 서버의 시간을 구해준다. (2.6.0 이상 지원)