← 목록

PRD DB MariaDB 11.4 버전업 - 운영 환경 적용 과정

운영(PRD) 환경에서 MariaDB 10.5를 11.4로 버전업한 실제 적용 과정과 주의사항 정리

2025-07-05MariaDBDatabaseMigrationProduction

DEV 환경에서 MariaDB 11.4 마이그레이션을 검증한 뒤, 운영(PRD) 환경에 적용한 과정을 정리한다.

운영 환경이다 보니 다운타임 최소화와 롤백 계획이 핵심이었다.

작업 계획

항목내용
대상PRD DB 서버
기존 버전MariaDB 10.5
목표 버전MariaDB 11.4
예상 다운타임1시간 이내
롤백 방안기존 10.5 서버 유지 (즉시 전환 가능)
작업 시간서비스 이용이 적은 시간대

사전 체크리스트

1. 백업

EBS 스냅샷

# AWS CLI로 EBS 스냅샷 생성
aws ec2 create-snapshot \
  --volume-id [volume-id] \
  --description "PRD DB backup before 11.4 migration" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=prd-db-pre-migration}]'

mysqldump 풀 백업

mysqldump -h [prd-db-ip] -u [user] -p \
  --single-transaction \
  --routines --triggers --events \
  --all-databases > /data/backup/prd-full-$(date +%Y%m%d).sql

백업 완료 확인

2. 신규 서버 구성

DEV에서 검증한 것과 동일한 절차로 진행했다.

EBS 볼륨 마운트

sudo mkdir -p /data
sudo mount /dev/xvdf /data
echo '/dev/xvdf /data xfs defaults,nofail 0 2' | sudo tee -a /etc/fstab

MariaDB 11.4 설치 및 설정

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | \
  sudo bash -s -- --mariadb-server-version="mariadb-11.4"
sudo yum install MariaDB-server MariaDB-client -y

PRD용 my.cnf는 DEV보다 리소스를 더 할당했다.

[mysqld]
datadir=/data/mysql
port=[db-port]
 
# Replication (Master)
server-id=1
log-bin=mysql-bin
binlog-format=ROW
log-slave-updates=ON
gtid_strict_mode=ON
 
# 성능 (PRD 사양에 맞춤)
innodb_buffer_pool_size=8G
innodb_log_file_size=1G
innodb_flush_log_at_trx_commit=1
sync_binlog=1
innodb_io_capacity=2000
innodb_io_capacity_max=4000
 
# 연결
max_connections=500
wait_timeout=600
interactive_timeout=600

3. 데이터 이관

테이블 데이터 이관

# 덤프 파일 import
mysql -u root -p < /data/backup/prd-full-*.sql

시퀀스 이관

DEV에서 겪었던 시퀀스 이슈를 반영해서, 미리 스크립트를 준비했다.

#!/bin/bash
# migrate-sequences.sh
 
SOURCE_HOST="[source-ip]"
SOURCE_USER="[user]"
DB_NAME="[db-name]"
 
# 시퀀스 목록 추출
sequences=$(mysql -h $SOURCE_HOST -u $SOURCE_USER -p -N -e \
  "SELECT TABLE_NAME FROM information_schema.TABLES \
   WHERE TABLE_SCHEMA='$DB_NAME' AND TABLE_TYPE='SEQUENCE';")
 
for seq in $sequences; do
  current_val=$(mysql -h $SOURCE_HOST -u $SOURCE_USER -p -N -e \
    "SELECT NEXTVAL($DB_NAME.$seq);")
  echo "Migrating $seq with value $current_val"
  mysql -u root -p -e \
    "CREATE SEQUENCE IF NOT EXISTS $DB_NAME.$seq START WITH $current_val;"
done

유저 및 권한

-- 애플리케이션 유저
CREATE USER '[app-user]'@'[app-server-ip]' IDENTIFIED BY '[password]';
GRANT SELECT, INSERT, UPDATE, DELETE ON [db-name].* TO '[app-user]'@'[app-server-ip]';
 
-- 복제 유저
CREATE USER '[repl-user]'@'[replica-ip]' IDENTIFIED BY '[repl-password]';
GRANT REPLICATION SLAVE ON *.* TO '[repl-user]'@'[replica-ip]';
 
FLUSH PRIVILEGES;

4. 서비스 전환

전환 순서

1. 애플리케이션 서비스 중지
2. 기존 DB에서 최종 변경분 확인
3. 최종 데이터 동기화
4. 애플리케이션 DB 접속 정보 변경
5. 애플리케이션 서비스 시작
6. 동작 확인

접속 정보 변경

# application.yml
datasource:
  url: jdbc:mariadb://[new-prd-db-ip]:[db-port]/[db-name]
  username: [app-user]
  password: [password]

5. 전환 후 검증

데이터 정합성

-- 주요 테이블 row count 비교
SELECT TABLE_NAME, TABLE_ROWS
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = '[db-name]'
  AND TABLE_TYPE = 'BASE TABLE'
ORDER BY TABLE_ROWS DESC;

복제 상태 확인

Replica 서버와의 복제가 정상 동작하는지 확인했다.

SHOW SLAVE STATUS\G
 
-- 확인 항목
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Seconds_Behind_Master: 0

모니터링

전환 후 24시간 동안 집중 모니터링을 진행했다.

롤백 계획

만약 문제가 발생하면 즉시 기존 10.5 서버로 롤백할 수 있도록 준비했다.

1. 애플리케이션 서비스 중지
2. DB 접속 정보를 기존 10.5 서버로 변경
3. 애플리케이션 서비스 시작

기존 10.5 서버는 전환 후 1주일간 유지한 뒤 제거했다.

마무리

DEV에서 충분히 검증한 덕분에 PRD 적용은 비교적 순조롭게 진행되었다. 시퀀스 마이그레이션 스크립트를 미리 준비한 것이 시간을 많이 절약해줬고, 롤백 계획을 세워둔 덕분에 심리적으로도 여유가 있었다.

배운 점

운영 작업에서 계획서의 절반은 롤백이었다. 되돌릴 방법을 정해두면 작업 중에 판단이 빨라진다. 이상 징후가 보일 때 "조금 더 보자"와 "되돌리자" 사이에서 망설이는 시간이 가장 위험하다.

기존 서버를 일주일 유지한 것도 같은 이유다. 전환 직후가 아니라 며칠 뒤에 드러나는 문제가 있다. 정리는 늦게 해도 손해가 적다.

앞선 검증 기록은 DEV DB 마이그레이션에 있고, 전환 뒤 복제가 밀렸을 때의 대응은 Replica SQL 적용 밀릴 때에 이어진다.

이어 읽기