본문 바로가기
dev/redis

redis sentinel High Availability

by igooo 2013. 11. 26.
728x90

redis 를 사용하는 방법은(?) 다양하다 단순 cache 서버로 memcached 처럼 사용하거나 RDB 처럼 persistent한 repository로 사용 할 수도 있다.(http://redis.io/topics/persistence)


redis를 cache 서버가 아닌 persistence repository로 사용 할 때 HA를 위해서 master - slave 구조를 사용하게 되고, HA를 위해서 sentinel로 redis instance들을 감시하여 failover를 해야한다. sentinel에 대해 구글링하다보면 사용시 주의해야 할 점들이 나오는데 실제로 각 케이스별로 sentinel이 어떤짓을 하는지 테스트를 해봤다.


Test 환경

redis master : RDB, AOF 사용 안 함

redis slave : RDB, AOF 사용

sentinel : 마스터 장비에 같이 사용

was : reids master 로 connection을 맺어서 사용


case 0. 정상적인 redis 사용

  • redis master start
  • redis slave start
  • slave sync (redis master에서 RDB생성 후 slave에 전달 data sync)
  • sentinel start (master, slave 감시)
  • input data to master

master로 데이터가 입력되면 slave는 AOF 파일이 커지고 RDB를 지정된 시간마다 생성한다. master는 메모리만 증가된다.


case 1. slave down

redis slave down 상황은 서비스에는 영향은 없다. was는 master만 바라보고 있다.

redis slave 복구 시 master 로 sync 요청을 한다. master는 RDB를 생성하고 slave에게 전달한다. (master 장비에 IO 발생)

slave down

sentinel detect

[6666] 16 Nov 05:54:43.691 # +sdown slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379

master는 정상 작동

slave  복구

slave에서 master로 sync 요청

master RDB 생성 후 slave에 전달
[6656] 16 Nov 06:00:56.243 * Slave ask for synchronization
[6656] 16 Nov 06:00:56.243 * Starting BGSAVE for SYNC
[6656] 16 Nov 06:00:56.244 * Background saving started by pid 6975
[6656] 16 Nov 06:00:56.250 * DB saved on disk
[6656] 16 Nov 06:00:56.250 * RDB: 0 MB of memory used by copy-on-write
[6556] 16 Nov 06:00:56.285 * Background saving terminated with success
[6656] 16 Nov 06:00:56.286 * Synchronization with slave succeeded

slave는 rdb를 메모리로 넣고 복구된다.
[495] 15 Nov 09:35:01.025 * Connecting to MASTER...
[495] 15 Nov 09:35:01.026 * MASTER <-> SLAVE sync started
[495] 15 Nov 09:35:01.026 * Non blocking connect for SYNC fired the event.
[495] 15 Nov 09:35:01.027 * Master replied to PING, replication can continue...
[495] 15 Nov 09:35:01.067 * MASTER <-> SLAVE sync: receiving 13306 bytes from master
[495] 15 Nov 09:35:01.068 * MASTER <-> SLAVE sync: Loading DB in memory
[495] 15 Nov 09:35:01.068 * MASTER <-> SLAVE sync: Finished with success
[495] 15 Nov 09:35:01.078 * Background append only file rewriting started by pid 498
[498] 15 Nov 09:35:01.139 * SYNC append only file rewrite performed
[498] 15 Nov 09:35:01.140 * AOF rewrite: 0 MB of memory used by copy-on-write
[495] 15 Nov 09:35:01.235 * Background AOF rewrite terminated with success
[495] 15 Nov 09:35:01.235 * Parent diff successfully flushed to the rewritten AOF (0 bytes)
[495] 15 Nov 09:35:01.236 * Background AOF rewrite finished successfully

sentinel slave 복구 감지

[6666] 16 Nov 06:00:56.243 * +reboot slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
[6666] 16 Nov 06:00:56.440 # -sdown slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379


case 2. master down

redis master 장비 down 시 서비스 장애 발생(was는 master로만 connection을 연결한다.) <= 자동 failover하는건 나중에 다시 post 하는 걸로...

sentinel이 master 다운을 감지하고 slave를 new master로 승격시킨다. old master가 복구되면 old master는 sentinel에 의해 slave로 복구가 되고 slave로 구동된다. old master는 backup 옵션을 켜놓지 않았음으로 운영자가 수동으로 old master를 master로 변경해줘야 한다.

master down

slave에서 master connection 관련 오류 발생 

[495] 15 Nov 09:42:58.378 * Connecting to MASTER...
[495] 15 Nov 09:42:58.378 * MASTER <-> SLAVE sync started
[495] 15 Nov 09:42:58.379 # Error condition on socket for SYNC: Connection refused

sentinel 이 master 다운을 감지

[6565] 16 Nov 06:08:59.327 # +sdown master mymaster 172.10.43.42 6379
[6565] 16 Nov 06:08:59.327 # +odown master mymaster 172.10.43.42 6379 #quorum 1/1
[6565] 16 Nov 06:08:59.327 # +failover-triggered master mymaster 172.10.43.42 6379
[6565] 16 Nov 06:08:59.327 # +failover-state-wait-start master mymaster 172.10.43.42 6379 #starting in 13459 milliseconds

sentinel 이 slave중 하나를 선택하여 master로 승격 시키고 old master는 slave로 전환한다.
[6565] 16 Nov 06:09:12.868 # +failover-state-select-slave master mymaster 172.10.43.42 6379
[6565] 16 Nov 06:09:12.969 # +selected-slave slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
[6565] 16 Nov 06:09:12.969 * +failover-state-send-slaveof-noone slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
[6565] 16 Nov 06:09:13.069 * +failover-state-wait-promotion slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
[6565] 16 Nov 06:09:13.372 # +promoted-slave slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
[6565] 16 Nov 06:09:13.372 # +failover-state-reconf-slaves master mymaster 172.10.43.42 6379
[6565] 16 Nov 06:09:13.471 # +failover-end master mymaster 172.10.43.42 6379
[6565] 16 Nov 06:09:13.471 # +switch-master mymaster 172.10.43.42 6379 172.10.43.47 6379

slave는 sentinel에 의해 master로 승격된다.

[495] 15 Nov 09:43:08.759 * MASTER MODE enabled (user request)

new master로 데이터 입력

aof 파일사이즈 증가, rdb 사이즈 증가(snapshot)

old master 복구

old master가 복구되면 slave로 복구되고 new master로 부터 data를 sync 한다.

old master
[7582] 16 Nov 06:33:35.395 * DB loaded from disk: 0.000 seconds
[7582] 16 Nov 06:33:35.395 * The server is now ready to accept connections on port 6379
[7582] 16 Nov 06:33:35.435 * SLAVE OF 172.10.43.47:6379 enabled (user request)
[7582] 16 Nov 06:33:36.400 * Connecting to MASTER...
[7582] 16 Nov 06:33:36.400 * MASTER <-> SLAVE sync started
[7582] 16 Nov 06:33:36.400 * Non blocking connect for SYNC fired the event.
[7582] 16 Nov 06:33:36.403 * Master replied to PING, replication can continue...
[7582] 16 Nov 06:33:36.578 * MASTER <-> SLAVE sync: receiving 16447 bytes from master
[7582] 16 Nov 06:33:36.579 * MASTER <-> SLAVE sync: Loading DB in memory
[7582] 16 Nov 06:33:36.579 * MASTER <-> SLAVE sync: Finished with success

new master
[495] 15 Nov 10:07:05.058 * Slave ask for synchronization
[495] 15 Nov 10:07:05.058 * Starting BGSAVE for SYNC
[495] 15 Nov 10:07:05.059 * Background saving started by pid 2215
[2215] 15 Nov 10:07:05.149 * DB saved on disk
[2215] 15 Nov 10:07:05.150 * RDB: 0 MB of memory used by copy-on-write
[495] 15 Nov 10:07:05.228 * Background saving terminated with success
[495] 15 Nov 10:07:05.229 * Synchronization with slave succeeded

sentinel detect
[6565] 16 Nov 06:33:35.435 * +demote-old-slave slave 172.10.43.42:6379 172.10.43.42 6379 @ mymaster 172.10.43.47 6379
[6565] 16 Nov 06:33:35.635 # -sdown slave 172.10.43.42:6379 172.10.43.42 6379 @ mymaster 172.10.43.47 6379
[6565] 16 Nov 06:33:45.458 * +slave slave 172.10.43.42:6379 172.10.43.42 6379 @ mymaster 172.10.43.47 6379

old master를 master로 원복

old master를 master로 변경하면 sentinel이 이를 감지하고 new master는 slave로 변경해준다. 그리고 slave로 변경된 new master는 master로 부터 data를 sync한다.

old master
redis> slaveof no one

[7582] 16 Nov 06:39:13.582 * MASTER MODE enabled (user request)
[7582] 16 Nov 06:39:17.551 * Slave ask for synchronization
[7582] 16 Nov 06:39:17.551 * Starting BGSAVE for SYNC
[7582] 16 Nov 06:39:17.552 * Background saving started by pid 7692
[7692] 16 Nov 06:39:17.558 * DB saved on disk
[7692] 16 Nov 06:39:17.558 * RDB: 0 MB of memory used by copy-on-write
[7582] 16 Nov 06:39:17.640 * Background saving terminated with success
[7582] 16 Nov 06:39:17.641 * Synchronization with slave succeeded

new master(slave)
[495] 15 Nov 10:12:38.830 * SLAVE OF 172.10.43.42:6379 enabled (user request)
[495] 15 Nov 10:12:39.768 * Connecting to MASTER...
[495] 15 Nov 10:12:39.768 * MASTER <-> SLAVE sync started
[495] 15 Nov 10:12:39.768 * Non blocking connect for SYNC fired the event.
[495] 15 Nov 10:12:39.769 * Master replied to PING, replication can continue...
[495] 15 Nov 10:12:39.857 * MASTER <-> SLAVE sync: receiving 16524 bytes from master
[495] 15 Nov 10:12:39.858 * MASTER <-> SLAVE sync: Loading DB in memory
[495] 15 Nov 10:12:39.858 * MASTER <-> SLAVE sync: Finished with success
[495] 15 Nov 10:12:39.859 * Background append only file rewriting started by pid 2493
[2493] 15 Nov 10:12:39.887 * SYNC append only file rewrite performed
[2493] 15 Nov 10:12:39.887 * AOF rewrite: 0 MB of memory used by copy-on-write
[495] 15 Nov 10:12:39.975 * Background AOF rewrite terminated with success
[495] 15 Nov 10:12:39.975 * Parent diff successfully flushed to the rewritten AOF (0 bytes)
[495] 15 Nov 10:12:39.976 * Background AOF rewrite finished successfully

sentinel
[6565] 16 Nov 06:39:16.395 # +failover-detected master mymaster 172.10.43.47 6379
[6565] 16 Nov 06:39:16.494 # +failover-end master mymaster 172.10.43.47 6379
[6565] 16 Nov 06:39:16.494 # +switch-master mymaster 172.10.43.47 6379 172.10.43.42 6379
[6565] 16 Nov 06:39:16.596 * +demote-old-slave slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
[6565] 16 Nov 06:39:26.622 * +slave slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379


 
case 3 : Master, Slave down => master 먼저 복구
master, slave가 동시에 다운되는 경우 master를 먼저 복구 시키는 경우 redis의 옵션에 따라 복구되는 방식이 다르다.

AOF 가 설정된경우 RDB 파일이 있더라도 AOF 파일을 사용하여 복구된다. (AOF  파일이 없으면 빈 데이터 로드)

RDB 설정이 없더라도 AOF 옵션이 꺼져있으면 RDB 파일로 데이터를 복구한다.

master, slave down

master 복구 

maser
[8670] 16 Nov 07:30:44.825 # Server started, Redis version 2.6.13
[8670] 16 Nov 07:30:44.826 * DB loaded from disk: 0.000 seconds
[8670] 16 Nov 07:30:44.826 * The server is now ready to accept connections on port 6379

sentinel
[6565] 16 Nov 07:26:24.204 # +sdown slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
[6565] 16 Nov 07:26:25.912 # +sdown master mymaster 172.10.43.42 6379
[6565] 16 Nov 07:26:25.912 # +odown master mymaster 172.10.43.42 6379 #quorum 1/1

master 복구 시 최근 RDB 데이터 기준으로 데이터를 복구한다.(RDB가 최신 파일이 아니면 데이터 유실)

sentinel이 master 복구를 감지
[6565] 16 Nov 07:30:44.835 * +reboot master mymaster 172.10.43.42 6379
[6565] 16 Nov 07:30:45.036 # -sdown master mymaster 172.10.43.42 6379
[6565] 16 Nov 07:30:45.036 # -odown master mymaster 172.10.43.42 6379

slave 복구 (master 데이터 기준으로 data sync발생)

slave
[14842] 18 Nov 09:56:51.803 * DB loaded from append only file: 0.001 seconds
[14842] 18 Nov 09:56:51.803 * The server is now ready to accept connections on port 6379
[14842] 18 Nov 09:56:51.803 * Connecting to MASTER...
[14842] 18 Nov 09:56:51.804 * MASTER <-> SLAVE sync started
[14842] 18 Nov 09:56:51.804 * Non blocking connect for SYNC fired the event.
[14842] 18 Nov 09:56:51.804 * Master replied to PING, replication can continue...
[14842] 18 Nov 09:56:51.902 * MASTER <-> SLAVE sync: receiving 16435 bytes from master
[14842] 18 Nov 09:56:51.903 * MASTER <-> SLAVE sync: Loading DB in memory
[14842] 18 Nov 09:56:51.904 * MASTER <-> SLAVE sync: Finished with success
[14842] 18 Nov 09:56:51.918 * Background append only file rewriting started by pid 14845
[14845] 18 Nov 09:56:51.978 * SYNC append only file rewrite performed
[14845] 18 Nov 09:56:51.978 * AOF rewrite: 0 MB of memory used by copy-on-write
[14842] 18 Nov 09:56:52.025 * Background AOF rewrite terminated with success
[14842] 18 Nov 09:56:52.025 * Parent diff successfully flushed to the rewritten AOF (0 bytes)
[14842] 18 Nov 09:56:52.026 * Background AOF rewrite finished successfully

sentinel
[6565] 19 Nov 07:47:51.686 * +reboot slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
[6565] 19 Nov 07:47:51.885 # -sdown slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379

 

case 4 : Master, Slave down => slave 먼저 복구

master, slave down

slave 복구
slave는 계속 마스터를 찾는다.
[15785] 18 Nov 10:14:19.592 # Server started, Redis version 2.6.13
[15785] 18 Nov 10:14:19.594 * DB loaded from append only file: 0.002 seconds
[15785] 18 Nov 10:14:19.594 * The server is now ready to accept connections on port 6379
[15785] 18 Nov 10:14:19.687 * Connecting to MASTER...
[15785] 18 Nov 10:14:19.688 * MASTER <-> SLAVE sync started

sentinel detect
[6565] 19 Nov 08:05:39.802 * +reboot slave 172.10.43.47:6379 172.10.4347 6379 @ mymaster 172.10.43.42 6379
[6565] 19 Nov 08:05:40.002 # -sdown slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379

master 복구

master는 이전 RDB 파일로 데이터를 복구하고 이를 slave 에 전달한다. (데이터 유실이 발생 할 수 있다.)

[11296] 19 Nov 08:08:22.515 # Server started, Redis version 2.6.13
[11296] 19 Nov 08:08:22.516 * DB loaded from disk: 0.000 seconds
[11296] 19 Nov 08:08:22.516 * The server is now ready to accept connections on port 6379
[11296] 19 Nov 08:08:23.129 * Slave ask for synchronization
[11296] 19 Nov 08:08:23.130 * Starting BGSAVE for SYNC
[11296] 19 Nov 08:08:23.131 * Background saving started by pid 11299
[11299] 19 Nov 08:08:23.140 * DB saved on disk
[11299] 19 Nov 08:08:23.141 * RDB: 0 MB of memory used by copy-on-write
[11296] 19 Nov 08:08:23.216 * Background saving terminated with success
[11296] 19 Nov 08:08:23.217 * Synchronization with slave succeeded
 
sentinel
[6565] 19 Nov 08:08:22.587 * +reboot master mymaster 172.10.43.42 6789
[6565] 19 Nov 08:08:22.787 # -sdown master mymaster 172.10.43.42 6789
[6565] 19 Nov 08:08:22.787 # -odown master mymaster 172.10.43.42 6789
 
slave
[15785] 18 Nov 10:16:59.930 * Connecting to MASTER...
[15785] 18 Nov 10:16:59.931 * MASTER <-> SLAVE sync started
[15785] 18 Nov 10:16:59.931 * Non blocking connect for SYNC fired the event.
[15785] 18 Nov 10:16:59.931 * Master replied to PING, replication can continue...
[15785] 18 Nov 10:17:00.018 * MASTER <-> SLAVE sync: receiving 16435 bytes from master
[15785] 18 Nov 10:17:00.019 * MASTER <-> SLAVE sync: Loading DB in memory
[15785] 18 Nov 10:17:00.019 * MASTER <-> SLAVE sync: Finished with success
[15785] 18 Nov 10:17:00.020 * Background append only file rewriting started by pid 15948
[15948] 18 Nov 10:17:00.047 * SYNC append only file rewrite performed
[15948] 18 Nov 10:17:00.047 * AOF rewrite: 0 MB of memory used by copy-on-write
[15785] 18 Nov 10:17:00.145 * Background AOF rewrite terminated with success
[15785] 18 Nov 10:17:00.145 * Parent diff successfully flushed to the rewritten AOF (0 bytes)
[15785] 18 Nov 10:17:00.146 * Background AOF rewrite finished successfully

http://charsyam.wordpress.com/2013/10/09/입-개발-redis-sentinel을-이용하면서-겪게-되는-문제-하나와-해/
 
 

case 5 : redis master, slave 구조에서 data 유실 없이 복구하기 

redis master - slave 구조에소는 master가 장애가 발생하면 master 복구 정책에 따라 데이터를 정상적으로 복구하지 못 할 수 있다. (master에 AOF가 설정이 없으면 RDB 파일로만 복구된다.)

위 테스트 case에 보면 master 장비는 backup 정책이 없고, slave만 data를 backup한다.
최근 데이터는 slave의 AOF 파일 또는 RDB 파일에 저장된다.
그러므로 master 장비 장애 시 slave 장비를 new master로 구성하고, master를 new master의 slave로 구성하여 데이터를 최신으로 복구하고 복구가 완료되면 다시 master를 바꿔서 서비스를 정상화한다.

slave 복구
[17052] 18 Nov 10:36:45.273 * DB loaded from append only file: 0.000 seconds
[17052] 18 Nov 10:36:45.274 * The server is now ready to accept connections on port 6379
[17052] 18 Nov 10:36:45.286 * Connecting to MASTER...
[17052] 18 Nov 10:36:45.286 * MASTER <-> SLAVE sync started
[17052] 18 Nov 10:36:45.287 # Error condition on socket for SYNC: Connection refused

sentinel detect
[6565] 19 Nov 08:28:31.752 * +reboot slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379

slave를 master로 변경
[17052] 18 Nov 10:38:35.827 * MASTER MODE enabled (user request)
 
sentinel이 slave를 new master를 설정
[6565] 19 Nov 08:30:24.537 # +failover-detected master mymaster 172.10.43.42 6379
[6565] 19 Nov 08:30:24.636 # +failover-end master mymaster 172.10.43.42 6379
[6565] 19 Nov 08:30:24.636 # +switch-master mymaster 172.10.43.42 6379 172.10.43.47 6379

old master 복구

slave로 복구되면서 new master의 데이터를 sync한다.
master
[11791] 19 Nov 08:31:13.202 * DB loaded from disk: 0.000 seconds
[11791] 19 Nov 08:31:13.202 * The server is now ready to accept connections on port 6379
[11791] 19 Nov 08:31:13.282 * SLAVE OF 172.10.43.47:6379 enabled (user request)
[11791] 19 Nov 08:31:14.203 * Connecting to MASTER...
[11791] 19 Nov 08:31:14.203 * MASTER <-> SLAVE sync started
[11791] 19 Nov 08:31:14.204 * Non blocking connect for SYNC fired the event.
[11791] 19 Nov 08:31:14.204 * Master replied to PING, replication can continue...
[11791] 19 Nov 08:31:14.378 * MASTER <-> SLAVE sync: receiving 16435 bytes from master
[11791] 19 Nov 08:31:14.379 * MASTER <-> SLAVE sync: Loading DB in memory
[11791] 19 Nov 08:31:14.380 * MASTER <-> SLAVE sync: Finished with success
 
sentinel
[6565] 19 Nov 08:31:13.281 * +demote-old-slave slave 172.10.43.42:6379 172.10.43.42 6379 @ mymaster 172.10.43.47 6379
[6565] 19 Nov 08:31:13.481 # -sdown slave 172.10.43.42:6379 172.10.43.42 6379 @ mymaster 172.10.43.47 6379
[6565] 19 Nov 08:31:23.304 * +slave slave 172.10.43.42:6379 172.10.43.42 6379 @ mymaster 172.10.43.47 6379
 
slave
[17052] 18 Nov 10:39:24.628 * Slave ask for synchronization
[17052] 18 Nov 10:39:24.628 * Starting BGSAVE for SYNC
[17052] 18 Nov 10:39:24.629 * Background saving started by pid 17181
[17181] 18 Nov 10:39:24.713 * DB saved on disk
[17181] 18 Nov 10:39:24.713 * RDB: 0 MB of memory used by copy-on-write
[17052] 18 Nov 10:39:24.798 * Background saving terminated with success
[17052] 18 Nov 10:39:24.799 * Synchronization with slave succeeded

old master 를 서비스를 위해 다시 master 로 변경 

master
[11791] 19 Nov 08:35:44.271 * MASTER MODE enabled (user request)
 
sentinel이 둘의 role을 다시 변경해준다.
sentinel
[6565] 19 Nov 08:35:54.022 # +failover-detected master mymaster 172.10.43.47 6379
[6565] 19 Nov 08:35:54.122 # +failover-end master mymaster 172.10.43.47 6379
[6565] 19 Nov 08:35:54.122 # +switch-master mymaster 172.10.43.47 6379 172.10.43.42 6379
[6565] 19 Nov 08:35:54.223 * +demote-old-slave slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
[6565] 19 Nov 08:36:04.244 * +slave slave 172.10.43.47:6379 172.10.43.47 6379 @ mymaster 172.10.43.42 6379
 
master
[11791] 19 Nov 08:35:54.935 * Slave ask for synchronization
[11791] 19 Nov 08:35:54.935 * Starting BGSAVE for SYNC
[11791] 19 Nov 08:35:54.936 * Background saving started by pid 11888
[11888] 19 Nov 08:35:54.943 * DB saved on disk
[11888] 19 Nov 08:35:54.943 * RDB: 0 MB of memory used by copy-on-write
[11791] 19 Nov 08:35:54.992 * Background saving terminated with success
[11791] 19 Nov 08:35:54.993 * Synchronization with slave succeeded
 
slave
[17052] 18 Nov 10:43:59.317 * SLAVE OF 172.10.43.42:6379 enabled (user request)
[17052] 18 Nov 10:44:00.005 * Connecting to MASTER...
[17052] 18 Nov 10:44:00.006 * MASTER <-> SLAVE sync started
[17052] 18 Nov 10:44:00.007 * Non blocking connect for SYNC fired the event.
[17052] 18 Nov 10:44:00.008 * Master replied to PING, replication can continue...
[17052] 18 Nov 10:44:00.065 * MASTER <-> SLAVE sync: receiving 16446 bytes from master
[17052] 18 Nov 10:44:00.066 * MASTER <-> SLAVE sync: Loading DB in memory
[17052] 18 Nov 10:44:00.066 * MASTER <-> SLAVE sync: Finished with success
[17052] 18 Nov 10:44:00.067 * Background append only file rewriting started by pid 17512
[17512] 18 Nov 10:44:00.194 * SYNC append only file rewrite performed
[17512] 18 Nov 10:44:00.194 * AOF rewrite: 0 MB of memory used by copy-on-write
[17052] 18 Nov 10:44:00.215 * Background AOF rewrite terminated with success
[17052] 18 Nov 10:44:00.215 * Parent diff successfully flushed to the rewritten AOF (0 bytes)
[17052] 18 Nov 10:44:00.216 * Background AOF rewrite finished successfully




Reference

http://redis.io/topics/sentinel

http://redis.io/topics/persistence

http://charsyam.wordpress.com/2013/07/25/%EC%9E%85-%EA%B0%9C%EB%B0%9C-redis-%EC%9E%A5%EC%95%A0-twilio-%EC%9D%98-redis-%EC%9E%A5%EC%95%A0%EC%9D%98-%EC%9B%90%EC%9D%B8%EA%B3%BC-%ED%95%B4%EA%B2%B0%EC%B1%85/

http://charsyam.wordpress.com/2013/10/09/%EC%9E%85-%EA%B0%9C%EB%B0%9C-redis-sentinel%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%98%EB%A9%B4%EC%84%9C-%EA%B2%AA%EA%B2%8C-%EB%90%98%EB%8A%94-%EB%AC%B8%EC%A0%9C-%ED%95%98%EB%82%98%EC%99%80-%ED%95%B4/


'dev > redis' 카테고리의 다른 글

What's new in Redis 4.0?  (0) 2017.02.03
JedisSentinelPool 사용기 Jedis + sentinel..  (0) 2013.11.28