Knowledgebase

적용 환경

가장 먼저 서비스 상태와 로그 확인

MySQL 서비스가 시작되지 않을 때 가장 먼저 확인해야 할 것은 systemd 상태와 최근 로그입니다.

sudo systemctl status mysql.service --no-pager -l
sudo journalctl -u mysql.service -b -n 100 --no-pager

status에서는 종료 코드와 마지막 오류를 확인하고, journalctl에서는 현재 부팅 이후 MySQL이 실패한 원인을 확인합니다. 설정 오류, 권한 오류, 포트 충돌, InnoDB 오류 등이 기록되어 있다면 해당 메시지를 기준으로 다음 단계를 선택하십시오.

Ubuntu 패키지 환경에서는 MySQL 자체 오류 로그가 /var/log/mysql/ 아래에 기록되는 경우가 일반적입니다. 실제 파일을 먼저 확인합니다.

sudo ls -lh /var/log/mysql/
sudo tail -n 100 /var/log/mysql/error.log

서버에서 로그 경로를 변경했다면 다음 명령으로 관련 설정을 확인합니다.

sudo grep -RniE '^[[:space:]]*(log_error|datadir|port|socket)[[:space:]]*=' /etc/mysql/ 2>/dev/null

MySQL 설정 파일 오류 확인

MySQL 설정을 수정한 직후 서비스가 시작되지 않는다면 문법이나 지원되지 않는 옵션이 원인일 가능성이 높습니다. Ubuntu 22.04 패키지는 /etc/mysql/ 아래 여러 설정 파일을 포함하므로 최근 변경 파일을 먼저 확인합니다.

sudo find /etc/mysql -type f -printf '%TY-%Tm-%Td %TH:%TM %p
' | sort -r
sudo grep -RniE '^[[:space:]]*[^#;[:space:]]' /etc/mysql/mysql.conf.d/ /etc/mysql/conf.d/ 2>/dev/null

MySQL 8.0.16 이상에서는 서버를 실제로 기동하지 않고 시작 설정을 검사하는 --validate-config 옵션을 사용할 수 있습니다.

sudo mysqld --validate-config
echo $?

오류가 없으면 종료 코드가 0이고, 잘못된 옵션이나 값이 확인되면 진단 메시지와 함께 종료 코드 1이 반환됩니다. 다만 이 검사는 storage engine의 모든 런타임 문제까지 검사하지는 않으므로 설정 검사가 성공해도 다른 원인으로 시작이 실패할 수 있습니다.

최근 수정한 설정을 복구할 가능성에 대비해 설정 디렉터리를 먼저 백업합니다.

sudo cp -a /etc/mysql /root/mysql-config-backup

로그에 unknown variable, unknown option 또는 잘못된 값과 관련된 오류가 보이면 해당 옵션을 수정한 뒤 다시 mysqld --validate-config를 실행하십시오.

디스크와 inode 부족 확인

MySQL은 시작 과정에서 데이터 파일, 임시 파일, PID, socket, 로그를 생성하거나 갱신해야 합니다. 루트 파일시스템이나 데이터 디렉터리의 공간이 가득 차면 서비스가 정상적으로 시작되지 않을 수 있습니다.

df -hT
df -i
sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/lib/mysql | sort -h

Use%가 100%이거나 inode 사용률이 100%라면 먼저 불필요한 로그, 캐시 또는 다른 서비스의 파일을 안전하게 정리해 여유 공간을 확보합니다.

3306 포트 충돌 확인

MySQL 오류 로그에 Address already in use 또는 TCP 포트를 바인딩할 수 없다는 메시지가 있다면 다른 프로세스가 MySQL 포트를 사용 중인지 확인합니다.

sudo ss -lntp | grep ':3306 '
sudo lsof -nP -iTCP:3306 -sTCP:LISTEN 2>/dev/null

lsof가 설치되어 있지 않다면 ss 결과만으로도 PID와 프로세스명을 확인할 수 있습니다. 다른 MySQL 또는 MariaDB 인스턴스가 이미 실행 중인지도 확인합니다.

ps -ef | grep '[m]ysqld'
systemctl list-units --type=service | grep -Ei 'mysql|maria'

