giip
SES 안건 등록
データベース移行移行サイジングロールバックストレージ承認

3TB 규모 데이터베이스를 마이그레이션할 때 계획을 세우는 방법

公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13

結論

3TB 규모의 마이그레이션 계획은 (1) 객체 단위로 실제 크기를 측정하고, (2) 전체 정지/초기 로드+CDC 따라잡기/이중 쓰기 중 어느 것으로 할지를 허용 중단 시간으로부터 정하고, (3) 대표 데이터로 시험 실행해 소요 시간을 실측하고, (4) 정합성 검증 방법을 정하고, (5) 롤백 조건과 복귀 불가 지점을 정의하는 순서로 구성합니다. 소요 시간의 기준값을 먼저 두어서는 안 됩니다. 계획에 올려도 되는 숫자는 자신의 환경에서의 시험 실행으로 얻은 실측값뿐입니다.

この文書の適用条件

対象製品데이터베이스 마이그레이션(MySQL 계열 / SQL Server 계열 등)
確認バージョン크기 측정 SQL은 MySQL 5.7 / 8.0 계열과 SQL Server 2012 이상에서 확인. 마이그레이션 도구 버전은 각 환경에서 확인 필요
適用環境온프레미스, AWS, Azure(및 상호 간 마이그레이션)
必要権限크기 측정은 메타데이터 조회 권한(SQL Server는 `VIEW DATABASE STATE`). 덤프 수집은 대상 스키마의 `SELECT`
実行影響측정 SQL은 영향 없음. 덤프 수집과 시험 로드는 소스·타겟 양쪽에 부하를 줌
再起動측정은 불필요. 전환 시 중단 여부는 선택한 방식에 따라 다름
最終検証日2026-08-13

そのまま実行できるコマンド

MySQL 계열에서 객체 단위 실제 크기 측정하기参照のみ
対象
MySQL 5.7 / 8.0, Aurora MySQL 2.x / 3.x
権限
`information_schema` 조회 권한
変更作業
없음(조회만)
Production実行
가능
-- 対象: MySQL 5.7 / 8.0、Aurora MySQL 2.x / 3.x
-- 権限: information_schema の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    ENGINE,
    TABLE_ROWS                                              AS estimated_rows,
    ROUND(DATA_LENGTH        / 1024 / 1024 / 1024, 2)       AS data_gb,
    ROUND(INDEX_LENGTH       / 1024 / 1024 / 1024, 2)       AS index_gb,
    ROUND(DATA_FREE          / 1024 / 1024 / 1024, 2)       AS free_gb,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024 / 1024, 2) AS total_gb
FROM information_schema.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
  AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;

