다른 서버에서 데이터베이스 옮기기
Millida VDS로 데이터베이스를 마이그레이션하는 절차를 알아봐요. 준비, 네트워크를 통한 덤프 전송, 무결성 확인, 다운타임을 최소화한 애플리케이션 전환을 다뤄요.
업데이트 2026년 8월 23일
데이터베이스 마이그레이션은 명령어에서 실패하지 않아요. 단계 순서에서 실패하죠. 사람들은 도메인부터 전환하고 나서야 데이터 절반이 넘어오지 않았다는 걸 알게 돼요. 아래는 그런 상황을 막는 순서예요.
준비
새 머신에 같은 버전이나 더 새로운 버전의 데이터베이스 서버를 설치하세요. PostgreSQL 또는 MySQL이에요. 다운그레이드는 지원하지 않아요.
psql --version
mysql --version
df -h /
데이터베이스 크기의 약 2.5배에 해당하는 여유 공간이 필요해요. 덤프, 압축을 푼 데이터, 그리고 약간의 여유분이죠. VDS-1에서는 총 40 GB이므로 미리 계획하세요.
이전 서버와 같은 인코딩으로 사용자와 빈 데이터베이스를 만드세요.
데이터 옮기기
가장 간단한 방법은 중간 파일 없이 SSH를 통한 덤프예요.
ssh root@OLD 'pg_dump -Fc -U shop shop' > /srv/shop.dump
pg_restore -U postgres -d shop --no-owner --role=shop /srv/shop.dump
MySQL의 경우:
ssh root@OLD 'mysqldump --single-transaction --routines --events -u root shop' \
| mysql -u root shop
역할과 사용자는 데이터베이스 덤프에 포함되지 않아요. 따로 내보내야 하죠. pg_dumpall --roles-only를 쓰거나 직접 만드세요. 사용자와 권한을 참고하세요.
대역폭은 최대 500 Mbps이므로 20 GB 데이터베이스는 몇 분 만에 이전돼요. 병목은 보통 디스크 쓰기이고, 이는 티어에 따라 제한돼요.
전환 전 확인
"사이트가 열렸다"가 아니라 숫자를 확인하세요.
SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;
SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='shop';
주요 테이블의 행 수를 이전 서버와 비교하고, 시퀀스가 초기화되지 않았는지 확인하세요(SELECT last_value FROM users_id_seq;). 그리고 테스트 모드에서 새 데이터베이스로 애플리케이션을 실행하세요.
전환하기
- 이전 서버에서 점검 모드를 켜거나 애플리케이션을 중지하세요.
- 준비 중에 발생한 변경 사항을 최종 덤프로 떠 두세요.
- 새 머신에 복원하세요.
- 애플리케이션의 연결 문자열을 바꾸고 서비스를 재시작하세요.
- 이전 서버는 데이터를 삭제하지 않은 채 일주일 더 실행해 두세요.
다섯 번째 단계를 건너뛰지 마세요. 사흘 뒤에 누락된 테이블을 발견하는 건 흔한 일이에요.
흔한 실수
| 증상 | 원인 |
|---|---|
복원 중 role does not exist | 역할이 이전되지 않음 — --no-owner와 수동 역할 생성을 사용하세요 |
| 글자가 깨짐 | 인코딩 불일치: utf8mb4 또는 UTF8 데이터베이스로 복원하세요 |
| 시퀀스가 1부터 시작 | 덤프에 setval 없이 데이터만 포함됨 |
| 복원에 몇 시간 소요 | 인덱스가 즉석에서 생성됨. 대용량 데이터베이스에는 pg_restore -j 4를 사용하세요 |
| 중간에 공간 부족 | 데이터와 함께 덤프 크기를 고려하지 않음 |
마이그레이션 전에 새 데이터베이스가
127.0.0.1에서만 수신하는지 확인하세요. "마이그레이션하는 동안"이라고 해서 공개적으로 노출할 필요는 없어요. 전송은 SSH를 통해 이루어지니까요. 원격 접속을 참고하세요.