지난 게시물인 redis 1부 - 설치에서는 stand alone으로 동작하도록 redis를 구성하였다.
이렇게 stand alone으로 구성할 경우, failover 상황에 대한 대비가 전혀 되지 않는 문제점을 가지게 된다.
이런 상황에 대비하기 위해, redis를 replication으로 구성해 보겠다.
redis도 DB의 일종이고, 대부분의 open source DB와 마찬가지로 replication을 지원한다.
1. 전체 구성
일단, sample로 만들어볼 목표 시스템은 아래와 같이 구성할 것이다.
이 예제에서는, 4대의 Machine에 Master 1개, Slave 3개, Sentinel 3개로 구성해 보겠다.
2. 개념
위 그림에서 보이는 몇 가지 새로운 개념에 대해 알아보자.
Master | read/write 용 redis redis에서 Master는 하나만 존재할 수 있다. |
Salve | read only 용 redis, Master의 data를 mirror하고 있는 redis |
Sentinel | redis의 Master와 Slave를 감시하다가, Master failover시에 새로운 Master를 지정 Sentinel 자체에도 문제가 발생할 수 있기 때문에, 여러 대의 Sentinel로 구성. 적어도 3개 이상, 홀수개로 구성해야 한다. Master를 지정하기 위해, Sentinel끼리 다수결로 결정 위의 경우, Sentinel이 3대이므로, 2 이상의 표를 얻어야 master로 선정 이 때, 숫자 2를 quorum이라 한다. quorum을 결정하는 수식 : (sentinel 의 수) / 2 + 1 |
3. replication의 구성
지난 1부애서 10.0.0.1에 설치한 redis를 master로 이용하겠다.
그리고, master에 필요한 설정(masterauth)은 이미 했으니, slave만 구성하면 된다.
download and build
1부에서 소개한 대로, direcory를 똑같이 구성하고, redis를 build 하자.
setting
1부에서 소개한 install_server.sh 을 실행해도 되지만, master(10.0.0.1)에 이미 생성해 둔게 있으니, 복사해서 이용하도록 하자. port는 master와 마찬가지로 16000 을 사용하지만, ip 는 각 machine에 맞게 변경해야 한다.
master에서 아래 file을 복사해 오자.
/home/backup/redis/conf/redis_16000.conf /etc/init.d/redis_16000 |
복사해 온 파일이 /home/backup/temp 에 있다고 가정하자.
$ ls -al /home/backup/temp -rwxr-xr-x 1 backup backup 1815 Apr 4 10:43 redis_16000 -rw-r--r-- 1 backup backup 62494 Apr 4 10:42 redis_16000.conf |
각 파일을 복사하자.
redis_16000 file은 실행 파일이므로, 실행 권한이 있어야 한다.
$ cp /home/backup/temp/redis_16000.conf /home/backup/redis/conf # cp /home/backup/temp/redis_16000 /etc/init.d/ # chmod +x /etc/init.d/redis_16000 |
먼저, conf 파일을 수정하자.
# vi /home/backup/redis/conf/redis_16000.conf bind 10.0.0.2 port 1600 replicaof 10.0.0.1 16000 requirepass 123!@#qwe masterauth 123!@#qwe loglevel notice dir /home/backup/redis/data/redis_16000 pidfile /home/backup/redis/pid/redis_16000.pid logfile /home/backup/redis/log/redis_16000.log |
주의할 부분은 3 곳이다.
bind 10.0.0.2 | 이 redis가 실행될 machine의 ip |
replicaof 10.0.0.1 16000 | 이 redis가 10.0.0.1 의 16000 에서 동작하고 있는 redis의 slave 라는 의미 |
requirepass | 이 값은 master/slave에 동일하게 주어야 한다. slave도 상황에 따라 master가 될 수 있으므로 ... |
masterauth | replication시에 master에 접속하기 위해 사용하는 password master의 requirepass와 동일해야 한다. 결론적으로, redis cluster에서 모든 master/slave의 requirepass와 masterauth는 동일한 값을 가져야 한다. |
그리고, service 파일을 수정하자.
# vi /etcc/init.d/redis_16000 EXEC=/usr/local/bin/redis-server CLIEXEC=/usr/local/bin/redis-cli PIDFILE=/home/backup/redis/pid/redis_16000.pid CONF="/home/backup/redis/conf/redis_16000.conf" REDISHOST="10.0.0.2" REDISPORT="16000" PASSWORD="123!@#qwe" ############### ~~~ $CLIEXEC -h $REDISHOST -p $REDISPORT -a $PASSWORD shutdown |
주의할 부분은 REDISHOST="10.0.0.2" 부분이다.
conf 파일의 bind 부분에 설정한 ip를 입력하자.
이제, service가 reboot시에도 자동 실행되도록 등록해 보자
install_server.sh 를 이용하지 않았기 때문에, 등록되어 있지 않다.
# chkconfig redis_16000 on # chkconfig --list | grep redis redis_16000 0:off 1:off 2:on 3:on 4:on 5:on 6:off |
위와 같은 작업을 각 slave에서 반복하자.
execute
설치가 완료되면, 각 slave에서 redis를 시작해 보자.
# service redis_16000 start Starting Redis server... |
salve의 log 파일을 확인해 보면, 아래와 같이 나올 것이다.
# vi /home/backup/redis/log/redis_16000.log 7189:C 03 Apr 2019 12:51:48.521 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 7189:C 03 Apr 2019 12:51:48.521 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=7189, just started 7189:C 03 Apr 2019 12:51:48.521 # Configuration loaded _._ _.-``__ ''-._ _.-`` `. `_. ''-._ Redis 5.0.4 (00000000/0) 64 bit .-`` .-```. ```\/ _.,_ ''-._ ( ' , .-` | `, ) Running in standalone mode |`-._`-...-` __...-.``-._|'` _.-'| Port: 16000 | `-._ `._ / _.-' | PID: 7190 `-._ `-._ `-./ _.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | http://redis.io `-._ `-._`-.__.-'_.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-' `-._ `-.__.-' _.-' `-._ _.-' `-.__.-' 7190:S 03 Apr 2019 12:51:48.531 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 7190:S 03 Apr 2019 12:51:48.531 # Server initialized 7190:S 03 Apr 2019 12:51:48.531 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 7190:S 03 Apr 2019 12:51:48.532 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reb oot. Redis must be restarted after THP is disabled. 7190:S 03 Apr 2019 12:51:48.532 * Ready to accept connections 7190:S 03 Apr 2019 12:51:48.532 * Connecting to MASTER 10.0.0.1:16000 7190:S 03 Apr 2019 12:51:48.532 * MASTER <-> REPLICA sync started 7190:S 03 Apr 2019 12:51:48.532 * Non blocking connect for SYNC fired the event. 7190:S 03 Apr 2019 12:51:48.533 * Master replied to PING, replication can continue... 7190:S 03 Apr 2019 12:51:48.534 * Partial resynchronization not possible (no cached master) 7190:S 03 Apr 2019 12:51:48.539 * Full resync from master: d7f06da8d1b8fa4c7c6bcf1f51b342fee75beace:0 7190:S 03 Apr 2019 12:51:48.583 * MASTER <-> REPLICA sync: receiving 175 bytes from master 7190:S 03 Apr 2019 12:51:48.583 * MASTER <-> REPLICA sync: Flushing old data 7190:S 03 Apr 2019 12:51:48.584 * MASTER <-> REPLICA sync: Loading DB in memory 7190:S 03 Apr 2019 12:51:48.584 * MASTER <-> REPLICA sync: Finished with success |
위의 log를 보면 다음과 같은 log를 발견할 수 있다.
Connecting to MASTER 10.0.0.1:16000
10.0.0.1 의 16000에서 동작하고 있는 Master에 접속하려는 것을 알 수 있다.
이번에는 Master의 log를 살펴보자.
# vi /home/backup/redis/log/redis_16000.log 7917:M 03 Apr 2019 16:52:55.629 * Replica 10.0.0.2:16000 asks for synchronization 7917:M 03 Apr 2019 16:52:55.629 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'df6282363217e236f2b81f60b64fc6af4781e92a', my replication IDs are '671b47d3a3f4f9f224d78d462e24c4dd6aa4a869' and '0000000000000000000000000000000000000000') 7917:M 03 Apr 2019 16:52:55.629 * Starting BGSAVE for SYNC with target: disk 7917:M 03 Apr 2019 16:52:55.632 * Background saving started by pid 7948 7948:C 03 Apr 2019 16:52:55.638 * DB saved on disk 7948:C 03 Apr 2019 16:52:55.639 * RDB: 6 MB of memory used by copy-on-write 7917:M 03 Apr 2019 16:52:55.710 * Background saving terminated with success 7917:M 03 Apr 2019 16:52:55.710 * Synchronization with replica 10.0.0.2:16000 succeeded |
요약하면, 10.0.0.2의 16000에서 sync 요청이 와서, sync 작업이 성공적으로 동작했다는 의미이다.
그러면, command line client인 redis-cli를 이용하여, 접속해 보자.
먼저, Master에 접속해 보자.
$ redis-cli -h 10.0.0.1 -p 16000 -a 123\!@#qwe Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 10.0.0.1:16000> info Replication # Replication role:master connected_slaves:3 slave0:ip=10.0.0.2,port=16000,state=online,offset=15511782,lag=1 slave1:ip=10.0.0.3,port=16000,state=online,offset=15511639,lag=1 slave1:ip=10.0.0.4,port=16000,state=online,offset=15511639,lag=1 master_replid:671b47d3a3f4f9f224d78d462e24c4dd6aa4a869 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:15511925 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:14463350 repl_backlog_histlen:1048576 10.0.0.1:16000> set foo_1 "bar_1" OK 10.0.0.1:16000> get foo_1 "bar_1" 10.0.0.1:16000> exit |
role이 master이고, 3개의 salve가 있다는 것을 알 수 있다.
set commnad를 이용해, <"foo_1", "bar_1">을 저장하고,
get commnad를 이용해, data를 읽어 왔다.
그 다음엔, Slave에 접속해 보자.
$ redis-cli -h 10.0.0.2 -p 16000 -a 123\!@#qwe Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 10.0.0.2:16000> info Replication # Replication role:slave master_host:10.0.0.1 master_port:16000 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_repl_offset:15499400 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:671b47d3a3f4f9f224d78d462e24c4dd6aa4a869 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:15499400 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:14450825 repl_backlog_histlen:1048576 10.0.0.2:16000> get foo_1 "bar_1" 10.0.0.2:16000> exit |
role이 salve이고, master는 10.0.0.1의 16000 이라는 것을 알 수 있다.
get commnad를 이용해, data를 읽어 오니, master에 입력한 data가 저장되어 있는 것을 볼 수 있다.
replication은 정상적이다 라는 것을 알 수 있다.
4. Sentinel의 구성
이제, replation 작업은 끝났다. 그러나, 이 상태로는 완전한 상태가 아니다.
예를 들어, Master의 Redis가 down된다면, 이 Redis cluster는 data를 더 이상 write 할 수 없는 상태가 된다.
위에서도 설명했지만, Sentinel이라는 것을 이용하여, Redis Cluster를 감시해야 한다.
redis의 Master와 Slave를 감시하다가, Master failover시에 새로운 Master를 지정하는 것이 Sentinel의 역활이다.
Sentinel은 또 다른 redis이다. conf 파일이 다를 뿐이다.
1부에서 source 파일 압축을 푼 곳(/home/backup/redis/redis-5.0.4)에 가 보면, sentinel.conf 라는 file이 있다.
이를 적당히 수정하여, conf 파일로 사용하면 된다.
자, 애초 계획했던 대로, 3대의 Sentinel을 구성해 보자.
10.0.0.1, 10.0.0.2, 10.0.0.4 에 설치하고, 17000 port를 사용할 것이다.
Sentinel의 기본 port는 26379 인데, 기본을 좋아하지 않기 때문에 ... ^^
setting
원본 conf(sentinel.conf)를 redis의 conf direcory로 복사한다.
$ cp /home/backup/redis/redis-5.0.4/sentinel.conf /home/backup/redis/conf/redis_sentinel_17000.conf |
Sentinel의 conf 파일을 수정하자.
파일을 열어서, 아래 내용에 해당하는 부분을 확인하고 수정하자.
# vi /home/backup/redis/conf/redis_sentinel_17000.conf bind 10.0.0.1 port 17000 daemonize yes loglevel notice sentinel monitor saerom.master 10.0.0.1 16000 2 sentinel auth-pass saerom.master 123!@#qwe sentinel down-after-milliseconds saerom.master 10000 sentinel parallel-syncs saerom.master 1 sentinel failover-timeout saerom.master 180000 pidfile "/home/backup/redis/pid/redis_sentinel_17000.pid" logfile "/home/backup/redis/log/redis_sentinel_17000.log" |
각 항목은 아래와 같은 의미를 가지고 있다.
bind 10.0.0.1 | Sentinel의 ip |
port 17000 | Sentinel이 listen할 port |
daemonize yes | daemon으로 background에서 실행 |
loglevel notice | log level |
sentinel monitor saerom.master 10.0.0.1 16000 2 | saerom.master : Redis Master를 나타내는 임의의 alias 10.0.0.1 16000 : Redis Master의 ip와 port 2 : quorum, sentinel이 3대이므로 3 / 2 + 1 = 2 |
sentinel auth-pass saerom.master 123!@#qwe | Master의 requirepass |
sentinel down-after-milliseconds saerom.master 10000 | 이 시간동안 Redis Master로 연결이 안되면 Master Down으로 판단, 단위 : ms, Default : 30초 |
sentinel parallel-syncs saerom.master 1 | Slave가 여러 개일 경우 몇 개씩 동시에 Sync 1이면 Salve 하나씩 순차적으로 2 로 하면, 한번에 2개의 Slave가 Sync를 진행하므로 Master의 부하가 증가 |
sentinel failover-timeout saerom.master 180000 | http://redisgate.kr/redis/sentinel/sentinel_failover-timeout.php |
pidfile "/home/backup/redis/pid/redis_sentinel_17000.pid" | process id 파일의 경로 |
logfile "/home/backup/redis/log/redis_sentinel_17000.log" | log 파일의 경로 |
Sentinel을 daemon으로 동작시키겠다라고 지정(daemonize yes)하였으므로, service로 등록하자.
위에서 언급한 것처럼, Sentinel은 또 다른 redis이므로, redis의 service 파일을 복사한 후 수정해서 사용하면 된다.
# cp /etc/init.d/redis_16000 /etc/init.d/redis_sentinel_17000 # vi /etc/init.d/redis_sentinel_17000 EXEC=/usr/local/bin/redis-sentinel CLIEXEC=/usr/local/bin/redis-cli PIDFILE=/home/backup/redis/pid/redis_sentinel_17000.pid CONF="/home/backup/redis/conf/redis_sentinel_17000.conf" REDISHOST="10.0.0.1" REDISPORT="17000" ############### ~~~ $CLIEXEC -h $REDISHOST -p $REDISPORT shutdown |
이제, service가 reboot시에도 자동 실행되도록 등록해 보자
# chkconfig redis_sentinel_17000 on # chkconfig --list | grep redis redis_17000 0:off 1:off 2:on 3:on 4:on 5:on 6:off |
위와 같은 작업을 Sentinel을 설치할 Machine에서 반복하자.
excute
각 Server에서 Sentinel을 모두 실행하자.
# service redis_sentinel_17000 start Starting Redis server... |
process 를 확인해 보자
# ps -ef | grep redis root 7944 1 0 Apr03 ? 00:04:37 /usr/local/bin/redis-server 10.0.0.1:16000 root 12409 1 0 10:53 ? 00:00:00 /usr/local/bin/redis-sentinel 10.0.0.1:17000 [sentinel] |
log를 확인해 보자.
$ vi /home/backup/redis/log/redis_sentinel_17000.log 12408:X 05 Apr 2019 10:53:45.536 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 12408:X 05 Apr 2019 10:53:45.536 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=12408, just started 12408:X 05 Apr 2019 10:53:45.536 # Configuration loaded 12409:X 05 Apr 2019 10:53:45.546 * Running mode=sentinel, port=7000. 12409:X 05 Apr 2019 10:53:45.547 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 12409:X 05 Apr 2019 10:53:45.547 # Sentinel ID is 2f74bada2a3166fff7455cbb3e652a97e8074135 12409:X 05 Apr 2019 10:53:45.548 # +monitor master saerom.master 10.0.0.1 16000 quorum 2 |
10.0.0.1 의 16000 에서 동작하고 있는 redis를 감시하고 있다는 것을 알 수 있다.
test
이제 설치, 설정, 실행 작업이 모두 끝났다. Sentinel을 설치한 효과가 있는지 확인해 보자.
이를 위해 Master를 중시시키면 어떤 일이 일어나는지 살펴 보자.
현재 Master인 10.0.0.1의 redis를 중지시키자.
# service redis_16000 stop Stopping ... Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. Redis stopped |
Sentinel의 log를 확인해 보자.
$ vi /home/backup/redis/log/redis_sentinel_17000.log 12409:X 05 Apr 2019 10:55:22.998 # +sdown master saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:23.051 # +odown master saerom.master 10.0.0.1 16000 #quorum 2/2 12409:X 05 Apr 2019 10:55:23.051 # +new-epoch 1 12409:X 05 Apr 2019 10:55:23.051 # +try-failover master saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:23.054 # +vote-for-leader 2f74bada2a3166fff7455cbb3e652a97e8074135 1 12409:X 05 Apr 2019 10:55:23.060 # 7c3f129a21af494fafb49ec6d7763f35e66667ec voted for 2f74bada2a3166fff7455cbb3e652a97e8074135 1 12409:X 05 Apr 2019 10:55:23.061 # a273c2a5611dd437c7bb2f0fcadb7ae5d456f84b voted for 2f74bada2a3166fff7455cbb3e652a97e8074135 1 12409:X 05 Apr 2019 10:55:23.125 # +elected-leader master saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:23.125 # +failover-state-select-slave master saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:23.207 # +selected-slave slave 10.0.0.2:16000 10.0.0.2 16000 @ saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:23.207 * +failover-state-send-slaveof-noone slave 10.0.0.2:16000 10.0.0.2 16000 @ saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:23.279 * +failover-state-wait-promotion slave 10.0.0.2:16000 10.0.0.2 16000 @ saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:23.302 # +promoted-slave slave 10.0.0.2:16000 10.0.0.2 16000 @ saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:23.302 # +failover-state-reconf-slaves master saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:23.332 * +slave-reconf-sent slave 10.0.0.3:16000 10.0.0.3 16000 @ saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:24.155 # -odown master saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:24.354 * +slave-reconf-inprog slave 10.0.0.3:16000 10.0.0.3 16000 @ saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:24.354 * +slave-reconf-done slave 10.0.0.3:16000 10.0.0.3 16000 @ saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:24.431 # +failover-end master saerom.master 10.0.0.1 16000 12409:X 05 Apr 2019 10:55:24.431 # +switch-master saerom.master 10.0.0.1 16000 10.0.0.2 16000 12409:X 05 Apr 2019 10:55:24.431 * +slave slave 10.0.0.3:16000 10.0.0.3 16000 @ saerom.master 10.0.0.2 16000 12409:X 05 Apr 2019 10:55:24.431 * +slave slave 10.0.0.1:16000 10.0.0.1 16000 @ saerom.master 10.0.0.2 16000 12409:X 05 Apr 2019 10:55:34.471 # +sdown slave 10.0.0.1:16000 10.0.0.1 16000 @ saerom.master 10.0.0.2 16000 |
10.0.0.1의 redis가 down되었고, 10.0.0.2의 redis가 Master가 되었다는 것을 알 수 있다.
10.0.0.2에 접속해, Master가 되었음을 확인할 수 있다.
$ redis-cli -h 10.0.0.2 -p 16000 -a 123\!@#qwe Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 10.0.0.2:16000> info Replication # Replication role:master connected_slaves:2 slave1:ip=10.0.0.3,port=16000,state=online,offset=15511639,lag=1 slave1:ip=10.0.0.4,port=16000,state=online,offset=15511639,lag=1 master_replid:671b47d3a3f4f9f224d78d462e24c4dd6aa4a869 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:15511925 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:14463350 repl_backlog_histlen:1048576 10.0.0.2:16000> exit |
현재 상태에서, 10.0.0.1 의 redis를 다시 시작하면, 어떻게 될까?
# service redis_16000 start Starting Redis server... |
Sentinel의 log를 확인해 보자.
$ vi /home/backup/redis/log/redis_sentinel_17000.log 12409:X 05 Apr 2019 10:58:12.662 # -sdown slave 10.0.0.1:16000 10.0.0.1 16000 @ saerom.master 10.0.0.2 16000 12409:X 05 Apr 2019 10:58:22.640 * +convert-to-slave slave 10.0.0.1:16000 10.0.0.1 16000 @ saerom.master 10.0.0.2 16000 |
10.0.0.1의 redis에 접속해 보자.
$ redis-cli -h 10.0.0.1 -p 16000 -a 123\!@#qwe Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 10.0.0.1:16000> info Replication # Replication role:slave master_host:10.0.0.2 master_port:16000 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_repl_offset:15499400 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:671b47d3a3f4f9f224d78d462e24c4dd6aa4a869 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:15499400 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:14450825 repl_backlog_histlen:1048576 10.0.0.1:16000> exit |
현재 slave로 동작하고 있고, Master는 10.0.0.2 이다.
여기까지 replication 구성을 완료하였다.
3부에서는 centos에서 redis를 실행했을 때 나타나는 경고 메세지에 대해서 알아보겠다.
'redis' 카테고리의 다른 글
redis 4부 - jedis를 이용한 client sample ... (0) | 2019.04.08 |
---|---|
redis 3부 - Warning 제거 ... (0) | 2019.04.08 |
redis 1부 - 설치 ... (0) | 2019.04.08 |