-- スキーマ単位の合計(全体像の把握用)
SELECT
    TABLE_SCHEMA,
    COUNT(*)                                                     AS table_count,
    ROUND(SUM(DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024 / 1024, 2) AS total_gb
FROM information_schema.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
  AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
GROUP BY TABLE_SCHEMA
ORDER BY total_gb DESC;

`TABLE_ROWS`는 InnoDB에서는 추정값입니다. 행 수를 정확히 알아야 하는 테이블만 `COUNT(*)`로 다시 측정하십시오. `index_gb`의 비율이 높은 테이블은 뒤에서 설명할 "로드 후 인덱스를 재생성" 전략의 효과가 큰 후보입니다.

SQL Server에서 객체 단위 실제 크기 측정하기参照のみ
対象
SQL Server 2012 이상, Amazon RDS for SQL Server, Azure SQL Managed Instance
権限
`VIEW DATABASE STATE`
変更作業
없음(조회만)
Production実行
가능
-- 対象: SQL Server 2012 以降(RDS / Azure SQL Managed Instance を含む)
-- 権限: VIEW DATABASE STATE
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    SCHEMA_NAME(t.schema_id)                                            AS schema_name,
    t.name                                                              AS table_name,
    SUM(CASE WHEN ps.index_id IN (0, 1) THEN ps.row_count ELSE 0 END)   AS row_count,
    SUM(ps.reserved_page_count) * 8.0 / 1024 / 1024                     AS reserved_gb,
    SUM(ps.used_page_count)     * 8.0 / 1024 / 1024                     AS used_gb
FROM sys.dm_db_partition_stats AS ps
INNER JOIN sys.tables AS t
        ON t.object_id = ps.object_id
GROUP BY t.schema_id, t.name
ORDER BY SUM(ps.reserved_page_count) DESC;

페이지 크기 8KB를 전제로 GB로 환산했습니다. `reserved_gb`는 예약된 용량, `used_gb`는 실제 사용량입니다. 차이가 큰 테이블은 단편화나 삭제된 영역을 포함하므로 마이그레이션 후 크기가 소스보다 작아질 수 있습니다(이것도 추정이 아니라 시험 로드로 확인하십시오).

대표 테이블로 시험 덤프를 떠서 소요 시간과 출력 크기 실측하기
対象
MySQL 5.7 / 8.0, Aurora MySQL(mysqldump / mydumper)
権限
대상 스키마에 대한 `SELECT`
変更作業
없음(소스는 조회만). 단 읽기 부하가 발생함
Production実行
부하를 감당할 수 있는 시간대에 실시할 것
# 対象: MySQL 5.7 / 8.0、Aurora MySQL(mysqldump / mydumper)
# 権限: 対象スキーマへの SELECT
# 変更作業: なし(移行元は参照のみ)。ただし読み取り負荷がかかる
# Production 実行: 負荷を許容できる時間帯で実施すること

# 1) 単一テーブルで所要時間を実測する(--no-tablespaces は MySQL 8.0 で
#    PROCESS 権限を要求されるのを避けるため)
time mysqldump \
  --single-transaction \
  --quick \
  --no-tablespaces \
  --host example-rds-endpoint \
  --user sample_user \
  --password \
  SampleDB sample_table \
  | gzip > /var/tmp/sample_table.sql.gz

# 2) 並列ダンプで実測する場合(資格情報はコマンドラインに書かず設定ファイルで渡す)
mydumper \
  --defaults-file /etc/mysql/sample-migration.cnf \
  --database SampleDB \
  --threads 8 \
  --rows 500000 \
  --compress \
  --outputdir /var/tmp/dump-sample

# 3) 出力サイズを確認し、テーブルサイズとの比率を記録する
du -sh /var/tmp/dump-sample

여기서 얻은 "이 테이블은 몇 분 걸렸고 출력은 몇 GB였는지"만이 계획에 올려도 되는 숫자입니다. 1개 테이블의 결과를 전체로 외삽할 때도 행의 너비, 인덱스 수, BLOB 유무가 다른 테이블에서는 비율이 달라지므로, 성격이 다른 대표 테이블을 여러 개 선택해 측정하십시오. `--single-transaction`은 일관된 스냅샷을 얻기 위한 옵션으로, DDL이 동시에 실행되면 일관성이 깨집니다.

마이그레이션 후 정합성 검증하기
対象
MySQL 5.7 / 8.0, Aurora MySQL(소스·타겟 양쪽)
権限
대상 테이블에 대한 `SELECT`
変更作業
없음(조회만). 단 전체 행 읽기로 부하가 발생함
Production実行
중단 중 또는 저부하 시간대에 실시할 것
-- 対象: MySQL 5.7 / 8.0、Aurora MySQL(移行元・移行先の双方で同じSQLを実行する)
-- 権限: 対象テーブルへの SELECT
-- 変更作業: なし(参照のみ)。ただし全行を読むため I/O 負荷がかかる
-- Production 実行: 停止中または低負荷時間帯に実施すること

-- 1) 行数の一致を確認する(最も軽い検証。ここが合わなければ先へ進まない)
SELECT 'sample_table' AS table_name, COUNT(*) AS row_count
FROM SampleDB.sample_table;

-- 2) 主要列の値までを含めた突き合わせ(同一エンジン間の比較に使う)
SELECT
    COUNT(*)                                                   AS row_count,
    SUM(CRC32(CONCAT_WS('|', id, name, DATE_FORMAT(updated_at, '%Y-%m-%d %H:%i:%s')))) AS crc_sum
