운영 중인 MariaDB를 옮길 때 가장 곤란한 건 “데이터는 옮겼는데 성능이 망가졌다” 또는 “스키마 정리하려다 다운타임이 길어졌다” 같은 상황입니다. 이 글은 CentOS 환경에서 온라인 영향 최소화 관점으로 마이그레이션을 진행하면서, 함께 해두면 좋은 인덱스/스키마 중심 개선을 한 번에 묶어 실전 순서로 정리했습니다.

두 데이터베이스가 안전하게 연결된 마이그레이션 메타포

핵심은 “복제(Replication)로 따라붙이고, 스키마 변경은 안전한 방식으로 나눠서, 마지막 전환만 짧게”입니다.

1) 사전 점검: 호환성·용량·부하를 먼저 숫자로 잡기

온라인 마이그레이션은 계획이 80%입니다. 특히 MariaDB 버전 차이와 설정 차이로 인한 문제(쿼리 플랜 변화, 문자셋/정렬 규칙, InnoDB 설정)가 전환 이후에 터지기 쉽습니다.

  • 버전/스토리지엔진 확인: 소스/타깃 MariaDB 버전, InnoDB 사용 여부, GTID 사용 여부
  • 문자셋/Collation: 서버 기본값과 DB/테이블/컬럼의 개별 설정이 섞여있는지 점검
  • 용량 산정: 데이터 크기 + 인덱스 크기 + 바이너리 로그/릴레이 로그 + 여유(최소 30% 권장)
  • 트래픽 패턴: 피크 시간대 QPS, 쓰기 비중(INSERT/UPDATE/DELETE), 장시간 트랜잭션 유무
  • 필수 기능: 이벤트 스케줄러, 트리거, 프로시저/함수, 파티션 테이블 사용 여부

CentOS에서는 OS 레벨도 같이 봅니다. 파일 디스크립터 한도, I/O 스케줄러, 시간 동기화(chrony), 방화벽 포트(3306 및 복제 관련), SELinux 정책 등이 마이그레이션 중 병목이 되거나 장애처럼 보이기도 합니다.

2) 온라인 마이그레이션 기본 전략: Replication 기반 “따라붙기 + 짧은 전환”

다운타임을 최소화하려면, 대체로 새 서버를 먼저 띄우고(타깃), 기존 서버(소스)를 기준으로 복제를 붙이는 방식이 가장 안정적입니다. 구조는 단순합니다: 처음 한 번 전체 덤프/백업으로 초기 데이터를 옮기고, 이후에는 바이너리 로그를 따라가며 변경분을 계속 반영합니다.

복제 기반 온라인 마이그레이션 흐름을 보여주는 다이어그램

  • 초기 로딩: mysqldump(논리 백업) 또는 mariabackup(물리 백업)으로 타깃에 초기 데이터 구성
  • 지속 동기화: Replication으로 소스의 쓰기를 타깃이 계속 따라감
  • 전환 시점: 애플리케이션 연결만 새 DB로 바꾸고, 소스는 잠시 읽기 전용으로 두어 롤백 가능성 확보

인덱스/스키마 개선까지 같이 하려면, “복제 중인 타깃에서 먼저 안전하게 검증”하고 “전환 직전에 위험한 변경을 몰아서 하지 않는 것”이 중요합니다.

3) 초기 데이터 이관: mysqldump vs mariabackup 선택 기준(운영 영향 관점)

운영 영향 최소화라면 물리 백업 도구(mariabackup)가 유리한 경우가 많습니다. 다만 환경에 따라 mysqldump가 더 단순하고 예측 가능할 때도 있습니다.

  • mariabackup 권장 상황: 데이터가 크고(수십~수백 GB), 백업 시간이 길어질수록 운영 부하가 부담될 때
  • mysqldump 권장 상황: 데이터가 비교적 작거나(수~수십 GB), 스키마/데이터를 선택적으로 정리하면서 옮기고 싶을 때
  • 공통 주의: 백업 시점과 바이너리 로그 위치(또는 GTID)를 정확히 기록해야 복제가 매끄럽게 붙습니다

온라인 덤프를 할 때는 장시간 락이 걸리지 않도록 옵션을 신중히 선택해야 합니다. 특히 큰 테이블의 스키마 변경/인덱스 생성이 동시에 돌면 I/O가 겹치며 애플리케이션 지연으로 이어질 수 있으니, 이관 작업 창(window)을 분리해 두는 게 좋습니다.

4) 인덱스 점검: “옮기기 전/후”가 아니라 “옮기면서” 정리하기

