MariaDB 운영 1주일 회고 : 구축부터 백업까지 배운 것들

 

 

※ 이 글은 운영자가 직접 홈서버를 운영하며 실험한 경험과 MariaDB, Docker의 공식 문서를 참고해 작성했습니다. 문장 정리와 구성에는 AI 도구의 도움을 일부 받았지만, 최종 내용은 운영자가 직접 확인하고 검토했습니다.

MariaDB 운영 1주일 회고 : 구축부터 백업까지 배운 것들

도입

이번 6주 차에는 Intel N100 홈서버에서 MariaDB를 처음부터 설치하고 운영하는 과정을 정리했습니다. 월요일에는 어떤 데이터베이스를 사용할지 여러 가지를 비교해 보았고, 화요일에는 Docker Compose를 활용해 MariaDB를 설치했습니다. 수요일에는 사용자 설정과 권한 관리에 대해 알아보았으며, 목요일에는 인덱스 활용법과 성능을 높이기 위한 기본적인 최적화 방법을 정리했습니다.

금요일에는 MariaDB 백업 전략을 살펴봤고, 토요일에는 홈서버 관리자가 꼭 챙겨야 할 운영 체크리스트를 만들어봤습니다. 그리고 오늘 일요일에는, 지난 일주일 동안 MariaDB를 관리하면서 어떤 점을 배우고 느꼈는지 한 번 정리해보려고 합니다.

처음에는 MariaDB를 설치하는 게 목표라고만 생각했어요. 그런데 한 주가 지나고 나니, 설치 자체보다 실제로 운영하는 게 훨씬 더 중요하다는 걸 느꼈습니다. 데이터베이스라는 건 단순히 한 번 실행하고 끝내는 기술이 아니라, 꾸준히 관리하고, 안전하게 지키고, 문제가 생겼을 때 복구할 줄도 알아야 하는 운영 중심의 기술이더라고요.

MariaDB 운영 1주일 동안 배운 구축, 권한, 성능, 백업, 운영 체크리스트를 한눈에 정리한 홈서버 회고 다이어그램입니다.

※ 다이어그램은 운영 환경 설계를 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감

본문

월요일 : 어떤 데이터베이스를 선택할까?

6주차는 RDBMS 선택 가이드로 시작했습니다. 홈서버에서 데이터베이스를 쓰려고 할 때 가장 먼저 떠오르는 게 SQLite, MySQL, MariaDB, PostgreSQL 같은 것들이죠. 각각의 장점이 다르고, 서버 운영 목적에 따라 가장 잘 맞는 선택지가 달라지기도 합니다.

DB 종류	특징	홈서버 관점
SQLite	가볍고 파일 기반	작은 앱과 단일 서비스에 적합
MySQL	오래된 웹 DB 표준	자료와 예제가 많음
MariaDB	MySQL 계열 오픈소스 DB	홈서버와 Docker 예제가 풍부함
PostgreSQL	기능이 강력하고 확장성 높음	고급 기능이 필요할 때 적합

이 과정을 통해 느낀 점은, 데이터베이스를 고를 때 반드시 하나의 정답이 정해져 있는 건 아니라는 것이었습니다. 가장 뛰어난 DB를 찾는 데 집중하기보다는, 실제로 운영할 서비스의 특성과 팀의 관리 역량에 잘 맞는 DB를 선택하는 게 훨씬 중요하다는 사실을 알게 됐습니다.

화요일 : Docker로 MariaDB를 구축해보니

화요일에는 Docker Compose를 이용해 MariaDB를 설치했습니다. 컨테이너를 띄우는 과정은 예상보다 간단했지만, 막상 중요한 부분은 컨테이너 자체가 아니라 데이터가 어디에 저장되는지였습니다.

volumes:
  - ./data:/var/lib/mysql

위와 같이 설정하면 MariaDB 컨테이너 안에서 생성된 데이터가 호스트 컴퓨터의 특정 폴더에 저장됩니다. 컨테이너를 지우고 새로 만들어도 데이터는 호스트에 남아 있으니 기록이 사라질 걱정이 없습니다. 만약 데이터 디렉터리 설정을 제대로 하지 않으면, 컨테이너를 삭제할 때 그동안 쌓아온 서비스 기록까지 함께 사라질 수 있습니다. 따라서 데이터 보존을 위해 꼭 호스트 디렉터리와 연결해두는 것이 좋습니다.

• 컨테이너는 다시 만들 수 있습니다.
• Compose 파일은 다시 작성할 수 있습니다.
• 이미지는 다시 받을 수 있습니다.
• 하지만 데이터는 사라지면 다시 만들기 어렵습니다.

MariaDB를 구축하면서 가장 크게 느낀 점은 컨테이너 자체보다 데이터가 어디에 저장되는지가 훨씬 더 중요하다는 사실이었습니다.