FROM SampleDB.sample_table;

-- 3) テーブル単位のチェックサム(全行を読む。大きな表では時間がかかる)
CHECKSUM TABLE SampleDB.sample_table EXTENDED;

2)는 소스와 타겟이 동일한 엔진 계열인 경우의 비교에 사용합니다. NULL 처리, 부동소수점 표현, 날짜 형식이 맞지 않으면 일치하지 않으므로 `CONCAT_WS`로 명시적으로 정형화했습니다. 이종 DB 간 마이그레이션에서는 값의 표현 자체가 바뀌므로 행 수 일치와 애플리케이션 관점의 검증(대표 화면·대표 배치의 결과 비교)을 중심으로 하십시오.

마이그레이션 대상의 동결 범위 확인하기(DDL과 배치 전수 조사)参照のみ
対象
MySQL 5.7 / 8.0, Aurora MySQL
権限
`information_schema` 조회 권한
変更作業
없음(조회만)
Production実行
가능
-- 対象: MySQL 5.7 / 8.0、Aurora MySQL
-- 権限: information_schema の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能

-- 1) 直近に定義が変わったテーブル(凍結期間中に変更が入っていないかの確認に使う)
SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_TIME, UPDATE_TIME
FROM information_schema.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
  AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
ORDER BY CREATE_TIME DESC;

-- 2) 二次インデックスの一覧(ロード後に作り直す対象の洗い出し)
SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    INDEX_NAME,
    GROUP_CONCAT(COLUMN_NAME ORDER BY SEQ_IN_INDEX) AS index_columns,
    MAX(NON_UNIQUE)                                 AS non_unique
FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
  AND INDEX_NAME <> 'PRIMARY'
GROUP BY TABLE_SCHEMA, TABLE_NAME, INDEX_NAME
ORDER BY TABLE_SCHEMA, TABLE_NAME, INDEX_NAME;

2)의 결과는 로드 전에 2차 인덱스를 제거하고 로드 후 재생성하는 전략을 취할 경우의 작업 목록 그 자체가 됩니다. 재생성용 DDL을 사전에 생성해 보관해두면 전환 당일에 정의를 다시 떠올릴 필요가 없어집니다. 고유 인덱스(`non_unique = 0`)는 중복 데이터 검출도 겸하므로 제거하는 경우 중복이 들어가지 않는다는 보장을 별도로 마련하십시오.

結果の読み方

意味確認するポイント
TABLE_SCHEMA / TABLE_NAME대상 스키마와 테이블마이그레이션 대상과 제외 대상의 경계를 이 목록 위에서 명시
estimated_rows추정 행 수(InnoDB에서는 통계 기반 근사값)검증의 기준으로 삼으려면 `COUNT(*)`로 실제 수치를 다시 가져옴
data_gb데이터 부분의 크기전송량의 주요 부분. 큰 순서로 시험 실행 대상을 선택
index_gb인덱스 부분의 크기비율이 높은 테이블일수록 로드 후 인덱스를 재생성하는 방식의 효과가 큼
free_gb / reserved-used의 차이예약되었지만 미사용인 영역타겟에서는 해소되는 경우가 많음. 타겟의 필요 용량이 소스의 예약량보다 작아질 수 있음
total_gb데이터와 인덱스의 합계스키마 단위로 합산해 전체의 "실제 크기"를 확정
index_columns(2차 인덱스 목록)인덱스 구성 열로드 후 재생성할 작업 목록이 됨
UPDATE_TIME테이블 정의·데이터 갱신 시각(엔진에 따라 다름)동결 기간 중 예상치 못한 변경이 없었는지 확인에 사용

こういう状況で使います

  • "몇 시간이면 끝나는가"를 질문받았지만 근거 있는 숫자를 내놓을 수 없음
  • 마이그레이션 리허설을 하지 않은 채 일정만 정해져 있음
  • 허용 중단 시간이 정해지지 않았는데 전환 방식 논의가 시작됨
  • 초기 로드는 끝났지만 차등분 따라잡기가 끝나지 않음
  • 타겟의 용량을 소스와 같게 했더니 로드 중에 부족해짐
  • 롤백 판단을 누가 언제 내릴지 정해지지 않음

