포럼

치명적인 오류 메시지

Can't lock aria control file '/var/lib/mysql/aria_log_control' for exclusive use, error: 11 Unable to lock ./ibdata1 error: 11 Plugin 'Aria' registration as a STORAGE ENGINE failed Plugin 'InnoDB' registration as a STORAGE ENGINE failed

그날 같은 문제를 겪었는데, Zeabur의 답변을 참고해 보세요: https://zeabur.com/forum/posts/69b21516f8458436bf7f1bd7

안녕하세요, 답변이 늦어 죄송합니다!

MariaDB 서비스를 확인한 결과, 현재 정상적으로 작동 중이며 이전의 데이터 파일 잠금 문제는 해결되었습니다.

참고 링크를 제공해주신 다른 사용자분께 감사드립니다. 향후 유사한 문제가 발생하면 서비스를 재시작하여 파일 잠금을 해제해 보시기 바랍니다.

현재 다른 궁금한 점이 있으신가요?

혹시 더 이상 답변을 도와주실 분이 안 계신가요...?

안녕하세요, 기다리게 해 드려 죄송합니다! 문의하신 내용에 대해 다음과 같이 설명해 드립니다.

이전 동료가 설명한 바와 같이, 백업 도구가 MariaDB에 연결하여 덤프를 수행할 때 MariaDB의 메모리 사용량이 일시적으로 증가합니다(쿼리 처리, 정렬 버퍼, 임시 테이블 등을 처리해야 하기 때문). 이때 메모리가 이미 한계치에 가까우면 프로세스가 비정상적으로 종료되어 제거되지 않은 잠금 파일(aria_log_control, ibdata1)이 남을 수 있습니다. 말씀하신 시간대를 고려할 때, 백업 중의 메모리 압박이 가장 유력한 원인입니다.

또한, 공유 클러스터의 노드는 정기적으로 유지보수가 진행되며, 유지보수 기간 동안 서비스는 다른 노드로 재배치됩니다. MariaDB가 백업 중에 노드 유지보수를 만나면 정상적인 graceful shutdown을 완료하지 못할 수 있으며, 이로 인해 잠금 파일이 잔류하게 됩니다.

권장되는 예방 조치:

1. 백업 시간을 트래픽이 적은 시간대로 조정: 이미 이 조치를 취하셨는데, 이는 백업과 일반 쿼리가 메모리를 두고 경쟁할 기회를 줄이는 올바른 방향입니다.
2. 메모리 할당량 적절히 상향: 현재 MariaDB의 평균 사용량은 약 117MB입니다. 백업 중의 추가 메모리 요구가 예외를 발생시키지 않도록 더 많은 공간(예: 256MB)을 확보하는 것을 권장합니다.
3. 잠금 발생 시 빠른 복구: 다시 잠금 문제가 발생하고 재시작으로 해결되지 않는 경우, 서비스의 '파일 관리' 페이지로 이동하여 /var/lib/mysql/aria_log_control을 삭제한 후 서비스를 재시작하면 30분을 기다릴 필요 없이 즉시 잠금을 해제할 수 있습니다.
4. 전용 서버 사용 고려: 공유 클러스터의 노드 유지보수와 리소스 공유는 간접적으로 데이터베이스 안정성에 영향을 줄 수 있습니다. 데이터베이스 안정성이 중요하다면, 노드 유지보수로 인한 예기치 않은 재시작을 피하기 위해 전용 서버로 서비스를 이전하는 것을 고려해 보시기 바랍니다.

상세한 보고 감사드리며, 다른 질문이 있으시면 새 게시물을 작성해 주시기 바랍니다. 감사합니다!