개요
Ncloud(네이버 클라우드)의 Database Migration Service는 다양한 환경의 데이터베이스를 클라우드 환경으로 손쉽게 마이그레이션하도록 도와주는 서비스로 여기서는 Public 환경의 [MariaDB]를 Private 환경의 [Cloud DB for MySQL 8.0]으로 마이그레이션하는 방법에 대해 정리해보겠습니다.
서비스에서 제공하는 기능
- 마이그레이션의 단계별 작업 자동화: Migration 작업을 생성하여 마이그레이션에 필요한 단계별 작업 자동화
- Endpoint 관리 기능: 손쉽게 Source DB Endpoint 생성 및 관리 가능
- 연결 테스트 기능: 마이그레이션 실행 전 Source DB와 Target DB 간 연결 테스트 진행
- 마이그레이션 작업 내역 모니터링: 마이그레이션 작업 상태와 내역 조회 가능
지원 데이터베이스
Database Migration Service는 MySQL 데이터베이스 간 마이그레이션을 지원합니다.
- Major 버전이 동일한 데이터베이스 간의 마이그레이션이 권장됩니다.
- Source DB는 MariaDB도 가능합니다.
- Target DB는 MySQL만 가능합니다.
⁃ 마이그레이션이 실패했을 경우에는 MariaDB MySQL 5.7 MySQL 8.0 이렇게 2단계로 마이그레이션 하는 방법을 시도해보시기 바랍니다.
상세 설정 지원 여부
Source DB의 상세 설정에 따른 지원 여부는 다음과 같습니다.
지원 항목
- 데이터베이스, TABLE의 캐릭터셋(CharacterSet): euckr, utf8(utf8mb3), utf8mb4 지원
- Table, View, Stored Procedure, Function, Trigger 마이그레이션 지원
미지원 항목
- TABLE ENGINE: MyISAM, BLACKHOLE, FEDERATED, ARCHIVE 미지원
- 사용자 계정 정보, MariaDB Config 항목, Event 마이그레이션 미지원
마이그레이션 진행 구조
마이그레이션은 Target DB Source DB로 접근하여 DB 데이터를 가져오는 방식으로 진행됩니다.
또한 작업 진행 단계는 다음과 같습니다.
- [Source DB]에서 [Export]
- [Target DB]로 [Import]
- 두 DB 간의 Replication 완료 상태
- 마이그레이션 작업 완료
서비스 점검
마이그레이션 작업을 진행할 때 서비스 점검을 언제할 것인가가 중요한 고려사항이 됩니다. 물론 가장 안전한 방법은 마이그레이션 작업 전에 서비스 점검을 시작하는 것이지만, DB의 용량이 클 경우는 [Export], [Import] 각각 몇 시간씩 소요될 수 있는데, 오랜 시간 서비스 점검을 하려면 부담이 될 수 밖에 없습니다.
그러므로 오랜 시간 동안 서비스 점검을 하기 어려울 경우 다음과 같이 진행하면 되겠습니다.
마이그레이션에서 [Export], [Import] 작업이 끝나면 두 DB간의 Replication 상태가 유지되는데 이때는 [Source DB]에 새로운 데이터가 추가되면 자동으로 [Target DB]로 복제가 됩니다. 그러므로 두 DB 간의 Replication이 완료 상태에서 서비스 점검을 시작하고 최종 마이그레이션 작업이 완료된 후에 서비스 점검을 종료하면 됩니다.
- [Source DB]에서 [Export]
- [Target DB]로 [Import]
- 두 DB 간의 Replication 상태
- 서비스 점검 시작
- 마이그레이션 작업 완료
- 서비스 점검 종료
테스트 환경
Source DB는 Ncloud(네이버 클라우드) 외부에 위치한 경우가 많을 것으로 예상되므로 다음과 같은 사항들을 가정하고 테스트 환경을 준비해보겠습니다.
- Source DB와 Target DB가 사설 네트워크로 접근이 불가능한 서로 다른 네트워크 환경에 존재한다.
- Source DB는 외부에서 공인 IP로 접근 가능한 Public 네트워크 환경에 존재한다.
- Target DB는 외부에서 접근이 불가능한 Private 네트워크 환경에 존재한다.
- Target DB는
NAT Gateway를 통해서 Source DB에 접근한다.
DB 버전 정보
- Source DB: CentOS 7.8, MariaDB 10.4.31
- Target DB: Cloud DB for MySQL 8.0.32
-
⁃ Source DB
-
⁃ Target DB
Source DB 정보 확인
테스트에 사용할 Source DB의 버전, Database, DB User 등의 정보를 확인해보겠습니다.
-
⁃ MariaDB 버전
테스트에 사용할 DB는 아래에서 확인할 수 있듯이 MariaDB 5.7.43입니다.
-
⁃ Database
테스트를 위해 testdb1, testdb2 이렇게 2개의 DB를 생성했습니다.
-
⁃ 계정
테스트를 위한 abcd1, abcd2 이렇게 2개의 DB User를 생성했습니다.
-
⁃ Table
테스트용 Database에 sampletable1, sampletable2 이렇게 각각 테이블을 1개씩 생성했습니다.
-
⁃ Procedure
테스트용 Database testdb2에 new_procedure2라는 이름의 Procedure를 생성했습니다.
Source DB 사전 설정
마이그레이션 전용 DB User 생성
마이그레이션을 위한 전용 유저 즉, Target DB에서 Source DB로 접속할 때 사용할 DB User를 아래와 같이 생성합니다.
- 패스워드는 최소 8자 이상, 최대 21 자까지만 입력이 가능합니다.
영문 / 특수문자 / 숫자가 포함되어야 합니다.
` & + \ “ ‘ / 스페이스 는 패스워드로 사용할 수 없습니다. - 기본 시스템DB를 제외한 사용자가 추가로 생성한 모든 데이터베이스에 대해 권한을 부여합니다.
CREATE USER 'migration_test'@'%' IDENTIFIED BY '[패스워드]';
GRANT RELOAD, PROCESS, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'migration_test'@'%';
GRANT SELECT ON mysql.* TO 'migration_test'@'%';
GRANT SELECT, SHOW VIEW, LOCK TABLES, TRIGGER ON [사용자 생성 DB].* TO 'migration_test'@'%';
FLUSH PRIVILEGES;
- 위쪽에서 Source DB에 테스용으로 [testdb1], [testdb2] 이렇게 2개를 데이터베이스가 존재하므로 두 개의 데이터베이스 각각에 대해 권한을 부여했습니다.
Character Set 점검
Target DB로 생성되는 Cloud DB for MySQL은 [utf8, utf8mb4, euckr] Character Set만 지원합니다.
Source DB에 이 외의 설정으로 되어 있다면 Character Set을 변경 후 마이그레이션을 진행해야 합니다.
- Character Set 점검 쿼리
SELECT character_set_name
FROM information_schema.TABLES T, information_schema.COLLATION_CHARACTER_SET_APPLICABILITY CCSA
WHERE CCSA.collation_name = T.table_collation
AND TABLE_SCHEMA NOT IN ( 'information_schema', 'mysql', 'performance_schema', 'sys' )
AND CCSA.character_set_name NOT IN ( 'utf8', 'utf8mb4', 'euckr' );
SELECT DEFAULT_CHARACTER_SET_NAME
FROM information_schema.SCHEMATA T
WHERE SCHEMA_NAME NOT IN ( 'information_schema', 'mysql', 'performance_schema', 'sys' )
AND DEFAULT_CHARACTER_SET_NAME NOT IN ( 'utf8', 'utf8mb4', 'euckr');
- Character Set 변경 쿼리 예시
ALTER DATABASE [데이터베이스명] CHARACTER SET utf8;
ALTER DATABASE [데이터베이스명] CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE [테이블명] CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
sql_mode 설정 점검
MariaDB에서 지원하는 sql_mode=’NO_AUTO_CREATE_USER’ 설정은 MySQL 8.0 버전에서는 지원하지 않기 때문에, Source DB에서 사용된 곳이 있으면 찾아서 해당 옵션을 제거해야 합니다.
sql_mode 설정 점검 쿼리
Procedure, Function 등의 ROUTINE과 TRIGGER에서 사용되므로 아래 쿼리로 [NO_AUTO_CREATE_USER] 옵션이 사용된 곳이 있는지 점검합니다.
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE
FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('sys','mysql');
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, sql_mode
FROM information_schema.triggers
WHERE TRIGGER_SCHEMA NOT IN ('sys','mysql');
- 테스트용 Source DB에서 점검 쿼리를 실행해보면 아래와 같이 [testdb2]의 [new_procedure2]에 [NO_AUTO_CREATE_USER] 옵션이 적용되어 있는 것을 확인할 수 있습니다.
sql_mode 호환성 이슈 조치 방법
Procedure, Function, Trigger의 Dump 파일을 생성하고 [NO_AUTO_CREATE_USER] 옵션을 제거한 후 다시 적용하면 됩니다.
- Procedure, Function, Trigger 에 대해서만 drop 및 create 구문이 생성된 sql 파일 생성
~# mariadb-dump -u {사용자명} -p --routines --triggers --no-create-info --no-data --no-create-db --add-drop-trigger --databases {사용자 DB} > backup.sql
- backup.sql 파일내 NO_AUTO_CREATE_USER 구문 모두 제거
해당 옵션을 일일이 찾아서 제거하기 힘드니 vim 에디터에서 [NO_AUTO_CREATE_USER] 문자를 찾아서 제거하는 명령을 실행합니다.
경우에 따라서는 Dump 파일에 [NO_AUTO_CREATE_USER] 옵션이 포함되지 않는 경우도 있습니다. 이때는 걱정말고 Dump 파일을 그냥 그대로 적용하면 됩니다.
vim 명령: %s /NO_AUTO_CREATE_USER,//g
원본 예시: SET sql_mode = 'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
수정 예시: SET sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'
- 적용하기
수정된 Dump 파일을 Source DB에 적용합니다.
~# mariadb -u {사용자명} -p {사용자 DB} < backup.sql
sql_mode 설정 변경 확인
설정이 제대로 변경되었는지 점검 쿼리로 다시 확인해보겠습니다.
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE
FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('sys','mysql');
- 아래 스샷처럼 [NO_AUTO_CREATE_USER] 옵션이 사라진 것을 확인할 수 있습니다.
바이너리 로그 설정
Source DB의 바이너리 로그 설정 중에서, [server_id] 값이 설정되어 있는지와 [log_bin]이 ON 상태로 설정되어 있지 확인 후 설정되어 있지 않다면 설정 후에 진행해야 합니다.
현재 설정 확인
아래 쿼리를 사용해 현재 설정 값을 확인합니다.
show variables like 'server_id';
show variables like 'log_bin';
- 현재 테스트용 Source DB는 [server_id]는 설정되어 있고, [log_bin]은 설정되어 있지 않은 상태입니다.
설정 변경
MariaDB의 환경 설정 파일 [server.cnf]를 열어서 아래 값을 추가하고, MariaDB 데몬을 재시작합니다.
~# vim /etc/my.cnf.d/server.cnf
log-bin
log-basename = mariadb
binlog-format = mixed
character-set-server = utf8
~# systemctl restart mariadb
변경 설정 확인
설정 변경 후에 확인해보면 아래와 같이 [server_id] 값이 설정되어 있고, [log_bin]이 ON 상태로 변경된 것을 알 수 있습니다.
Target DB 사전 설정
위에서 [Source DB]의 사전 설정이 끝났으므로 이제 [Target DB]의 사전 설정이 필요한 항목을 확인해보겠습니다.
DEFINER 계정 확인
[Source DB]에 [Procedure], [Function], [VIEW] 등이 존재한다면 이 때 사용된 DB User 즉, [DEFINER] 계정을 [Target DB]에도 미리 추가 생성해 두어야 마이그레이션을 진행할 수 있습니다.
아래 쿼리는 [Procedure], [Function], [VIEW] 등을 생성할 때 사용된 [DEFINER] 계정을 확인하는 쿼리입니다.
SELECT DEFINER FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN ( 'information_schema', 'mysql', 'performance_schema', 'sys' ) AND SECURITY_TYPE = 'DEFINER';
SELECT DEFINER FROM information_schema.VIEWS
WHERE table_schema NOT IN ( 'information_schema', 'mysql', 'performance_schema', 'sys' ) AND SECURITY_TYPE = 'DEFINER' ;
- 위에서 [Source DB]에 테스트 환경을 설정하면서 [Procedure]를 하나 생성했었는데 그때 사용된 [DEFINER] 계정을 확인할 수 있었습니다. 여기서 확인된 DB User를 [Target DB]에 미리 추가 생성해 두어야 합니다.
DEFINER 계정 추가
[Target DB]를 선택하고 [DB 관리] - [DB User 관리] 메뉴를 선택합니다.
- DB User 관리 화면에서 위에서 확인했던 [DEFINER] 계정을 DDL 권한으로 설정해서 추가하고 저장합니다.
접근 권한 설정
[Source DB], [Target DB] 양쪽의 사전 설정을 모두 완료했으면, 다음으로는 양쪽 DB간의 접근 권한을 설정해야 합니다.
앞에서도 설명했지만 마이그레이션은 Target DB Source DB로 접근하게 됩니다.
NAT Gateway 생성
현재 [Target DB]는 [Private] 네트워크 환경에 위치해 있으므로 [Source DB]로 접근하기 위해서는 [NAT Gateway]를 생성해서 외부 통신이 가능하도록 해야 합니다.
여기서는 [NAT Gateway]가 생성되어 있다고 가정하고, 어떻게 설정하는지 확인해보겠습니다.
- [NAT Gateway] 상세 정보 중에서 [공인 IP]는 따로 기록해 두었다가, 아래쪽에서 [방화벽(ACG) 설정]에서 사용하게 됩니다.
VPC 환경에서 [NAT Gateway]를 생성하는 상세한 방법은 아래 문서를 참고하시면 됩니다.
Route Table 설정
다음으로 [VPC] - [Route Table]에서 [Target DB]의 Subnet에 연관된 [Route Table]을 선택하고, [Routes 설정] 버튼을 클릭합니다.
- Route Table 설정 화면에서 [Destination]에는 [Source DB]의 공인 IP를 입력하고, [Target Type]은 [NATGW], [Target Name]은 위에서 생성했던 NAT Gateway를 선택하고 [생성] 버튼을 클릭합니다.
방화벽(ACG) 설정
Target DB Source DB로 접근하여 DB 데이터를 가져오기 위해 [Target DB] 방화벽에서는 [Outbound] 규칙을, [Source DB] 방화벽에서는 [Inbound] 규칙을 설정해야 합니다.
Target DB ACG 설정
우선 [Target DB]의 [Outbound] 규칙을 설정해보겠습니다. [Target DB]를 선택하면 나타나는 DB 상세 정보 화면에서 [ACG]를 클릭합니다.
- [ACG] 화면에서 해당 ACG를 선택하고 [ACG 설정] 메뉴를 클릭합니다.
- [ACG 규칙 설정] 팝업에서 [Outbound] 탭을 선택하고, [목적지]에는 [Source DB]의 IP 주소, [허용 포트]에는 [Source DB]의 포트 번호를 입력한 후 [추가]-[적용] 버튼을 클릭합니다.
Source DB 방화벽 설정
이제 [Source DB] 방화벽에 위에서 확인했던 [NAT Gateway]의 [공인 IP]를 추가해서 [Taget DB]가 접근할 수 있도록 설정하겠습니다.
-
On Premise 등 Ncloud 외부 서버의 경우 자체 방화벽에 직접 추가하시면 됩니다.
-
Ncloud 내부 서버의 경우 해당 서버의 ACG의 [Inbound] 설정에 아래처럼 추가하면 됩니다.
마이그레이션 서비스 위치
이제 모든 준비를 마쳤으면 본격적으로 마이그레이션 작업을 진행해보겠습니다.
[Database Migration] 서비스는 [Services] - [Database] - [Database Migration]에 있습니다.
마이그레이션 설정
[Source DB]와 [Target DB]에서 사전 준비가 끝났으면 이제 [Database Migration Service] 설정을 시작합니다.
Endpoint 설정
우선 [Database Migration Service] - [Endpoint Management] 메뉴에서 [Endpoint 생성] 버튼을 클릭합니다.
여기서 [Endpoint]는 [Source DB]를 지칭하는 것으로 [Source DB]의 정보를 입력한다고 생각하시면 됩니다.
다음으로 Endpoint 생성화면에서 [Source DB] 관련 정보를 입력하고 [생성] 버튼을 클릭합니다.
- Endpoint URL: Source DB의 IP 또는 도메인을 입력합니다.
- DB PORT: Source DB의 Port를 입력합니다.
- DB User: 위에서 Source DB에 생성했던 마이그레이션 전용 DB User를 입력합니다.
- DB Password: 마이그레이션 전용 DB User의 패스워드를 입력합니다.
마이그레이션 작업 생성
[Database Migration Service] - [Migration Management] 메뉴에서 [Migration 작업생성] 버튼을 클릭합니다.
Test Connection
[Source DB] 항목과 [Target DB] 항목을 선택한 후에 [Test Connection] 버튼을 클릭해 Target DB Source DB로 접근을 테스트 해봅니다.
마이그레이션 작업 시작
[Test Connection]에서 이상이 없을 경우 아래와 같이 옮겨오게 될 [Source DB]의 정보를 확인할 수 있습니다. 문제가 없으면 [Migration 작업시작] 버튼을 클릭해서 마이그레이션 작업을 시작합니다.
마이그레이션 작업 진행 상태
마이그레이션 작업은 [Exporting], [Importing], [Replication] 이렇게 3가지 단계로 진행되는데, 각각의 진행 상태를 확인할 수 있습니다.
진행 상태 확인 메일
진행 상태는 콘솔에서도 확인할 수 있지만, 작업이 오래 걸리는 경우도 대비해서 각 단계가 완료될 때마다 안내 메일이 발송됩니다.
-
⁃ Export Completed
-
⁃ Import Completed
-
⁃ Migration Completed
마이그레이션 완료
마이그레이션 작업이 완료되면 아래와 같이 콘솔화면에서 [완료] 버튼이 활성화 됩니다. 즉, 현재는 [Replication] 작업이 완료된 상태로 [Source DB]와 [Target DB]가 동기화 되어 있고, [Target DB]는 [쓰기 불가] 상태입니다.
그러므로 [완료] 버튼 클릭해야 모든 작업이 완료되고, [Target DB]가 [쓰기 가능] 상태로 변경됩니다.
- [완료] 버튼 클릭하면 아래와 같이 안내 메시지가 출력되고 [확인] 버튼을 클릭하면 완료됩니다.
최종 완료
최종 완료가 되면 아래와 같이 [Migration Status] 상태가 완료상태로 변경되고 [Migration 종료 일시]로 기록됩니다.
Target DB 데이터 확인
마이그레이션이 모두 완료되었으므로 [Source DB]의 데이터가 [Target DB]로 모두 이상 없이 마이그레이션 되었는지 [Target DB]에 접속해서 직접 확인해보겠습니다.
확인해보는 방법은 [Target DB]와 동일한 [Subnet]에 테스터 서버를 생성하고, [Target DB]에 접속해서 [Database], [Table], [Procedure] 등이 정상적으로 존재하는지 살펴보는 것인데, 아래 스샷처럼 모두 이상이 없는 것을 확인할 수 있습니다.
오류 상황
지금부터는 마이그레이션 진행 중에 나타날 수 있는 오류 메시지 관련해서 정리해보고, 해결 방법을 알아보겠습니다.
방화벽 설정 오류
[Source DB]의 방화벽 Inbound 설정과 [Target DB]의 ACG Outbound 설정이 올바르지 않을 경우 나타나는 메시지 입니다. 접근 권한 설정 내용을 다시 확인해주세요.
Source DB Inbound 와 Target DB Outbound ACG 를 점검해 주세요.
Endpoint DB User 설정 오류
[Endpoint 설정]에서 [DB User] 또는 [DB Password] 설정이 올바르지 않을 경우 나타나는 메시지 입니다. Endpoint 설정 내용을 다시 확인해주세요.
DB ACL 을 점검해 주세요.
DEFINER 계정 생성 오류
[Source DB]에 [Procedure], [Function], [VIEW] 등이 존재하고, 이때 사용된 DB User 즉, [DEFINER] 계정이 [Target DB]에 존재하지 않았을 경우 나타나는 메시지 입니다. DEFINER 설정 내용을 다시 확인해주세요.
Definer 에 사용된 계정은 먼저 생성후 진행해 주세요.
필요 Definer 계정 : abcd2@%
바이너리 로그 설정 오류
Source DB의 바이너리 로그 설정 중에서, [server_id], [log_bin] 관련 설정이 올바르지 않을 경우 나타나는 메시지 입니다. 바이너리 로그 설정 내용을 다시 확인해주세요.
추가 필요 설정 : log_bin
sql_mode 설정 오류
[Source DB] 사전 설정에서 sql_mode 관련된 설정을 수정하지 않았을 경우 아래와 같이 마이그레이션 진행 중에 [Importing] 단계에서 실패가 발생하고 [에러 보기] 버튼을 클릭하면 아래와 같은 메시지가 나타납니다. sql_mode 설정 내용을 다시 확인해주세요.
마이그레이션 재실행
위와 같이 [sql_mode] 관련 오류로 마이그레이션 작업이 실패했을 경우에는 [재시작] 버튼으로 재시작을 할 경우에는 동일한 오류가 계속 발생하게 됩니다.
이때는 [sql_mode] 설정을 수정한 후에 마이그레이션 작업을 삭제하고, [Target DB]에 생성된 [Database]을 모두 삭제 후에 마이그레이션 작업을 다시 생성해야 정상 작동합니다.
- [sql_mode] 설정을 수정한 후에 [삭제] 버튼을 클릭해서 마이그레이션 작업을 삭제합니다.
- [Target DB]의 [DB 관리] - [DB Server 상세보기] 메뉴를 클릭해서 [Database 관리] 기능으로 이동합니다.
- [Database 관리]에서 [Source DB]에서 Import한 [Database]을 모두 삭제하고, [저장] 버튼을 클릭합니다.
그런 후에 마이그레이션 작업을 다시 생성해야 정상 작동합니다.
참고 URL
- Database Migration Service 개요
- Source DB 및 Target DB 접속 설정
문서 업데이트 내역
| 날짜 | 내용 |
|---|---|
| 2023-11-02 | 문서 최초 생성 |