考えられる原因(可能性の高い順)

  1. 01

    실제 크기를 측정하지 않고 "3TB"라는 총량만으로 계획함

    총량이 같아도 하나의 거대 테이블인지, 중간 규모 테이블이 수천 개인지에 따라 작업 난이도가 완전히 다릅니다. 객체 단위의 크기와 개수를 먼저 확정하십시오.

  2. 02

    소요 시간을 일반적인 기준값으로 추정함

    전송 속도는 회선 대역폭, 스토리지 처리량, 병렬도, 인덱스 유무, 압축 유무에 따라 자릿수 단위로 달라집니다. 다른 곳의 사례값을 자신의 환경에 그대로 적용하면 계획 자체가 성립하지 않습니다.

  3. 03

    허용 중단 시간이 먼저 정해지지 않음

    전환 방식은 허용 중단 시간으로부터 결정됩니다. 중단할 수 있는 시간이 길다면 전체 정지 방식이 가장 단순하고 확실합니다. 역산 없이 방식을 고르면 나중에 작업을 되돌려야 합니다.

  4. 04

    인덱스를 유지한 채로 로드하고 있음

    2차 인덱스를 유지한 일괄 로드는 행을 삽입할 때마다 인덱스 갱신이 발생합니다. 로드 후 일괄 재생성하는 방식과 비교하면 소요 시간이 달라지므로 둘 다 시험 실행으로 비교하십시오.

  5. 05

    검증 방법을 정하지 않고 전환 당일을 맞이함

    "동작하는 것처럼 보인다"는 검증이 아닙니다. 행 수, 값 대조, 애플리케이션 관점 확인 중 어느 것을 어디까지 할지 사전에 합의해 두어야 합니다.

  6. 06

    복귀 불가 지점(point of no return)이 정의되지 않음

    새 환경으로의 쓰기가 시작된 이후에는 단순한 롤백이 불가능해집니다. 어느 시점을 지나면 앞으로 나아갈 수밖에 없는지를 작업 절차에 명시하십시오.

確認手順

  1. 1

    객체 단위로 실제 크기와 개수 측정하기

    参照のみ

    위의 측정 SQL을 실행해 테이블 수, 최대 테이블 크기, 상위 10개가 전체의 몇 퍼센트를 차지하는지 확정합니다.

  2. 2

    허용 중단 시간을 관계자와 확정하기

    参照のみ

    기술적 검토에 앞서 업무상 몇 시간 중단할 수 있는지를 정합니다. 이것이 정해지지 않으면 방식을 정할 수 없습니다.

  3. 3

    성격이 다른 대표 테이블을 선택해 시험 실행하기

    큰 테이블, 행이 넓은 테이블, BLOB을 포함한 테이블, 인덱스가 많은 테이블 등 여러 성격을 선택해 소요 시간을 실측합니다.

  4. 4

    타겟의 실제 용량을 시험 로드로 확인하기

    소스의 사용량과 같아지지 않습니다. 단편화 해소나 스토리지 구조의 차이로 늘거나 줍니다.

  5. 5

    차등분 발생량 측정하기

    参照のみ

    CDC 방식을 취하는 경우 초기 로드 중에 발생하는 변경량이 따라잡기 소요 시간을 결정합니다. 일일 갱신 행 수를 실측하십시오.

  6. 6

    리허설을 운영과 동등한 절차로 1회 이상 진행하기

    절차서의 누락은 리허설에서만 발견됩니다. 소요 시간의 실측값도 여기서 확정됩니다.

対応方法

