giip
SES 안건 등록
TiDB専門家レビュー必須移行バージョン互換性インデックストランザクションサイジング

TiDB에서 Aurora MySQL로 마이그레이션할 때 확인할 항목

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

結論

TiDB에서 Aurora MySQL로 마이그레이션할 때는 "MySQL 호환이니 그대로 동작할 것"이라는 전제를 두지 말고, 번호 부여(`AUTO_INCREMENT`의 비연속 할당과 `AUTO_RANDOM`), 기본 키 구조(클러스터형/비클러스터형, `SHARD_ROW_ID_BITS`), TiDB 고유 구문과 시스템 변수, 트랜잭션 동작, 통계와 인덱스 선택, 문자 집합과 콜레이션, 용량(TiKV와 InnoDB의 필요량 차이)의 7가지를 실제 환경에서 확인하십시오. 동작은 TiDB 버전에 따라 달라지므로, 문서가 아니라 자신의 환경 버전으로 검증하는 것이 전제입니다.

この文書の適用条件

対象製品TiDB(마이그레이션 소스) → Aurora MySQL(마이그레이션 타겟)
確認バージョンTiDB는 버전에 따른 동작 차이가 크므로 반드시 `SELECT TIDB_VERSION();`으로 자신의 환경 버전을 확인한 뒤 각 항목을 검증할 것. 타겟은 Aurora MySQL 3.x(MySQL 8.0 호환)를 가정
適用環境TiDB(셀프 호스트/매니지드) → Amazon Aurora(AWS)
必要権限조사는 `information_schema` 조회 권한과 대상 스키마의 `SELECT`. 마이그레이션 실행에는 덤프 소스의 읽기 권한과 타겟의 쓰기 권한
実行影響조사 SQL은 영향 없음. 초기 로드와 CDC 구성은 소스·타겟 양쪽에 부하를 줌
再起動조사는 불필요. 전환 시 중단 시간은 선택한 방식에 따라 다름
最終検証日2026-08-13

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

소스 TiDB의 버전과 주요 설정 확인하기参照のみ
対象
TiDB(전 버전)
権限
접속 권한
変更作業
없음(조회만)
Production実行
가능
-- 対象: TiDB(バージョンにより出力が異なる)
-- 権限: 接続権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能

-- 1) TiDB のバージョン(VERSION() はMySQL互換の文字列、TIDB_VERSION() はTiDB固有の詳細)
SELECT VERSION() AS mysql_compat_version;
SELECT TIDB_VERSION() AS tidb_version;

-- 2) トランザクションモードと分離レベル
SHOW GLOBAL VARIABLES WHERE Variable_name IN (
    'tidb_txn_mode',
    'transaction_isolation',
    'tidb_constraint_check_in_place',
    'tidb_enable_clustered_index'
);

-- 3) 新しい照合順序フレームワークが有効かどうか
--    (無効な環境では utf8mb4_general_ci の比較挙動がMySQLと異なる)
SELECT VARIABLE_NAME, VARIABLE_VALUE
FROM mysql.tidb
WHERE VARIABLE_NAME = 'new_collation_enabled';

여기서 얻은 버전이 이후 모든 판단의 전제가 됩니다. TiDB는 버전에 따라 기본값과 지원 기능이 바뀌므로, 본 문서의 기술과 자신의 환경 출력이 다르면 자신의 환경 출력을 우선하십시오. `mysql.tidb`나 `tidb_enable_clustered_index`는 버전에 따라 존재하지 않을 수 있습니다(오류가 발생하면 그 기능 자체가 없는 버전으로 판단할 수 있습니다).

테이블 정의에서 TiDB 고유 속성 찾아내기参照のみ
対象
TiDB(전 버전)
権限
대상 스키마의 메타데이터 조회 권한
変更作業
없음(조회만)
Production実行
가능
-- 対象: TiDB(全バージョン)
-- 権限: 対象スキーマのメタデータ参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能

