|
최근에는 몇 가지 특별한 이유로 MySQL 서버가 발견되었습니다“오류 1129 (00000): 호스트 'xxx'가 여러 연결 오류로 차단되었습니다. 'mysqladmin flush-hosts'로 차단 해제”문제가 해결된 후, 파라미터 max_connect_errors에 대해 더 배우는 과정에서 서로 다른 네트워크 데이터에 대한 모순된 설명들이 약간 혼란스러웠습니다(이 오류에 관해서는 같은 IP가 짧은 시간 내에 너무 많은 중단된 데이터베이스 연결을 생성했기 때문입니다(최대 max_connect_errors 값을 초과하며), 다음은 문제를 탐색하고 분석하며 의문을 해소하는 과정입니다. 우선 인터넷에서 정보를 찾아봤는데, 많은 정보가 비밀번호 입력 횟수가 변수를 초과하면 MySQL이 이 클라이언트 로그인을 차단한다고 max_connect_errors 도입한다고 맹세하고 있습니다. 그리고 아래에 보이는 max_connect_errors 도입에 관한 공식 정보를 찾았습니다. MySQL 5.6/5.7도 동일합니다 만약 호스트로부터 이보다 더 많은 연속 연결 요청이 중단되면, 서버는 해당 호스트의 추가 연결을 차단합니다. 차단된 호스트는 호스트 캐시를 플러셔하면 차단 해제할 수 있습니다. 이를 위해 FLUSH HOSTS 문장을 발행하거나 mysqladmin flush-hosts 명령을 실행하세요. 이전 연결이 중단된 후 max_connect_errors회 이내에 성공적으로 연결이 확립되면, 호스트의 오류 수가 0으로 해제됩니다. 하지만 호스트가 차단되면 호스트 캐시를 플러셔하는 것만이 차단을 해제하는 유일한 방법입니다. 기본값은 100입니다. 위에서 보았듯이, 변환은 대략 다음과 같습니다: MySQL 서버가 동일한 호스트로부터 연속 요청을 받고 이 모든 연속 요청이 연결을 성공적으로 구축하지 못한 채 중단되면, 이 연속 요청들의 누적 값이 max_connect_errors 집합 값보다 클 때, MySQL 서버는 이 호스트로부터 온 모든 후속 요청을 차단합니다. 이 정보를 처음 보면 당신도 공격받을 것이라고 믿습니다“호스트로부터 여러 차례 연속된 연결 요청이 중단되는데, 성공적인 연결이 이루어지지 않았습니다”혼란스러운 점은, 네트워크 이상 때문에 데이터베이스 연결이 중단되었기 때문입니다. 나는 인터넷에서 그런 정보를 찾아봤다: 그 변수에 대해 혼란이 있는 것 같습니다. 이 프로토콜은 반복적인 무효 비밀번호에 대해서는 호스트를 차단하지 않고, 네트워크 오류로 인해 연결이 중단된 경우를 차단합니다. 그럼 우리가 직접 실험하고 검증해서 어느 쪽이 맞는지 알아내면 되겠죠. MySQL 데이터베이스에 테스트 계정을 만들고, max_connect_errors 변수를 다음과 같이 설정합니다3. 그 다음 다른 테스트 머신을 사용해 잘못된 비밀번호로 MySQL 데이터베이스에 연결하는데, 아래 사진과 같이 이전 세 개의 잘못된 비밀번호를 입력해도 네 번째 입력에서는 위의 오류가 발생하지 않습니다.그렇다면 이 변수가 잘못된 비밀번호 입력과 관련이 있다는 것을 배제할 수 있습니다. [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p 비밀번호 입력: 오류 1045 (28000): 사용자 'test'@'mytestlnx02' 접근 거부 (비밀번호: YES) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p 비밀번호 입력: 오류 1045 (28000): 사용자 'test'@'mytestlnx02' 접근 거부 (비밀번호: YES) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p 비밀번호 입력: 오류 1045 (28000): 사용자 'test'@'mytestlnx02' 접근 거부 (비밀번호: YES) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p 비밀번호 입력: 오류 1045 (28000): 사용자 'test'@'mytestlnx02' 접근 거부 (비밀번호: YES) [root@mytestlnx02 TMP] # 실제로 IP가 잘못된 비밀번호를 입력하면, MySQL은 performance_schema 데이터베이스 아래 host_cache 테이블에 기록합니다. COUNT_AUTHENTICATION_ERRORS 필드에 다음과 같이 누적되어 기록됩니다:
공식 정보에 따르면, host_cache 분야는 통계적으로 다음과 같이 간주됩니다“막힘”연결 오류(max_connect_errors 시스템 변수를 기반으로 평가됨). 프로토콜 핸드셰이크 오류만 집계되며, 인증된 호스트에만 사용됩니다(HOST_VALIDATED = YES). SUM_CONNECT_ERRORS "차단"으로 간주되는 연결 오류 수(max_connect_errors시스템 변수). 프로토콜 핸드셰이크 오류만 집계되며, 검증을 통과한 호스트에 대해서만 HOST_VALIDATED = YES가 포함됩니다. MySQL클라이언트는 데이터베이스와의 연결을 구축하기 위해 3회 핸드셰이크 프로토콜을 시작해야 하며, 보통 이 시간은 매우 짧지만, 네트워크 이상 현상, 네트워크 타임아웃 및 기타 요인이 나타나면 핸드셰이크 프로토콜이 완료되지 않습니다. MySQL에는 매개변수 connect_timeout이 있는데, 이는 MySQL 서버 프로세스가 연결이 확립될 때까지 몇 초 동안 기다리는 시간입니다. connect_timeout 시간 이후에도 프로토콜 핸드셰이크가 완료되지 않으면, MySQL 클라이언트는 다음과 같은 예외 메시지를 받게 됩니다: 'XXX'에서 MySQL 서버 연결이 끊겼습니다, 시스템 오류: 에르노, 변수는 기본값으로 10초를 사용합니다:
네트워크 타임아웃으로 인해 데이터베이스 연결이 중단되는 경우를 가정해봅시다. 복잡한 환경에서 네트워크 전송 지연 상황을 시뮬레이션하기 위해 Linux의 netem과 tc 명령을 사용합니다. 다음 설정을 거쳐 테스트 서버가 MySQL 서버에 접근하는 시점에 11초의 지연이 발생합니다: [root@gettestlnx02 ~]# 핑 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) 바이트의 데이터. 10.20.57.24에서 64바이트: icmp_seq=1 ttl=62 time=0.251ms 10.20.57.24에서 64바이트: icmp_seq=2 ttl=62 time=0.330ms 10.20.57.24에서 64바이트: icmp_seq=3 ttl=62 time=0.362ms 10.20.57.24에서 64바이트: icmp_seq=4 ttl=62 time=0.316ms 10.20.57.24에서 64바이트: icmp_seq=5 ttl=62 time=0.281ms 10.20.57.24에서 64바이트: icmp_seq=6 ttl=62 time=0.377ms ^C --- 10.20.57.24 핑 통계 --- 6개의 패킷 전송, 6개의 수신, 0% 패킷 손실, 시간 5716ms RTT min/Avg/Max/mdev = 0.251/0.319/0.377/0.047 ms [root@gettestlnx02 ~]# TC QDc Add Dev eth0 root netem 지연 11000ms [root@gettestlnx02 ~]# 핑 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) 바이트의 데이터. 10.20.57.24에서 64바이트: icmp_seq=1 ttl=62 time=11000ms 10.20.57.24에서 64바이트: icmp_seq=2 ttl=62 time=11000ms 10.20.57.24에서 64바이트: icmp_seq=3 ttl=62 time=11000ms 10.20.57.24에서 64바이트: icmp_seq=4 ttl=62 time=11000ms 10.20.57.24에서 64바이트: icmp_seq=5 ttl=62 time=11000ms 10.20.57.24에서 64바이트: icmp_seq=6 ttl=62 time=11000ms 10.20.57.24에서 64바이트: icmp_seq=7 ttl=62 time=11000ms
아래 참조와 같이 테스트 서버 gettestlnx02의 MySQL 데이터베이스에 연결됩니다(참고로 SSH로 접속 중이라면 gettestlnx02 작업이 꽤 느릴 수 있습니다). 물론 MySQL 서버에서 네트워크 지연을 시뮬레이션할 수도 있고, connect_timeout 지연과 네트워크 지연 시간을 모두 낮출 수도 있습니다) [root@gettestlnx02 ~]# mySQL -h10.20.57.24 -utest -p 비밀번호 입력: 오류 2013 (HY000): '인증 패킷 읽기' 시 MySQL 서버 연결이 끊김, 시스템 오류: 0 [root@gettestlnx02 ~] # 위에서 보듯이, 네트워크 지연이 10초 이상 발생해 MySQL 연결이 실패했습니다. 이 시점에서 MySQL 서버의 host_cache 테이블을 조회하면 SUM_CONNECT_ERRORS가 1이 되고 COUNT_HANDSHAKE_ERRORS도 변경된 것을 알 수 있습니다1.
그다음 이렇게 세 번 반복해서 던지면, SUM_CONNECT_ERRORS가 3이 되고 COUNT_HANDSHAKE_ERRORS가 3이 되는 것을 볼 수 있습니다. 그 다음 netem과 tc 명령어를 사용해 테스트 서버에서 네트워크 지연 시뮬레이션을 취소하고, 다음 테스트에서 볼 수 있는 MySQL 데이터베이스와의 테스트 연결로 이동합니다: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mySQL -h10.20.57.24 -utest -p 비밀번호 입력: ERROR 1129 (HY000): 호스트 '192.168.27.180'이 여러 연결 오류로 차단되었습니다; 'mysqladmin flush-hosts'로 차단 해제 [root@gettestlnx02 ~] #
현재 건설 가능합니다“ERROR 1129 (HY000): 호스트 '192.168.27.180'이 여러 연결 오류로 차단되었습니다; 'mysqladmin flush-hosts'로 차단 해제”틀렸다. 용액 해결된 오류 1129 (00000): 호스트 'xxx'가 여러 연결 오류로 차단되었습니다. 'mysqladmin flush-hosts'로 'Unblock' 오류를 일으키는 방법은 여러 가지가 있지만, 일부는 일시적입니다. 임시 계획은 지표들이 근본 원인을 해결하지 않는 것입니다. 핵심은 네트워크 오류를 해결하는 것이며(종종 네트워크 관리자나 시스템 관리자의 상담이 필요합니다) 우회 방법: 1변수 max_connection_errors의 값을 더 큰 값으로 설정하세요
이 임시 해결책은 IP가 금지되는 지연 트리거 조건일 뿐이며, 복잡한 경우나 높은 동시성 상황에서는 큰 값을 설정해야 하며, 그렇지 않으면 쉽게 다시 트리거됩니다. 또한 변수는 현재 환경에서만 영향을 미치며, 재시작하면 만료됩니다. 2: 사용플러시 호스트 mysql> 호스트 플러시; 쿼리 OK, 영향 행 0개 (0.00초) mySQL> performance_schema.host_cache에서 * 선택; 빈 집합 (0.00초) mysql> 물론, mysqladmin flush-hosts 명령어를 사용해 호스트 캐시 정보를 정리할 수도 있습니다 [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host 비밀번호 입력: 그렇다면 호스트 캐시란 무엇일까요? 공식 소개는 다음과 같습니다: MySQL 서버는 클라이언트에 대한 IP 주소, 호스트 이름, 오류 정보 등 정보를 포함하는 호스트 캐시를 메모리에 유지합니다. 서버는 이 캐시를 비로컬 TCP 연결에 사용합니다. 루프백 인터페이스 주소(127.0.0.1 또는 ::1)를 사용하여 구축된 TCP 연결이나 유닉스 소켓 파일, 이름 파이프, 공유 연결을 통해 구축된 경우에는 캐시를 사용하지 않습니다 기억. 간단히 말해, MySQL 서버는 클라이언트 정보(IP 주소, 호스트명, 오류 메시지 등)를 메모리에 캐시로 유지합니다. 서버는 비로컬 TCP 연결 정보를 캐시합니다. 루프백 인터페이스 주소(127.0.0.1 또는 ::1)를 사용해 생성된 TCP 연결이나 유닉스 소켓 파일, 이름 있는 파이프라인, 공유 메모리를 사용한 연결을 캐시하지 않습니다. 호스트 캐시 정보는 performance_schema 데이터베이스의 host_cache 테이블을 통해 조회할 수 있습니다. 3: 변수 host_cache_size를 다음과 같이 설정하세요0 사실, MySQL 서버가 호스트 캐시 정보를 기록하지 않게 만드는 것은 가장 신뢰할 수 없는 해결책이라고 생각합니다. 이 방법은 완전히 무시할 수 있습니다.
| 
게시됨 2019. 4. 8. 오전 11:01:48
|
|
|
|