실제 운영에 필요한 프로세스인지 확인하기 전에 강제 종료하지 마십시오. 의도하지 않은 중복 인스턴스라면 해당 서비스를 정상 종료하고, 여러 MySQL 인스턴스를 의도적으로 운영한다면 각각 다른 포트와 socket, 데이터 디렉터리를 사용하도록 구성해야 합니다.

데이터 디렉터리 소유권과 권한 확인

MySQL 공식 문서는 데이터 디렉터리에 접근할 수 없는 권한 문제를 대표적인 시작 실패 원인으로 안내합니다. 기본 Ubuntu 구성에서는 mysqld가 mysql 사용자로 실행됩니다.

id mysql
sudo ls -ld /var/lib/mysql /var/log/mysql /run/mysqld
sudo find /var/lib/mysql -maxdepth 1 -printf '%u:%g %m %p
' | head -n 30

로그에 Permission denied 또는 Errcode: 13이 있고 표준 데이터 디렉터리의 소유자가 잘못 변경된 사실이 확인된 경우에만 소유권을 교정합니다.

sudo chown -R mysql:mysql /var/lib/mysql

AppArmor 차단 확인

Ubuntu 22.04의 mysql-server-8.0 패키지에는 /etc/apparmor.d/usr.sbin.mysqld 프로파일이 포함됩니다. 데이터 디렉터리나 로그 경로를 기본 위치 밖으로 변경한 뒤 MySQL이 시작되지 않는다면 AppArmor가 접근을 차단하는지 확인해야 합니다.

sudo aa-status | grep -i mysqld
sudo journalctl -k -b | grep -iE 'apparmor|DENIED' | tail -n 50

로그에 apparmor="DENIED"와 mysqld가 함께 보이고 최근에 datadir, log_error, socket 경로 등을 변경했다면 해당 경로를 허용하도록 AppArmor 프로파일을 수정해야 합니다.

패키지 설치·업그레이드 상태 확인

APT 업데이트나 MySQL 패키지 업그레이드가 중간에 중단된 뒤 서비스가 시작되지 않는다면 패키지 상태를 확인합니다.

dpkg -l | grep -E '^..[[:space:]]+(mysql-server|mysql-server-8.0|mysql-server-core-8.0)'
apt policy mysql-server mysql-server-8.0
sudo dpkg --audit

미구성 패키지가 확인될 때는 먼저 dpkg 구성을 마무리합니다.

sudo dpkg --configure -a
sudo apt -f install

패키지 파일이 손상되었다고 판단되더라도 데이터를 보존해야 하므로 MySQL을 제거하거나 /var/lib/mysql을 초기화하기 전에 반드시 백업 상태와 데이터 디렉터리를 확인하십시오.

InnoDB 복구 오류 확인

강제 종료, 스토리지 장애 또는 손상된 페이지 때문에 InnoDB 복구 단계에서 mysqld가 종료되는 경우가 있습니다. 이 경우 systemd 상태보다 /var/log/mysql/error.log의 InnoDB 메시지가 핵심 진단 자료입니다.

sudo grep -iE 'InnoDB|corrupt|crash|recovery|ERROR' /var/log/mysql/error.log | tail -n 100

오류 로그에 실제 데이터 손상이나 InnoDB recovery 실패가 명확히 표시될 때는 데이터를 임의 삭제하거나 재초기화하지 말고 먼저 데이터 디렉터리의 전체 복사본 또는 스토리지 스냅샷을 확보하는 것이 중요합니다.

InnoDB 손상이 확인된 경우에는 정상 백업에서 복구하는 방법을 우선 검토하고, 강제 복구가 필요한 상황이라면 원본 데이터 디렉터리를 보존한 복제본에서 복구 절차를 테스트하는 것이 안전합니다.

메모리 부족과 OOM 기록 확인

MySQL이 시작 직후 종료되거나 이전에 정상 동작하던 mysqld가 반복적으로 사라진다면 커널의 OOM Killer가 프로세스를 종료했는지 확인합니다.

free -h
swapon --show
sudo journalctl -k -b | grep -iE 'out of memory|oom|killed process' | tail -n 50

OOM 기록이 있다면 단순 재시작보다 innodb_buffer_pool_size 같은 메모리 설정, 서버의 총 RAM, swap 구성, 동시에 실행되는 다른 프로세스의 메모리 사용량을 함께 점검해야 합니다.