-- 1) 定義そのものを出力し、AUTO_RANDOM / SHARD_ROW_ID_BITS /
--    CLUSTERED・NONCLUSTERED / PRE_SPLIT_REGIONS の有無を目視で確認する
SHOW CREATE TABLE SampleDB.sample_table;

-- 2) 主キーの構造を一覧で確認する(TIDB_PK_TYPE はTiDB独自列。
--    存在しない版ではエラーになるので、その場合は 1) を全テーブル分実行する)
SELECT TABLE_SCHEMA, TABLE_NAME, TIDB_PK_TYPE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'metrics_schema', 'sys')
ORDER BY TABLE_SCHEMA, TABLE_NAME;

-- 3) 主キーの無いテーブル(移行後のCDCで問題になる)
SELECT t.TABLE_SCHEMA, t.TABLE_NAME
FROM information_schema.TABLES t
LEFT JOIN information_schema.KEY_COLUMN_USAGE k
       ON  k.TABLE_SCHEMA    = t.TABLE_SCHEMA
       AND k.TABLE_NAME      = t.TABLE_NAME
       AND k.CONSTRAINT_NAME = 'PRIMARY'
WHERE t.TABLE_TYPE = 'BASE TABLE'
  AND t.TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'metrics_schema', 'sys')
  AND k.COLUMN_NAME IS NULL
ORDER BY t.TABLE_SCHEMA, t.TABLE_NAME;

`AUTO_RANDOM`은 TiDB 고유 기능으로 MySQL에는 동등한 기능이 없습니다. 사용 중인 열은 Aurora MySQL 쪽에서 다른 설계(`BIGINT` 연번, 애플리케이션 번호 부여, UUID 계열 등)로 대체해야 하며, 값의 호환성과 자릿수를 모두 검토하십시오. `SHARD_ROW_ID_BITS`와 `PRE_SPLIT_REGIONS`는 TiKV의 분산 배치를 위한 지정으로, Aurora 쪽에는 대응하는 개념이 없습니다(그대로 무시해도 된다는 것이 아니라, 그 지정이 필요했던 접근 패턴이 마이그레이션 후 어떻게 되는지 검토해야 합니다).

외래 키·생성 열·파티션의 사용 현황 확인하기参照のみ
対象
TiDB(전 버전)
権限
대상 스키마의 메타데이터 조회 권한
変更作業
없음(조회만)
Production実行
가능
-- 対象: TiDB(全バージョン)
-- 権限: 対象スキーマのメタデータ参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能

-- 1) 外部キー定義の有無(定義があっても実際に強制されているかは版に依存する)
SELECT CONSTRAINT_SCHEMA, TABLE_NAME, CONSTRAINT_NAME,
       REFERENCED_TABLE_NAME, UPDATE_RULE, DELETE_RULE
FROM information_schema.REFERENTIAL_CONSTRAINTS
ORDER BY CONSTRAINT_SCHEMA, TABLE_NAME;

-- 2) 生成列(GENERATED COLUMN)
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, EXTRA, GENERATION_EXPRESSION
FROM information_schema.COLUMNS
WHERE GENERATION_EXPRESSION IS NOT NULL
  AND GENERATION_EXPRESSION <> ''
ORDER BY TABLE_SCHEMA, TABLE_NAME;

-- 3) パーティション定義
SELECT TABLE_SCHEMA, TABLE_NAME, PARTITION_NAME, PARTITION_METHOD, PARTITION_EXPRESSION
FROM information_schema.PARTITIONS
WHERE PARTITION_NAME IS NOT NULL
ORDER BY TABLE_SCHEMA, TABLE_NAME, PARTITION_ORDINAL_POSITION;

TiDB는 오랫동안 외래 키 구문을 받아들이면서도 제약을 강제하지 않는 구현이었습니다. 강제되는지 여부는 버전에 따라 다르므로 "정의가 있는가"가 아니라 "실제로 위반 INSERT가 거부되는가"를 자신의 환경에서 시도해 확인하십시오. 강제되지 않았던 경우, Aurora MySQL 쪽에서 외래 키가 활성화되면 지금까지 통과했던 데이터 입력이 실패하게 됩니다.