수요일 : 사용자와 권한은 생각보다 중요했다

수요일에는 MariaDB 접속 오류와 사용자 권한 설정을 정리했습니다. Access denied for user 오류는 단순히 비밀번호가 틀렸다는 뜻만은 아니었습니다. 사용자, Host, 권한, Docker network까지 함께 확인해야 했습니다.

CREATE USER 'appuser'@'%'
IDENTIFIED BY 'change_this_password';

GRANT ALL PRIVILEGES
ON appdb.*
TO 'appuser'@'%';

FLUSH PRIVILEGES;

처음에는 root 계정 하나로 모든 서비스를 운영하는 게 편하게 느껴질 수 있습니다. 하지만 점점 서비스가 많아지면, 각 서비스가 어떤 데이터베이스에 접근하는지 일일이 파악하기가 점점 더 어렵게 됩니다.

수요일의 핵심은 참 단순했습니다. 데이터베이스가 안정적으로 운영되려면, 누가 어디에서 무엇을 할 수 있는지 깔끔하게 정리되어 있어야 했죠.

목요일 : DB는 저장보다 검색이 중요했다

목요일에는 인덱스와 성능 최적화의 기초를 함께 살펴봤습니다. 처음에는 데이터베이스를 그저 데이터를 저장하는 공간이라고만 생각하기 쉽죠. 그런데 시간이 지나고 데이터가 점점 쌓이다 보면, 결국 핵심은 원하는 정보를 얼마나 빠르게 찾아낼 수 있느냐에 달려 있다는 걸 깨닫게 됩니다.

CREATE INDEX idx_users_email
ON users(email);

EXPLAIN
SELECT *
FROM users
WHERE email = 'user@example.com';

인덱스는 마치 책에서 목차를 보는 것과 비슷합니다. 처음부터 끝까지 일일이 페이지를 넘기지 않고도, 필요한 내용을 훨씬 빠르게 찾아볼 수 있도록 도와주는 역할을 하죠.

하지만 인덱스를 많이 만든다고 해서 무조건 좋은 결과가 나오는 건 아니었습니다. 인덱스가 많아지면 저장 공간이 늘어나고, 데이터에 쓸 때 오히려 부담이 생기기도 했죠. 그래서 실제로 자주 검색하는 컬럼 위주로 꼭 필요한 만큼만 인덱스를 추가하는 게 중요하다고 느꼈습니다.

금요일 : DB는 다시 설치할 수 있지만 데이터는 다시 만들 수 없다

금요일에는 MariaDB 백업 전략에 대해 정리했습니다. 이번 주에 다룬 내용 중에서도 특히 중요하게 느껴진 부분이었습니다. 데이터베이스 서버야 다시 설치할 수 있지만, 그 안에 저장된 데이터만큼은 한 번 잃으면 쉽게 복구할 수 없으니까요.

docker exec mariadb \
  mysqldump -u root -p homelab \
  > /opt/backup/mariadb/homelab_backup.sql

mysqldump는 데이터베이스를 SQL 파일 형태로 내보내는 대표적인 방법입니다. 홈서버 규모에서는 가장 이해하기 쉬운 백업 출발점으로 보였습니다.

백업 파일이 있다고 해서 안심할 수는 없었습니다. 정말로 복구가 되는지 직접 확인해봐야 했죠. 백업이 끝났다고 해서 곧바로 복구까지 보장되는 건 아니라는 사실이 가장 크게 느껴졌습니다.

토요일 : 운영 체크리스트가 필요했다

토요일에는 MariaDB 운영에 필요한 체크리스트를 직접 만들어보았습니다. 컨테이너 상태부터 디스크 사용량, 로그와 사용자 권한 관리, 그리고 인덱스와 백업 점검까지 빠짐없이 챙겼어요. 리소스 사용량과 업데이트 상황도 체크했고, 서비스 연결 상태와 복구 테스트 항목도 정리해두었습니다.

점검 항목	확인 방법	운영 의미
컨테이너 상태	docker compose ps	정상 실행 여부 확인
로그	docker compose logs	오류와 경고 확인
권한	SHOW GRANTS	사용자별 접근 범위 확인
성능	EXPLAIN	쿼리 실행 방식 확인
백업	ls -lh /opt/backup	최근 백업 존재 여부 확인

운영 체크리스트를 만들면서 느낀 점은, 서버를 자주 만지는 것이 반드시 좋은 운영 방식은 아니라는 것이었습니다. 오히려 꼭 필요한 항목들을 정기적으로 점검하고, 작은 이상 신호도 빠르게 알아채는 습관이 훨씬 중요하다고 느꼈습니다.

이번 주 가장 중요했던 것

6주차를 정리하면서 개인적으로 중요하다고 느낀 순서를 다시 정리하면 다음과 같습니다.

