집 > 기사 > 백엔드 개발 > Redis 클러스터 장애 분석

Redis 클러스터 장애 분석

小云云원래의: 2017-12-14 15:04:062356검색

Redis 클러스터는 분산되어 단일 장애 지점을 허용하는 고급 버전의 Redis입니다. Redis 클러스터에는 가장 중요하거나 중앙에 있는 노드가 없습니다. 이 버전의 주요 목표 중 하나는 선형 확장 가능한 기능을 설계하는 것입니다(노드를 마음대로 추가하고 삭제할 수 있음).

이 글은 주로 Redis 클러스터 장애에 대한 자세한 분석을 소개합니다. 모두에게 도움이 되기를 바랍니다. ㅋㅋㅋ :

동일한 랙에서

xx.x.xxx.199

xx.x.xxx.200
xx.x.xxx.201

redis-server 프로세스 상태:

Passed Command ps -eo pid,lstart | grep $pid,

프로세스가 3개월 동안 계속 실행되고 있음을 발견했습니다

실패 전 클러스터의 노드 상태:

xx.x.xxx.200 :8371( bedab2c537fe94f8c0363ac4ae97d56832316e65) 마스터
xx.x.xxx.199:8373(792020fe66c00ae56e27cd7a048ba6bb2b67adb6) 슬레이브
xx.x.xxx.201:8375(5ab4f85 306da6d 633e4834b4d3327f45af02171b) 마스터

xx.x.xxx.201:8372(826607654f5ec81c3756a4a21f357e644efe605a) 슬레이브

xx.x.xxx.199:8370(462cadcb41e635d460425430d318f2fe464665c5) 마스터xx.x.xxx.200:8374(1238085b578390f3c8efa30824fd9a4baba10ddf) 슬레이브

------ --- ----------다음은 로그 분석입니다------------------ --- --

1단계:

마스터 노드 8371이 슬레이브 노드 8373과의 연결이 끊어졌습니다.
46590:M 09 Sep 18:57:51.379 # 슬레이브와의 연결 xx.x.xxx.199:8373 분실.

2단계:

마스터 노드 8370/8375는 8371이 연락이 끊겼다고 판단합니다.
42645:M 09 Sep 18:57:50.117 * 표시 노드 bedab2c537fe94f8c0363ac4ae97d56832316e65 실패로 간주됩니다(정족수 도달).

3단계: 노드 8372/8373/8374에서 8371이 손실되었다는 마스터 노드 8375를 수신했습니다.
46986:S 09 Sep 18:57:50.120 * 5ab4f85306da6d633e4834b4d3327f45af02171b에서 침대에 대한 FAIL 메시지 수신 ab2c537fe94f8c0363ac 4ae97d56832316e65

4단계:
마스터 노드 8370/8375 인증 8373 마스터 노드 전송으로 업그레이드:
42645:M 09 Sep 18:57:51.055 # epoch 16에 대해 792020fe66c00ae56e27cd7a048ba6bb2b67adb6에 장애 조치 인증이 부여됨

5단계:

원래 노드 837 1 직접 수정 8373의 슬레이브 노드가 됩니다.
46590:M 09 Sep 18:57:51.488 # 구성 변경이 감지되었습니다. 792020fe66c00ae56e27cd7a048ba6bb2b67adb6

6단계:
마스터 노드 8370/8375/8373 클리어 8371 실패 상태:
42645:M 09 Sep 18:57:51.522 * bedab2c537fe94f8c0363ac4ae97d56832316e65 노드의 FAIL 상태 지우기: 슬롯이 없는 마스터에 다시 연결할 수 있습니다.

7단계:

새 슬레이브 노드 8371에서 시작하고 새 마스터 노드 8373, 첫 번째 전체 데이터 동기화:
8373 로그:

4255:M 09 Sep 18:57:51.906 * 슬레이브 xx.x.xxx.200:8371

4255:M 09 Sep 18:57:51.906 * BGSAVE 시작에서 전체 재동기화 요청 대상이 있는 SYNC의 경우: disk4255: M 09 Sep 18:57:51.941 * 백그라운드 저장이 pid 52308371에 의해 시작됨 로그:
46590:S 09 Sep 18:57:51.948 * 마스터에서 전체 재동기화: d7751c4ebf1e63d3baebea1ed409e0e7243 a4423:440721 826993

8단계:마스터 노드 8370/8375는 8373(새 소유자)이 손실되었음을 확인합니다.
42645:M 09 Sep 18:58:00.320 * 노드 792020fe66c00ae56e27cd7a048ba6bb2b67adb6을 실패로 표시 (정족수 도달).