마이그레이션 대상 데이터량 측정하기(그대로 타겟 추정에 사용하지 말 것)参照のみ
対象
TiDB(전 버전)
権限
`information_schema` 조회 권한
変更作業
없음(조회만)
Production実行
가능
-- 対象: TiDB(全バージョン)
-- 権限: information_schema の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    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,
    TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
  AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'metrics_schema', 'sys')
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;

TiDB의 `TABLE_ROWS`와 `DATA_LENGTH`는 통계 정보에 기반한 추정치입니다. TiKV는 여러 레플리카를 유지하고 압축도 수행하므로, 이 값을 그대로 Aurora(InnoDB)의 필요 스토리지로 사용할 수 없습니다. 타겟의 용량은 대표적인 테이블을 실제로 로드해 실측한 비율로 추정하십시오.

초기 로드용 덤프 가져오기
対象
TiDB(Dumpling)
権限
덤프 대상 스키마에 대한 `SELECT`(TiDB 쪽)
変更作業
없음(소스는 조회만). 단 읽기 부하가 발생함
Production実行
부하를 감당할 수 있는 시간대에 실시할 것
# 対象: TiDB(Dumpling によるダンプ)
# 権限: ダンプ対象スキーマへの SELECT(TiDB側)
# 変更作業: なし(移行元は参照のみ)。ただし読み取り負荷がかかる
# Production 実行: 負荷を許容できる時間帯で実施すること

# まず1テーブルだけダンプして所要時間と出力サイズを実測する
tiup dumpling \
  --host 192.0.2.10 \
  --port 4000 \
  --user sample_user \
  --filetype sql \
  --threads 8 \
  --rows 200000 \
  --filter 'SampleDB.sample_table' \
  --output /var/tmp/dump-sample

# 出力サイズと所要時間を確認する(この実測値だけが計画の根拠になる)
du -sh /var/tmp/dump-sample

먼저 일부 테이블로 실측한 뒤 거기서 전체를 추정합니다. `--rows`를 지정하면 테이블을 분할해 병렬로 출력할 수 있습니다. `--threads`를 높이면 소스의 부하가 올라가므로 운영 가동 중에는 낮은 값부터 시작하십시오. 옵션명은 Dumpling 버전에 따라 바뀔 수 있으므로 `tiup dumpling --help`로 확인하십시오.

차등 동기화(CDC) 구성 검토하기
対象
TiCDC(TiDB 쪽) 또는 AWS DMS
権限
TiCDC의 운영 권한, 또는 DMS의 IAM 권한과 엔드포인트 자격 증명
変更作業
있음(변경 데이터 전달 구성. 소스·타겟 양쪽에 영향)
Production実行
운영 소스에 대한 설정 변경. 사전 검증과 롤백 절차 필수
# 対象: TiCDC(TiDB側)または AWS DMS
# 権限: TiCDC の操作権限、または DMS の IAM 権限とエンドポイント資格情報
# 変更作業: あり(変更データ配信の構成)
# Production 実行: 本番ソースへの設定変更。事前検証と切り戻し手順を用意してから実施

# TiCDC で MySQL 互換のシンク(= Aurora MySQL)へ変更を流す例。
# CLI のオプション名はTiDB/TiCDCのバージョンで変わる(--pd と --server など)ため、
# 必ず自環境のバージョンのドキュメントで確認すること。
tiup ctl cdc changefeed create \
  --server "http://192.0.2.10:8300" \
  --changefeed-id "example-changefeed" \
  --sink-uri "mysql://sample_user@example-rds-endpoint:3306/"

# 作成後は状態と遅延を確認する
tiup ctl cdc changefeed list --server "http://192.0.2.10:8300"

