[MySQL 스터디] 기타기능

새벽 점검 작업 : 설정 변경을 위한 MariaDB 재시작
- InnoDB Redo Log Size
50MB x 2 => 2GB x 3
- InnoDB Buffer Pool (전체 물리 메모리 64GB)
32GB => 40GB

- 서비스 차단 후 DB Shutdown
- 버퍼 풀 덤프 & 로드
- MariaDB 설정 변수 변경

새벽 시간이라 가볍게 생각했던 부분
- mysqldump 를 이용한 DB 풀백업

서비스 오픈 이후 DB의 급격한 성능 저하!
mysql> SHOW PROCESSLIST;
+-----+------+------+------+---------+------+------------+--------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+------+------+---------+------+------------+--------------------------------+
| ... | ... | ... | ... | ... | ... | ... | ... |
| ... | ... | ... | ... | ... | 3 | statistic | INSERT INTO LOG_TBL ... |
| ... | ... | ... | ... | ... | 2 | update | INSERT INTO LOG_TBL ... |
| ... | ... | ... | ... | ... | 3 | Sending.. | SELECT COL1, COl2, ... |
| ... | ... | ... | ... | ... | 2 | Sending.. | SELECT COUNT(*) FROM ... |
| ... | ... | ... | ... | ... | 2 | Sorting.. | SELECT COL5, COl6, ... |
| ... | ... | ... | ... | ... | 2 | Copying to | SELECT * FROM ( SEL ... |
| ... | ... | ... | ... | ... | 0 | closing.. | drop temporary table ... |
| ... | ... | ... | ... | ... | ... | ... | ... |
+-----+------+------+------+---------+------+------------+--------------------------------+

SHOW ENGINE INNODB STATUS 의
SEMAPHORE 절에서 경합을 발견
storage/innobase/include/dict0boot.ic
dict_sys->mutex

구글링 !!!
InnoDB scalability issues due to tables without primary keys
PK가 없는 InnoDB 테이블에서
내부적으로 관리되는 row id 값을
획득하기 위해 데이터 딕셔너리에 접근

상황 파악 1차
1) DB 재시작 이후, mysqldump 실행으로 자주 사용되지 않는
테이블의 데이터 페이지가 버퍼 풀에 적재
2) 서비스 오픈 이후 메모리 효율 저하 및 I/O 부하 증가
3) 쿼리 처리가 지연되며, 많은 양의 스레드가 적체
4) PK 없는 테이블의 INSERT에서 dict_sys mutex 경합 발생
=> dict_sys mutex 경합을 DB 부하의 결과로 파악

자주 활용되는 데이터가 메모리에 적재되며
DB 부하가 해소되었으나..
처리 성능이 튜닝 전보다 나빠짐

피크 타임 때, 다시 한 번 부하 발생하며 멘탈붕괴!!!
“무슨 설정 DB 설정을 바꿨냐?”
... Write Ahead Logging .. Buffer Pool ..
DBA로서 가지고 있던 상식에 대한 믿음이 흔들림

mysql> SHOW PROCESSLIST;
+-----+------+------+------+---------+------+------------+--------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+------+------+---------+------+------------+--------------------------------+
| ... | ... | ... | ... | ... | ... | ... | ... |
| ... | ... | ... | ... | ... | 2 | Copying to | SELECT * FROM ( SEL ... |
| ... | ... | ... | ... | ... | 0 | closing.. | drop temporary table ... |
| ... | ... | ... | ... | ... | ... | ... | ... |
+-----+------+------+------+---------+------+------------+--------------------------------+
크고 작은 부하 발생시마다 눈에 보이는 한 줄

!!!!!!!!!!!
다시 한 번 문서 확인
InnoDB scalability issues due to tables without primary keys

drop temporary table ~
해당 구문을 처리하는 배치 프로세스 확인
배치 실행시, 3~4만번 정도의 반복문을 통하여 특정
프로시저를 호출하는데, 이 프로시저 내부에서
create/drop temporary table 구문을 사용

매우 빠른 속도로
create/drop temporary table
구문이 반복적으로 수행됨

상황 파악 2차
1) CREATE/DROP 구문이 Loop 형태로 사용되며, 데이터 딕
셔너리 정보 갱신을 위해 반복적으로 dict_sys mutex 점유
2) PK없는 테이블이 INSERT를 처리하면서, row id 획득을 위
해 데이터 딕셔너리 테이블 접근
3) dict_sys mutex 발생
4) INSERT 쿼리가 처리되지 못하며, 다른 쿼리의 처리 또한 영
향을 받음
=> dict_sys mutex 경합이 DB 부하의 원인!

create/drop temporary 를 사용하지 않도록
프로시저를 수정 한 이후 문제가 해결!
하지만 적은 빈도로 수행되는 DDL 명령 수행 시,
심하지 않지만 dict_sys mutex 경합은 여전

* 고민이 필요한 부분
- InnoDB 테이블에는 PK 설정에 문제가 없는가?
(파티션 제약)
- 로그성 테이블이 물리적으로 분리가 가능한가?
- 로그성 데이터 입력을 실시간이 아닌,
배치 형태로 변경이 가능한가?

* 결론
장애 상황은 DBA의 수명을 줄인다.
장애 상황은 문서를 통한 간접 경험만으로도 충분하다.

[MySQL 스터디] 기타기능

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Empfohlen

Empfohlen (20)

[MySQL 스터디] 기타기능