สอนใช้ AWS DMS ย้ายข้อมูลจาก RDS MySQL ไปอีก RDS แบบ Step-by-Step พร้อมแนวทางแก้ปัญหา

1. DMS คืออะไร

1.1 แนะนำให้รู้จัก DMS

AWS Database Migration Service (DMS) คือบริการจาก Amazon Web Services ที่ช่วยให้คุณสามารถย้ายฐานข้อมูลจากที่หนึ่งไปยังอีกที่หนึ่งได้อย่างรวดเร็ว ปลอดภัย และมี Downtime ต่ำมาก ไม่ว่าจะเป็นการย้ายจาก On-premise มายัง AWS, จาก RDS ไปยัง RDS หรือแม้แต่ระหว่างฐานข้อมูลต่างชนิดกัน เช่น จาก MySQL ไปยัง PostgreSQL ก็สามารถทำได้

1.2 DMS ทำอะไรได้บ้าง

DMS ช่วยให้การย้ายข้อมูลทำได้ง่ายขึ้น โดยมีความสามารถหลักๆ ดังนี้:

• ย้ายข้อมูลจากฐานข้อมูลต้นทาง (Source) ไปยังปลายทาง (Target)
• รองรับการย้ายแบบ Full load (ย้ายข้อมูลทั้งหมด) และ ongoing replication (ซิงค์ข้อมูลใหม่ๆ ที่เกิดขึ้นหลังจากการย้าย)
• รองรับการแปลง schema ด้วย AWS Schema Conversion Tool (SCT)
• ตรวจสอบความถูกต้องของข้อมูลหลังการย้าย (Data validation)

1.3 เลือก Source และ Target อะไรได้บ้าง

DMS รองรับฐานข้อมูลหลากหลายประเภท เช่น:

• Source: MySQL, PostgreSQL, Oracle, Microsoft SQL Server, MongoDB, Amazon Aurora, Amazon S3 ฯลฯ
• Target: Amazon RDS, Amazon Redshift, Amazon S3, DynamoDB, Elasticsearch, Kinesis ฯลฯ

✅ Tip: ตรวจสอบว่าเวอร์ชันของฐานข้อมูลที่ใช้งานรองรับกับ DMS หรือไม่จาก เอกสารของ AWS

1.4 Best Practice ของ DMS

• วางแผนการย้ายข้อมูลล่วงหน้า และทดสอบในสภาพแวดล้อมทดลองก่อน
• ใช้ Premigration assessment เพื่อตรวจสอบความพร้อมก่อนย้าย
• เปิดใช้งาน Data validation เพื่อความมั่นใจในความถูกต้องของข้อมูล
• เปิด CloudWatch Logs เพื่อตรวจสอบและแก้ไขปัญหาได้อย่างรวดเร็ว
• เลือก instance type ที่เหมาะสมกับขนาดของข้อมูลและปริมาณการใช้งาน

2. ลองลงมือทำกันเถอะ

สิ่งที่อยากทำ

ในบทความนี้ เราจะลองย้ายข้อมูลจาก MySQL ที่รันอยู่บน Amazon RDS ไปยังอีก RDS MySQL หนึ่ง โดยใช้ AWS DMS กันครับ

โดยในบทความนี้เราจะใช้ Thailand Region ในการทดสอบครับ

2.1 เตรียมตัว

1. สร้าง MySQL บน RDS 2 ตัว

โดยพื้นฐานจะมีประมาณนี้ครับ

• เข้าไปที่ AWS Console > RDS > Create database
• เลือก MySQL
• เลือก Instance size เป็น db.t4g.micro (ขนาดเล็ก ประหยัดงบ)
• ตั้งชื่อ DB Instance เช่น mysql-source และ mysql-target (ที่ใส่ tartest หมายถึงชื่อผมนะ)
• ตั้งค่ารหัสผ่านและ security group ให้สามารถเชื่อมต่อได้

หากใครต้องการทราบรายละเอียดแบบละเอียด สามารถเข้าไปดูได้ที่

