Mysql 읽 기와 쓰기 분리 만 료 상용 솔 루 션

mysql 읽 기와 쓰기 분 리 된 구덩이
읽 기와 쓰기 분리의 주요 목 표 는 메 인 라 이브 러 리 의 압력 을 분담 하고 클 라 이언 트 가 백 엔 드 데이터 베 이 스 를 선택 하여 조회 하 는 것 이다.또 하나의 구 조 는 MYSQL 과 클 라 이언 트 사이 에 중간 프 록 시 계층 proxy 가 있 고 클 라 이언 트 의 연결 proxy 이 며 proxy 가 요청 유형 과 문맥 에 따라 요청 한 배포 경 로 를 결정 하 는 것 이다.

클 라 이언 트 직접 연결 방안:proxy 퍼 가기 가 적 기 때문에 조회 성능 이 약간 좋 고 전체적인 구조 가 간단 하 며 문 제 를 조사 하 는 것 이 싸다.그러나 이런 방안 은 백 엔 드 배치 의 세부 사항 을 해결 해 야 하기 때문에 메 인 전환,라 이브 러 리 이전 등 작업 이 나타 날 때 클 라 이언 트 가 감지 하고 데이터 베이스 연결 정 보 를 조정 해 야 한다.

대 proxy 구조:클 라 이언 트 에 비교적 우호 적 입 니 다.클 라 이언 트 는 백 엔 드 디 테 일,연결 유지,백 엔 드 정보 유지 등 작업 에 관심 을 가 질 필요 가 없습니다.모두 proxy 에서 이 루어 집 니 다.하지만 이렇게 되면 백 엔 드 유지보수 팀 에 대한 요구 가 높 아 집 니 다.

어떤 구 조 를 사용 하 든 주종 이 지연 되 기 때문에 클 라 이언 트 가 하나의 새로운 사 무 를 완성 한 후에 바로 조 회 를 시작 합 니 다.만약 에 조회 가 라 이브 러 리 에서 선택 하면 방금 의 사 무 를 읽 을 수 있 습 니 다.이러한'라 이브 러 리 에서 시스템 의 만 료 상태'를 읽 을 수 있 는 현상 을 우 리 는 잠시'만 료 읽 기'라 고 부른다.
프로젝트 1:주 라 이브 러 리 프로젝트 강제 실행
검색 요청 을 두 가지 로 나 눕 니 다.

최신 결 과 를 받 아야 한 다 는 요청 에 대해 메 인 라 이브 러 리 에 강제로 보 냅 니 다.예 를 들 어 하나의 인도 플랫폼 에서 판매자 가 상품 을 발표 한 후에 바로 홈 페이지 로 돌아 가 상품 의 발표 성공 여 부 를 봐 야 한다.그렇다면 이 요청 은 최신 결 과 를 얻 으 려 면 주 창고 로 가 야 한다.

오래된 데 이 터 를 읽 을 수 있 는 요청 에 대해 서 만 라 이브 러 리 에 보 냅 니 다.이 인도 플랫폼 에서 바 이 어 는 상점 페이지 를 구경 하 러 왔 고 최근 에 발 표 된 상품 을 몇 초 늦게 봐 도 받 아들 일 수 있 습 니 다.그렇다면 이런 요청 은 창고 에서 나 갈 수 있다.이 방안 의 가장 큰 문 제 는 모든 조회 가'기한 이 지난 읽 기'의 수요 가 아니 라 는 것 이다.예 를 들 어 금융 류 업무 등 은 읽 기와 쓰기 분 리 를 포기 하고 모든 스트레스 가 메 인 창고 에 있다 는 것 이다.아래 의 방안 을 채택 하 다.

프로젝트 2:Sleep 프로젝트
메 인 라 이브 러 리 가 업 데 이 트 된 후에 라 이브 러 리 에서 읽 기 전에 sleep 을 하 십시오.select sleep(1)명령 을 실행 한 것 과 같 습 니 다.이 방안 의 가설 은 대부분의 경우 메 인 준비 가 1 초 안에 지연 되 고 sleep 을 하면 최신 데 이 터 를 얻 을 수 있 습 니 다.
판매자 가 상품 을 발표 하 는 것 을 전체 63925 로 하고 상품 이 발표 되면 Ajax 로 클 라 이언 트 가 입력 한 내용 을'새로운 상품'으로 페이지 에 표시 합 니 다.데이터 베 이 스 를 검색 하 는 것 이 아 닙 니 다.이렇게 하면 판매 자 는 이 디 스 플레이 를 통 해 제품 이 이미 발표 되 었 음 을 확인 할 수 있다.판매자 가 다시 페이지 를 새로 고치 고 상품 을 조회 할 때 사실은 시간 이 지나 면 sleep 의 목적 을 달성 하고 기한 이 지난 문 제 를 해결 할 수 있다.
방안 3:주 준비 지연 방안 판단:
첫 번 째 방법:먼저 show slave status 결 과 를 사용 하여 63977℃의 secondsbehind_master 매개 변수 값 은 분량 의 주 준비 지연 시간의 길 이 를 가늠 할 수 있 습 니 다.이 매개 변수 값 이 0 인지 여 부 를 판단 하고 0 이 아니라면 이 매개 변수 가 0 으로 변 할 때 까지 기 다 려 야 요청 을 수행 할 수 있 습 니 다.
두 번 째 방법:대비 위치 점 확보 주 준비 지연 없 음.