1. 백업 : 데이터 손실은 가장 치명적입니다.
2. 데이터 위치 : Docker에서는 컨테이너보다 volume과 host 경로가 중요합니다.
3. 권한 관리 : root 계정 하나에 의존하지 않는 구조가 필요합니다.
4. 성능 확인 : 인덱스와 실행 계획을 이해하면 문제 추적이 쉬워집니다.
5. 설치 : 설치는 시작점일 뿐 운영의 전부는 아니었습니다.

처음에는 설치가 가장 큰일처럼 느껴졌어요. 그런데 일주일이 지나고 보니, 설치는 오히려 시작에 불과하다는 걸 알게 됐죠. 실제로 서비스가 돌아가기 시작하면 데이터 위치나 권한 관리, 백업, 그리고 점검 루틴 같은 것들이 훨씬 더 오래 신경 써야 할 문제로 남더라고요.

운영 로그

아래 표는 6주차 일요일을 기준으로 정리한 MariaDB 운영 1주일 회고입니다. 실제 상태나 항목은 운영 환경, 서비스 개수, 데이터의 중요도, 그리고 백업 구조에 따라 달라질 수 있습니다.

요일	주제	핵심 정리
월요일	RDBMS 선택	운영 환경에 맞는 DB 선택이 중요함
화요일	MariaDB 구축	컨테이너보다 데이터 위치가 중요함
수요일	사용자와 권한	누가 어디서 무엇을 할 수 있는지 정리해야 함
목요일	인덱스와 성능	저장보다 검색 속도가 중요해질 수 있음
금요일	백업 전략	백업은 복구 가능성까지 확인해야 함
토요일	운영 체크리스트	정기 점검 습관이 필요함

에디터의 해석 노트 (Editor's Lab Note)

• 처음에는 MariaDB를 설치하는 것이 목표라고 생각했습니다.
• 하지만 한 주를 정리하면서 설치보다 운영이 더 중요하다는 것을 알게 되었습니다.
• Docker 환경에서는 컨테이너보다 데이터 위치가 중요했고, 백업보다 중요한 것은 복구 가능 여부였습니다.
• 이번 주는 MariaDB를 배우는 시간이라기보다 운영 습관을 배우는 시간에 가까웠습니다.

참고 링크 (References)

1. MariaDB Documentation
2. MariaDB Official Docker Image
3. MariaDB Backup and Restore Overview
4. Docker Compose Documentation
5. Docker volumes documentation

트러블슈팅

문제 : MariaDB 설치는 성공했지만 운영이 불안하게 느껴짐

MariaDB 컨테이너가 실행되고 접속까지 가능하다고 해서 바로 운영 준비가 완료된 것은 아닙니다. 사용자 설정과 권한 관리, 데이터 저장 위치 확인, 백업 및 복구 테스트, 그리고 로그 점검 같은 부분이 빠져 있다면, 실제로 장애가 발생했을 때 제대로 대응하기 힘들 수 있습니다. 이런 항목들도 꼼꼼하게 점검해야 비로소 안정적으로 운영할 수 있습니다.

확인 : 권한, 성능, 백업, 로그, 복구 가능성을 순서대로 점검

# 컨테이너 상태
docker compose ps

# 로그 확인
docker compose logs mariadb --tail=100

# 권한 확인
SHOW GRANTS FOR 'appuser'@'%';

# 백업 파일 확인
ls -lh /opt/backup/mariadb

원인 : 설치만 완료하고 운영 계획, 백업 전략, 점검 루틴을 만들지 않음

해결 : 주간 점검표를 만들고, 사용자 권한과 백업 파일, 복구 테스트를 정기적으로 확인

현재 구성에서는 MariaDB를 단순 설치 대상이 아니라 운영 대상 서비스로 보는 것이 더 현실적이었습니다.

마무리

MariaDB를 일주일 동안 운영해 보니, 가장 크게 와닿았던 점은 설치는 단지 출발선일 뿐이라는 사실이었습니다. 데이터베이스는 어떻게 설치하느냐보다, 실제로 어떻게 운영하고 관리하느냐가 훨씬 더 중요한 기술이라는 걸 알게 됐습니다.

이번 주에는 RDBMS 선택부터 Docker Compose 구축, 사용자 및 권한 설정, 인덱스와 성능, 백업 전략, 그리고 운영 체크리스트까지 차근차근 정리해봤습니다. 이렇게 과정을 정리하면서, MariaDB가 단순한 데이터 저장 역할을 넘어서 홈서버 서비스의 핵심적인 기반이라는 사실을 다시 한 번 실감하게 되었어요.

다음 주에는 실제 데이터를 다루고 활용하는 데 더 집중해 볼 생각입니다. MariaDB를 단순히 구축하는 데서 그치지 않고, 데이터가 서비스와 어떻게 연결되고, 또 이 과정이 운영 기록으로 어떻게 남는지 직접 살펴보려 합니다.