V2 Prod 배포 전에 V1 Prod EC2의 MySQL 컨테이너 데이터를 RDS for MySQL(Single-AZ)로 옮겨야 한다. 이 문서는 V1 DB의 현재 상태를 정리하고, 공식 문서와 공개 벤치마크를 근거로 이관 방식을 비교해 쓰기 중단 시간을 최소화하는 이관 방식을 선택한다. V1 Prod MySQL 실측(2026-10-14) 결과 데이터가 1 MB 미만이어서, 데이터 이동보다 전환 순서와 검증이 쓰기 중단 시간을 결정한다. 데이터베이스 토폴로지(RDS Single-AZ) 선택 근거는 V2 DB 인프라 설계를 따른다.

V1 Prod는 t3.medium(2 vCPU / 4 GiB) EC2 1대에서 Nginx·Next.js·Spring Boot·MySQL을 Docker Compose로 함께 실행한다. MySQL은 같은 호스트의 다른 컨테이너와 CPU·메모리·디스크를 나눠 쓴다.

수치 출처는 V2 DB 인프라 설계와 V1 Docker Compose 구조의 한계 분석이다.

• MySQL은 internal: true인 database 네트워크에만 연결돼 있고 호스트 포트를 게시하지 않는다. 따라서 현재 상태로는 EC2 밖에서 V1 MySQL에 접속할 수 없다.
• V2는 V1 VPC(10.20.0.0/16)를 공유하고, RDS용 data 서브넷을 같은 VPC 안에 만든다(v2/network.tf). V1 EC2와 RDS는 VPC 로컬 라우팅으로 통신할 수 있으므로, 퍼블릭 공개나 VPN이 필요하지 않다.
• 선택한 방식(6장)에서는 V1 MySQL을 노출하지 않는다. 덤프는 EC2 안에서 실행하고, V1 EC2에서 RDS로 나가는 3306 연결만 RDS SG에서 허용한다.
• binlog 복제(부록 A)로 바꿀 때만 MySQL 3306을 EC2 사설 IP에만 게시하고, V1 Prod SG의 3306 인바운드는 RDS SG에서 오는 것만 허용한다. 0.0.0.0 바인딩과 CIDR 개방은 금지한다. Dev에 적용한 루프백 게시 원칙(MySQL SSM 접근 구성 스프린트 백로그의 CLOUD-DB-05)과 같은 취지다.

• S3 backup 버킷의 moyeota-db-backups/prod/ prefix와 보존기간(backup_retention_days), EC2 업로드 IAM 권한은 Terraform으로 만들어져 있다(infra/storage.tf, infra/iam.tf).
• 마일스톤 문서에는 backup-mysql.sh와 "Prod 배포 전 MySQL backup이 S3에 생성된다"는 완료 조건이 있다. 하지만 스크립트는 레포에 없어서 실제 백업이 주기적으로 실행되는지 확인되지 않았다. 이관 전에 최신 백업 객체가 있는지 확인하고, 이관 직전에 수동 백업을 하나 더 남긴다.

V1 Prod MySQL에서 직접 쿼리해 확인한 값이다. 실행한 쿼리는 부록 B에 있다.

테이블별 크기(mb는 소수 첫째 자리 반올림)는 다음과 같다.

데이터보다 binlog(binlog.000003 하나만 약 7.6 MB)가 더 크다. 이관할 데이터 양이 아니라 전환 순서와 정합성 검증이 이관의 핵심이라는 뜻이다.

V2 배포 일정은 10/16 stg 배포 → 10/17 QA → 10/19 Prod 배포이며, Prod DB 이관이 끝나야 Prod를 배포할 수 있다.

이관은 초기 적재(기존 데이터를 통째로 옮기기)와 변경분 동기화(적재하는 동안 생긴 쓰기를 따라잡기)의 조합이다. 초기 적재만 하면 적재하는 내내 쓰기를 멈춰야 하는 오프라인 이관이 되고, 변경분 동기화를 붙이면 전환 순간에만 쓰기를 멈추는 무중단에 가까운 이관이 된다.

공개 벤치마크는 대부분 V1보다 훨씬 큰 데이터와 장비에서 측정됐다. 따라서 절대 시간은 그대로 옮기지 않고, 도구 간 상대 순위와 단일 스레드 적재의 비용을 근거로 쓴다.