Master_Log_File 과 ReadMaster_Log_Pos,읽 은 메 인 라 이브 러 리 의 최신 위 치 를 표시 합 니 다.

Relay_Master_Log_File 과 ExecMaster_Log_Pos,준비 은행 의 최신 위 치 를 나타 낸다.

하면,만약,만약...Log_File 과 RelayMaster_Log_File、Read_Master_Log_Pos 와 ExecMaster_Log_Pos 두 그룹의 값 이 완전히 같 으 면 받 은 로그 가 동기 화 되 었 음 을 나 타 냅 니 다.
세 번 째 방법:GTID(전역 사물 ID)를 비교 하여 주 준비 지연 없 음 확보

Auto_Position=1 은 주 된 관계 에 대해 GTID 프로 토 콜 을 사 용 했 음 을 나타 낸다.

Retrieved_Gtid_Set,라 이브 러 리 에서 받 은 모든 로그 의 GTID 집합 입 니 다.

Executed_Gtid_Set,라 이브 러 리 가 완 성 된 모든 GTID 집합 입 니 다.

이 두 집합 이 같다 면,라 이브 러 리 에서 받 은 로그 가 모두 동기 화 되 었 음 을 나타 낸다.
프로젝트 4:등 주 라 이브 러 리 위치 방안select master_pos_wait(file, pos[, timeout]);이 명령 은 라 이브 러 리 에서 실 행 됩 니 다.매개 변수 file 과 pos 는 메 인 라 이브 러 리 의 파일 이름과 위 치 를 말 합 니 다.timeout 은 이 함수 가 최대 N 초 를 기다 리 고 있 음 을 표시 합 니 다.

이 명령 이 정상적으로 돌아 온 결 과 는 정수 M 으로 명령 부터 실행 을 시작 하고 file 과 pos 가 표시 하 는 binlog 위치 까지 얼마나 많은 업 무 를 수행 하 는 지 나타 낸다.

라 이브 러 리 동기 화 스 레 드 에 이상 이 발생 하면 null

으로 돌아 갑 니 다.

N 초 이상 기다 리 면 돌아 갑 니 다.-

집행 을 시작 하 자마자 이미 실 행 된 것 을 발견 하면 0

으로 돌아 갑 니 다.

그림:먼저 직진 trx 1 을 하고 검색 요청 의 논 리 를 수행 합 니 다.정확 한 데 이 터 를 찾 을 수 있 도록 저 희 는 사용 할 수 있 습 니 다.
이 논리
1.trx 1 사물 업데이트 가 완료 되면 바로 실행 show master status 를 통 해 현재 주 라 이브 러 리 에서 실행 중인 File 과 Position 을 얻 을 수 있 습 니 다.
2.라 이브 러 리 에서 검색 어 를 선택 하 십시오.
3.라 이브 러 리 에서 select masterpos_wait(File, Position, 1)；
4.반환 값 이>=0 의 정수 라면 이 라 이브 러 리 에서 검색 어 는 63750 입 니 다.
5.그렇지 않 으 면 메 인 라 이브 러 리 에서 검색 어 를 찾 습 니 다.
이것 은 63977 입 니 다.이 select 조 회 는 라 이브 러 리 에서 최대 1 초 를 기다린다 고 가정 합 니 다.그럼,1 초 안에 masterpos_돌아 오 기 를 기다리다
0 보다 큰 정수 로 라 이브 러 리 에서 행동 하 는 이 조회 결 과 는 반드시 trx 1 의 데 이 터 를 포함 하도록 확보한다.
5.메 인 라 이브 러 리 에서 검색 어 는 63750℃이 고 이런 방안 에서 자주 사용 하 는 퇴화 체제 이다.라 이브 러 리 에서 지연 시간 을 제어 할 수 없 기 때문에 없 을 수 없습니다.
대기 제한 이 있 기 때문에 대기 시간 이 초과 되면 포기 하고 메 인 라 이브 러 리 에 가서 찾 아야 합 니 다.만 료 되 지 않도록 설정 한 요구 에 따라 두 가지 선택 만 있 습 니 다.하 나 는 시간 초과 포기 이 고 하 나 는 메 인 라 이브 러 리 로 이동 하여 조회 하 는 것 입 니 다.
동시 접속 및 동시 조회
innodb_thread_concurrency 인 자 는 innodb 의 병렬 스 레 드 상한 선 을 제어 합 니 다.이 수 치 를 초과 하면 새 요청 은 대기 에 들 어 갑 니 다.

show processlist 에서 본 수천 개의 연결 은 값 병렬 연결 이 고 현재 실행 중인 문 구 는 병렬 조회 입 니 다.동시 연결 의 영향 은 크 지 않 습 니 다.메모 리 를 많이 차지 할 뿐 동시 검색 이 야 말로 CPU 킬러 입 니 다.

스 레 드 가 잠 금 대기 에 들 어간 후에 동시 다발 스 레 드 의 수 는 건의 할 것 이다.즉,등 줄 잠 금 의 스 레 드 는 동시 다발 조회 에 포함 되 지 않 는 다.기다 리 느 라 CPU 를 안 먹 어 요.

.
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.