CentOS 7에서 MariaDB 서비스가 시작되지 않는 문제를 해결하는 방법

적용 환경과 CentOS 7 지원 상태

서비스 상태와 MariaDB 버전 확인

먼저 MariaDB 서비스가 실제로 실패한 상태인지와 설치된 패키지 계열을 확인합니다. CentOS 7 기본 저장소의 mariadb-server와 MariaDB 공식 저장소의 MariaDB-server는 패키지 이름과 버전이 다를 수 있으므로 재설치 전에 현재 구성을 확인해야 합니다.

sudo systemctl status mariadb.service -l --no-pager
sudo systemctl is-active mariadb.service
sudo systemctl is-enabled mariadb.service

rpm -qa | grep -Ei '^(mariadb|MariaDB)' | sort
mysqld --version

status 출력에서 Active: failed, 종료 코드와 마지막 오류 메시지를 확인합니다. disabled는 부팅 시 자동 시작이 꺼져 있다는 뜻일 뿐 수동 시작 실패의 직접 원인은 아닙니다.

서비스가 존재하지 않는다고 표시되면 유닛 파일과 서버 패키지가 설치되어 있는지 확인합니다.

systemctl list-unit-files | grep -i mariadb
rpm -qa | grep -Ei 'mariadb.*server|MariaDB-server'

systemd 저널과 MariaDB 오류 로그 확인

MariaDB 공식 문서도 서비스가 시작되지 않을 때 오류 로그와 systemd 저널을 가장 먼저 확인하도록 안내합니다. 현재 부팅에서 발생한 MariaDB 로그를 확인합니다.

sudo journalctl -u mariadb.service -b -n 150 --no-pager

문제를 재현하면서 실시간으로 새 로그를 확인하려면 첫 번째 터미널에서 다음 명령을 실행합니다.

sudo journalctl -fu mariadb.service

다른 터미널에서 서비스를 시작합니다.

sudo systemctl start mariadb.service

MariaDB 오류 로그의 위치는 버전과 설정에 따라 달라질 수 있습니다. 설정에서 log_error와 datadir 값을 먼저 찾습니다.

sudo grep -RniE '^[[:space:]]*(log[-_]error|datadir)[[:space:]]*=' \
  /etc/my.cnf /etc/my.cnf.d 2>/dev/null

sudo find /var/log /var/lib/mysql -maxdepth 2 -type f \
  \( -name '*.err' -o -name '*mariadb*.log' -o -name '*mysql*.log' \) \
  -print 2>/dev/null

오류 로그가 별도 파일로 설정되어 있지 않다면 systemd 저널에 시작 실패 원인이 기록될 수 있습니다. 파일 경로를 추측해 임의로 생성하기보다 실제 설정과 저널을 기준으로 진단하십시오.

설정 파일과 실제 적용 옵션 확인

MariaDB는 my.cnf와 포함된 추가 설정 파일을 읽습니다. 설치 방법과 버전에 따라 읽는 파일과 옵션 그룹이 다를 수 있으므로 서버 프로그램이 실제로 읽는 경로를 확인합니다.

mysqld --help --verbose 2>&1 | \
  sed -n '/Default options are read from/,/The following groups are read/p'

설정 파일에서 서버 관련 주요 값을 확인합니다.

sudo grep -RniE '^[[:space:]]*(datadir|socket|port|pid-file|log[-_]error|innodb_force_recovery)[[:space:]]*=' \
  /etc/my.cnf /etc/my.cnf.d 2>/dev/null

my_print_defaults mysqld server mariadb 2>/dev/null

MariaDB 구버전에는 모든 환경에서 동일하게 사용할 수 있는 독립적인 설정 문법 검사 명령이 있는 것이 아니므로, 최근에 변경한 .cnf 파일을 우선 확인하고 Unknown option, unknown variable, Found option without preceding group 같은 오류가 저널에 기록되는지 확인합니다.

설정을 변경하기 전 백업합니다.

sudo cp -a /etc/my.cnf /etc/my.cnf.before-mariadb-fix
sudo cp -a /etc/my.cnf.d /etc/my.cnf.d.before-mariadb-fix

디스크·inode·메모리 부족 확인

MariaDB는 시작 과정에서 데이터 파일, 임시 파일, 로그, PID 파일과 소켓을 생성하거나 갱신합니다. 파일시스템 공간이나 inode가 부족하면 서비스가 시작되지 않을 수 있습니다.

df -h
df -i
free -m

데이터 디렉터리가 별도 마운트에 있다면 실제 datadir 경로의 파일시스템을 따로 확인하십시오.

df -h /var/lib/mysql
df -i /var/lib/mysql

MariaDB가 메모리 부족으로 커널에 의해 종료되었는지도 확인합니다.

sudo journalctl -k -b --no-pager | grep -iE 'out of memory|killed process|oom'

