redis

redis 2부 - replication ...

drscg 2019. 4. 8. 11:20

지난 게시물인 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