MySQL, MariaDB 의 signal crash

 

이 페이지에서는 MySQL, MariaDB 를 사용 시 발생 할 수 있는 signal crash 에 대해서 다룬다

 

이 페이지는 아래의 외부 참조 URL 들을 참조한다.

 

[1] https://jobdamuny.tistory.com/52

 

[2] https://forums.percona.com/t/database-crash-with-mysqld-got-signal-11/11703/2

 

[3] https://bugs.mysql.com/bug.php?id=96918

 

[4] https://kldp.org/node/2782

 

[5] https://badayak.com/3302

 

또한 이전 게시글과 연관되어 있다.

 

2023.06.16 - [DB 관련 지식/DB 기본 개념] - latch, mutex, enqueue

 

 

Signal Crash 개념

 

일반적으로 데이터베이스 또한 S/W 이기에 구성된 시스템에서 리소스 부족 등으로 인한 가용성 부족으로 여러 이슈가 발생할 수 있고, 버그로 인하여 강제 종료 등이 발생할 수 있다.

 

MySQL, MariaDB 또한 일반적으로 OS (일반적인 서비스를 구성 시 사용하는 OS 인 리눅스 기준) 와 결부되어 강제종료 등이 발생할 수 있는데 이 때, OS 와 결부된 이슈로 강제종료가 되면 error log 에 signal error 를 기록하며 이로 인해 발생하는 crash 를 signal crash 라 한다. 

 

 

Signal Crash 가 발생하는 이유

 

일반적으로 MySQL, MariaDB 에서 signal crash 가 발생하는 이유는 데이터베이스가 쿼리나 기타 작업들을 처리 하면서 데이터베이스 처리 logic (stack logic) 내에 이상 또는 OS 에 이상 접근 시에 발생한다.

 

 

Signal Crash 종류

 

MySQL 에서 MariaDB 에서 signal crash 가 발생시 보내는 error log 는 'MySQL got signal (숫자)' 로 기록된다.

대표적인 signal crash 는 6, 11 이 있고 흔하지 않지만 7 이 발생할 수 있다. 이 숫자들은 [1] [4] 에 언급된 것과 같이 OS (Linux) 가 프로세스에 보내는 event signal 과 관련되었다는 공통점이 있다.

 

- MySQL got signal 6

 

데이터베이스가 이상 logic 으로 쿼리를 처리하면서 이로 인하여 비정상적으로 강제 종료된 crash 다.

일반적으로 데이터 처리 stack logic 이슈인 경우가 많으며 관련된 내용들을 [3] 과 같이 mysql bug report 에서 우선적으로 찾아 볼 것을 권장 한다.

 

- MySQL got signal 11

 

메모리에 비정상적으로 접근시에 발생하는 crash 다. 이 또한 logic 문제인데 6 crash 와는 다르게 리소스 접근 logic 이 잘못되었을 가능성이 높다.

 

- MySQL got signal 7

 

흔하지않은 crash 유형으로 Bus error 라 하여 특정 CPU 프로세서 (예: ARM processor) 에서 데이터베이스 처리 logic 을 받아 들이지 못하여 데이터베이스가 강제 종료되는 crash 다.

 

 

Signal Crash 에 대한 조치방안

 

이 글을 읽어보면 어느정도 짐작하겠지만, crash 는 처리 logic 과 관련된 경우가 많아서 관련된 검색자료가 많지 않고 해결이 쉽지 않다. 그래서 이 이슈를 발견한다면, 가능한 crash 에 도달하는 과정을 우회하든가 crash 를 유발하는 쿼리를 수정 하는 방법 중 확인 및 적용이 쉬운 방법을 적용 하는 게 좋다.