레거시 MariaDB 서버 업그레이드 사전 조사 체크리스트

고객사의 운영 DB 서버 업그레이드 의뢰를 받았을 때, 곧바로 mariadb-upgrade를 실행하는 것은 위험하다. 운영 환경의 MariaDB 업그레이드는 사전 조사가 작업 시간의 대부분을 차지한다. 실제 업그레이드 자체보다 “업그레이드해도 되는 상태인가”를 확인하는 것이 핵심이다.

Open Table of contents

1. 현재 버전과 목표 버전 확인
2. 스키마 분석
3. 스토어드 프로시저 및 이벤트 감사
4. 리플리케이션 상태 확인
5. 백업 검증
6. 설정 파일 비교
7. 테스트 마이그레이션 계획
8. 롤백 계획
핵심 정리
참고 자료

1. 현재 버전과 목표 버전 확인

가장 먼저 현재 버전을 정확히 파악한다.

SELECT VERSION();
SHOW GLOBAL VARIABLES LIKE 'version%';
SHOW GLOBAL VARIABLES LIKE 'innodb_version';

MariaDB는 메이저 버전 간 업그레이드 시 한 단계씩 올리는 것을 권장한다. 예를 들어 10.3에서 10.11로 가려면 10.3 → 10.4 → 10.5 → … → 10.11 순서를 밟아야 한다. 뛰어넘으면 내부 시스템 테이블 마이그레이션이 실패할 수 있다.

체크 항목:

현재 버전의 EOL 날짜 확인 (MariaDB Foundation 공식 페이지)
목표 버전의 릴리스 노트에서 Breaking Changes 확인
중간 버전의 Deprecated 기능 중 현재 사용 중인 것이 있는지 확인

2. 스키마 분석

업그레이드 후 호환성 문제가 가장 많이 발생하는 부분이 스키마다.

-- 전체 데이터베이스 목록과 크기
SELECT table_schema AS db,
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS size_mb,
       COUNT(*) AS table_count
FROM information_schema.tables
WHERE table_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys')
GROUP BY table_schema
ORDER BY size_mb DESC;

-- 스토리지 엔진별 테이블 수
SELECT engine, COUNT(*) AS cnt
FROM information_schema.tables
WHERE table_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys')
GROUP BY engine;

-- MyISAM 테이블 목록 (업그레이드 시 주의 대상)
SELECT table_schema, table_name, engine, table_rows
FROM information_schema.tables
WHERE engine = 'MyISAM'
  AND table_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys');

체크 항목:

MyISAM 테이블 존재 여부 — InnoDB 전환 검토
utf8 (3바이트) 캐릭터셋 사용 테이블 — utf8mb4 전환 필요성 검토
ROW_FORMAT 확인 — COMPACT에서 DYNAMIC으로 변경 필요 여부
외래키 제약조건의 엔진 일관성 (InnoDB 끼리만 FK 가능)

-- utf8 사용 테이블 확인
SELECT table_schema, table_name, table_collation
FROM information_schema.tables
WHERE table_collation LIKE 'utf8_%'
  AND table_collation NOT LIKE 'utf8mb4_%'
  AND table_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys');

3. 스토어드 프로시저 및 이벤트 감사

레거시 시스템일수록 스토어드 프로시저, 트리거, 이벤트에 비즈니스 로직이 숨어 있다.

-- 스토어드 프로시저/함수 목록
SELECT routine_schema, routine_name, routine_type, created, last_altered
FROM information_schema.routines
WHERE routine_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys')
ORDER BY routine_schema, routine_type, routine_name;

-- 트리거 목록
SELECT trigger_schema, trigger_name, event_object_table, action_timing, event_manipulation
FROM information_schema.triggers
WHERE trigger_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys');

-- 이벤트 스케줄러 목록
SELECT event_schema, event_name, status, execute_at, interval_value, interval_field
FROM information_schema.events;

체크 항목:

Deprecated 함수 사용 여부 (예: PASSWORD(), ENCRYPT())
SQL 모드 변경에 영향받는 구문 (ONLY_FULL_GROUP_BY 등)
DEFINER 계정이 실제로 존재하는지

-- DEFINER 계정 확인
SELECT DISTINCT definer
FROM information_schema.routines
UNION
SELECT DISTINCT definer
FROM information_schema.triggers
UNION
SELECT DISTINCT definer
FROM information_schema.views;

4. 리플리케이션 상태 확인

Master-Slave 또는 Galera Cluster 환경이라면 업그레이드 순서가 중요하다.

-- Slave 상태 확인
SHOW SLAVE STATUS\G

-- 주요 확인 항목
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Seconds_Behind_Master: 0 (이상적)
-- Last_Error: (비어있어야 함)

-- Master 상태 확인
SHOW MASTER STATUS;
SHOW SLAVE HOSTS;

업그레이드 순서 원칙:

