안녕하세요.
지금가지 Dual Master 구성을 진행 했었는데요. 가능하면 듀얼 마스터를 순환형으로 구축을 한번 해보는것도 좋을것 같다는 생각이 듭니다. 가능하면 여러번 연습해서 내꺼로 만드는걸 강력하게 추천 드립니다. 이번에는 Mysql의 control, Monitoring, Explain등 추가적인부분을알아볼까합니다.
Table Design - control
– 대용량 MySQL instances/schemas/tables을 관리하는 추가 코스트 ( > 2TB)
– 데이터 사이즈가 커짐에 따라 인덱스 구조가 더 넓어지고 깊어짐, 모든 SQL 작업에 영향
– 사용 하지 않는 이력 데이터에 대해서 삭제하거나 아카이브 성능 저하
– 신속하게 늘어나는 테이블에 대해서 대책을 세워야 함
– 파티션 테이블을 사용하면 과거 데이터를 삭제하는데 성능 영향 줄임
• 파티션 키가 아닌 컬럼에 대한 조회 성능 저하됨
– Insert 성능을 위해 큰 테이블 (1억건 이상) 은 파티션 테이블로 I/O부하 분산
– 성능 문제 뿐만 아니라 백업/복구 운영 작업의 문제
Table Design - Monitoring
애플리케이션 지표를 확인 : 서비스하는 앱의 속도 문제
• Slow Query Log
> 느린 쿼리를 찾아내서 튜닝
• SHOW FULL PROCESSLIST;
> 느린 쿼리로 인해 슬로우 발생시 쿼리 실행 지연 현상 발생
Table Design – Explain
EXPLAIN Columns:
• select_type SIMPLE,PRIMARY, Union, JOIN , Subquery, Derived, Union_result, Dependent subquery…
• table 테이블 명
• partitions 파티션 명
• type const(유니크 키), eq_ref(PK), ref(인덱스), range(인덱스),index(인덱스 스캔), all(테이블 스캔)
• possible Keys : 선택 가능한 인덱스
• key 실제 사용한 인덱스
• ref 인덱스와 비교한 컬럼
• rows 예측 건수
• filtered 조회 조건에 의해 필터링된 퍼센트수
• extra using where, using index, using temporary, using file sort, using join buffer…
출력의 모든 행 수를 곱하여 쿼리의 총 "비용"을 계산.
| using index | 커버링 인덱스라고 하며 인덱스 자료 구조를 이용해서 데이터를 추출 |
| using where | where 조건으로 데이터를 추출. type이 ALL 혹은 Indx 타입과 함께 표현되면 성능이 좋지 않다는 의미 |
| using filesort | 데이터 정렬이 필요한 경우로 메모리 혹은 디스크상에서의 정렬을 모두 포함. 결과 데이터가 많은 경우 성능에 직접적인 영향을 줌 |
| using temporary | 쿼리 처리 시 내부적으로 temporary |
EXPLAIN (옵티마이저의 실행 계획 확인)
• 쿼리 목적을 분석하고 다시 작성할 수도 있음.
– 예를 들면 SubQuery 를 joins으로 혹은 OR를 UNION으로 작성 가능함.
• 쿼리 목적을 분석하고 다시 작성할 수 있는지 확인 ?
• 적당한 인덱스를 추가
# 결론
• EXPLAIN 를 통해서 실행 계획 확인만 잘해도 튜닝을 잘할 수 있다.
• 테이블 설계시 사용될 쿼리를 고려해서 인덱스를 지정한다.
• Data 증가로 인해 서버 모니터링을 수시로 한다.
> 갑자기 서버 로드가 발생 했다면 특정 쿼리의 Slow Query가 발생 가능성 있음.
