Go to Database world

3. Performance Schema

2023-01-06T01:11:54+00:00

performance schema : MYSQL 서버 내에서 실행되는 작업에 대한 상세한 메트릭 제공(disk wait time, response time, query execute time.. etc).
instrument : 정보를 얻고자 하는 mysql 코드의 어느 부분을 나타냄.
consumer : 어떤 코드가 수행되었는지에 대한 정보를 저장하는 단순한 테이블(instrument가 정보를).
digest(바인드 변수 활용) : 쿼리에서 변경되는 부분을 제거하고 쿼리를 집계하는 방법.
1. 성능 스키마
[1] instrument 요소
performance_schema의 setup_instruments 테이블에는 지원되는 모든 instrument 목록이 포함.
특정 instrument가 검사하는 내용을 이해하려면 instrument 명, 직관, 그리고 mysql 소스 코드에 대한 지식을 활용해야함. because almost document’s row has null value.
ex) statement/sql/error, statement/abstract/Query, Statement/abstract/new_packet, statement/abstract/relay_log, memory/performance_schema/mutex_instances
[2] 컨슈머 체계
consumer는 instrument가 정보를 보내는 대상.
_current : 현재 서버에서 발생하고 있는 이벤트
_history/_history_long : 스레드당 최종 100/10000개의 완료된 이벤트
events_waits : low level server
events_statements : SQL문
events_stages : 임시 테이블 생성이나 데이터 전송과 같은 profile 정보
event_transactions : transaction들

[3] 요약테이블과 digest
요약테이블 : 테이블이 제안하는 모든 것에 대한 집계된 정보를 저장.
instance : MYSQL 설치에 사용할 수 있는 객체 인스턴스.
자원 소비 : consumer의 최대 사이즈를 설정해서 사용하는 메모리양 제한 가능. performance_schema의 일부 테이블은 자동 크기 조정을 지원.

[4] sys 스키마
performance_schema에 대한 뷰와 stored routine 으로만 구성.
performance_schema를 보다 손쉽게 사용하도록 설계. 자체적으로 데이터 저장 x.(performance_schema의 테이블에 저장된 데이터만 액세스 할 수 있다.)
[5] 스레드 이해하기
각 스레드는 최소 두개의 고유 식별자가 있음. ex) 운영체제 스레드 id + 내부적인 MYSQL 스레드 id.
mysql 스레드 id = performance_schema의 thread_id
performance_schema는 모든 곳에서 thread_id를 사용하는 반면, processlist_id 는 threads 테이블에서만 사용 가능. ex) processlist_id를 가져와서 잠금을 가지고 있는 연결을 종류하는 경우, 해당 값을 얻기 위해 threads 테이블을 조회해야함.

2. 설정
[1] 활성화

performance_schema 변수 on/off
instrument 활성화 방법
1. update performance_schema.setup_instruments set enable Where name = “statement/sql/select”
2. sys schema에서 ps_setup_enable_instrument stored procedure 호출
  ex) CALL sys.ps_setup_enable_instrument(‘statement/sql/select’);
3. 서버 시작 때 performance-schema-instrument parameter 사용
  ex) performance-schema-instrument=’statement/sql/select=ON’
컨슈머 활성화와 비활성화 [2] 특정 개체에 대한 모니터링 튜닝 [3] 스레드 모니터링 튜닝 [4] 성능 스키마에 대한 메모리 크기 조정 [5] 기본값 3. 성능 스키마 사용
[1]

2. monitoring in SRE environment

2023-01-06T00:11:54+00:00

복제 : 소스인 어느 서버에서 레플리카라 하는 하나 이상의 추가 서버로 데이터를 보내는 기능.
기능적 샤딩 : 데이터 세트의 가동 시간, 성능, 액세스 제어를 별도로 관리하기 위해 특정 비즈니스 기능을 수행하는 특정 테이블을 전용 클러스터로 분할하는 것을 의미함.
수평적 샤딩 : 단일 클러스터에서 안정적으로 제공할 수 있는 크기 이상으로 데이터 세트가 증가한 경우, 이를 여러 클러스터로 분할하여 여러 노드의 데이터를 제공하고 필요한 하위 집합을 찾는 조회 메터니즘에 따라 데이터를 제공.
샤딩 : 같은 테이블 schema를 가진 데이터를 다수의 DB.(하나의 큰 테이블을 쪼개 각각 다른 DB에 분산)
수평 파티셔닝 : 같은 DB에서 하나의 큰 테이블을 쪼개 분산,저장.
수직 파티셔닝 : 테이블의 일부 열을 빼내는 형식으로 분할.
1. 서비스 수준 목표의 정의
SLI(서비스 수준 지표) : 사용자의 관점에서 건강한 시스템의 정도.(고객의 만족도를 어떻게 측정할까)
SLO(서비스 수준 목표) : SLI가 정상적인 서비스로 간주 될 수 있게 하기 위한 목표 범위.(고객이 만족할 수 있게 SLI를 허용할 수 있는 최소 수준)
SLA(서비스 수준 계약) : 하나 이상의 비즈니스 고객과의 계약에 포함된 SLO. SLA는 선택 사항임.
#모든 기능이 고객의 만족을 유지하기 위해 높은 가용성을 요구하는 것이 아님 -> 특정 기능의 영향이나 그로 인한 수익에 따라 다양한 SLI와 SLO 갖게 됨.
=> 데이터 세트가 서로 다른 이해 관계자에 의해 실행된 별개의 쿼리에서 병목 현상이 발생하여 성능이 저하되는 경우를 감지하는 것이 중요.
=> 합리적인 SLI와 SLO를 제시할 수 있도록 이해 관계자들의 요구를 분리하는 방법을 찾아야됨.