Slave부터 업그레이드 (서비스 영향 최소화)
Slave 업그레이드 후 리플리케이션 정상 작동 확인
Master 업그레이드 전 Slave를 임시 Master로 전환 가능한지 확인
Master 업그레이드 실행

체크 항목:

리플리케이션 필터 설정 확인 (replicate-do-db, replicate-ignore-db)
binlog 포맷 확인 (ROW, STATEMENT, MIXED)
GTID 사용 여부 — 버전 간 GTID 호환성 확인 필요

5. 백업 검증

백업이 “있다”와 “복구 가능하다”는 다른 문제다.

# 논리 백업 (mariadb-dump)
mariadb-dump --all-databases --routines --triggers --events \
  --single-transaction --quick \
  --result-file=/backup/full_dump_$(date +%Y%m%d).sql

# 백업 파일 무결성 기본 확인
tail -1 /backup/full_dump_*.sql
# 마지막 줄이 "-- Dump completed on YYYY-MM-DD HH:MM:SS" 이어야 함

체크 항목:

최근 백업 날짜와 크기 확인
백업에서 실제 복구 테스트 수행 (별도 인스턴스에서)
복구 소요 시간 측정 — 장애 시 RTO 계산에 필요
물리 백업(mariabackup) 사용 여부와 호환 버전 확인
바이너리 로그 보존 기간 — Point-in-Time Recovery 가능 범위 확인

6. 설정 파일 비교

현재 설정 중 새 버전에서 제거되거나 변경된 항목이 있는지 확인한다.

-- 현재 설정 전체 덤프
SHOW GLOBAL VARIABLES;

-- 주요 확인 대상
SHOW GLOBAL VARIABLES LIKE 'innodb_file_format';        -- 10.3 이후 제거
SHOW GLOBAL VARIABLES LIKE 'innodb_large_prefix';        -- 10.3 이후 제거
SHOW GLOBAL VARIABLES LIKE 'query_cache_%';              -- 10.1.7부터 비활성화
SHOW GLOBAL VARIABLES LIKE 'sql_mode';

체크 항목:

my.cnf에서 Deprecated/Removed 옵션 제거
sql_mode 기본값 변경에 따른 애플리케이션 영향 검토
innodb_buffer_pool_size 등 메모리 설정 재검토
character_set_server, collation_server 기본값 변경 확인

7. 테스트 마이그레이션 계획

실제 운영 환경에 적용하기 전, 반드시 동일 조건의 테스트 환경에서 리허설한다.

테스트 환경 구성:

운영 백업으로 테스트 인스턴스 구축 (Docker 활용 권장)
현재 버전에서 백업 복원 확인
목표 버전으로 업그레이드 실행
mariadb-upgrade 실행 및 출력 확인
애플리케이션 주요 쿼리 실행 테스트

# Docker로 테스트 환경 구축 예시
docker run -d --name mariadb-test \
  -e MARIADB_ROOT_PASSWORD=test \
  -v /backup/full_dump.sql:/docker-entrypoint-initdb.d/dump.sql \
  mariadb:10.6

# 업그레이드 테스트
docker exec mariadb-test mariadb-upgrade -u root -p

체크 항목:

업그레이드 후 모든 테이블 CHECK TABLE 실행
스토어드 프로시저 전체 실행 테스트
주요 비즈니스 쿼리의 EXPLAIN 비교 (실행 계획 변경 여부)
애플리케이션 연결 테스트 (커넥터 호환성)

8. 롤백 계획

업그레이드가 실패했을 때 원복할 수 있는 계획이 없으면 시작하지 않는다.

롤백 시나리오:

물리 백업(mariabackup)으로 원복하는 데 걸리는 시간
논리 백업(dump)으로 원복하는 데 걸리는 시간
다운타임 허용 범위
롤백 실패 시 2차 대응 방안

핵심 정리

레거시 MariaDB 업그레이드의 사전 조사를 요약하면 이렇다.

버전 경로 — 한 단계씩, 뛰어넘지 않기
스키마 — 엔진, 캐릭터셋, ROW_FORMAT 호환성
프로시저 — Deprecated 함수, DEFINER 계정
리플리케이션 — Slave 먼저, binlog/GTID 호환성
백업 — “복구 가능한” 백업인지 실제 테스트
설정 — Removed 옵션 제거, sql_mode 변경 영향
리허설 — 테스트 환경에서 전체 과정 1회 이상 실행
롤백 — 실패 시나리오와 원복 시간 계산

업그레이드 작업 자체는 몇 분이면 끝나지만, 이 체크리스트를 빠짐없이 확인하는 데는 며칠이 걸린다. 그 며칠이 운영 장애를 막는다.

참고 자료

MariaDB Upgrading Between Major Versions — MariaDB 공식 메이저 버전 업그레이드 가이드
mariadb-upgrade Utility — MariaDB 공식 업그레이드 유틸리티 문서