마이그레이션 후 성능 문제가 생기는 흔한 이유는 인덱스 자체가 부족하거나, 반대로 불필요한 인덱스가 너무 많아 쓰기가 느려지는 경우입니다. 온라인 관점에서는 “한 번에 다 바꾸지 말고, 우선순위를 정해 단계적으로”가 안전합니다.

인덱스 점검과 성능 튜닝을 상징하는 일러스트

  • 미사용 인덱스 정리: 쓰기 성능 개선에 즉효가 있지만, 삭제는 롤백이 어려우니 충분히 관찰 후 진행
  • 누락된 복합 인덱스 추가: WHERE + ORDER BY/ GROUP BY 패턴이 반복되는데 단일 인덱스만 있는 경우
  • 인덱스 폭 줄이기: 너무 긴 VARCHAR 전체 인덱스 대신 prefix index 고려(정확도/카디널리티 확인 필수)
  • PK/클러스터링 고려: InnoDB에서 PK는 물리적 정렬 기준이라, 랜덤 PK는 페이지 분할로 쓰기 부하가 커질 수 있음

추천 흐름은 다음입니다. (1) 소스에서 상위 느린 쿼리 목록을 확보 → (2) 타깃에 동일 워크로드(가능하면 리플레이/스테이징)를 걸어 실행 계획 비교 → (3) 인덱스 추가는 타깃에서 먼저 검증 후 운영 반영. 이렇게 하면 전환 이후 “예상치 못한 쿼리 플랜 변화”를 줄일 수 있습니다.

5) 스키마 개선: 컬럼/타입/Collation 정리와 온라인 DDL 접근

스키마 정리는 마이그레이션과 궁합이 좋지만, 동시에 가장 위험한 파트이기도 합니다. 운영 중 영향 최소화를 위해서는 DDL을 나눠서 진행하고, 온라인 DDL이 가능한지(버전/엔진/작업 종류에 따라 다름)를 먼저 확인해야 합니다.

  • 문자셋/Collation 통일: DB 기본값과 테이블/컬럼 값이 섞여 있으면 정렬/비교 결과가 달라질 수 있음
  • NULL/DEFAULT 정리: 애플리케이션 로직이 기대하는 기본값을 스키마에 명시해 장애 가능성 축소
  • 타입 최적화: INT 과다 사용, 문자열로 저장된 숫자/날짜, 지나치게 큰 VARCHAR 등은 인덱스 효율을 떨어뜨림
  • 대형 테이블 변경은 분리: “컬럼 추가/변경 + 인덱스 변경”을 한 번에 하지 말고 단계적으로

스키마 변경은 가능하면 타깃에서 먼저 적용/검증하고, 전환 직전에는 “최소 변경”만 남기는 방식이 안정적입니다. 또한 전환 뒤에 해야 하는 변경이라면, 트래픽이 낮은 시간대에 배치하고, 실행 전후로 메트릭(응답시간, 락 대기, 버퍼풀 히트율)을 함께 확인하는 게 좋습니다.

6) 전환(Cutover) 체크리스트: 짧게, 되돌릴 수 있게

전환 자체는 짧아야 하고, “문제가 생기면 원복할 수 있어야” 마음이 편합니다. 아래 체크리스트대로 준비하면 cutover 시간을 줄이면서도 사고 확률을 낮출 수 있습니다.

  • 복제 지연 확인: Seconds_Behind_Master(또는 동등 지표)가 0에 가깝게 유지되는지
  • 타깃 성능 사전 검증: 주요 API/배치 쿼리의 실행 시간, 커넥션 수, CPU/I/O 여유
  • 읽기 전용 전환 계획: 소스를 잠시 read_only로 두고 마지막 동기화 후 전환
  • DNS/Endpoint 전환 방식: 앱 설정 변경, VIP, ProxySQL 등 환경에 맞는 방법 확정
  • 롤백 시나리오: 타깃 장애 시 소스로 되돌리는 절차(연결 문자열, 쓰기 재개 순서) 문서화
  • 관측(Observability): slow query log, error log, 시스템 메트릭을 전환 전후로 비교할 수 있게 준비

전환 직후에는 스키마/인덱스를 추가로 만지기보다, 먼저 안정화(에러율/지연/락 대기)부터 확인하는 편이 좋습니다. “전환”과 “개선 작업”을 같은 시간대에 겹치지 않게 잡으면 장애 대응이 훨씬 수월합니다.

마무리

CentOS에서 MariaDB를 온라인으로 마이그레이션할 때는 Replication으로 안전하게 따라붙인 뒤, 전환만 짧게 가져가는 전략이 가장 실용적입니다.

인덱스/스키마 개선은 마이그레이션에 얹기 좋은 작업이지만, 한 번에 몰아치지 말고 타깃에서 먼저 검증하고 단계적으로 적용하는 흐름을 권합니다.