2. 측정 대상

모니터링 솔루션 : 쿼리 분석 및 모니터링 쿼리 대기 시간은 고객 경험에 중점을 두어야한다. so, 쿼리 응답 시간이 합의된 임계값보다 길어지면 가능한 한 빨리 경고할 수 있는 도구에 의존해야 한다. -> 해당 수준의 모니터링을 달성하기 위한 여러가지 방법 소개.
- 상용 옵션 : mysql 성능을 프로파일링하는 특정 작업이 경쟁 우위인 벤더에게 비용을 지불하는 사례 중 하나.
- 오픈 소스 옵션 : 확실한 오프 소스 옵션 = PMM(Percona Monitoring and Management). 클라/서버 쌍으로 작동하며 매트릭을 수집하여 서버 부분으로 보내는 클라이언트를 DB instance 에 설치. -> 장점 : mysql 성능 모니터링에 대한 Percona 커뮤니티의 오랜 경험 바탕으로 대시보드 구성 가능.
가용성 모니터링 : 가용성은 오류 없이 고객 요청에 응답할 수 있어야 함. 가용성을 나타내는 메트릭(저장된 데이터에 대해 수행되는 계산. 그결과가 리포트로 표시됨)을 선택할 때 ‘100% 가동’은 합리적이지 않으며, 여기에서 초점은 해당 컴포넌트의 장애가 불가피함을 이해하고 수용하는 가운데, 가능한 한 최고의 고객 경험을 제공하는 것이라는 데 초점을 맞추고 고객 지원 팀과 함께 기대치를 설정. 선호하는 가용성 확인 방법 : 클라이언트 or 원격의 엔드포인트에서 하는 것.
- 대표적인 가용성 mysql 메트릭 : threads_running(현재 실행 중인 쿼리 수)
- 가용성 mysql 매트릭2 : max_connections 에 얼마나 근접해 있는지 모니터링하여 진행 중인 작업의 과부화 확인 가능.
쿼리 지연 모니터링 : datadog(유료), solarwinds database performance monitor(유료), pmm(오픈 소스) 매트릭 요약 && 애플리케이션 개발자와의 협업.
오류 모니터링 : 모든 오류가 확실히 문제가 있다고는 말할 수 없지만, DB 쿼리를 처리하는 서비스 전체에 걸쳐 발생하는 오류의 비율은 문제를 일을키는 중요한 지표.
- Lock wait timeout : 트랜잭션이 계속 재시도하고 여전히 실패하는 소스 노드의 행 잠금 경합이 증가하고 있다는 신호 가능성.
- Aborted connections : 중단된 연결의 갑작스러운 급증을 보고하는 클라이언트는 클라이언트와 DB instance 사이에 있는 액세스 계층의 문제를 나타내는 지표 가능성.
- Connection_errors_xxx : mysql 서버가 추적하는 방법. 서버 변수 집합. xxx = 다른 종류의 연결 error. 이 수치 중 하나라도 갑자기 증가하면 새롭고 특이한 무언가가 현재 고장 났음을 알려주는 지표.
사전 모니터링 : 정상 상태 모니터링 -> 변경 여부와 관계없이 시스템에서 예기치 않은 일이 발생하고 있음 알 수 있음.
유용한 신호 예시
- 디스크 증가 : 문제가 될 때까지는 신경쓰지 않아도 되는 일종의 메트릭. undo log가 크거나 table 변경이 있는 장기 실행 트랜잭션과 같은 작업은 전체 디스크가 너무 빨리 채워지는 원인이 될 수 있음.
- 연결 증가 : 애플리케이션에서 하는 일이 많음 -> 연결 많이 필요. so, 레플리카를 추가하거나, 복제를 확장 수단으로 사용하거나, proxySQL과 같은 미들웨어 계층을 사용하여 늘어나는 frontend를 db에서 직접 연결 부하로부터 분리함으로써 당분간 이러한 연결 완화.
- 복제 지연 : 원본에 기록 중인 데이터와 레플리카에서 사용 가능한 데이터 사이의 지연을 복제 지연이라고 함. -> 지연으로 인해 데이터가 불일치하는 것으로 보일 수 있음.
- I/O 활용 : iostat 도구 사용. -> I/O 대기 상태를 모니터링할 수 있음.
  DB 서버의 IOwait에 thread가 많다면, 그 스레드들이 일부 디스크 리소스가 사용 가능해질 때를 기다리는 대기열에 있다는 것을 알려주길 원함.
  IOutil을 유의미한 기간 동안의 실행 그래프를 통해 추적하면 이 사실 확인 가능.(전체 시스템 디스크 액세스 용량의 백분율로 보고) -> 병목 현상 유발 미리 방지