디스크가 가득 찼다면 데이터베이스 파일을 임의로 삭제하지 마십시오. 먼저 로그·백업·임시 파일 등 안전하게 정리할 수 있는 데이터를 식별하고 충분한 여유 공간을 확보한 뒤 MariaDB를 다시 시작합니다.

데이터 디렉터리 권한과 SELinux 확인

오류 로그에 Permission denied, Can't create test file, Can't create/write to file 등이 나타난다면 일반 파일 권한과 SELinux를 함께 확인합니다. 먼저 실제 데이터 디렉터리를 확인한 후 해당 경로의 소유권과 컨텍스트를 점검하십시오.

sudo ls -ld /var/lib/mysql
sudo ls -ldZ /var/lib/mysql
namei -l /var/lib/mysql
getenforce

일반적인 패키지 설치 환경에서 MariaDB 서버는 mysql 사용자로 실행되므로 데이터 디렉터리에 필요한 접근 권한이 있어야 합니다. 단, 커스텀 데이터 디렉터리나 공유 스토리지를 사용하는 서버에서 경로 전체를 무조건 chown -R하지 말고 오류가 발생한 경로와 파일의 소유권을 먼저 확인하십시오.

SELinux AVC 거부가 기록되었는지 확인합니다.

sudo ausearch -m AVC -ts recent | grep -iE 'mysqld|mariadb'

데이터 디렉터리를 예를 들어 /data/mysql로 이동했다면 MariaDB용 SELinux 파일 컨텍스트를 지정해야 할 수 있습니다.

sudo semanage fcontext -a -t mysqld_db_t '/data/mysql(/.*)?'
sudo restorecon -Rv /data/mysql

기본값이 아닌 TCP 3307 포트를 사용하고 있고 SELinux가 차단한다면 현재 허용 포트를 확인한 뒤 필요한 경우 포트 타입을 등록합니다.

sudo semanage port -l | grep mysqld_port_t
sudo semanage port -a -t mysqld_port_t -p tcp 3307

포트 충돌과 중복 MariaDB 인스턴스 확인

오류 로그에 Address already in use가 나타나거나 3306 포트 바인딩에 실패한다면 다른 프로세스가 해당 포트를 사용 중인지 확인합니다.

sudo ss -lntp | grep ':3306 '
ps -ef | grep -E '[m]ysqld|[m]ariadbd'

MariaDB 공식 문서에서 Can't lock aria control file 또는 Unable to lock ./ibdata1 error: 11과 같은 오류는 동일한 데이터 디렉터리를 이미 다른 MariaDB 인스턴스가 사용하고 있을 가능성을 우선 확인하도록 안내합니다.

systemd 밖에서 수동으로 실행한 mysqld가 남아 있는지, 컨테이너 또는 별도 인스턴스가 같은 포트와 데이터 디렉터리를 사용하는지 확인하십시오.

패키지 혼용과 설치 파일 손상 확인

CentOS 7 기본 MariaDB 패키지와 MariaDB 공식 저장소 패키지가 혼용되거나 업그레이드가 중단되면 라이브러리와 서버 구성 불일치가 발생할 수 있습니다. 설치된 패키지를 확인합니다.

rpm -qa | grep -Ei '^(mariadb|MariaDB|mysql)' | sort
yum history list | head -n 20

서버 패키지가 관리하는 파일이 변경되거나 누락되었는지 확인하려면 실제 설치 패키지명을 확인한 뒤 RPM 검증을 실행합니다. 아래 PACKAGE_NAME은 mariadb-server 또는 MariaDB-server 등 실제 설치된 서버 패키지명으로 변경하십시오.

rpm -V PACKAGE_NAME

검증 결과가 있다고 해서 데이터 디렉터리까지 자동으로 복구하거나 패키지를 무조건 재설치하지 마십시오. 특히 /var/lib/mysql의 사용자 데이터는 RPM 재설치 대상과 별개이므로 먼저 백업과 로그 확인이 필요합니다.

CentOS 7은 EOL이므로 yum reinstall이나 패키지 설치가 실패한다면 GPG 키, Vault 저장소 또는 외부 MariaDB 저장소의 CentOS 7 지원 상태를 별도로 확인해야 합니다.

InnoDB 손상이 의심될 때의 응급 복구

오류 로그에 InnoDB 페이지 손상, crash recovery 실패, 반복적인 InnoDB assertion 또는 corruption 관련 오류가 나타날 때만 이 절차를 검토하십시오. innodb_force_recovery는 손상된 데이터를 고치는 기능이 아니라 서버를 제한된 복구 모드로 시작해 데이터를 덤프할 기회를 얻기 위한 응급 옵션입니다.

백업을 확보한 뒤 테스트가 필요하다면 서버 설정의 [mysqld] 그룹에 가장 낮은 복구 단계인 1부터 임시로 설정합니다.

[mysqld]
innodb_force_recovery=1