すぐに実施できる低リスクの対応

  • 대상 전수 조사 끝내기

    参照のみ

    마이그레이션할 테이블, 마이그레이션하지 않을 테이블, 마이그레이션 전에 삭제할 테이블을 구분합니다. 마이그레이션하지 않을 것을 정하는 것만으로 총량이 줄어드는 경우가 드물지 않습니다.

  • 허용 중단 시간으로부터 전환 방식 후보 좁히기

    参照のみ

    장시간 중단할 수 있다면 전체 정지 방식, 짧은 시간만 중단할 수 있다면 초기 로드+CDC 따라잡기, 중단할 수 없다면 이중 쓰기가 후보가 됩니다.

事前検討が必要な変更

  • 시험 실행으로 소요 시간 실측하기

    대표 테이블의 실측값에서 전체를 합산합니다. 기준값이 아니라 실측값만을 계획에 올리십시오.

  • 인덱스와 제약의 처리 방식 정하기

    2차 인덱스와 일부 제약을 로드 후 재생성하는 방식을 실측으로 비교해 채택 여부를 정합니다. 재생성용 DDL은 사전에 생성해 보관합니다.

  • 검증 합격 조건 문서화하기

    参照のみ

    행 수 일치, 주요 테이블의 체크섬 일치, 대표 화면·대표 배치의 결과 일치 등 "무엇이 갖춰지면 전환 완료로 볼 것인가"를 먼저 정합니다.

  • 동결과 공지 계획 세우기

    参照のみ

    스키마 변경·배치·데이터 입력을 언제부터 멈출지, 누구에게 공지할지, 예외 신청을 어떻게 처리할지를 정합니다.

再起動・サービス影響を伴う変更

  • 초기 로드 실시하기

    소스에 읽기 부하, 타겟에 쓰기 부하가 걸립니다. 실측한 소요 시간에 예상치 못한 재실행분을 감안한 여유를 두십시오.

  • 차등 동기화(CDC)를 구성해 따라잡기

    차등 발생량이 처리량을 초과하면 영원히 따라잡지 못합니다. 지연이 줄어들고 있는지 지속적으로 확인합니다.

専門家のレビューが必要な作業

  • 전환(cutover) 실시하기

    専門家レビュー必須

    쓰기 중단 → 차등분 따라잡기 완료 확인 → 검증 → 접속 대상 전환 → 모니터링 강화의 순서로, 각 단계의 판단자와 판단 기준을 정한 뒤 실행합니다.

  • 롤백 판단하기

    専門家レビュー必須

    합격 조건을 만족하지 못한 경우 어디까지 되돌릴지(접속 대상만인지, 데이터도인지)를 사전에 정해 둡니다. 복귀 불가 지점을 지난 경우에는 전진만 선택할 수 있습니다.

!注意事項

  • 소요 시간의 일반적인 기준값은 본 문서에서 제시하지 않습니다. 회선, 스토리지 성능, 병렬도, 인덱스 구성에 따라 자릿수 단위로 달라지기 때문입니다. 계획에 올려도 되는 숫자는 자신의 환경에서의 시험 실행으로 얻은 실측값뿐입니다.
  • 1개 테이블의 실측값을 전체로 외삽할 때, 행의 너비·인덱스 수·BLOB 유무가 다른 테이블에서는 비율이 달라집니다. 성격이 다른 대표 테이블을 여러 개 측정하십시오.
  • 타겟의 필요 용량은 소스의 사용량과 같아지지 않습니다. 단편화 해소로 줄어들 수도, 스토리지 구조의 차이로 늘어날 수도 있습니다. 시험 로드로 확인하십시오.
  • 2차 인덱스를 제거하고 로드하는 경우, 고유 인덱스도 제거하면 중복 데이터가 들어갈 수 있습니다. 중복이 들어가지 않는다는 보장을 별도로 마련하십시오.
  • `CHECKSUM TABLE`과 전체 행의 체크섬 계산은 테이블 전체를 읽습니다. 운영 가동 중에 큰 테이블에 실행하지 마십시오.
  • 복귀 불가 지점을 정의하지 않은 마이그레이션 계획은 문제가 발생했을 때 판단할 수 없습니다. 롤백의 조건·절차·판단자를 일정보다 먼저 정하십시오.
  • 동결 기간 중의 스키마 변경은 이미 로드된 데이터와 타겟의 정의를 어긋나게 만듭니다. 동결 대상과 예외 처리를 문서화하십시오.