- 자동 증가 공간(잘 안알려짐) : 자동 증가 기본 키가 기본적으로 부호를 가진 정수로 생성되어 키 공간이 부족할 수 있다. 이 문제는 자동 증가 키가 가능한 최댓값에 도달할 정도로 충분히 삽입된 경우에 발생.
  키 공간 부족 모니터링 : PMM/Prometheus exporter -> -collect.auto_increment.columns 플래그 키기.
- 백업 생성/복원 시간 : 재해 복구. 샤딩이나 파티셔닝 같은 작업은 데이터가 너무 클 때 시작하는게 아니라 성공적인 고객 경험을 제공하기 위한 목표를 정의할 때 시작해야함.

3. 장기적인 성능 측정

[1] 비즈니스 케이던스 배우기 : 비즈니스 Cadence는 피크 트래픽 시간이 평균보다 훨씬 크다는 것을 의미할 수 있음. 비즈니스 주기는 비즈니가 대상으로 하는 고객의 요구에 따라 크게 달라짐. 엔지니어링 조직의 다른 부서와 동일한 도구를 최대한 많이 사용하는 것부터 시작 -> 전체 스택의 성능에 투자하고 엔지니어가 작성하는 기능과 이를 지원하는 DB간에 느낄 수 있는 간극을 줄이는데 도움.
[2] 효과적인 메트릭 추정 : 특정 시점에 데이터 저장소 인프라의 상태를 측정할 수 있을 뿐만 아니라 정기적으로 성능 향상 또는 저하 추세를 파악할 수 있어야 함.
[3] 성능 점검을 위한 모니터링 도구 사용

평균을 맹신하지 말자 : 몇 주 이상의 기간 동안 메트릭의 추세를 확인해야 하는 경우 평균은 최고치를 완화. -> 잘못된 보안 정보. so, 월별 데이터를 추세화 할 때 항상 최고점을 확인해야 뷰에서 간헐적으로 급증하는 데이터의 정확도를 유지 가능.
백분위수는 우리에게 많은 도움을 준다 : 백분위수는 주어진 시간 범위에서 데이터 요소를 정렬하고 대상 백분위수에 따라 가장 높은 값을 제거하는 방식(95%찾을려면 상위 5%제거).=> SLI,SLO와 시각적으로 더 유사하게 만드는 good method.
긴 보존 기간 및 성능 : 비즈니스 메트릭 동향에 대한 솔루션을 평가하는 경우 더 긴 시간 범위의 데이터 기간을 요청할 때 사용자 경험이 어떻게 달라지는지 테스트해야함. 메트릭 솔루션은 수집속도나 데이터 유지 기간이 아니라 가용한 데이터를 만드는 데만 효과적.

[4] 전체 아키텍처링에 SLO 사용하기 : 장단기 메트릭을 모두 처리할 수 있고 유용한 방식으로 변경 추세를 추적할 수 있는 메트릭 솔루션을 갖는 것은 DB의 인프라의 운영방식에 대한 장기적인 비즈니스 영향 추세와 함께 전술적 성능 메트릭을 추적하는 데 매우 중요한 부분임.

1. MySQL architecture

2023-01-02T05:16:54+00:00

스토리지 엔진 : 데이터가 디스크에서 저장되고 검색되는 방법을 구동하는 소프트웨어. mysql에서는 innoDB 권장.

논리적 아키텍쳐
- (클라이언트) -> (연결/스레드 핸들링 -> 파서 옵티마이저 -> 옵티마이저) -> (스토리지 엔진(innoDB))
  (1) 최상위 계층 (클라이언트) : 네트워크 기반 클라이언트/서버 도구 or 서버에 필요한 연결 처리, 인증, 보안 등의 서비스의 포함.
  (2) 두 번째 계층 : 쿼리 파싱, 분석, 최적화 및 모든 기본 제공 함수를 포함하여 MYSQL에서 대부분의 지능적인 부분이 여기에 속함.
  (3) 세 번째 계층 : 스토리지 엔진이 포함됨. MYSQL에 저장된 모든 데이터를 저장하고 검색하는 역할 담당.