TiCDC의 CLI는 버전 간에 옵션명이 바뀌어 왔습니다(`--pd`에서 `--server`로의 변경 등). 여기 적힌 형태를 그대로 쓰지 말고 자신의 환경 버전의 문서에 맞추십시오. AWS DMS를 소스 TiDB에 대해 사용하는 경우, TiDB가 DMS의 소스로 지원되는지, 어떤 모드(풀 로드만/CDC 포함)로 사용할 수 있는지를 실제로 사용할 DMS 버전에서 확인하십시오(본 문서에서는 단정하지 않습니다). 비밀번호는 명령줄에 직접 쓰지 말고 환경 변수나 설정 파일을 사용하십시오.

結果の読み方

意味確認するポイント
tidb_versionTiDB의 실제 버전모든 호환성 판단의 전제. 문서보다 자신의 환경 버전을 우선
tidb_txn_mode트랜잭션 모드(낙관/비관)낙관이면 커밋 시 충돌 오류를 반환한다는 전제로 앱이 작성되었을 가능성
new_collation_enabled새로운 콜레이션 프레임워크 활성화 여부비활성화면 utf8mb4 계열 콜레이션의 비교 동작이 MySQL과 다름. 마이그레이션 후 중복 판정이 바뀔 수 있음
TIDB_PK_TYPE기본 키가 클러스터형인지 여부클러스터형을 전제한 성능 특성이 Aurora 쪽에서 재현된다는 보장은 없음
estimated_rows통계 정보에 기반한 추정 행 수실제 수치가 아님. 검증용 `COUNT(*)`와 대조
data_gb / index_gbTiDB 쪽에서 보고되는 데이터·인덱스 크기TiKV의 복제·압축을 포함하므로 Aurora의 필요 용량으로 그대로 사용할 수 없음
REFERENCED_TABLE_NAME외래 키의 참조 대상정의 여부가 아니라 실제로 강제되는지를 시험해 확인
GENERATION_EXPRESSION생성 열의 식함수 지원 현황이 타겟과 일치하는지 개별적으로 확인

こういう状況で使います

  • TiDB에서 동작하던 SQL이 Aurora MySQL 검증 환경에서 오류가 됨
  • 마이그레이션 후 번호 부여의 연속성이 바뀌어 애플리케이션 쪽 예상과 어긋남
  • 같은 인덱스가 있는데도 마이그레이션 후에만 실행 계획이 바뀌어 느려짐
  • 외래 키 위반 데이터가 이미 존재해서 타겟에 입력할 수 없음
  • 타겟의 스토리지 추정치가 소스의 보고값과 크게 어긋남
  • 문자열의 비교·정렬 결과가 마이그레이션 전후로 바뀜

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

  1. 01

    `AUTO_INCREMENT`의 할당 방식이 다름

    TiDB는 각 노드에 번호 부여 범위를 일괄 할당하기 때문에 번호가 연속되지 않을 수 있습니다. "ID의 대소=삽입 순서"를 전제한 애플리케이션은 마이그레이션 전후 어느 쪽이든 재검토가 필요합니다. 구체적인 동작은 버전과 설정에 따라 다르므로 자신의 환경에서 연번성을 실측하십시오.

  2. 02

    `AUTO_RANDOM`에 상응하는 기능이 MySQL에 없음

    핫스팟 회피를 위한 TiDB 고유 기능입니다. Aurora MySQL로 마이그레이션할 때는 값 생성 방식 자체를 다시 설계해야 합니다. 기존 데이터의 ID 값을 그대로 가져올 수 있는지도 함께 확인하십시오.

  3. 03

    클러스터형 기본 키의 전제가 다름

    InnoDB는 기본 키로 클러스터화되는 것이 기본이지만, TiDB에서는 클러스터형·비클러스터형을 선택할 수 있습니다. 비클러스터형 테이블은 마이그레이션 후 접근 패턴별 성능 특성이 바뀝니다.

  4. 04

    트랜잭션 동작이 다름

    낙관적 트랜잭션에서는 커밋 시 충돌이 감지되고, 비관적 트랜잭션에서는 실행 시점에 락을 잡습니다. 어느 쪽으로 동작했는지에 따라 마이그레이션 후의 락 대기나 오류 발생 방식이 달라집니다.

  5. 05

    TiDB 고유 구문·시스템 변수·힌트를 사용 중

    `TIDB_`로 시작하는 시스템 변수, TiDB 고유 옵티마이저 힌트, `ADMIN` 계열 관리 명령은 MySQL에서 동작하지 않습니다. 애플리케이션과 배치의 SQL을 전문 검색해 찾아내십시오.

  6. 06

    통계와 인덱스 선택 방식이 다름

    옵티마이저가 다른 구현인 이상, 같은 인덱스 구성이라도 선택되는 실행 계획이 달라질 수 있습니다. 마이그레이션 후 "같은 SQL인데 느려짐"은 예상 범위 내로 두고, 대표 쿼리의 실행 계획을 타겟에서 다시 확인하는 것을 전제로 하십시오.

  7. 07

    스토리지 구조가 다름

    TiKV는 레플리카를 가지며 압축도 수행합니다. InnoDB와는 전제가 다르므로 소스의 사용량에서 타겟의 필요 용량을 기계적으로 환산할 수 없습니다.

