SeolOps

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

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

작업 계획

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

사전 체크리스트

DEV 환경 마이그레이션 완료 및 검증
EBS 스냅샷 백업
mysqldump 풀 백업
애플리케이션 DB 접속 정보 변경 준비
롤백 절차 문서화
관련 팀 공지

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시간 동안 집중 모니터링을 진행했습니다.

CPU / 메모리 사용률
Slow Query 발생 여부
복제 지연 (Seconds_Behind_Master)
커넥션 수

롤백 계획

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

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

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

마무리

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

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