1. mysqldump가 느린 지점은 덤프가 아니라 적재다. 같은 1.56 GB에서 복원 시간이 MySQL Shell의 약 7.8배, XtraBackup의 약 12.8배였다. 원인은 SQL 파일 하나를 단일 스레드로 적재하는 구조이며, 세 벤치마크가 같은 결론을 낸다.
2. 이 차이는 데이터 크기에 비례한다. Pythian의 mysqldump 복원은 1.56 GB에 1,462초, 약 1.07 MB/s였다. V1 실측 크기(약 0.7 MB)를 대입하면 약 1초다. 같은 비율로 MySQL Shell(약 8.3 MB/s)과 XtraBackup(약 13.7 MB/s)은 1초 미만이다. 그래서 V1에서는 도구 간 적재 시간 차이가 무시할 수 있는 수준이다.
3. 변경분 동기화(R1)의 가치는 "적재 시간을 쓰기 중단에서 빼는 것"이다. 데이터가 클 때는 결정적이지만, 적재가 약 1초인 V1에서는 R1으로 줄일 수 있는 쓰기 중단도 약 1초뿐이다.
4. 따라서 V1에서는 이관 도구의 속도나 동기화 방식이 아니라, 전환 단계의 앱 전환 시간(backend 재기동, DNS 전파)과 운영 변경의 위험이 쓰기 중단 시간과 방식 선택을 결정한다.

1.6의 실측 크기(약 0.7 MB)와 4.3의 처리율을 대입해 산정했다. 모든 방식에 공통으로 들어가는 앱 전환 시간(V1 backend를 RDS로 다시 연결하는 재기동과 헬스체크, Compose start_period 60s 기준 최대 약 1분)은 표의 "공통 전환 시간"으로 따로 둔다.

산정 근거:

• 덤프·적재 시간은 4.2의 Pythian 측정(2 core / 4 GB, mysqldump 복원 약 1.07 MB/s)을 실측 크기에 비례 적용한 값이다. 네트워크 왕복과 테이블 생성(16개) 오버헤드가 더해져도 수 초 안쪽으로 본다. 8장 리허설로 실측한다.
• 공통 전환 시간은 V1 deploy/v1-compose.yaml의 backend 헬스체크 start_period: 60s를 상한으로 잡았다.

• 데이터 이동으로 인한 쓰기 중단이 수 초다. 실측 데이터가 1 MB 미만이라, binlog 복제를 붙여도 줄일 수 있는 시간이 약 1초뿐이다. 쓰기 중단의 대부분은 어떤 방식을 쓰든 같은 앱 전환 시간이다.
• 조회는 중단하지 않는다. V1 MySQL을 super_read_only로 바꾸면 쓰기만 실패하고, 조회는 V1에서 계속 처리된다.
• Prod V1 MySQL을 바깥에 노출하지 않는다. 덤프는 V1 EC2 안에서 실행하고, V1 EC2에서 RDS로 나가는 연결만 연다. R1처럼 V1 MySQL 포트를 게시하거나 컨테이너를 재생성할 필요가 없다.
• AWS 공식 절차의 덤프·적재 단계를 그대로 쓴다. 다운타임을 줄인 가져오기의 mysqldump 옵션(--single-transaction, --order-by-primary)과 적재 방식을 따르고, 데이터가 작아 복제 단계만 생략한다.
• 롤백도 수 초다. 전환 후 문제가 생기면 같은 방법으로 RDS → V1 역방향 덤프를 하면 된다(7.6).
• 새 도구와 상시 리소스가 없다. mysqldump와 mysql 클라이언트는 mysql:8.4.11 이미지에 들어 있다.

1. RDS 파라미터 그룹을 만든다: time_zone=Asia/Seoul, character_set_server=utf8mb4, collation_server=utf8mb4_0900_ai_ci.
2. RDS for MySQL 8.4.11을 V2 data 서브넷에 만든다. 서울 리전에서 이 버전을 쓸 수 있는지 먼저 확인한다.

   aws rds describe-db-engine-versions --engine mysql --engine-version 8.4.11 \
     --region ap-northeast-2 --query 'DBEngineVersions[].EngineVersion'

