MariaDB Bugs / issues
현재까지 발견된 MariaDB의 Bug를 정리한 것으로 source 상에 exception 처리가 잘되있지 않아서 간혹 signal error를 발생시키며 DB를 kill시킨다. 쿼리 수행만으로도 DB를 down시킬수 있으므로 주의해야한다.
- JDBC-Connector 설정
현상 : 특정SQL(스칼라 서브쿼리안의 조건절에 ifnull, max 함수를 사용하는 SQL)을 mariadb가 prepareStatement를 제대로 수행하지 못하고 signal error 발생함. 즉, 특정 쿼리 prepare하는 과정에서 제대로 수행하지 못해 dbdown 현상 발생함.
해결방안 : mariadb-jdbc-1.4.6의 useServerPrepStmts를 false로 변경(디폴트 true임)
세부 조치내용 :
1) JIRA에 문의
2) signal 11, 6 error는 null pointexception, 메모리 설정 등의 에러임
3) 오뉴에서 my.cnf의 파라미터 값 조정 받음(메모리값 조정)
4) general_log=1 통해 SQL 수집하고, 배치 수행때 또 다시 발생하여 해당 sql을 분석함.
5) 툴에서는 발생하지 않고, 배치 서버 통해 jdbc 거쳐 prepare하는 단계에서 발견되는 것을 확인
6) 현상 재현, 소스 분석
7) jdbc의 useServerPrepStmts 파라미터 false로 변경하여 이슈 종료
(mysql jdbc의 경우 해당 파라미터 default false임.)
JIRA 답변 :
MDEV-9181 (NULLIF(count(table.col)), 0) gives wrong result on 10.1.x
Wrapping args[0] and args[2] into an Item_cache for aggregate functions.
참고 : https://jira.mariadb.org/browse/MDEV-10347
- DB프로세스 OOM으로 인한 KILLED 현상
mysqldump 수행 간 free memory가 캐시로 빠져서 0에 수렴하고, 이때 대량의 트랜잭션 수행으로 인해 OOM이 발생하였음.
1. 리눅스 캐시메모리 flush
리눅스 메모리 반환은 해당 프로세스가 종료되기 전까지 반환되지 않을수도 있으므로 아래와 같이 캐시메모리를 반환하여 free메모리 확보
1) sync 10번 수행
2) my.cnf -> innodb_flush_method = O_DIRECT
3) echo 3 > /proc/sys/vm/drop_caches (가능한 mysqld 작업 없을때 수행)
참고 : http://zetawiki.com/wiki/%EB%A6%AC%EB%88%85%EC%8A%A4_%EC%BA%90%EC%8B%9C_%EB%A9%94%EB%AA%A8%EB%A6%AC_%EB%B9%84%EC%9A%B0%EA%B8%B0
2. mysqldump를 quick 옵션 없이 수행하면 테이블의 데이터들을 모두 Client의 메모리에 모두 로딩하므로, quick 옵션줘서 dump 받을 것
3. http://minsql.com/mysql/linux-%EC%9D%98-oom-out-of-memory-killer-%EB%A1%9C-%EC%9D%B8%ED%95%9C-mysqld-shutdown-%ED%94%BC%ED%95%98%EA%B8%B0/
- Temp 영역 변경
현상 : 악성쿼리 수행되면서 (테이블 cross join) 세션에 할당된 1GB temp buffer보다 과도하게 발생하여, 65기가를 Disk에 write함.
해당 파일이 /logs001/data 영역에 write되어 결과적으로 /logs001이 full 발생하여 binary log가 write 되지 못하여 DB가 hang상태로 빠짐.
해결방안 :
1) DB 재기동하여 상태 정리 후 해결
2) my.cnf에 tmpdir을 /logs001/masvc01/data 에서 /data001/tmpdir로 변경
: 현재 /data001 이하는 3.5 테라, /logs001 이하는 binary log 만 쌓일 수 있게 함.
세부 조치내용 :
1) 문제 발생 후 악성 쿼리 kill하여 템프 공간 확보
2) /logs001 이하 Full로 인해 트랜잭션이 수행되지 못함. 트랜잭션 commit 후 /logs001 이하에 있는 binary log file이 write되지 못했고, 1)에서 kill하여 temp공간 확보하였으나 처리되지 못한 트랜잭션이 정리되는 시간으로 서비스가 지연됨.
3) 현재 DB상에 수행중인 쿼리들 kill하였으나 status가 killed로 빠질 뿐 kill이 수행되지 않음.
4) DB 재기동하여 상태 정리 후 해결
5) my.cnf에 tmpdir을 /logs001/masvc01/data 에서 /data001/tmpdir로 변경
: 현재 /data001 이하는 3.5 테라, /logs001 이하는 binary log 만 쌓일 수 있게 함.
- HeidiSQL 사용시 주의 사항
현상 : 특정 sql 수행 후 DB down 현상(signal 11 error)
Maria DB에서 제공하는 SQL Tool(Heidi)에서 복잡한 구문 수행시 DB Down 현상 발생
만약 mariadb의 캐릭터셋이 utf8mb4가 아니라면 HeidiSQL 접속 후 아래의 내용을 수행한다.
조치사항 :
JIRA에 문의함. (Heidi의 Character Set을 UTF8로 세팅 가능한지 확인)
프로젝트에서는 toad를 사용하거나, HeidiSQL 사용시 set names utf8 수행 후 사용하라고 얘기함. (현 세션의 캐릭터셋 확인은 set variables like '%char%'로 확인 가능하며, 모두 utf8이어야 함.
상세 조치내용 :
1) 8/31 16:20:00 : 특정 SQL이 HeidiSQL에서 수행되면서 DB down(Signal 11 error) 됨.
2) 8/31 16:20:31 : 30초 뒤에 slave가 master로 승격
3) 8/31 18:05:09 : 원복은 new master로 부터 xtrabackup 받아서 18:05:09에 진행
4) error 로그의 threadId를 확인하여 slow 로그에서 sql 확인 진행하였고, 사용자가 수행한 쿼리로 추정하여 HeidiSQL에서 장애발생한 시간대의 sql history 를 확인
5) 해당 SQL로 TEST서버에서 재현함
6) 재현 가능하게 SQL 수정하고, JIRA에 문의함
7) MariaDB로 부터 버그로 판정받음.
8) HeidiSQL 외에 toad나 서버에서 직접 수행하면 발생하지 않아 HeidiSQL에서 수행될때 차이가 무엇인지 general_log 통해 분석함.
9) HeidiSQL에서 세션 접속될때 set names utf84mb4을 수행함. 서버의 캐릭터셋은 utf8임.
10) utf85mb4로 명시적으로 세팅한 후, HeidiSQL 외 다른 툴에서 특정 sql을 수행하니 또다시 DB DOWN되었음.
11) 특정 SQL과 다른 캐릭터셋으로 인해 발생하는 문제로 귀결함.
12) 위의 사실 JIRA에 문의함. (Heidi의 Character Set을 UTF8로 세팅 가능한지 확인)
프로젝트에서는 toad를 사용하거나, HeidiSQL 사용시 set names utf8 수행 후 사용하라고 얘기함. (현 세션의 캐릭터셋 확인은 set variables like '%char%'로 확인 가능하며, 모두 utf8이어야 함.
참고 : https://jira.mariadb.org/browse/MDEV-10713
- XTRABACKUP간 주의사항
현상 : xtrabackup 후 apply log 진행 간 에러 발생
: InnoDB: Cannot add field `EDI_GROUP_NO` in table `glapp`.`tb_li_glap_xxseds_shpist` because after adding it, the row size is 8141 which is greater than maximum allowed size (8126) for a record on index leaf page.
원인 :
Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
: 확인 결과 row size가 8126를 초과하여 나오는 현상
해결방안 :
실제 테이블의 컬럼수가 302개로 1 row size의 범위를 벗어나서 나타나는 현상임.
사용하지 않는 attribute등을 식별하여 drop하거나 row_format을 변경하여 관리하겠음.
우선 xtrabackup 후 apply-log 적용할때 나타나는 현상이긴 하나 실제로 복구하는데 문제없으며, 백업 진행간에 8126 size 이상의 데이터가 들어올 경우 해당 현상이 발생함. 만약 apply-log 간에 이러한 에러가 발생하면 해당 테이블을 따로 백업받아서 복구함. (근본적인 해결방안은 테이블의 컬럼 사이즈를 줄이거나 row_format을 변경)