Linux에서 MySQL(Percona 서버)이 충돌하는 원인을 어떻게 확인합니까?

Question

저는 Percona 버전의 MySQL Server v5.6을 실행하고 있으며 며칠마다 MySQL이 충돌한 다음 자동으로 다시 시작되는 것 같습니다. 충돌 원인이 무엇인지 어떻게 알 수 있나요? 나는 MySQL을 사용하는 다른 사람들이 예기치 않게 멈추는 것을 본 적이 있는데 그것은 메모리 문제로 인한 것 같지만 그들의 경우에는 오류 로그에 이 내용이 언급되어 있습니다. 내 경우에는 실제로 다시 시작할 때까지 로그 파일에 아무것도 나타나지 않습니다.

아래에는 마지막 "예상" 오류와 관련된 로그 파일과 MySQL이 다시 시작될 때 기록되는 내용이 포함되어 있습니다. 이는 충돌 이전의 다양한 "바이너리 로그에 기록된 안전하지 않은 문" 경고로 구성되어 있지만 이것이 충돌의 원인이라고 생각하지 않습니다. (로그가 가득 차는 것을 막기 위해 구성을 사용하지 않도록 명령문을 곧 업데이트할 것입니다 ON DUPLICATE KEY. 또한 복제를 수행하지 않는다는 점을 언급해야 합니다. 이것이 현재로서는 그다지 중요하지 않다고 생각하는 이유입니다. )

서버는 가상 머신(Virtuozzo)에서 실행되는 64비트 Centos 6.6입니다.

누군가 충돌의 원인을 파악하기 위해 올바른 방향을 알려줄 수 있기를 바랍니다. 감사해요!

아래 로그 파일:

2018-03-19 08:39:51 21476 [주의] BINLOG_FORMAT = STATEMENT이므로 명령문 형식을 사용하여 바이너리 로그에 안전하지 않은 명령문이 작성되었습니다. INSERT... ON DUPLICATE KEY UPDATE는 하나 이상의 UNIQUE KEY가 있는 테이블에 대해 안전하지 않습니다. 명령문: INSERT INTO xxxx ON DUPLICATE KEY UPDATE xxxx
180319 08:39:52 mysqld_safe 현재 실행 중인 프로세스 수: 0
180319 08:39:52 mysqld_safe mysqld가 다시 시작되었습니다.
2018-03-19 08:39:53 0 [경고] 암시적 DEFAULT 값이 있는 TIMESTAMP는 더 이상 사용되지 않습니다. --explicit_defaults_for_timestamp 서버 옵션을 사용하세요(자세한 내용은 설명서 참조).
2018-03-19 08:39:53 20217 [경고] myisam-recover-options 대신 고유 옵션 접두사 myisam-recover를 사용하는 것은 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. 대신 전체 이름을 사용하세요.
2018-03-19 08:39:53 20217 [참고] 플러그인 'FEDERATED'가 비활성화되었습니다.
2018-03-19 08:39:53 20217 [참고] InnoDB: 원자성을 사용하여 버퍼 풀 페이지 참조 계산
2018-03-19 08:39:53 20217 [참고] InnoDB: InnoDB 메모리 힙이 비활성화되었습니다.
2018-03-19 08:39:53 20217 [참고] InnoDB: Mutexes 및 rw_locks는 GCC 원자 내장을 사용합니다.
2018-03-19 08:39:53 20217 [참고] InnoDB: 메모리 배리어를 사용하지 않음
2018-03-19 08:39:53 20217 [참고] InnoDB: 압축 테이블은 zlib 1.2.3을 사용합니다.
2018-03-19 08:39:53 20217 [참고] InnoDB: Linux 네이티브 AIO 사용
2018-03-19 08:39:53 20217 [참고] InnoDB: CPU crc32 명령어 사용
2018-03-19 08:39:53 20217 [참고] InnoDB: 버퍼 풀 초기화 중, 크기 = 3.0G
2018-03-19 08:39:54 20217 [참고] InnoDB: 버퍼풀 초기화 완료
2018-03-19 08:39:54 20217 [참고] InnoDB: 지원되는 최고 파일 형식은 Barracuda입니다.
2018-03-19 08:39:54 20217 [참고] InnoDB: 체크포인트 lsn 123717382274를 지나 로그 스캔이 진행되었습니다.
2018-03-19 08:39:54 20217 [참고] InnoDB: 데이터베이스가 정상적으로 종료되지 않았습니다!
2018-03-19 08:39:54 20217 [참고] InnoDB: 크래시 복구를 시작합니다.
2018-03-19 08:39:54 20217 [참고] InnoDB: .ibd 파일에서 테이블스페이스 정보를 읽는 중...
2018-03-19 08:39:54 20217 [참고] InnoDB: 반쯤 쓰여진 데이터 페이지 복원 가능
2018-03-19 08:39:54 20217 [참고] InnoDB: doublewrite 버퍼에서...
InnoDB: 복구 중: 로그 시퀀스 번호 123717811056까지 스캔됨
InnoDB: 트랜잭션 790235434가 XA 준비 상태였습니다.
InnoDB: 롤백하거나 정리해야 하는 트랜잭션 1개
InnoDB: 실행 취소할 총 0개 행 작업
InnoDB: Trx ID 카운터는 790235904입니다.
2018-03-19 08:39:55 20217 [참고] InnoDB: 데이터베이스에 로그 레코드 일괄 적용을 시작합니다...
InnoDB: 진행률(%): 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 7
InnoDB: 배치 적용 완료
InnoDB: 마지막 MySQL binlog 파일 위치 0 697177863, 파일 이름 mysql-bin.000227
InnoDB: 커밋되지 않은 트랜잭션의 롤백을 백그라운드에서 시작
2018-03-19 08:39:56 20217 [참고] InnoDB: 128개의 롤백 세그먼트가 활성화되어 있습니다.
2018-03-19 08:39:56 7f481bd03700 InnoDB: 준비되지 않은 트랜잭션 롤백 완료
2018-03-19 08:39:56 20217 [참고] InnoDB: 퍼지 시작을 기다리는 중
2018-03-19 08:39:56 20217 [참고] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.22-71.0 시작; 로그 시퀀스 번호 123717811056
2018-03-19 08:39:56 20217 [참고] /var/lib/mysql/mysql-bin을 사용하여 충돌 후 복구
2018-03-19 08:46:36 20217 [참고] 크래시 복구를 시작합니다...
2018-03-19 08:46:36 7f491ce677e0 InnoDB: XA 트랜잭션 복구 시작 중...
2018-03-19 08:46:36 7f491ce677e0 InnoDB: 복구 후 준비된 상태의 트랜잭션 790235434
2018-03-19 08:46:36 7f491ce677e0 InnoDB: 트랜잭션에 1개 행에 대한 변경 사항이 포함되어 있습니다.
2018-03-19 08:46:36 7f491ce677e0 InnoDB: 복구 후 준비된 상태의 트랜잭션 1개
2018-03-19 08:46:36 20217 [참고] InnoDB에서 준비된 트랜잭션 1개 발견
2018-03-19 08:46:36 20217 [참고] 크래시 복구가 완료되었습니다.
2018-03-19 08:46:36 20217 [참고] RSA 개인 키 파일을 찾을 수 없습니다: /var/lib/mysql//private_key.pem. 일부 인증 플러그인은 작동하지 않습니다.
2018-03-19 08:46:36 20217 [참고] RSA 공개 키 파일을 찾을 수 없습니다: /var/lib/mysql//public_key.pem. 일부 인증 플러그인은 작동하지 않습니다.
2018-03-19 08:46:36 20217 [참고] 서버 호스트 이름(바인드 주소): '*'; 포트: 3306
2018-03-19 08:46:36 20217 [참고] IPv6를 사용할 수 있습니다.
2018-03-19 08:46:36 20217 [참고] - '::'는 '::'으로 해석됩니다.
2018-03-19 08:46:36 20217 [참고] IP: '::'에 서버 소켓이 생성되었습니다.
2018-03-19 08:46:37 20217 [참고] 이벤트 스케줄러: 0개 이벤트 로드됨
2018-03-19 08:46:37 20217 [참고] /usr/sbin/mysqld: 연결 준비가 완료되었습니다.
버전: '5.6.22-71.0-log' 소켓: '/var/lib/mysql/mysql.sock' 포트: 3306 Percona Server(GPL), 릴리스 71.0, 개정 726
2018-03-19 08:46:38 20217 [주의] BINLOG_FORMAT = STATEMENT이므로 명령문 형식을 사용하여 바이너리 로그에 안전하지 않은 명령문이 작성되었습니다. INSERT... ON DUPLICATE KEY UPDATE는 하나 이상의 UNIQUE KEY가 있는 테이블에 대해 안전하지 않습니다. 명령문: INSERT INTO xxxx ON DUPLICATE KEY UPDATE xxxx

편집: 댓글에 있는 @impimp의 질문에 따르면 다음 내용이 있습니다./var/log/messages

3월 18일 04:02:22 HOSTNAME rsyslogd: [origin Software="rsyslogd" swVersion="5.8.10" x-pid="474" x-info="http://www.rsyslog.com"] rsyslogd가 HUP되었습니다.
3월 19일 08:39:52 HOSTNAME 커널: [103311785.405884] UB 650543의 메모리 부족: OOM 종료 프로세스 21476(mysqld) 점수 0 vm:6363484kB, rss:4024500kB, 스왑:45536kB
3월 20일 09:17:35 HOSTNAME 커널: [103400050.711461] UB 650543의 메모리 부족: OOM 종료 프로세스 20217(mysqld) 점수 0 vm:6382720kB, rss:4066652kB, 스왑:0kB