確認手順

  1. 1

    TiDB의 버전과 주요 설정 가져오기

    参照のみ

    `TIDB_VERSION()`, `tidb_txn_mode`, 콜레이션 프레임워크 상태를 확인합니다. 이후의 모든 판단은 이 결과를 전제로 합니다.

  2. 2

    전체 테이블의 `SHOW CREATE TABLE` 저장하기

    参照のみ

    TiDB 고유 속성은 정의문에만 나타나는 것이 있습니다. 전량을 저장하고 `AUTO_RANDOM` / `SHARD_ROW_ID_BITS` / `NONCLUSTERED`를 검색합니다.

  3. 3

    애플리케이션 SQL에서 TiDB 고유 요소 전문 검색하기

    参照のみ

    `TIDB_`, 고유 힌트, `ADMIN` 명령을 검색합니다. DB 쪽에서는 보이지 않으므로 코드 쪽에서 찾아내야 합니다.

  4. 4

    외래 키가 실제로 강제되는지 검증 환경에서 시험하기

    위반하는 INSERT를 실행해 오류가 발생하는지 확인합니다. 정의 여부만으로는 판단할 수 없습니다.

  5. 5

    대표 테이블을 타겟에 시험 로드해 용량 비율 실측하기

    이 실측값만이 타겟 스토리지 추정의 근거가 됩니다.

  6. 6

    대표 쿼리를 타겟에서 실행해 실행 계획과 소요 시간 비교하기

    소스와 같은 성능이 나온다는 보장은 없습니다. 차이가 난 쿼리를 개별적으로 대응할 시간을 계획에 포함하십시오.

対応方法

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

  • 버전을 확정하고 차이 항목을 목록화하기

    参照のみ

    "TiDB이기 때문"이 아니라 "이 버전의 TiDB이기 때문"으로 판단합니다. 차이 목록이 마이그레이션 계획의 뼈대가 됩니다.

  • 마이그레이션 대상과 제외 대상을 먼저 나누기

    参照のみ

    임시 테이블이나 분석용 대용량 테이블을 마이그레이션 대상에서 제외할 수 있다면 초기 로드의 부담이 크게 줄어듭니다.