서비스가 시작되면 정상 운영을 재개하는 것이 아니라 필요한 데이터부터 덤프합니다. 실제 데이터베이스 계정과 백업 정책에 맞게 실행하십시오.

mysqldump --all-databases --single-transaction --routines --events > /root/mariadb-recovery.sql

MariaDB 공식 문서는 복구 모드를 1부터 시작해 필요한 경우에만 한 단계씩 올리도록 안내합니다. 높은 값일수록 더 많은 안전 기능과 복구 작업을 건너뛰며 데이터 일관성이 떨어질 위험이 커집니다.

데이터를 확보한 뒤에는 innodb_force_recovery 설정을 제거하고 정상 모드에서 복구 가능한지 확인해야 합니다. 손상이 계속된다면 백업에서 새 데이터 디렉터리로 복원하는 방식이 원칙이며, 복구 모드를 상시 운영 설정으로 남겨두면 안 됩니다.

복구 후 정상 작동 확인

원인을 수정한 뒤 실패 상태를 초기화하고 서비스를 시작합니다.

sudo systemctl reset-failed mariadb.service
sudo systemctl start mariadb.service
sudo systemctl status mariadb.service -l --no-pager
sudo systemctl is-active mariadb.service

서비스가 active 상태라면 수신 포트를 확인합니다. 커스텀 포트를 사용한다면 실제 설정값으로 변경하십시오.

sudo ss -lntp | grep ':3306 '

데이터베이스 관리자 자격 증명을 알고 있다면 실제 SQL 연결까지 확인합니다.

mysql -u root -p -e 'SELECT VERSION();'

시작 직후 다시 종료되는지 확인하기 위해 잠시 후 상태와 최근 로그를 한 번 더 확인합니다.

sleep 5
sudo systemctl is-active mariadb.service
sudo journalctl -u mariadb.service -b -n 50 --no-pager

부팅 시 자동 시작이 필요한 서버라면 정상 작동을 확인한 뒤 활성화합니다.

sudo systemctl enable mariadb.service
sudo systemctl is-enabled mariadb.service

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

원상복구 원칙

문제를 해결하기 위해 변경한 설정이 오히려 시작 실패를 악화시켰다면 백업한 설정 파일을 복원합니다.

sudo cp -a /etc/my.cnf.before-mariadb-fix /etc/my.cnf
sudo rm -rf /etc/my.cnf.d
sudo cp -a /etc/my.cnf.d.before-mariadb-fix /etc/my.cnf.d

innodb_force_recovery를 임시 설정했다면 데이터 덤프가 끝난 뒤 반드시 제거하고 정상 모드로 복귀합니다.

관련 지구 IDC 기술자료

• CentOS 7에서 systemd 서비스가 시작되지 않을 때 원인을 확인하는 방법
• CentOS7에 MariaDB 설치하기

공식 참고자료

자주 묻는 질문

MariaDB가 시작되지 않으면 가장 먼저 무엇을 확인해야 하나요?

systemctl status mariadb.service와 journalctl -u mariadb.service -b를 먼저 확인하십시오. 단순한 status=1/FAILURE만 보인다면 MariaDB 자체 오류 로그에서 구체적인 파일, 옵션, InnoDB 또는 권한 오류를 찾아야 합니다.

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

권한 오류일 때만 해당될 수 있습니다. 커스텀 데이터 디렉터리, 심볼릭 링크, 공유 스토리지, SELinux 문제도 있으므로 실제 오류 로그와 경로를 확인하지 않고 전체 데이터 디렉터리에 재귀적인 소유권 변경을 적용하는 것은 피하는 것이 좋습니다.

SELinux를 끄면 MariaDB가 시작되는데 그대로 꺼도 되나요?

권장하지 않습니다. 커스텀 데이터 경로는 mysqld_db_t, 커스텀 로그 경로는 mysqld_log_t, 비표준 포트는 mysqld_port_t가 올바르게 설정되었는지 AVC 로그를 기준으로 수정하십시오.

ibdata1이나 ib_logfile을 삭제하면 시작되는 경우가 있다는데 해도 되나요?

일반적인 문제 해결 방법으로 사용해서는 안 됩니다. 해당 파일들은 InnoDB 데이터와 복구에 중요한 역할을 하며 잘못 삭제하면 데이터 손실이 발생할 수 있습니다. 먼저 백업·스냅샷과 오류 로그를 확보하고 MariaDB 버전에 맞는 복구 절차를 따라야 합니다.

innodb_force_recovery를 설정하면 손상된 DB가 복구되나요?

아닙니다. MariaDB 공식 문서에 따르면 이 옵션은 손상을 수리하는 기능이 아니라 응급 상황에서 서버를 제한적으로 시작하여 데이터를 읽고 덤프하기 위한 기능입니다. 가장 낮은 단계인 1부터 시작하고 필요한 데이터 확보 후 정상 모드로 돌아가야 합니다.