MySQL-JDBC 드라이버로 인한 버그 설명-MySQL 튜토리얼-php.cn

MySQL-JDBC 드라이버로 인한 버그 설명

php是最好的语言

풀어 주다： 2018-08-03 13:56:23

원래의

1232명이 탐색했습니다.

문제 배경

회사는 전자상거래 시스템에 종사하고 있으며 전체 시스템은 Huawei Cloud를 기반으로 구축되었습니다. 시스템을 설계할 때 후속 사용자 및 주문 수가 상대적으로 많다는 점을 고려하면 일부 대규모 데이터베이스 구성 요소를 사용해야 합니다. 관계형 데이터베이스의 경우 후속 데이터 볼륨의 급격한 증가를 고려하여 MySQL에 직접 쓰는 대신 Huawei Cloud의 분산 데이터베이스 미들웨어 DDM을 사용했습니다. DDM을 사용한 후에는 기업이 인지하지 못하는 사이에 MySQL 읽기 인스턴스 수를 직접 늘려 읽기 성능을 선형적으로 향상시킬 수 있습니다. 또한 미들웨어 수준에서 하위 데이터베이스와 테이블을 지원하여 대규모 관계형 데이터베이스에 대한 작업을 제공합니다. 단순히 전자상거래 시스템에 맞게 맞춤화되었습니다.

DDM 자체는 클러스터 형태로 서비스를 제공하며, 다수의 연결 IP 주소가 개방되어 업무에 활용됩니다. 로드 밸런싱 계층이 필요합니다. 로드 밸런싱을 위해 LB를 추가하는 기존 방법을 사용하면 추가 전송 계층이 발생하여 성능 손실이 발생합니다. 따라서 MySQL-JDBC에서 제공하는 클라이언트 로드밸런싱 기능을 그대로 사용한다.

논리적 구조는 아래 그림과 같습니다.

▲기업은 MySQL-JDBC의 Loadbalance를 통해 여러 DDM 노드에 액세스할 수 있습니다. MySQL-JDBC는 로드 밸런싱 기능을 제공합니다.

문제 설명

MySQL JDBC 드라이버의 클라이언트 로드 밸런싱 기능이 잘 실행되고 있으며 성능도 놀랍습니다. 그런데 얼마 전 이유 없이 사업요청이 실패했습니다. 진짜 머니가 관련된 전자상거래 주문 모듈을 담당하고 있는데 이 문제 때문에 식은땀이 났습니다...

그래서 재빨리 백그라운드 로그를 확인해보니 DDM에 접속했을 때 예외가 발생했습니다. , Huawei Cloud DDM 서비스를 직접 제공했습니다.

Huawei Cloud의 서비스는 여전히 매우 좋습니다. 30분 이내에 전담 직원이 저에게 연락하여 문제를 해결하기 위해 협력했습니다.

저희 비즈니스 로그를 내려 DDM 지원 담당자와 함께 분석한 결과 다음과 같이 오류가 보고된 것을 확인했습니다. 근본 원인은 MySQL 드라이버의 버그로 밝혀졌으며, StackOverflow 로컬 스택을 발생시켰습니다. 오버플로... 버그로 인한 살인으로 밝혀졌습니다. DDM 서비스를 오해해서 정말 죄송합니다

스택을 보면 예외로 인해 버그가 발생한 것을 알 수 있습니다. MySQL-JDBC에서는 스택이 오버플로될 때까지 루프 호출이 발생합니다. Huawei DDM 지원 직원의 제안에 따라 드라이버 코드가 디컴파일되었으며 실제로 루프 중첩 가능성이 있음을 알 수 있습니다.

로드밸런스 폴링 연결 -> 새 연결과 이전 연결의 상태를 동기화합니다. -> 서버에 SQL을 보냅니다. ->

해당 코드는 다음과 같습니다.

이렇게 명백한 버그인데 MySQL이 발견하지 못할 거라고는 생각하지 않습니다. 현재 5.1.44 버전의 드라이버를 사용하고 있으며 최신 5.1.66 코드를 확인한 결과 이 문제가 실제로 수정되었음을 확인했습니다.

SET 및 SHOW 문을 필터링하여 확인했습니다. , 이 문제는 방지됩니다. 중첩 루프가 발생합니다.

그러나 5.1.66에서는 postProcess가 호출되는 모든 곳에 SQL이 있는 것은 아니기 때문에 여기의 코드는 널 포인터 예외를 발생시킵니다. MySQL JDBC 개발자들이 테스트를 하지 마세요...

말도 안 돼요, 5.1.44의 코드를 분석한 결과 loadBalanceAutoCommitStatementThreshold 매개 변수의 값을 적절하게 조정하면 루프 중첩도 피할 수 있다는 사실을 발견했습니다. 우리 환경을 5로 변경했습니다. 수정 후 일주일 동안 아무런 문제 없이 원활하게 실행되었습니다.

수정 계획

loadBalanceAutoCommitStatementThreshold를 5로 수정했는데, 문제는 비즈니스에 시간이 많이 걸리는 SQL이 포함된 경우 DDM 로드 불균형이 발생할 수 있다는 것입니다. 하지만 현재 상황으로 볼 때 DDM의 성능은 여전히 상대적으로 강합니다~