事前検討が必要な変更

  • `AUTO_RANDOM` 열의 설계 대체하기

    타겟에서의 번호 부여 방식(연번, 애플리케이션 번호 부여, UUID 계열)을 정하고 기존 값의 이전 가능 여부와 자릿수를 확인합니다. 애플리케이션 쪽 변경을 수반합니다.

  • 기본 키가 없는 테이블에 키 준비하기

    CDC로 차등 동기화하는 경우 기본 키가 없는 테이블은 적용 오류의 원인이 됩니다. 마이그레이션 전에 키를 정의하십시오.

  • 대표 쿼리의 실행 계획을 타겟에서 다시 확인하기

    타겟에서 인덱스 추가·변경이 필요하다는 전제로 검증 기간을 계획에 확보합니다.

  • 문자 집합과 콜레이션을 타겟 기준으로 통일하기

    콜레이션 차이는 비교 결과를 바꿉니다. utf8mb4화 확인 항목은 관련 문서를 참조하십시오.

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

  • 초기 로드 실시하기

    Dumpling 등으로 덤프해 타겟에 로드합니다. 소요 시간은 반드시 샘플 실측으로 추정하십시오.

  • 차등 동기화(TiCDC / DMS) 구성하기

    운영 소스에 대한 설정 추가가 됩니다. 지연 모니터링 방법과 롤백 절차를 정한 뒤 실시하십시오.

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

  • 전환(cutover) 실시하기

    専門家レビュー必須

    쓰기 중단, 차등분 따라잡기 확인, 정합성 검증, 접속 대상 전환, 롤백 판단의 순서와 담당을 정한 뒤 실시합니다. 이 부분은 자동화가 아니라 사전 합의된 절차와 사람의 판단으로 진행하는 영역입니다.

!注意事項

  • TiDB의 동작은 버전에 따라 달라집니다. 본 문서의 기술과 자신의 환경 출력이 다르면 반드시 자신의 환경 출력을 우선하십시오.
  • "MySQL 호환"은 "동일"이 아닙니다. 구문이 통과하는 것과 같은 결과·같은 성능이 나오는 것은 별개입니다.
  • TiDB 쪽의 `DATA_LENGTH`를 Aurora의 필요 스토리지로 그대로 환산하지 마십시오. TiKV는 레플리카와 압축을 전제로 한 값입니다.
  • 외래 키는 정의가 있어도 강제되지 않을 수 있습니다. 타겟에서 강제되게 되면 기존 데이터 입력이나 기존 처리가 실패할 수 있습니다.
  • 마이그레이션 소요 시간은 본 문서에서 제시하지 않습니다. 테이블 구성·데이터량·네트워크·병렬도에 따라 달라지므로 반드시 샘플 실측으로 추정하십시오.
  • 전환(cutover)은 되돌리기 어려운 작업입니다. 롤백 가능한 지점(point of no return)을 사전에 정의하고 판단자를 정한 뒤 실시하십시오.

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

TiDB 버전 차이클러스터형 기본 키의 기본값, 콜레이션 프레임워크, 외래 키 강제, TiCDC의 CLI 옵션 등은 모두 버전에 따라 다릅니다. 단정적인 기술은 피하고 `SELECT TIDB_VERSION();`의 결과에 대응하는 공식 문서를 참조하십시오.
타겟이 Aurora MySQL 3.x(MySQL 8.0 호환)인 경우콜레이션 기본값이 `utf8mb4_0900_ai_ci` 계열이 되므로 소스의 콜레이션과 비교 동작이 달라질 수 있습니다. 고유 제약이 있는 열에서 중복 판정이 바뀌지 않는지 검증하십시오.
타겟이 Aurora MySQL 2.x(MySQL 5.7 호환)인 경우MySQL 8.0에서 추가된 구문(윈도우 함수, CTE 등)을 TiDB 쪽에서 사용했다면 타겟에서 동작하지 않습니다. SQL 전수 조사가 필요합니다.

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

  • 애플리케이션의 드라이버와 타임아웃 설정 확인하기

    접속 대상이 바뀌면서 재접속이나 타임아웃의 동작이 바뀔 수 있습니다.

  • 분석계 워크로드의 행선지 정하기

    TiDB에서 분석계 쿼리를 함께 돌렸다면 Aurora 단독으로는 같은 성능 특성이 나오지 않을 수 있습니다. 읽기 전용 인스턴스나 별도 기반 이용을 검토하십시오.

  • 배치 처리의 병렬도와 실행 시간 재측정하기

    스토리지 구조가 바뀌므로 같은 병렬도가 최적이라는 보장은 없습니다.

  • 운영 절차(백업, 모니터링, 권한 관리)를 타겟용으로 다시 만들기

    TiDB용 절차를 그대로 쓸 수 없습니다. 마이그레이션 계획에 운영 절차 작성을 포함하십시오.

  • 롤백 조건과 절차 확인하기

    어느 시점까지 되돌릴 수 있는지, 되돌릴 경우 무엇을 버리는지를 전환 전에 문서화하십시오.

