소개

가상 머신상에 호스팅하고 있던 MySQL을 Azure Database로 마이그레이션할 기회가 있었습니다만, 준비 작업에 수고가 걸렸으므로,ToDo로서 정리해 둡니다.

전제

소스
우분투 18.04
MySQL 5.7

타겟
Azure Database for MySQL (ver 5.7)
SKU Standard
Private Link & Private Endpoint

구성

설정 변경이 필요했지만 요구사항의 편의상 다운타임이 허용되지 않기 때문에 마이그레이션용 소스 DB(복제본)를 작성하여 데이터 동기화를 수행했습니다.

할 일

자세한 내용은 여기을 참조하십시오.
이후 포인트 억제하여 소개합니다.

설정 변경
다음 구성을 사용하여 원본 DB의 my.ini(Windows) 또는 my.cnf(Unix) 파일에 대한 바이너리 로깅을 활성화합니다. (요 재부팅)

[mysqld]
...
binlog_format = row
log_slave_updates = 1
...

마이그레이션 사용자 만들기
소스 DB에 대한 마이그레이션 사용자를 준비합니다. ※유저명과 패스워드는 적절히 변경해 주세요

CREATE USER 'dms'@'%' IDENTIFIED BY 'secret';
GRANT REPLICATION SLAVE ON *.* TO 'dms'@'%';
GRANT REPLICATION CLIENT ON *.* TO 'dms'@'%';
GRANT ALL PRIVILEGES ON <migration db>.* TO 'dms'@'%';
FLUSH PRIVILEGES;

대상 DB 인스턴스 만들기
Azure Database를 만듭니다. 자세한 내용은 여기을 참조하십시오.
만들 때 일부 매개 변수를 변경합니다.

innodb_lock_wait_timeout = 1073741824

Private Link & Private Endpoint 설정
여기 필수는 아니지만 Azure Database가 VNet 내에서만 액세스 할 수 있도록 보안 요구 사항이 필요한 경우를 권장합니다. 자세한 내용은 여기을 참조하십시오.

외래 키 해제
소스 DB에 외래 키가 있는지 확인합니다.
쿼리 후반의 ...KCU.REFERENCED_TABLE_SCHEMA = 'SchemaName'... SchemaName은 적절하게 DB 이름으로 변경하십시오.
존재하는 것으로 보이면 추출 결과의 drop 쿼리를 발행하고 해제하십시오.
마이그레이션 완료 후, 다시 외래 키를 설정할 때를 위해 설정(Add) 쿼리를 삼가도록.

SET group_concat_max_len = 8192;
    SELECT SchemaName, GROUP_CONCAT(DropQuery SEPARATOR ';\n') as DropQuery, GROUP_CONCAT(AddQuery SEPARATOR ';\n') as AddQuery
    FROM
    (SELECT
    KCU.REFERENCED_TABLE_SCHEMA as SchemaName,
    KCU.TABLE_NAME,
    KCU.COLUMN_NAME,
    CONCAT('ALTER TABLE ', KCU.TABLE_NAME, ' DROP FOREIGN KEY ', KCU.CONSTRAINT_NAME) AS DropQuery,
    CONCAT('ALTER TABLE ', KCU.TABLE_NAME, ' ADD CONSTRAINT ', KCU.CONSTRAINT_NAME, ' FOREIGN KEY (`', KCU.COLUMN_NAME, '`) REFERENCES `', KCU.REFERENCED_TABLE_NAME, '` (`', KCU.REFERENCED_COLUMN_NAME, '`) ON UPDATE ',RC.UPDATE_RULE, ' ON DELETE ',RC.DELETE_RULE) AS AddQuery
    FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE KCU, information_schema.REFERENTIAL_CONSTRAINTS RC
    WHERE
      KCU.CONSTRAINT_NAME = RC.CONSTRAINT_NAME
      AND KCU.REFERENCED_TABLE_SCHEMA = RC.UNIQUE_CONSTRAINT_SCHEMA
  AND KCU.REFERENCED_TABLE_SCHEMA = 'SchemaName') Queries
  GROUP BY SchemaName;

트리거 해제
마이그레이션시 데이터 무결성 담보를 위해 일시적으로 트리거를 해제합니다. 표시된 결과 내용을 발행합니다.

SELECT Concat('DROP TRIGGER ', Trigger_Name, ';') FROM  information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'your_schema';

LOB 데이터 유형 확인mediumtext / longtext / blob /mediumblob / longblob 형식의 열을 찾아 32KB(32768byte)를 초과하지 않는지 확인합니다. 초과하면 대상 DB에서 잘립니다. 소스 DB에 대해 다음 쿼리에서 데이터의 길이를 확인합니다.

SELECT max(length(foo)) as LEN from hoge;

마이그레이션 프로젝트를 만들 때 마이그레이션 마법사의 마이그레이션 설정 구성 단계에서 LOB에 대한 설정을 변경할 수 있으므로 여기에서 LOB의 데이터 길이를 입력하십시오.

스키마 마이그레이션
소스 DB에서 DB 스키마를 내보냅니다.

mysqldump -h [servername] -u [username] -p[password] --databases [db name] --no-data > [schema file path]
ex) mysqldump -h 192.168.0.4 -u foo -p --databases soruce --no-data > ~/import.dump

내보낸 스키마에 DEFINER가 포함되어 있는지 find 명령 등을 확인하고 존재하는 경우 제외합니다.

ex) sed -i -e 's/DEFINER=`root`@`localhost`//g' [schema file path]

대상 DB로 가져오기

mysql -h [servername] -u [username] -p[password] [database] < [schema file path]
ex) mysql -h hoge.mysql.database.azure.com -u foo -p target < ~/import.dump

기타

대상 DB의 가격 수준 (인스턴스 크기)을 변경할 수 있습니까?
가능했습니다.
당초 비용 억제를 위해 최소 사양(GP 2vCore)으로 타겟을 세웠습니다만, 프로덕션 가동에서는 메모리 최적화 타입으로의 가격 레벨 변경이 필요했습니다.
전환하기 전에 가격 수준을 변경해 보았지만 특히 문제없이 할 수있었습니다.
DMS 측에서 뭔가 오류가 발생했던 흔적은 없었다고 기억합니다.

참고

htps : // / cs. 미 c 로소 ft. 코 m / 자 jp / 아즈레 / dms / 쓰리 아 l mysql 아즈레 my sql
htps : // / cs. 미 c 로소 ft. 코 m / 쟈 jp / 아즈레 / dms / k의 w-이스에 s-t 브 b 쇼쇼 친 g dms