연결 관리 및 보안
- 각 클라이언트 연결은 서버 프로세스 내에서 고유한 스레드를 가짐. 서버는 즉시 사용할 수 있는 스레드의 캐시 유지 관리 -> 새로운 연결마다 매번 스레드 생성/폐기 필요 x.
동시성 제어
- shared lock, exclusive lock : oracle과 동일.
- oracle은 행 수준 잠금만 사용하지만, mysql은 잠금 전략이 두가지.
  (1) 테이블 잠금 : 전체 테이블을 잠금. 가장 기본적인 잠금 전략이자 가장 낮은 오버헤드를 가진 전략. 유리 상황 : read local 테이블 잠금은 일부 유형의 동시 쓰기 작업을 허용. 쓰기 및 읽기 대기열은 읽기 대기열보다 전적으로 우선순위가 높은 쓰기 대기열과 별도로 관리.
  (2) 행 잠금 : 스프레드시트의 행만 잠그는 것과 같음. 가장 큰 동시성을 제공하고 오버헤드가 가장 큰 잠금 행태.
트랜잭션
- oracle과 동일. acid 트랙잭션.
  (1) Deadlock : 현재 innodb가 deadlock 처리 방법 : exclusive lock이 가장 적은 트랜잭션으로 롤백.(교착상태 발생하면 트랜잭션의 일부 또는 전체를 롤백하지 않고는 교착상태 해제 안됨. -> so, 현재 트랜잭션 시스템은 application layer에서 처리하게 설계돼야함.)
  (2) 트랜잭션 로깅 : oracle과 동일하게 append 방식으로 로깅.
  (3) 트랜잭션에서 스토리지 엔진 혼합 : mysql은 서버 수준에서 트랜잭션 관리 x. -> innoDB가 트랜잭션 자체를 구현. => 단일 트랜잭션에서 서로 다른 엔진을 안정적으로 혼용 불가.(트랜잭션에서 트랜잭션 테이블과 비 트랜잭션 테이블을 혼영할 경우[innoDB] 모든 것이 순조로우면 트랜잭션이 제대로 작동. but, 롤백이 필요한 경우 비트랜잭션 테이블에 대한 변경 사항을 취소 불가능. => DB 일관성 파괴, 트랜잭션 지점 무의미) 결론 : 애플리케이션에서 스토리지 엔진 혼용 하지말자
  (4) 암시적 잠금과 명시적 잠금 : InnoDB는 2단계 잠금 프로토콜 사용. commit/rollback 될때까지 잠금 해제 x. but, innoDB는 SQL 표준에서 전혀 언급하지 않는 명시적 잠금도 지원. ex) select … for share / select … for update. 내기억에 오라클도 for update 지원.
MVCC(multi version concurrency control)
특정 시점에 존재했던 데이터의 snapshot을 사용하여 작동. = 트랜잭션은 실행 기간에 관계없이 데이터 일관되게 볼 수 있음.
oracle 처럼 undo 사용하여 롤백후 이용.
복제
한 노드가 사용하는 쓰기를 추가 노드에 배포하는 기본적인 방법. 소스 노드에 쓰려고 할 때 새 데이터를 보내는 복제 클라이언트로 로그인된 레플리카에 대한 스레드 있음.(토폴로지 트리)
운영 환경에서 실행하는 데이터의 경우, 재해 복구 계획을 위해 복제를 사용하고 여러 위치에 분산되어 있는 3개 이상의 레플리카를 보유하는 것이 이상적.
데이터 파일 구조
테이블 메타데이터 -> 테이블의 .ibd파일에 포함된 데이터 딕셔너리로 재설계(8.0기준).
information_schema에만 의존하는 대신, 딕셔너리 오브젝트 캐시사용(oracle과 동일).
InnoDB 엔진
- 쿼리에서 터치한 행만 잠그는 것이 아니라 인덱스 구조의 공백도 잠가서 팬텀이 삽입되는 것을 방지.
- db 테이블은 클러스터형 인덱스로 구성.
- JSON 유형(5.7 이후) : json 문서의 자동 유효성 검사와 빠른 읽기 엑세스가 가능한 최적화된 스토리지.
- 데이터 딕셔너리의 변화(8.0 이후) : 파일 기반 테이블 메타데이터 스토리지 제거 -> innoDB 테이블 스토리지를 사용하여 데이터 딕셔너리로 이동. -> 테이블 변경과 같은 작업에 모든 충돌 복구 트랜잭션의 이점을 제공.
- Atomic DDL(8.0 이후) : 데이터 정의문이 완전히 완료되거나 완전히 롤백될 수 있음을 의미. DDL 관련 언두/리두 로그를 생성함으로써 가능.