단계 9: 마스터 노드 8370/8375 결정 8373(새 마스터) 복원됨:
60295:M 09 Sep 18:58:18.181 * 노드 792020fe66c00ae56e27cd7a048ba6bb2b67adb6에 대한 FAIL 상태 지우기: 다시 연결할 수 있으며 일정 시간이 지나면 아무도 해당 슬롯을 제공하지 않습니다.

10단계:

전체 동기화를 완료하려면 마스터 노드 8373 BGSAVE 작업이 필요합니다.
5230:C 09 Sep 18:59:01.474 * DB가 디스크에 저장됨

5230:C 09 Sep 18:59:01.491 * RDB: 7112 쓰기 중 복사에 사용된 메모리 MB

4255:M 09 Sep 18:59:01.877 * 백그라운드 저장이 성공으로 종료되었습니다

11단계:

노드 8371에서 시작하여 마스터 노드 8373에서 수신된 데이터:

46590: S 09 Sep 18:59:02.263 * MASTER e09be6022d700e04aeaa85a5f42fdcb2 SLAVE sync: 마스터로부터 2657606930바이트 수신

12단계:

마스터 노드 8373은 슬레이브 노드 8371이 출력 버퍼를 제한했음을 발견했습니다.

4255:M 9월 9일 19:00:19.014 # 클라이언트 id=14259015 addr=xx.x.xxx.200:21772 fd=844 name= age=148 유휴=148 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=16349 oll=4103 omem=95944066 events=rw cmd=psync 출력 버퍼 제한 극복을 위해 최대한 빨리 종료될 예정입니다.4255:M 09 Sep 19:00:19.015 # 슬레이브와의 연결 xx.x.xxx.200: 8371 분실.

13단계:
슬레이브 노드 8371이 마스터 노드 8373의 데이터를 동기화하지 못하고 연결이 끊어졌으며 첫 번째 전체 동기화에 실패했습니다.
46590:S 09 Sep 19:00:19.018 # 동기화를 시도하는 중 I/O 오류가 발생했습니다. MASTER 사용: 연결 끊김
46590:S 09 Sep 19:00:20.102 * MASTER xx.x.xxx.199:8373
46590:S 09 Sep 19:00:20.102 * MASTER e09be6022d700e04aeaa85a5f42fdcb2

14단계:
노드 8371에서 동기화 다시 시작, 연결 실패, 마스터 노드 8373에 대한 연결 수가 가득 참:
46590:S 09 Sep 19:00:21.103 * MASTER xx.x.xxx에 연결 중 .199:8373
46590:S 09 Sep 19:00:21.103 * MASTER e09be6022d700e04aeaa85a5f42fdcb2 SLAVE 동기화가 시작되었습니다
46590:S 09 Sep 19:00:21.104 * SYNC에 대한 비차단 연결이 이벤트를 시작했습니다.
46590:S 09 Sep 19: 00:21.104 # 마스터에서 PING에 대한 오류 응답: '-ERR 최대 클라이언트 수에 도달했습니다'

15단계:
노드 8371에서 마스터 노드 8373으로 다시 연결하고 두 번째로 전체 동기화를 시작합니다. :
8371 로그:
46590:S 09 Sep 19:00:49.175 * MASTER xx.x.xxx.199:8373
46590:S 09 Sep 19:00:49.175 * MASTER e09be6022d700e04aeaa85a5f42fdcb2
46590:S 09 Sep 19:00:49.175 * SYNC에 대한 비차단 연결이 이벤트를 시작했습니다.
46590:S 09 Sep 19:00:49.176 * 마스터가 PING에 응답했으며 복제는 계속될 수 있습니다...
46590:S 09 Sep 19:00:49.179 * 부분 재동기화 불가능(캐시된 마스터 없음)
46590:S 09 Sep 19:00:49.501 * 마스터에서 전체 재동기화: d7751c4ebf1e63d3baebea1ed409e0e7243a4423:440780763454
8373 로그:
4255:M 9월 9일 19:00:49.176 * 슬레이브 xx.x .xxx.200:8371이 동기화를 요청합니다
4255:M 09 Sep 19:00:49.176 * 슬레이브 xx.x.xxx.200:8371
4255:M 09 Sep 19:00에 의해 전체 재동기화가 요청되었습니다. 49.176 * 대상: disk
4255:M 09 Sep 19:00:49.498 * 백그라운드 저장이 pid 18413
18413:C 09 Sep 19:01:52.466에 의해 시작됨 * DB가 디스크에 저장됨
18413:C 09 Sep 19:01:52.620 * RDB: 쓰기 중 복사에 사용된 메모리 2124MB
4255:M 09 Sep 19:01:53.186 * 백그라운드 저장이 성공으로 종료되었습니다