https://dev.classmethod.jp/articles/how-to-create-rds-and-connect-from-ec2/

2. สร้าง Random Data ลงใน MySQL ตัวแรก

• เชื่อมต่อเข้า MySQL ด้วย EC2 หรือเครื่องมือเช่น DBeaver หรือ MySQL Workbench
• สร้าง database และ table โดยในบทความนี้ผมจะสร้างประมาณนี้ครับ:

CREATE DATABASE sampledb;
USE sampledb;

CREATE TABLE customers (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO customers (name, email) 
VALUES 
('John Doe', 'john@example.com'),
('Jane Smith', 'jane@example.com'),
('Alice Johnson', 'alice@example.com');

(ภาพตอนผมทำใน MySQL Workbench)

2.2 ลงมือทำเกี่ยวกับ DMS

2.2.1 สร้าง Replication Instance

• ไปที่ DMS > Replication instances > Create replication instance

• ตั้งชื่อ เช่น dms-replication-1
• เลือก instance class เป็น dms.t3.micro (ซึ่งอีกเหตุผลนึงคือเราปรับขนาดตาม DB ด้วย)

  💡 เหมาะสำหรับงานทดลองหรือข้อมูลขนาดเล็ก

• High Availability เลือกเป็น single
• นอกนั้นให้เป็นค่า Default

• กำหนด VPC ให้ตรงกับ RDS ที่สร้างไว้

• ปิด Public accessible (เนื่องจากในงานนี้ไม่ได้ใช้)

  💡 การเปิด Public accessible จะทำให้ instance ใช้งาน Public IPv4 ซึ่งจะมีค่าใช้จ่ายเพิ่มเติม

• หากไม่มี Replication subnet group ให้เลือก ให้เราสร้างใหม่ขึ้นมา โดยไปที่ DMS > Subnet groups > Create subnet group

  💡 subnets ที่เราควรเลือกใน subnet group ควรจะเป็นอันเดียวกับที่เลือกใน RDS

• สร้างเสร็จแล้ว รอจนสถานะเป็น “Available”
• เข้าไปดู Private IP address ของ Replication instances แล้วทำการเพิ่มลงไปใน inbound rule ของ Security Group ของ RDS เพื่อให้ Replication instances สามารถเชื่อมเข้าไปที่ RDS ได้

2.2.2 สร้าง Endpoint ของ Source และ Target

• ไปที่ AWS Console > DMS > Endpoints > Create endpoint

• สร้าง Source endpoint:
  • Endpoint type: Source endpoint
  • ✅Select RDS DB instance
  • เลือก Source Instance ที่เราสร้างขึ้น

• กรอกข้อมูลเช่น host, port, username, password ที่จะทำการเชื่อมต่อ ซึ่งรอบนี้ผมไม่ได้เก็บ Password ไว้ใน "Secrets Manager" ผมจึงเลือก Provide access information manually แล้วกรอกข้อมูลตามภาพ

• จากนั้นกด Create endpoint ด้านล่างสุด

• กดเข้าไปที่ endpoint ที่เราสร้างขึ้น แล้วกด “Connections” แล้วกด Test connections

• กด Run test

💡 หากเชื่อมต่อไม่ได้ ลองตรวจสอบ Security group หรือ Username Password สำหรับเข้าใช้ดู

ถ้าขึ้นแบบด้านล่างถือว่าโอเคแล้วครับ

ต่อไป เราจะสร้าง Target Endpoint ครับ ซึ่งขั้นตอนก็จะเหมือนกับของ Source Endpoint เลยครับ

• สร้าง Target endpoint:
  • Endpoint type: Target endpoint
  • ✅Select RDS DB instance
  • เลือก Target Instance ที่เราสร้างขึ้น
  • กรอกข้อมูลเช่น host, port, username, password ที่จะทำการเชื่อมต่อ ซึ่งรอบนี้ผมไม่ได้เป็น Password ไว้ใน "Secrets Manager" ผมจึงเลือก Provide access information manually แล้วกรอกข้อมูลตามภาพ
  • จากนั้นกด Create endpoint ด้านล่างสุด

เมื่อสร้างเสร็จแล้ว แล้วเราทำการ Test Connection แล้วได้ successful แล้วถือว่าโอเคครับ

2.2.3 สร้าง Database Migration Task

• ไปที่ DMS > Database migration tasks > Create task

• ตั้งชื่อ task เช่น migrate-sampledb

• เลือก Replication instance ที่สร้างไว้

• เลือก Source และ Target endpoint ที่สร้างไว้

เลือก Migration type:

1. Migrate (การย้ายข้อมูล)

ตัวอย่างการใช้งาน:
การย้ายฐานข้อมูล (DB) จากระบบภายในองค์กร (On-Premise) ไปยัง AWS RDS

• ในกรณีนี้ จะมีการดำเนินการบำรุงรักษา และจะไม่มีการอัปเดตข้อมูลในฐานข้อมูลต้นทางระหว่างการย้ายข้อมูล
• เหมาะสำหรับกรณีที่ไม่มีการเปลี่ยนแปลงข้อมูลระหว่างการย้าย
• หลังจากการย้ายข้อมูลเสร็จสิ้นแล้ว DMS Replication Instance จะไม่จำเป็นต้องใช้งานอีกต่อไป

2. Migrate and replicate (ย้ายและจำลองข้อมูลต่อเนื่อง)

ตัวอย่างการใช้งาน:
การคัดลอกข้อมูลจาก RDS หนึ่งไปยังอีก RDS หนึ่ง โดยมีการแปลงข้อมูลระหว่างทาง

• ฐานข้อมูลต้นทางยังคงมีการอัปเดตข้อมูลอยู่
• การเปลี่ยนแปลงในต้นทางจะถูกส่งต่อไปยังปลายทางอย่างต่อเนื่อง พร้อมการแปลงข้อมูล
• ในกรณีนี้ DMS Replication Instance จะต้องเปิดใช้งานตลอดเวลา

3. Replicate (จำลองข้อมูล)

ตัวอย่างการใช้งาน:
การซิงค์ข้อมูลระหว่าง RDS สองตัวแบบเรียลไทม์ เพื่อใช้เป็นการสำรองข้อมูลหรือแยกโหลด

• ฐานข้อมูลต้นทางใช้สำหรับการอัปเดตข้อมูล
• ฐานข้อมูลปลายทางใช้สำหรับการวิเคราะห์ เช่น การวิเคราะห์สถิติ
• เพื่อไม่ให้การวิเคราะห์ไปกระทบกับประสิทธิภาพของฐานข้อมูลต้นทาง
• กรณีนี้เริ่มจากที่ข้อมูลถูกคัดลอกไว้เรียบร้อยแล้ว
• DMS Replication Instance จะต้องเปิดใช้งานตลอดเวลา

🟢 คำแนะนำ: สำหรับการทดลองครั้งนี้ ให้เลือก Migrate

ตั้งค่า Table mappings:

ในส่วนนี้จะเป็นการตั้งค่าว่าส่วนไหนที่เราจะทำการย้ายไปบ้าง

โดยอย่างน้อย เราจำเป็นต้องทำการเขียน Selection rules ขึ้นก่อน

โดยเรากด Add new selection rule ไป เราจะสามารถตั้งค่ากฎได้ในส่วนนี้

โดยผมจะใช้กฎตามนี้ครับ

where schema name is like '%' and Source table name is like '%', include

💡 หากเชื่อมต่อไม่ได้ ลองตรวจสอบ Security group หรือ Username Password สำหรับเข้าใช้ดู

Task Settings:

• ✅ เปิด Data validation
  เพื่อให้ DMS ตรวจสอบความถูกต้องของข้อมูลหลังจากย้ายเสร็จ

• ✅ เปิด Task logs (CloudWatch logs)
  เพื่อให้สามารถดู log และ debug ได้ง่ายหากเกิดปัญหา

• ✅ เปิด Premigration assessment
  ระบบจะประเมินความพร้อมของ schema, data type, constraint ฯลฯ ก่อนเริ่มการย้าย
  เช่น แจ้งเตือนหาก table ไม่มี primary key หรือมี data type ที่ไม่รองรับ

• ในส่วนของ S3 เราต้องการ storage สำหรับเก็บ Assessment report

โดยในส่วนนี้ให้เราทำการสร้าง Role และ ฺBucket ตามที่ AWS Document ได้ระบุไว้ครับ

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.AssessmentReport.Prerequisites.html

เสร็จแล้วเราเลื่อนมาล่างสุด แล้วทำการกด Create database migration task ได้เลย

ใครทำตามผมทุกขั้นตอนแล้วได้ Fail เหมือนภาพด้านล่างเหมือนผม แปลว่าคุณมาถูกทางแล้วครับ ยินดีด้วยครับ

2.2.4 วิธีแก้ไข Failed

ด้วยการที่เราเปิดการใช้งาน Premigration assessment มันจะทำการตรวจสอบข้อผิดพลาดของ Task ที่เราจะทำการดำเนินการได้ ซึ่ง Task จะไม่ยอมให้เรา Start progress ถ้าเรายังไม่ได้แก้ Failed ที่เกิดขึ้น

เพราะฉนั้นในขั้นตอนนี้เราจะมาแก้ Failed ที่เกิดขึ้นกัน

💡 หากเราปิด Premigration assessment ไว้ เราสามารถ Start progress ได้ แต่ผลลัพท์คือมันจะ Failed อยู่ดี เพราะฉนั้นเปิด Premigration assessment ไว้ดีกว่า เพราะเราจะได้ทราบได้ว่าทำไมมันถึง Failed จะได้แก้ได้ตรงจุด

• ก่อนอื่นให้เราคลิกไปที่ Latest premigration assessment

เราจะเห็นหน้าต่างที่เขียนว่ามันเปิดอะไรขึ้นมาบ้าง ซึ่งถ้าเป็นงานจริง เราก็แก้ตามที่เขาให้แก้ครับ

ซึ่งมาดูกันว่าผมมีอะไรบ้าง

Failed 1

Validate if the timeout values are appropriate for a MySQL source or target
----
Net read, net write and wait timeouts must be greater than 5 minutes for DMS target database to prevent connection drops while replicating. Please increase the timeouts to at least 300 seconds

ซึ่งอันนี้คือลิ้งค์ที่ AWS แปะมาให้ครับ

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.MySQL.ConnectionDisconnect

สิ่งที่เขาจะให้ผมแก้คือเพิ่มเวลา Timeouts เป็นอย่างน้อย 300 sec ใน DMS source database และ DMS target database

โดยการเพิ่ม Timeouts นั้นต้องไปแก้ใน Parameter group ของ RDS

ซึ่งตอนที่ผมสร้าง source & target RDS ขึ้น ผมใช้เป็น Default parameter group ทำให้ไม่สามารถแก้ไขรายละเอียดข้างในได้

ผมต้องไปทำสิ่งต่อไปนี้

1. สร้าง custom parameter group ขึ้นมาใหม่
2. แก้ข้อมูล parameter Timeout ตามตารางด้านล่างนี้
3. เอา parameter group ไปแปะที่ RDS แทนที่ตัวเก่า
4. Reboot RDS เพื่อให้มันปรับตาม

โดยถ้าใครไม่เคยแก้ไข หรือ สร้าง Parameter group มาก่อน เข้าไปอ่านบนความนี้อ้างอิงได้

https://dev.classmethod.jp/articles/setting-up-timezone-with-rds/#%25E0%25B8%2581%25E0%25B8%25B2%25E0%25B8%25A3%25E0%25B8%25AA%25E0%25B8%25A3%25E0%25B9%2589%25E0%25B8%25B2%25E0%25B8%2587%2520Parameter%2520groups

Failed 2

Validate if DMS user has necessary privileges for the MySQL database as a target
----
| Schema | Table | Privilege | Message | Results |
| --- | --- | --- | --- | --- |
| * | * | ALTER | This privilege is required for CDC task | Failed |
| * | * | CREATE | This privilege is required for CDC task | Failed |
| * | * | DROP | This privilege is required for CDC task | Failed |
| * | * | INDEX | This privilege is required for CDC task | Failed |
| * | * | INSERT | This privilege is required for CDC task | Failed |
| * | * | UPDATE | This privilege is required for CDC task | Failed |
| * | * | DELETE | This privilege is required for CDC task | Failed |
| * | * | SELECT | This privilege is required for CDC task | Failed |
| awsdms_control | * | ALL PRIVILEGES | This privilege is required for CDC task | Failed |

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html#CHAP_Target.MySQL.Prerequisites

อันนี้เป็นปัญหาที่ DMS user ไม่มีสิทธิเพียงพอในการทำอะไรต่างๆ ใน Target Database

โดยผมไปถาม AI มา ได้วิธีแก้มาแบบนี้

โดยก่อนอื่นเราต้องเชื่อมต่อเข้าไปที่ Target Database ก่อน

ผมจะให้สิทธิ์ที่จำเป็นกับ DMS User
โดยจะทำตามคำแนะนำที่ AWS Document เขียน

อันนี้คือที่เขาแนะนำ

-- 1. สร้าง DMS user
CREATE USER 'dms_user'@'%' IDENTIFIED BY 'StrongPassword123!';

-- 2. ให้สิทธิ์ read/write กับ schema ที่ใช้ในการ migration
GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT 
ON your_database_name.* 
TO 'dms_user'@'%';

-- 3. ให้สิทธิ์เต็มกับ schema ที่ DMS ใช้ควบคุม CDC
GRANT ALL PRIVILEGES 
ON awsdms_control.* 
TO 'dms_user'@'%';

-- 4. โหลดสิทธิ์ใหม่
FLUSH PRIVILEGES;

🔁 อย่าลืมเปลี่ยน:

*'dms_user' เป็นชื่อผู้ใช้ที่คุณต้องการ'StrongPassword123!' เป็นรหัสผ่านที่คุณกำหนดyour_database_name เป็นชื่อ schema/database ที่คุณใช้กับ DMS*

• 'dms_user' เป็นชื่อผู้ใช้ที่คุณต้องการ
• 'StrongPassword123!' เป็นรหัสผ่านที่คุณกำหนด
• your_database_name เป็นชื่อ schema/database ที่คุณใช้กับ DMS

โดยผมจะทำการเพิ่มข้อมูลลงไปตามนี้ (ผมจะให้สิทธิกับทุก database เนื่องจากจะได้ง่าย ไม่สับสน)

CREATE USER 'dms_user'@'%' IDENTIFIED BY 'Aws_2022';

GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT 
ON *.* 
TO 'dms_user'@'%';

GRANT ALL PRIVILEGES 
ON awsdms_control.* 
TO 'dms_user'@'%';

FLUSH PRIVILEGES;

ผลลัพท์ก็ได้ประมาณนี้

ซึ่งส่งผลให้เราต้องไปแก้เนื้อหาใน Endpoint ให้เป็นตามนี้ด้วยครับ

• คลิกไปที่ Modify

• แล้วเข้าไปแก้ในส่วน User name Password ให้เป็น DMS User ที่เราสร้างขึ้นเมื่อกี้
• เสร็จแล้วให้กด Save

Failed 3

Validate if DMS user has SELECT privileges for the source database tables
----
| Schema | Table | Privilege | Message | Results |
| --- | --- | --- | --- | --- |
| sampledb | customers | SELECT | AWS DMS user must have this privileges on source tables | Failed |

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html#CHAP_Source.MySQL.Prerequisites.

ปัญหานี้คือ DMS User ไม่มี สิทธิ SELECT ใน source database tables ที่เราต้องการครับ

เหมือนกับ Failed ที่ 2 ผมจะไปทำการเพิ่ม DM User แล้วก็ไปเพิ่มสิทธิ SELECT ให้
โดยคราวนี้ผมจะลองให้สิทธิแบบขั้นต่ำ ตามที่　↑AWS Document ระบุมาดูครับ

-- สร้าง DMS user
CREATE USER 'dms_user'@'%' IDENTIFIED BY 'Aws_2022';

-- ให้สิทธิ์ SELECT บน schema และ table ที่ต้องการ
GRANT SELECT ON sampledb.customers TO 'dms_user'@'%';
GRANT SELECT ON mysql.user TO 'dms_user'@'%';
GRANT SELECT ON mysql.db TO 'dms_user'@'%';
GRANT SELECT ON mysql.tables_priv TO 'dms_user'@'%';
GRANT SELECT ON mysql.role_edges TO 'dms_user'@'%';

-- โหลดสิทธิ์ใหม่ (ไม่จำเป็นในทุกกรณี แต่แนะนำให้ทำ)
FLUSH PRIVILEGES;

• แล้วก็อย่าลืมไปอัพเดทข้อมูลใน Endpoint ของ source database ด้วยนะครับ

ลองตรวจสอบ assessment อีกรอบ

• คราวนี้เรากลับมาที่ Assessment ของเราแล้วกด Re-run assessment ดูครับ

แล้วคราวนี้ถ้าเราไม่มี Failed ตามภาพด้านล่าง

คราวนี้พอกลับมาดูจะเห็นว่า Migration อยู่ในสถานะ Created

2.2.5 เริ่มต้น Task

• หลังจากสร้าง Task เสร็จแล้ว ให้เข้าไปที่หน้ารายการ Task

เมนูในหน้าต่าง Task:

• Table statistics: ดูสถานะการย้ายของแต่ละ table
• Logs: ดู log แบบละเอียดจาก CloudWatch
• Assessment report: ดูรายงานจาก Premigration assessment
• Progress: แสดงความคืบหน้าของ task

เราต้องทำการ Start process การ Migration
โดยไปที่ Action ที่อยู่ด้านขวาบน แล้วไปที่ Restart\Resume

ถ้า คุณได้ Starting ตามภาพด้านล่าง ถือว่าโอเคแล้วครับ ขั้นตอนต่อไปคือการรอครับ รอจนกว่ามันจะเสร็จ

และ..มันไม่เสร็จครับ(จริงๆมันเสร็จแล้ว)

ผมพยายามจะหาเกี่ยวกับ Error ในครั้งนี้

ผมเลยไปที่ CloudWatch Log แล้วเอา Log ให้ AI ดูว่าเกิดปัญหาอะไรไหม ซึ่งผลลัพธ์คือ__มันไม่มีปัญหาอะไร__ครับ

จากนั้นผมไปเช็ค Table statistics ผม อ๋อ ทันที เราจะเห็นว่า Table customers ถูกย้ายไปโดยไม่มีปัญหาอะไร ที่ error จะเป็น table Default ที่ถูกสร้างขึ้นมา

ซึ่งนี่ก็ถือว่าเรา Migration เสร็จแล้วครับ

เพื่อให้เห็นตัวอักษรสีเขียวๆว่า Load complete ผมจะเข้าไปแก้ Mapping rules ให้ได้ตามนี้

schema name is like 'sampledb' and Source table name is like 'customers'

แล้วทำการ Restart\Resume อีกรอบ

ได้ Load complete แล้ว

3. ทดสอบผลลัพธ์

หลังจาก Task ทำงานเสร็จ:

• เข้าไปที่ MySQL Target RDS
• ตรวจสอบว่ามี database และ table ที่ถูกย้ายมาแล้ว
• ลอง query ข้อมูล เช่น:

SELECT * FROM sampledb.customers;

เอาล่ะ เท่านี้ก็น่าจะเพียงพอสำหรับการเขียนบล็อคแล้ว

ค้นพบอะไรบ้าง

• ✅ ข้อมูลถูกย้ายมาครบถ้วน
  ตรวจสอบแล้วพบว่า table และข้อมูลทั้งหมดจาก Source ถูกย้ายมาที่ Target อย่างถูกต้อง

• ✅ Data Validation ช่วยตรวจสอบความถูกต้อง
  หากเปิดใช้งาน Data Validation ใน Task settings ระบบจะเปรียบเทียบข้อมูลระหว่าง Source และ Target เพื่อให้มั่นใจว่าข้อมูลตรงกัน

• ✅ CloudWatch Logs มีประโยชน์มาก
  การเปิดใช้งาน CloudWatch Logs ทำให้สามารถตรวจสอบปัญหาได้อย่างละเอียด เช่น table ไหนย้ายไม่สำเร็จ หรือเกิด error ขณะทำงาน

• ✅ Premigration Assessment แจ้งเตือนล่วงหน้า
  ช่วยให้เราทราบปัญหาเช่น:

  • table ไม่มี primary key
  • data type ที่ไม่รองรับ
  • constraint ที่ไม่สามารถย้ายได้

  ทำให้สามารถแก้ไขก่อนเริ่ม migration ได้ทันเวลา

ลบ Resource ที่สร้างขึ้น

ใครที่ลองทำตามแล้ว ต้องการลบ Resource ที่สร้างขึ้นแบบขาวสะอาด นี่เป็นรายการที่จำเป็นต้องลบครับ

ลบฝั่ง DMS

ลบ Resource ตามลำดับต่อไปนี้ (ทุกอย่างลบได้โดยการกด Actions แล้วก็กด Delete)

1. ลบ Database migration tasks
2. ลบ Endpoint
3. ลบ Replication instances

(ภาพตัวอย่าง)

ลบฝั่ง RDS

ลบ RDS ที่เราสร้างขึ้น
อ้างอิงวิธีลบจากบทความด้านล่าง

https://dev.classmethod.jp/articles/how-to-create-rds-and-connect-from-ec2/#toc--rds1

ลบฝั่ง อื่นๆ

1. ลบ S3 Bucket ที่เราสร้างขึ้น
2. ลบ IAM Role ที่เราสร้างขึ้น
3. ลบ CloudWatch Log ที่เราสร้างขึ้น
4. ลบ EC2 ที่เราสร้างขึ้น(กรณีที่ใช้ EC2 ในการเชื่อมต่อ RDS)

(ภาพตัวอย่าง)

✅ สรุป

AWS DMS เป็นเครื่องมือที่มีประสิทธิภาพสูง ใช้งานง่าย(รึเปล่า) และเหมาะสำหรับการย้ายฐานข้อมูลทั้งในระดับทดลองและ production โดยเฉพาะเมื่อเราทำตาม Best Practice เช่น:

• เตรียม Source/Target ให้พร้อม
• เปิดใช้ Premigration Assessment
• เปิด Data Validation
• เปิด CloudWatch Logs

สิ่งเหล่านี้จะช่วยให้การย้ายข้อมูลเป็นไปอย่างราบรื่น ปลอดภัย และสามารถตรวจสอบย้อนกลับได้หากเกิดปัญหา

💡 หากคุณต้องการขยายการใช้งาน DMS สำหรับ ongoing replication หรือใช้ร่วมกับฐานข้อมูลต่างชนิด (heterogeneous migration) แนะนำให้ศึกษาการใช้งานร่วมกับ AWS Schema Conversion Tool (SCT) เพิ่มเติม

https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html

บทความที่เกี่ยวข้อง

https://dev.classmethod.jp/articles/how-to-create-rds-and-connect-from-ec2/
https://dev.classmethod.jp/articles/setting-up-timezone-with-rds/#%25E0%25B8%2581%25E0%25B8%25B2%25E0%25B8%25A3%25E0%25B8%25AA%25E0%25B8%25A3%25E0%25B9%2589%25E0%25B8%25B2%25E0%25B8%2587%2520Parameter%2520groups
https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.AssessmentReport.Prerequisites.html