3. RDS SG에 V1 Prod EC2 SG에서 오는 3306 인바운드를 추가한다(전환 기간 V1 backend와 덤프 적재용). V2 ECS SG에서 오는 인바운드도 함께 둔다.
4. RDS에 앱 계정을 만든다. V1 backend.env의 DB_USERNAME과 같은 이름을 쓰되 비밀번호는 새로 만들어 SSM에 넣는다.
5. 앱이 기동할 때 스키마를 바꾸는 설정(예: JPA ddl-auto, Flyway)이 있는지 BE와 확인한다. 있다면 V2 BE의 스키마가 V1 데이터와 호환되는지 확인한다.
6. Route 53 moyeota.com 레코드의 TTL을 전환 전날까지 60초로 낮춘다.
7. 전환 직전 S3에 최종 백업을 남긴다.

V1 MySQL 컨테이너는 internal: true 네트워크에만 붙어 있어 RDS에 직접 연결할 수 없다. 따라서 덤프는 컨테이너 안에서 실행하고, 적재는 호스트 네트워크를 쓰는 임시 클라이언트 컨테이너로 보낸다.

# V1 Prod EC2 (/opt/moyeota)
docker compose exec -T mysql sh -c 'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" \
  --single-transaction --order-by-primary --set-gtid-purged=OFF \
  --routines=0 --triggers=0 --events=0 --databases moyeota' > moyeota-cutover.sql

docker run -i --rm --network host mysql:8.4.11 \
  mysql -h <rds-endpoint> -u <master> -p"<password>" < moyeota-cutover.sql

• 트리거·루틴·이벤트가 0개이므로(1.6) 위 옵션으로 빠지는 객체가 없다.
• mysql 스키마(계정)는 덤프하지 않는다. 계정은 7.1의 4단계에서 따로 만든다.

-- V1과 RDS 양쪽에서 실행해 결과 비교
SELECT 'users', COUNT(*) FROM moyeota.users
UNION ALL SELECT 'messages', COUNT(*) FROM moyeota.messages;   -- 16개 테이블 모두
CHECKSUM TABLE moyeota.users, moyeota.messages, ...;           -- 16개 테이블 모두
SELECT NOW(), @@time_zone, @@character_set_server, @@collation_server;

같은 8.4.11, InnoDB, 같은 행 형식이므로 CHECKSUM TABLE 값이 일치해야 한다.

산정 쓰기 중단: 수 초(덤프·적재·검증) + 최대 약 1분(backend 재기동) ≈ 1분 이내. 쓰기 중단 동안에는 로그인 토큰 저장(session_tokens)도 실패하므로 신규 로그인이 막힌다. 저트래픽 시간대에 실행한다.

권장은 A다. 쓰기 중단을 backend 재기동 시간으로 묶을 수 있고, DNS 캐시가 남은 클라이언트도 정상적으로 쓸 수 있다.

• 4단계 이전: V1 MySQL SET GLOBAL super_read_only = OFF;로 되돌린다. RDS에 쓰기가 없었으므로 데이터 손실이 없다.
• 4단계 이후: RDS에 새 쓰기가 쌓인다. 롤백 기준(전환 후 N분 안에 오류율 X% 초과 등, 리허설 후 확정)을 넘으면 같은 방식을 역방향으로 실행한다. RDS 파라미터 read_only=1로 쓰기를 막고, RDS → V1 덤프·적재(데이터가 작아 수 초)를 한 뒤 V1 super_read_only=OFF로 되돌린다. 그다음 backend DB_HOST와 DNS를 V1으로 되돌린다.
• V1 data EBS와 7.1의 최종 백업은 이관이 안정될 때까지 삭제하지 않는다.

10/16 stg 배포 때 V1 Prod를 소스로 7.2·7.3을 stg RDS에 실행한다. --single-transaction 덤프는 V1 서비스를 멈추지 않으므로 읽기 전용 전환 없이 리허설할 수 있다.

리허설이 끝나면 stg RDS는 기존 운영 방침대로 삭제한다.

데이터가 커져서 6.2의 조건에 해당할 때 쓰는 절차다. 절차는 AWS: 다운타임을 줄인 가져오기와 외부 소스 binlog 파일 위치 복제를 따른다.

