슬픈 일이다. 어제 또 서버가 마비되었다. 지난 달에도 그러더니 이번에도 또 MySQL서버가 문제였다. 사실 웹서버든 메일서버든 다운이 되면 일단 로그부터 찾기 마련이다. 비행기 사고나면 블랙박스 찾는 마음으로 말이다. 아래는 지난 달 MySQL서버 터졌을때의 로그다.
160613 13:24:59 [Note] Plugin ‘FEDERATED’ is disabled.
160613 13:24:59 InnoDB: The InnoDB memory heap is disabled
160613 13:24:59 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160613 13:24:59 InnoDB: Compressed tables use zlib 1.2.8
160613 13:24:59 InnoDB: Using Linux native AIO
160613 13:24:59 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
160613 13:24:59 InnoDB: Completed initialization of buffer pool
160613 13:24:59 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160613 13:24:59 [ERROR] Plugin ‘InnoDB’ init function returned error.
160613 13:24:59 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
160613 13:24:59 [ERROR] Unknown/unsupported storage engine: InnoDB
160613 13:24:59 [ERROR] Aborting160613 13:24:59 [Note] /usr/sbin/mysqld: Shutdown complete
첫 줄 Plugin ‘Federated’가 마음에 걸려 이것저것 구글에서 뒤져서 my.cnf에 아래와 같은 설정을 추가해 놓은 상태였다.
[mysqld]
federated = 1
그리고 넋놓고 살고 있었는데 또 MySQL서버가 먹통이 되어서 에러 로그를 보니 이렇다.
160706 11:01:54 InnoDB: The InnoDB memory heap is disabled
160706 11:01:54 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160706 11:01:54 InnoDB: Compressed tables use zlib 1.2.8
160706 11:01:54 InnoDB: Using Linux native AIO
160706 11:01:54 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
160706 11:01:54 InnoDB: Completed initialization of buffer pool
160706 11:01:54 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160706 11:01:54 [ERROR] Plugin ‘InnoDB’ init function returned error.
160706 11:01:54 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
160706 11:01:54 [ERROR] Unknown/unsupported storage engine: InnoDB
160706 11:01:54 [ERROR] Aborting160706 11:01:54 [Note] /usr/sbin/mysqld: Shutdown complete
진짜 FEDERATED 부분만 쏙 빠지고 나머지는 똑같다. 아무래도 메모리가 부족해서 인 것 같은데, 사실 지금 솔직히 스왑파티션(Swap Partition)도 없는 상태다. 현재 1 CPU, 512MB RAM, 월 1TB 전송량에서 돈 더 주고 메모리 용량을 늘리기에는 시기상조이고, 스왑파티션을 만드는 것은 클라우드 서버에서 돌아가는 SSD 특성상 권하지 않는 것이 디지털오션의 정책이라 만들 수는 없고, 이것저것 구글링 하다가 MySQL쪽 설정을 바꿔 보기로 했다. 지금 innodb_buffer_pool_size가 기본값인 128M로 세팅이 되어 있는데 메모리가 작을 때에는 더 줄이는 것을 권장하길래 그렇게 해보기로 했다.
먼저
sudo nano /etc/mysql/my.cnf
명령어를 입력한후,
[mysqld] 란에다가
innodb_buffer_pool_size = 64M
key_buffer_pool_size = 8M
이렇게 두 줄을 추가해 주었다. key_buffer_pool_size도 기본값 16M에서 8M로 축소했다.
그리고
mysqlcheck -u root -p --auto-repair --check --all-databases
명령어를 입력해서 MySQL 모든 테이블과 데이터베이스 자동 검사 및 복구를 실행하였다.
잘 되었으면 좋겠다. 이번에도 안되면 크론(cron)으로 매일 새벽에 자동 재부팅 걸어 놓을 예정이다. 그래도 또 안되면 그냥 돈 더주고 메모리 업그레이드 하는 수 밖에…
같은 증상으로 검색하다 왔습니다.
마지막 메모리 축소후 어떻게 경과가 진행되었나요?
결국 스왑파티션을 만들었습니다. https://i.k-june.com/wp/3556
평소에는 스왑파티션이 거의 사용되지 않지만 순간적으로 메모리가 급증할 경우에는 효과적으로 대응할 수 있는 것 같네요. 지금은 몇달째 에러없이 잘 돌아가고 있습니다.
빠른 답급 감사드립니다.
swap이 답이군요. 정말 감사합니다
좋은 내용 감사합니다.
디스크 용량도 같이 확인해주면 좋아요
https://realmojo.tistory.com/349
네. 감사합니다.