AWS DMS(Database Migration Service)란?
- Replication Instance를 생성하여 이를 통해 마이그레이션한다
- 관계형 데이터베이스 , 데이터 웨어하우스, NoSQL데이터베이스 등등을 쉽게 AWS로 마이그레이션하도록
해주는 클라우드 서비스
참고
https://www.slideshare.net/awskorea/1-aws-dms-oracle-db-migration
고려사항
다른 DBMS로 이전 하는 경우
https://docs.aws.amazon.com/ko_kr/SchemaConversionTool/latest/userguide/CHAP_Installing.html
특정 DBMS를 고집하지 않는 경우 Aurora DB를 고려한다
Aurora DB는 1/10 의 가격으로 5배의 성능
실습(EC2에 Mysql 설치하여 온프레미스로 가정한 뒤 DMS)
1. 시나리오
1) 목표 인프라
2) 목표
- Public Subnet에 EC2를 배치하고 Mysql을 직접 설치하여 온프레미스 환경의 DB Server로 가정하고
해당 DB를 AWS에 미리 구축되어있는 인프라의 RDS로 마이그레이션 한다
(192.168.0.0 에 배치 되어있는 DB Server를 10.0.0.0/16으로 이주한다)
2. 온프레미스 DB Server 환경구축
- DB를 마이그레이션 하기위해서는 외부에서 접근이 가능한 곳이므로 AWS의 EC2에 Instance를 생성한 뒤 Public IP를
할당하여 Mysql Server를 구축한다음 온프레미스 환경으로 가정한다
1) Subnet 생성
(VPC : 192.168.0.0/16)
2) EC2 생성
- Onpremiss의 DB역할을 할 EC2 인스턴스
1) 인스턴스 생성
2) ssh 접속
- putty를 이용하여 접속한뒤 관리자 계정으로 전환한다
$ sudo su - root
3) DB서버 구축
mysql 설치 및 접속
mysql 테이블 생성
mysql 데이터 입력
4) 외부에서 DB접속 확인
3. AWS 환경 구축
- DB Server를 이주할 곳이다.
1) Subnet 생성
(VPC : 10.0.0.0/16)
2) EC2 생성
- DB를 이주한 뒤 확인하기 위한 Bastion 호스트
1) Instance Name : JJY-DMS-BasionHost
2) Public IP : SSH 접속시 사용될 Public IP로 꼭 부여해야한다
3) VPC : JJY-VPC
4) Subnet : Public-Subnet1
3) RDS 생성
- 온프레미스의 DB가 이주될 DB 인스턴스이다
- RDS 설치방법 : http://galid1.tistory.com/352
VPC : 10.0.0.0/16
Subnet : Private Subnet1(10.0.11.0/24)
Private Subnet2(10.0.12.0/24)
4. AWS DMS를 이용하여 DB 마이그레이션
1. Replication Subnet Group 생성
1) DMS 서비스로 진입하여 좌측의 Subnet groups탭을 클릭한뒤 Create Subnet Group을 클릭한다.
2. 마이그레이션 시작
1) Database 마이그레이션을 위해 좌측 탭의 Get Started를 선택한다
2) Next 를 클릭한다
3. Replication Instance(복제 인스턴스) 생성
- 가장 중요한것은 양쪽(Source DB, Target DB)가 모두 접근이 가능한
Subnet에 Replication Instance를 배치해야 한다
- 마이그레이션에 사용될 Replication Instance를 생성한다
Name : Replication instance의 이름
VPC : Replication instance가 설치될 VPC를 선택한다
(앞서 만든 Replication Subnet Group이 속한 VPC를 선택하면 된다)
Replication Subnet Group : 앞서 생성한 Replication Subnet Group을 선택한다
Availability zone : Replication Subnet Group에 속한 Subnet들 중 원하는 Subnet이 속한 AZ영역을 선택한다
VPC Security Group : DMS replication Instance를 위해 미리 생성한 Security Group을 선택한다
4. Source DB와 Target DB endpoint 설정
- Source DB와 Target DB에 대한 접근성을 테스트한다
1) Source Database Connection details
- Migration할 원본 DB를 지정한다
Endpoint Identifier : 아무 이름이나 기입
Source engine : mysql 로 생성하였으므로 mysql로 지정
Server name : 2. 에서 생성한 OnpremissDB Instance의 Public DNS 또는 IP를 기입한다
Port : 3306 (mysql이 동작하는 Port)
SSL mode : None
User name : DB의 계정 이름을 기입한다
Password : DB 계정의 암호를 입력한다
=> 다 작성한 뒤에는 하단의 Run test를 눌러 Connection이 가능한 상태인지를 확인한다.
2) Target Database Connection Details
- Migration될 대상 DB를 지정한다
Selecct RDS DB Instance : 우리가 마이그레이션 하기위해 AWS의 인프라에 RDS를 생성하였다 따라서
RDS인스턴스를 사용할 것이므로 체크를 해야한다.
RDS Instance : 마이그레이션에 사용될 RDS를 선택한다
Endpoint Identifier : 아무 이름이나 기입
Target engine : Mysql
Server name : RDS Instance의 End Point를 입력한다
Port : 3306
User name : RDS 생성시 입력했던 계정
Password : RDS 생성시 입력했던 계정암호
=> 마찬가지로 Runtest를 눌러 Connection이 가능한 상태인지를 확인한다
5. Task 생성
- 실질적인 Migration 작업을 위한 Task를 생성한다
1) Task name : 마이그레이션 작업을 구분하기위한 이름을 작성
Source endpoint : 기존 onpremiss환경으로 가정한 onpremiss-ec2-onpremissdb 인스턴스
Target endpoint : 마이그레이션 될 AWS상의 RDS
Replication instance : 앞전에 만든 마이그레이션 작업을 진행하는 Replication Instance
Start task on create : task가 생성되면 바로 시작한다
2) Target table preparation mode : 마이그레이션을 위해 대상 DB에서 할 작업을 지정
Inclide LOB columns in replication : 마이그레이션에 LOB 열을 포함할지 여부 지정
3) Table name is like : source db에 존재하는 jjy로 시작하는 모든 table을 선택(지정)한다
Action : 선택된 table에 대한 행동으로 include면 마이그레이션 작업에 포함한다는 뜻이다.
Addselection rule을 클릭하여 설정한 rule를 추가한다
4) 방금 생성된 Rule이 보인다 Create Task를 눌러 task를 생성한다
5) 생성된 task를 클릭한뒤 Start를 눌러준다 1) 에서 start task on create를 체크했다면 task가 자동실행될 것이다
6. 확인
1) 마이그레이션이 완료되었다
- status가 Load Complete라고 나타난다면 마이그레이션이 성공적으로 완료된 것이다.
2) 대상 DB에서 테이블과 레코드를 확인한다
- BastionEC2로 접속한뒤 RDS(TargetDB)로 접근하여 확인한 결과 모든 레코드가 성공적으로 마이그레이션 되었다
DMS 오류(원인 추측)
가끔 Task를 만들고 DMS 실패가 나타나는 경우가 있다
하지만 RDS에 접속해서 테이블을 확인하면 데이터는 Migration되는 것을 볼 수 있다
원인
- table 이름을 User로 만들어서 마이그레이션 했었는데
Mysql 내부에서 사용하는 User 테이블과 테이블명이 충돌되어 나타나는 현상인것 같다
아직은 더 확인해봐야한다.
DMS 제거방법
주의사항
- 반드시 순서대로 해야한다
- 삭제 요청후 Status Deleting이 끝나고 완전히 사라져야 다음 단계의 삭제 요청이 가능하다
제거방법
1. Task를 삭제한다
- Replication Instance가 Task를 사용하고 있으므로 Task를 먼저 삭제해야한다
2. Replication Instance를 삭제한다
- Task가 먼저 삭제되어야 한다.
3. EndPoint 를 삭제한다
- Task에서 Endpoint를 사용하므로 Task가 먼저 삭제되어야 한다
- Replication Instance와는 상관이 없다
- Migration에 사용된 Target DB 와 Source DB에 대한 Endpoint가 남아있으므로 삭제해야한다.
4. Subnet Group을 삭제한다
- Replication instance가 상주하기 위해 생성했던 SubnetGroup이므로 Replication Instance가 먼저 삭제되어야한다
'AWS > Migration Service' 카테고리의 다른 글
AWS - 마이그레이션 서비스(VMWare(가상머신) AWS로 마이그레이션) - 수정중 (0) | 2018.12.28 |
---|