1. V1 MySQL 3306을 <Prod EC2 사설 IP>:3306에만 게시하고, V1 Prod SG에 RDS SG에서 오는 3306 인바운드를 추가한다. Compose ports를 바꾸면 MySQL 컨테이너가 재생성되므로 저트래픽 시간대에 하거나, database 네트워크에 붙는 중계 컨테이너로 게시한다.
2. V1에 복제 계정을 만들고 REPLICATION CLIENT, REPLICATION SLAVE 권한을 준다(접속 호스트는 V2 data 서브넷 대역으로 제한).
3. RDS 파라미터 그룹에 autocommit=1, 복제 기간 동안 read_only=1을 둔다.
4. mysqldump에 --source-data=2를 추가해 덤프하고, 헤더의 SOURCE_LOG_FILE·SOURCE_LOG_POS를 기록한 뒤 RDS에 적재한다.
5. RDS에서 복제를 시작한다. 8.4의 기본 인증 caching_sha2_password 때문에 마지막 인자(TLS)를 1로 준다(AWS 복제 프로시저).

   CALL mysql.rds_set_external_source('<V1 사설 IP>', 3306, 'repl_user', '<password>',
                                      '<SOURCE_LOG_FILE>', <SOURCE_LOG_POS>, 1);
   CALL mysql.rds_start_replication;
   SHOW REPLICA STATUS\G   -- Seconds_Behind_Source = 0 확인

6. 전환: V1 super_read_only=ON → 지연 0 확인 → CALL mysql.rds_stop_replication; → CALL mysql.rds_reset_external_source; → RDS read_only=0 → 7.4의 4단계부터 같다.

SELECT VERSION();

SELECT table_name, table_rows,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS mb
  FROM information_schema.tables
 WHERE table_schema = 'moyeota'
 ORDER BY (data_length + index_length) DESC;

SHOW VARIABLES WHERE Variable_name IN
  ('log_bin', 'server_id', 'binlog_format', 'binlog_row_image',
   'gtid_mode', 'enforce_gtid_consistency', 'binlog_expire_logs_seconds');
SHOW BINARY LOG STATUS;

SELECT t.table_name
  FROM information_schema.tables t
  LEFT JOIN information_schema.table_constraints c
    ON c.table_schema = t.table_schema AND c.table_name = t.table_name
   AND c.constraint_type = 'PRIMARY KEY'
 WHERE t.table_schema = 'moyeota' AND t.table_type = 'BASE TABLE'
   AND c.constraint_name IS NULL;

SELECT 'trigger', COUNT(*) FROM information_schema.triggers WHERE trigger_schema = 'moyeota'
UNION ALL SELECT 'routine', COUNT(*) FROM information_schema.routines WHERE routine_schema = 'moyeota'
UNION ALL SELECT 'event', COUNT(*) FROM information_schema.events WHERE event_schema = 'moyeota';

공식 문서

• AWS: Importing data to an Amazon RDS for MySQL database with reduced downtime
• AWS: Configuring binary log file position replication with an external source instance
• AWS: Configuring, starting, and stopping binary log replication (stored procedures)
• AWS: Restoring a backup into an Amazon RDS for MySQL DB instance
• AWS Prescriptive Guidance: Migration options for large MySQL and MariaDB databases
• AWS Prescriptive Guidance: mydumper
• AWS DMS: Using a MySQL-compatible database as a source
• AWS DMS: Migrating data from MySQL databases with homogeneous data migrations
• AWS re:Post: DMS MySQL source to MySQL target
• AWS: Blue/Green Deployments overview
• AWS: Amazon RDS for MySQL now supports new minor version 8.4.11
• MySQL 8.4: Replication Compatibility Between MySQL Versions
• MySQL 8.4.0 Release Notes (mysqlpump 제거)
• MySQL 8.4: What Is New (SHOW MASTER STATUS 제거, expire_logs_days 제거)
• MySQL Shell 8.4: Load Dump Utility
• MySQL Shell: Copy Instance, Schemas, and Tables

벤치마크와 사례

• Pythian: Backup/Restore Comparison Using MySQL Shell vs mysqldump vs XtraBackup
• Percona: Migrate to Amazon RDS Using Percona XtraBackup
• MySQL Blog: MySQL Shell Dump & Load Part 2 – Benchmarks
• Percona: Backup/Restore Performance Conclusion
• Percona: Backup Performance Comparison
• Oracle MySQL Blog: Copy Data Directly to a MySQL Instance with MySQL Shell
• Stripe: Online migrations at scale