この文書の根拠と限界

一般的な技術説明

TiDB와 MySQL(Aurora MySQL)의 공개된 사양상의 차이와 일반적인 이종 DB 간 마이그레이션 검증 절차에 기반합니다. TiDB는 버전에 따른 동작 차이가 크므로 본 문서는 "무엇을 확인해야 하는지"를 보여주는 것이며, 개별 동작을 단정하는 것은 아닙니다. 특정 고객사의 마이그레이션 사례 및 소요 시간 실적값은 포함하지 않습니다.

よくある質問

TiDB는 MySQL과 호환되므로 그대로 마이그레이션할 수 있습니까?

반드시 그대로 되는 것은 아닙니다. 호환되는 것은 연결 프로토콜과 대부분의 SQL 구문이며, 번호 부여 동작, 기본 키 구조, 트랜잭션 동작, 통계와 인덱스 선택, 스토리지 전제는 각각 다릅니다. 구문이 통과하는 것과 같은 결과·같은 성능이 나오는 것은 별개 문제로 보고 항목별로 검증하십시오.

AUTO_RANDOM을 사용하는 열은 어떻게 해야 합니까?

MySQL에는 동등한 기능이 없으므로 번호 부여 방식 자체를 다시 설계해야 합니다. 연번, 애플리케이션 번호 부여, UUID 계열 중 어느 것으로 할지 정하고, 기존 ID 값을 그대로 가져올 수 있는지, 자릿수가 애플리케이션 쪽 예상에 들어맞는지 확인하십시오.

타겟의 스토리지는 얼마나 필요합니까?

소스의 보고값으로는 결정할 수 없습니다. TiKV는 레플리카를 유지하고 압축도 수행하므로 InnoDB와는 전제가 다릅니다. 대표적인 테이블을 실제로 타겟에 로드하고 그 비율로 전체를 추정하십시오.

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

조사용 SQL은 모두 조회 전용이므로 운영 중인 TiDB에서도 실행할 수 있습니다. Dumpling에 의한 덤프는 읽기 부하가 발생하므로 시간대 조정이 필요하고, TiCDC나 DMS 구성은 운영 소스에 대한 설정 변경에 해당합니다. 전환은 사전에 합의한 절차에 따라 실시하십시오.

외래 키는 어떻게 됩니까?

TiDB에서는 정의되어 있어도 실제로는 강제되지 않는 경우가 있습니다. 강제되는지 여부는 버전에 따라 다르므로 위반 데이터를 입력해 실제 동작을 확인하십시오. 강제되지 않았던 경우, 타겟에서 외래 키가 활성화되면 기존 처리가 실패할 수 있습니다.

결과를 어떻게 판단합니까?

체크리스트의 각 항목을 "차이 없음", "애플리케이션 변경 필요", "설계 변경 필요"의 3가지로 분류합니다. 설계 변경이 하나라도 있으면 마이그레이션은 데이터 이전이 아니라 애플리케이션 개수를 포함하는 프로젝트가 됩니다. 일정은 그 전제로 잡으십시오.

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

  • MySQL 호환 DB 간 인덱스 차이를 어떻게 확인하는가
  • TiDB의 AUTO_INCREMENT가 연속되지 않는 이유를 알고 싶다
  • TiDB에서 RDS로 마이그레이션할 때 데이터량 추정
  • TiDB의 외래 키는 MySQL과 동일하게 동작하는가

リスク表示の意味

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

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エージェントと人間の専門家が継続的に監視・運用しています。

関連するナレッジ

関連サービス

TiDB 마이그레이션 평가를 요청하기

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

TiDB 마이그레이션 평가를 요청하기

ナレッジベース一覧へ