원인 수정 후 MySQL 다시 시작

확인된 원인을 수정한 뒤 설정 검사를 다시 수행하고 서비스를 시작합니다.

sudo mysqld --validate-config
sudo systemctl reset-failed mysql.service
sudo systemctl start mysql.service
sudo systemctl status mysql.service --no-pager -l

서비스가 다시 실패하면 재시작을 반복하지 말고 최신 journalctl과 MySQL 오류 로그를 다시 확인해 실패 지점이 변경되었는지 비교하십시오.

정상 작동 확인

서비스가 시작된 뒤에는 systemd 상태만 보지 말고 실제 mysqld 프로세스와 포트, 로컬 SQL 연결까지 확인합니다.

systemctl is-active mysql.service
systemctl is-enabled mysql.service
sudo ss -lntp | grep ':3306 '
sudo mysqladmin ping

systemctl is-active가 active이고, 설정된 포트에서 mysqld가 수신하며 mysqladmin ping이 서버 응답을 확인하면 기본적인 기동 상태는 정상입니다.

Ubuntu 기본 설치의 로컬 관리자 인증 구성을 사용하는 경우 다음과 같이 SQL 접속도 확인할 수 있습니다.

sudo mysql -e 'SELECT VERSION(), NOW();'

자주 발생하는 오류와 해결 방법

원상복구 방법

설정 변경 직후 문제가 시작되었다면 가장 안전한 원상복구는 변경한 설정만 이전 값으로 되돌리는 것입니다. 앞에서 만든 백업이 있다면 파일 단위로 비교합니다.

sudo diff -ru /root/mysql-config-backup /etc/mysql

복구할 설정이 명확하다면 해당 파일을 되돌린 뒤 설정 검사와 재시작을 수행합니다.

sudo mysqld --validate-config
sudo systemctl restart mysql.service
sudo systemctl status mysql.service --no-pager -l

관련 지구 IDC 기술자료

• Ubuntu 20.04에 APM 설치하기 (Apache2, MySQL, PHP)

기존 문서는 MySQL을 포함한 APM 설치 절차를 다루고 있으며, 이번 문서는 Ubuntu 22.04에서 이미 설치된 MySQL 서비스의 시작 실패 원인을 진단하고 복구하는 데 초점을 맞춥니다.

공식 참고자료

자주 묻는 질문

mysql.service가 failed이면 MySQL을 재설치해야 하나요?

대부분의 경우 바로 재설치할 필요가 없습니다. 설정 오류, 디스크 부족, 권한, 포트 충돌처럼 데이터와 관계없는 원인도 많으므로 먼저 systemctl status, journalctl, MySQL 오류 로그를 확인해야 합니다.

/var/lib/mysql의 소유자를 mysql:mysql로 바꾸면 항상 해결되나요?

아닙니다. 소유권 오류가 실제 원인으로 확인된 표준 데이터 디렉터리에서만 적용해야 합니다. 커스텀 데이터 경로, NFS 또는 별도 스토리지를 사용한다면 해당 파일시스템 권한과 AppArmor 정책을 함께 확인해야 합니다.

MySQL error.log를 삭제해도 되나요?

시작 실패를 진단하는 동안에는 삭제하지 않는 것이 좋습니다. 오류 로그에는 실제 실패 원인이 기록되어 있으므로 먼저 보존하고 분석하십시오. 로그 용량 문제가 있다면 MySQL 및 logrotate 설정을 확인해 정상적인 방식으로 관리해야 합니다.

3306 포트를 다른 프로그램이 사용하면 MySQL은 시작되지 않나요?

MySQL이 동일한 주소와 포트에 바인딩하려는 경우 시작에 실패할 수 있습니다. ss -lntp로 포트를 점유한 프로세스를 확인하고, 중복 서비스인지 또는 의도된 프로그램인지 판별한 뒤 조치해야 합니다.

innodb_force_recovery를 바로 사용해도 되나요?

권장하지 않습니다. 오류 로그에서 InnoDB 손상이 확인되고 정상적인 기동이 불가능하며 데이터 dump가 필요한 긴급 상황에서만 검토해야 합니다. 먼저 데이터 디렉터리 복사본이나 스냅샷을 확보하고 가능한 한 값 1부터 시작해야 합니다.