MariaDB 운영 체크리스트 만들기: 홈서버 관리자가 확인해야 할 10가지
도입
6주차에는 Intel N100 홈서버에서 MariaDB를 운영하기 위한 과정을 순서대로 정리하고 있습니다. 월요일에는 RDBMS 선택 기준을 살펴봤고, 화요일에는 Docker Compose로 MariaDB를 구축했습니다. 수요일에는 사용자와 권한 설정 문제를 다뤘고, 목요일에는 인덱스와 성능 최적화 기초를 정리했습니다. 금요일에는 MariaDB 백업 전략을 살펴봤습니다.
토요일에는 지금까지 다룬 내용을 바탕으로 MariaDB 운영 체크리스트를 만들어보려 합니다. 구축, 권한, 성능, 백업을 한 번씩 정리했다면 이제 필요한 것은 정기적으로 상태를 확인하는 습관입니다.
좋은 운영은 문제가 생겼을 때만 대응하는 것이 아니라, 문제가 생기기 전에 확인하는 것에 가까웠습니다. 이번 글에서는 홈서버 관리자가 MariaDB를 운영하면서 주기적으로 확인하면 좋은 10가지 항목을 정리해보겠습니다.

※ 다이어그램은 운영 환경 설계를 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감
본문
왜 운영 체크리스트가 필요할까?
MariaDB를 한 번 구축했다고 해서 운영이 끝나는 것은 아니었습니다. 컨테이너가 실행 중인지, 로그에 오류가 쌓이고 있지는 않은지, 백업 파일이 실제로 생성되고 있는지, 저장 공간이 부족해지고 있지는 않은지 계속 확인해야 했습니다.
사람은 잊기 쉽고, 서버는 조용히 문제가 쌓이는 경우가 많습니다. 어느 날 갑자기 접속이 안 되거나, 서비스가 느려지거나, 백업이 비어 있다는 사실을 뒤늦게 알게 되면 복구가 더 어려워질 수 있습니다.
- 정기적으로 확인할 항목을 고정할 수 있습니다.
- 문제가 생기기 전에 이상 신호를 발견할 수 있습니다.
- 장애 발생 시 원인 추적이 쉬워집니다.
- 백업과 복구 준비 상태를 확인할 수 있습니다.
- 운영 기록을 남기기 쉬워집니다.
체크리스트는 특별한 자동화 도구보다 먼저 필요한 운영 기준이었습니다. 자동화는 나중에 붙일 수 있지만, 무엇을 확인해야 하는지 모르면 자동화도 방향을 잡기 어렵습니다.
1. 컨테이너 상태 확인
가장 먼저 확인할 항목은 MariaDB 컨테이너의 실행 상태입니다. Docker Compose로 운영한다면 docker compose ps 명령으로 현재 상태를 확인할 수 있습니다.
docker compose ps
확인할 것은 단순히 실행 중인지뿐만이 아닙니다. 컨테이너가 Up 상태인지, 반복 재시작되고 있지는 않은지, 예상하지 못한 종료 상태는 없는지 확인해야 합니다.
| 상태 | 의미 | 운영 판단 |
|---|---|---|
Up |
컨테이너 실행 중 | 정상 여부를 로그로 추가 확인 |
Restarting |
반복 재시작 중 | 로그와 설정값 즉시 확인 |
Exited |
컨테이너 종료됨 | 종료 원인 확인 필요 |
2. 데이터 저장 공간 확인
MariaDB는 데이터를 계속 쌓아갑니다. 게시글, 사용자 정보, 실행 기록, 로그성 데이터가 늘어나면 디스크 사용량도 함께 증가합니다. 홈서버에서는 저장 공간이 넉넉하지 않을 수 있기 때문에 디스크 상태를 주기적으로 확인해야 했습니다.
# 전체 디스크 사용량 확인
df -h
# MariaDB 데이터 디렉터리 용량 확인
du -sh /opt/docker/mariadb/data
특히 MariaDB 데이터가 저장되는 경로가 어디인지 정확히 알고 있어야 합니다. Docker Compose에서 ./data:/var/lib/mysql처럼 연결했다면 호스트의 data 디렉터리가 핵심 점검 대상입니다.
3. MariaDB 로그 확인
컨테이너가 실행 중이어도 내부적으로 경고나 오류가 반복되고 있을 수 있습니다. 그래서 로그 확인은 운영 체크리스트에서 빠질 수 없는 항목입니다.
# 최근 로그 확인
docker compose logs mariadb --tail=100
# 실시간 로그 확인
docker compose logs -f mariadb
로그에서는 Error, Warning, 접속 실패, 권한 오류, 재시작 흔적 등을 확인합니다. 모든 로그를 완벽히 해석할 필요는 없지만, 같은 오류가 반복되는지는 반드시 살펴봐야 합니다.
4. 사용자와 권한 점검
수요일에 정리했듯이 MariaDB 운영에서는 사용자와 권한 관리가 중요합니다. 서비스가 늘어날수록 root 계정 하나에 의존하지 않고, 서비스별 사용자와 권한을 분리하는 것이 좋습니다.
SELECT User, Host
FROM mysql.user;
사용하지 않는 계정이 남아 있지는 않은지, 불필요하게 넓은 권한을 가진 사용자가 있는지, Host 범위가 너무 넓지는 않은지 점검합니다.
SHOW GRANTS FOR 'appuser'@'%';
특히 'user'@'localhost'와 'user'@'%'의 차이를 구분해야 합니다. Docker 환경에서는 다른 컨테이너에서 접속해야 하므로 Host 설정을 잘못 이해하면 접속 오류로 이어질 수 있습니다.
5. 인덱스와 성능 확인
목요일에는 MariaDB 인덱스와 성능 최적화 기초를 정리했습니다. 운영 체크리스트에서는 자주 검색되는 컬럼에 인덱스가 적절히 있는지, 쿼리가 불필요하게 많은 데이터를 확인하고 있지는 않은지 살펴봅니다.
# 인덱스 목록 확인
SHOW INDEX FROM users;
# 실행 계획 확인
EXPLAIN
SELECT *
FROM users
WHERE email = 'user@example.com';
실제 운영 서비스의 테이블에 임의로 인덱스를 추가하는 것은 신중해야 합니다. 하지만 실행 계획을 확인하는 습관은 성능 문제를 이해하는 데 도움이 됩니다.
6. 백업 파일 존재 확인
금요일에 정리한 것처럼 백업은 문제가 생기기 전에 준비하는 운영 습관입니다. 체크리스트에서는 백업 파일이 실제로 만들어졌는지, 최근 날짜인지, 파일 크기가 비정상적으로 작지는 않은지 확인해야 합니다.
# 백업 파일 목록 확인
ls -lh /opt/backup/mariadb
# 백업 디렉터리 크기 확인
du -sh /opt/backup/mariadb
백업 파일이 존재하는 것만으로는 충분하지 않습니다. 어떤 데이터베이스를 백업했는지, 언제 생성되었는지, 복구 가능한 형식인지도 함께 확인해야 합니다.
7. 메모리와 CPU 사용량 확인
Intel N100 홈서버는 저전력 장비이므로 리소스 상태도 확인해야 합니다. MariaDB가 과도하게 메모리를 사용하고 있거나 CPU 사용량이 높게 유지된다면 쿼리, 데이터 양, 백업 작업, 다른 컨테이너와의 영향 관계를 함께 봐야 합니다.
docker stats
docker stats는 실행 중인 컨테이너의 CPU, 메모리, 네트워크, 블록 I/O 사용량을 확인하는 데 도움이 됩니다. 일시적인 상승은 문제가 아닐 수 있지만, 지속적으로 높은 사용량이 유지된다면 원인을 확인해야 합니다.
8. 업데이트 계획 확인
MariaDB도 Docker 이미지로 운영한다면 이미지 업데이트를 고려해야 합니다. 다만 데이터베이스는 단순 웹 서비스보다 업데이트에 더 신중해야 합니다. 데이터 구조, 호환성, 백업 상태를 먼저 확인해야 하기 때문입니다.
# 이미지 목록 확인
docker images
# 현재 컨테이너 이미지 확인
docker inspect mariadb --format='{{.Config.Image}}'
업데이트 전에는 반드시 백업을 확인하고, major version 변경 여부를 살펴보는 것이 좋습니다. 운영 환경에서는 최신 버전보다 안정적으로 복구 가능한 상태가 더 중요했습니다.
9. 접속 정보와 서비스 연결 확인
MariaDB는 단독으로 존재하는 것이 아니라 여러 서비스와 연결됩니다. WordPress, Nextcloud, n8n 같은 서비스가 MariaDB에 접속한다면 DB Host, DB Name, User, Password, Port 정보가 맞아야 합니다.
- DB Host: Docker network 안에서는 서비스명 사용 여부 확인
- DB Port: 내부 포트와 외부 포트 혼동 방지
- DB Name: 서비스별 데이터베이스 이름 확인
- DB User: root가 아닌 전용 사용자 사용 여부 확인
- Password:
.env와 서비스 설정값 일치 여부 확인
특히 Docker 환경에서는 localhost가 MariaDB 컨테이너를 의미하지 않을 수 있습니다. 같은 network 안에서는 mariadb 같은 서비스명을 사용하는 구성이 더 자연스러울 수 있습니다.
10. 복구 테스트 일정 확인
마지막 항목은 복구 테스트입니다. 백업 파일이 있다는 것과 실제로 복구할 수 있다는 것은 다릅니다.
# 테스트 DB 생성 예시
CREATE DATABASE restore_test;
# 백업 파일 복구 예시
docker exec -i mariadb \
mariadb -u root -p restore_test \
< /opt/backup/mariadb/homelab_backup.sql
운영 데이터에 바로 복구 테스트를 하는 것은 위험할 수 있으므로, 테스트용 데이터베이스나 별도 환경에서 확인하는 것이 좋습니다. 복구 테스트 일정까지 체크리스트에 넣어두면 백업의 신뢰도를 높일 수 있습니다.
핵심 문장
백업 완료는 복구 가능을 의미하지 않습니다. 실제 복구 과정을 확인해야 백업이 운영 전략이 됩니다.
운영 로그
아래 표는 6주차 토요일 기준으로 정리한 MariaDB 운영 체크리스트입니다. 실제 점검 주기와 항목은 서비스 수, 데이터 중요도, 저장소 구성, 백업 방식에 따라 달라질 수 있습니다.
| 점검 항목 | 확인 방법 | 상태 기준 |
|---|---|---|
| 컨테이너 상태 | docker compose ps |
정상 실행 여부 확인 |
| 디스크 사용량 | df -h |
여유 공간 확인 |
| MariaDB 로그 | docker compose logs |
Error, Warning 반복 여부 확인 |
| 사용자 권한 | SHOW GRANTS |
불필요한 권한 여부 확인 |
| 인덱스와 성능 | EXPLAIN |
인덱스 사용 여부 확인 |
| 백업 파일 | ls -lh /opt/backup |
최근 백업 존재 여부 확인 |
| 리소스 사용량 | docker stats |
CPU, Memory 상태 확인 |
| 업데이트 계획 | docker images |
백업 후 검토 |
| 서비스 연결 | DB Host, User, Port 확인 | 서비스별 접속 정보 확인 |
| 복구 테스트 | 테스트 DB 복원 | 백업 유효성 검증 |
에디터의 해석 노트 (Editor's Lab Note)
- 처음에는 서버를 자주 만져야 잘 운영하는 것이라고 생각했습니다.
- 하지만 시간이 지나면서 중요한 것은 수정이 아니라 정기적인 확인이라는 것을 알게 되었습니다.
- 운영 체크리스트는 문제가 생긴 뒤에 보는 문서가 아니라, 문제가 생기기 전에 보는 문서에 가까웠습니다.
- MariaDB는 구축보다 점검 루틴이 더 오래 가는 운영 기준이었습니다.
참고 링크 (References)
트러블슈팅
문제: 어느 날 갑자기 MariaDB 기반 서비스가 느려짐
서비스가 느려졌을 때 바로 MariaDB 설정을 바꾸기보다, 먼저 기본 점검 항목을 순서대로 확인하는 것이 좋습니다. 디스크 공간, 로그, 메모리 사용량, 백업 작업, 쿼리 상태가 모두 영향을 줄 수 있기 때문입니다.
확인: 디스크, 로그, 메모리, 백업 상태, 쿼리 실행 계획을 순서대로 점검
# 디스크 확인
df -h
# MariaDB 로그 확인
docker compose logs mariadb --tail=100
# 리소스 확인
docker stats
# 실행 계획 확인
EXPLAIN
SELECT *
FROM users
WHERE email = 'user@example.com';
원인: 저장 공간 부족, 로그 누적, 메모리 부족, 백업 작업과 사용 시간대 겹침, 인덱스 미사용
해결: 주간 점검 체크리스트를 기준으로 상태를 확인하고, 문제가 반복되는 항목을 운영 로그에 기록
현재 구성에서는 문제가 생긴 뒤에 급하게 설정을 바꾸는 것보다, 체크리스트를 통해 작은 이상 신호를 먼저 발견하는 편이 더 현실적이었습니다.
마무리
MariaDB 운영은 구축으로 끝나지 않았습니다. 사용자와 권한을 관리하고, 성능을 점검하고, 백업을 준비했다면 이제는 꾸준히 확인하는 습관이 필요합니다.
좋은 운영은 문제가 생겼을 때 대응하는 것이 아니라, 문제가 생기기 전에 확인하는 것에 가까웠습니다. 컨테이너 상태, 저장 공간, 로그, 권한, 성능, 백업, 복구 테스트는 모두 MariaDB를 오래 운영하기 위한 기본 점검 항목이었습니다.
다음 글에서는 “내 홈서버 DB는 지금 건강할까?”라는 질문으로 MariaDB 점검 루틴과 6주차 운영 회고를 정리해보겠습니다.
'코어-테크 : 트러블 슈팅 노트' 카테고리의 다른 글
| MariaDB 백업은 어떻게 해야 할까? Docker 환경 백업 전략 정리 (0) | 2026.06.12 |
|---|---|
| MariaDB는 왜 느려질까? 인덱스와 성능 최적화 기초 (0) | 2026.06.11 |
| MariaDB 접속이 안 되는 이유는? 사용자와 권한 설정 트러블 슈팅 (1) | 2026.06.10 |
| Intel N100 홈서버에 MariaDB 구축하기 : Docker Compose로 데이터베이스 서버 만들기 (0) | 2026.06.09 |
| 내 홈서버에는 어떤 데이터베이스가 맞을까? RDBMS 선택 가이드 (0) | 2026.06.08 |