16단계:
노드 8371의 데이터 동기화 성공적으로 경험을 로드하기 시작했습니다. 메모리:
46590:S 09 Sep 19:01:53.190 * MASTER e09be6022d700e04aeaa85a5f42fdcb2 SLAVE sync: 마스터에서 2637183250바이트 수신
46590:S 09 Sep 19:04:51.485 * MASTER 34c3e6a88750e9d70e32fce585209217 SLAVE 동기화: 오래된 데이터 플러시
46590:S 09 Sep 19:05:58.695 * MASTER e09be6022d700e04aeaa85a5f42fdcb2 SLAVE 동기화: 메모리에 DB 로드 중

17단계:
클러스터가 정상으로 돌아갑니다. :M 09 Sep 19:05: 58.786 * bedab2c537fe94f8c0363ac4ae97d56832316e65 노드의 FAIL 상태 지우기: 슬레이브에 다시 연결할 수 있습니다.

18단계: 노드 8371에서 데이터를 성공적으로 동기화합니다. 7분 소요: 6590:S 09 9월 19일: 08:19. 303 * MASTER c8fa30c56d0a6b6d6017db05e2d4e757 SLAVE 동기화 완료

8371 연결 끊김 원인 분석:
여러 머신이 동일한 랙에 있으므로 네트워크 중단이 발생할 가능성이 없습니다. 이므로 SLOWLOG GET 명령어를 통해 확인합니다. 느린 쿼리 로그를 확인한 결과 KEYS 명령어가 실행된 것을 확인했는데, 8.3초가 걸렸습니다. 그러다가 클러스터 노드 타임아웃 설정을 확인해보니 5s(cluster-node-timeout)였습니다. 5000)

노드 연결이 끊어진 이유:
클라이언트가 8.3초 걸린 명령을 실행했는데,

2016/9/9 18:57:43 KEYS 명령 실행을 시작했습니다

2016/9/9 18:57:50 8371 연결이 끊긴 것으로 판단되었습니다(redis 로그)

2016/9/9 18:57:51 KEYS 명령 실행 후

요약하면 다음과 같은 문제가 있습니다.

1. Cluster-node-timeout 설정이 상대적으로 짧기 때문에 속도가 느립니다. KEYS 쿼리로 인해 클러스터 판단 노드 8371의 연결이 끊겼습니다.

2. 8371이 연결이 끊겼기 때문에 8373이 마스터로 업그레이드되고 마스터가 시작되었습니다. -슬레이브 동기화

3. 클라이언트 출력-버퍼 제한 구성의 한계로 인해 첫 번째와 두 번째 전체 동기화가 실패했습니다

4.PHP 클라이언트의 연결 풀에 문제가 있어 연결되었습니다. 서버가 미친 듯이 SYN 공격과 유사한 효과가 발생했습니다

5. 첫 번째 전체 동기화가 실패한 후 슬레이브 노드가 마스터 노드에 다시 연결되는 데 30초가 걸렸습니다(최대 연결 수를 1w 초과)

client-output-buffer-limit 매개변수 정보:

# The syntax of every client-output-buffer-limit directive is the following: 
# 
# client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds> 
# 
# A client is immediately disconnected once the hard limit is reached, or if 
# the soft limit is reached and remains reached for the specified number of 
# seconds (continuously). 
# So for instance if the hard limit is 32 megabytes and the soft limit is 
# 16 megabytes / 10 seconds, the client will get disconnected immediately 
# if the size of the output buffers reach 32 megabytes, but will also get 
# disconnected if the client reaches 16 megabytes and continuously overcomes 
# the limit for 10 seconds. 
# 
# By default normal clients are not limited because they don&#39;t receive data 
# without asking (in a push way), but just after a request, so only 
# asynchronous clients may create a scenario where data is requested faster 
# than it can read. 
# 
# Instead there is a default limit for pubsub and slave clients, since 
# subscribers and slaves receive data in a push fashion. 
# 
# Both the hard or the soft limit can be disabled by setting them to zero. 
client-output-buffer-limit normal 0 0 0 
client-output-buffer-limit slave 256mb 64mb 60 
client-output-buffer-limit pubsub 32mb 8mb 60

취해야 할 조치:
1 단일 인스턴스를 4G 미만으로 줄이고, 그렇지 않으면 마스터. -슬레이브 전환에 시간이 오래 걸립니다

2. 프로세스 도중에 동기화가 실패하는 것을 방지하려면 클라이언트 출력-버퍼 제한 매개변수를 조정하세요

3. 클러스터 노드 시간 초과를 조정할 수 없습니다. 15초 미만

4. 클러스터 노드 시간 초과보다 오래 걸리는 느린 쿼리는 마스터-슬레이브 전환으로 이어질 수 있으므로 금지하세요

5. SYN 공격과 유사한 클라이언트의 미친 연결 방법을 수정하세요

Redis 클러스터 장애 분석

관련 기사