バージョン・環境による違い

전환 방식 1: 전체 정지서비스를 멈추고 덤프·로드·검증을 수행한 뒤 재개합니다. 가장 단순하고 검증하기 쉬운 반면, 소요 시간이 그대로 중단 시간이 됩니다. 허용 중단 시간이 길다면 이것이 가장 확실합니다.
전환 방식 2: 초기 로드+CDC 따라잡기가동 중에 초기 로드를 수행하고 그 사이의 차등분을 CDC로 따라잡은 뒤 짧은 중단으로 전환합니다. 중단 시간을 줄일 수 있지만 CDC 구성·모니터링·오류 처리라는 별도 작업이 늘어납니다. 차등 발생량이 처리량을 초과하면 따라잡을 수 없습니다.
전환 방식 3: 이중 쓰기애플리케이션에서 신구 양쪽에 쓰고 일정 기간 병행 가동한 뒤 전환합니다. 중단을 거의 없앨 수 있지만 애플리케이션 개수가 필요하고, 양쪽 시스템의 불일치를 어떻게 처리할지 설계가 가장 어려워집니다.
측정 SQL의 엔진 차이MySQL 계열의 `TABLE_ROWS`와 `DATA_FREE`, SQL Server의 `reserved_page_count`와 `used_page_count`는 각각 의미가 다릅니다. 엔진을 넘어 단순 비교하지 마십시오.

これで解決しない場合に確認すること

  • 네트워크 경로와 실제 유효 대역폭 확인하기

    소스와 타겟 사이의 경로(전용선, VPN, 인터넷)와 실제 유효 대역폭을 실제로 데이터를 흘려보내며 측정하십시오. 카탈로그 값으로는 계획할 수 없습니다.

  • 타겟의 임시 영역과 로그 영역 확인하기

    로드 중에는 트랜잭션 로그나 임시 영역이 평상시보다 크게 늘어납니다. 데이터 영역만 본 용량 계획은 부족해집니다.

  • 로드 중 소스에 대한 영향 확인하기

    읽기 부하로 서비스 쪽이 느려질 수 있습니다. 병렬도를 낮추거나 시간대를 나누거나 레플리카에서 읽는 등의 선택지를 검토하십시오.

  • 문자 집합·콜레이션·시간대 처리 확인하기

    마이그레이션 전후로 값의 표현이 바뀌면 검증에서 불일치가 발생합니다. 마이그레이션 전에 기준을 정하십시오.

  • 권한·접속 정보·모니터링 설정의 이전을 계획에 포함하기

    데이터가 이전되어도 사용자, 권한, 모니터링, 백업 설정은 자동으로 이전되지 않습니다. 이 작업들의 시간도 일정에 포함하십시오.

  • 관계자 공지와 문의 창구 정하기

    동결 기간, 전환 시각, 영향 범위, 문의 대상을 사전에 공지합니다. 당일의 혼란은 대부분 여기서 예방할 수 있습니다.

この文書の根拠と限界

一般的な技術説明

MySQL의 `information_schema.TABLES`와 SQL Server의 `sys.dm_db_partition_stats` 공개 사양, 그리고 `mysqldump` / `mydumper`의 공개된 옵션 사양에 기반한 일반적인 마이그레이션 계획 수립 방법입니다. 소요 시간·전송 속도·용량 비율 등의 수치는 환경에 크게 의존하므로 의도적으로 기재하지 않았습니다. 특정 고객사의 마이그레이션 사례는 포함하지 않습니다.

よくある質問

3TB 마이그레이션에는 시간이 얼마나 걸립니까?

본 문서에서는 숫자를 제시하지 않습니다. 소요 시간은 회선의 실제 유효 대역폭, 소스와 타겟의 스토리지 성능, 병렬도, 인덱스 구성, 압축 유무에 따라 자릿수 단위로 달라지기 때문입니다. 대표 테이블로 시험 실행하고 그 실측값에서 합산하십시오. 다른 곳의 사례값을 자신의 환경에 그대로 적용하면 계획이 성립하지 않습니다.

어떤 전환 방식을 선택해야 합니까?

허용 중단 시간으로부터 결정합니다. 장시간 중단할 수 있다면 전체 정지 방식이 가장 단순하고 검증하기 쉽고, 짧은 시간만 중단할 수 있다면 초기 로드+CDC 따라잡기, 거의 중단할 수 없다면 이중 쓰기가 후보입니다. 나머지 두 방식은 중단 시간을 줄이는 대신 CDC 운영이나 애플리케이션 개수라는 작업이 늘어납니다.

Production에서 실행할 수 있습니까?

크기 측정과 정의 전수 조사 SQL은 조회 전용이므로 운영 환경에서도 실행할 수 있습니다. 시험 덤프와 체크섬 계산은 읽기 부하가 발생하므로 시간대를 선택하십시오. 초기 로드와 전환은 계획된 작업으로서 사전에 합의한 절차로 실시합니다.

인덱스는 로드 전과 후 중 언제 만들어야 합니까?

일반론으로는 결정할 수 없으므로 둘 다 시험 실행으로 비교하십시오. 2차 인덱스를 로드 후 재생성하는 방식이 유리한 경우가 많지만, 재생성 자체에 시간이 걸리므로 총 시간으로 판단해야 합니다. 고유 인덱스를 제거하는 경우에는 중복 데이터가 들어가지 않는다는 보장을 별도로 마련하십시오.

검증은 어디까지 하면 충분합니까?

"무엇이 갖춰지면 완료로 볼 것인가"를 사전에 합의한 내용이 기준입니다. 최소한 전체 대상 테이블의 행 수 일치, 추가로 주요 테이블의 값 대조, 그리고 대표적인 화면·배치의 결과가 마이그레이션 전과 일치하는지를 확인합니다. 전체 값 대조는 시간이 걸리므로 대상과 범위를 정해 실시하십시오.

롤백은 언제까지 가능합니까?

새 환경으로의 쓰기가 시작되기 전까지입니다. 그 이후에는 새 환경에만 존재하는 데이터가 생기기 때문에, 단순히 기존 환경으로 되돌리면 데이터를 잃게 됩니다. 이 경계를 복귀 불가 지점으로 절차서에 명시하고 통과 판단을 누가 할지 정하십시오.

この文書がカバーする質問

  • 대규모 데이터베이스 마이그레이션에 걸리는 시간을 어떻게 추정하는가
  • 데이터베이스 마이그레이션 전환 방식을 선택하는 방법
  • 마이그레이션 후 데이터 정합성을 어떻게 검증하는가
  • 타겟의 스토리지 용량을 어떻게 추정하는가

リスク表示の意味

  • 参照のみデータと設定を変更しません。
  • 影響は限定的ですが、権限と負荷の確認が必要です。
  • 性能・ロック・コストに影響する可能性があります。
  • 障害・データ損失・復旧作業が発生する可能性があります。
  • 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

마이그레이션 계획 자체는 실측과 리뷰를 거듭하면 만들 수 있습니다. 실무에서 놓치기 쉬운 것은 전환 후 몇 주간입니다. GIIP에서는 전환 전에 수집한 주요 지표(대표 쿼리의 실행 시간, 오류율, 스토리지 사용량 추이)를 기준선으로 저장하고, 전환 후 같은 지표를 나란히 놓고 차이를 추적합니다. 차이가 나타난 것만 대응 대상으로 분리하고, 일상적인 비교와 1차 조사는 AI 에이전트가, 롤백이나 구성 변경의 판단은 사람이 하는 분담으로 하고 있습니다.

執筆・技術検証

GIIP プロダクション運用チーム

大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。

関連するナレッジ

関連サービス

3TB급 마이그레이션 계획 리뷰를 요청하기

同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。

3TB급 마이그레이션 계획 리뷰를 요청하기

ナレッジベース一覧へ