DMS, SCT আর Database Migration

এই লেসন শেষে তুমি পারবে

• AWS Database Migration Service (DMS) কী করে, বুঝিয়ে বলতে: একটা replication instance source endpoint থেকে পড়ে target endpoint-এ লেখে, এর মধ্যে source ব্যবহার হতেই থাকে, আর cutover-এ downtime হয় সামান্য (শূন্য না)।
• DMS-এর প্রধান source আর target-গুলোর নাম বলতে, আর “অন্তত একটা endpoint AWS-এ থাকতেই হবে” নিয়মটা কাজে লাগাতে।
• Homogeneous আর heterogeneous migration আলাদা করতে, আর বলতে AWS SCT (বা DMS Schema Conversion) কী বদলায়, DMS নিজে কী বানায়, আর কোনটা দুজনের কেউই তোমার হয়ে করে না।
• তিন ধরনের task (full load, full load আর CDC, শুধু CDC) থেকে ঠিকটা বাছতে, আর CDC-র জন্য source-এর log-এ কী কী লাগে, বলতে।
• Multi-AZ replication instance দিয়ে migration-টাকেই highly available করতে, আর DMS Serverless, data validation আর LOB mode চিনতে।
• RDS আর বাইরের MySQL বা PostgreSQL থেকে Aurora-য় যাওয়ার native পথ বাছতে: Aurora read replica আর promote, snapshot restore, S3 থেকে Percona XtraBackup, mysqldump, pg_dump, বা DMS।

#Database সরানো কেন আলাদা একটা ঝামেলা

লেসন ২৩.১ আর ২৩.২ ছিল দুর্যোগ সামলে টিকে থাকা নিয়ে। এই লেসন আর পরের দুটো হলো AWS-এ চলে আসা নিয়ে। Server block ধরে ধরে কপি করা যায় (লেসন ২৩.৪), file device-এ ভরে পাঠানো যায় (লেসন ২৩.৫), কিন্তু চালু database সরানো কঠিন: প্রতি সেকেন্ডে সেটা বদলায়, অন্য অনেক system তার হুবহু আচরণের ওপর নির্ভর করে, আর তার schema আর ভেতরের code লেখা থাকে নির্দিষ্ট একটা engine-এর ভাষায়।

পুরো লেসনে দুটো বাংলাদেশি উদাহরণ চলবে:

• ঢাকার একটা telco তাদের prepaid billing চালায় ৩ TB-র একটা on-premises Oracle database-এ। Oracle-এর license-এর টাকা বাঁচাতে তারা যেতে চায় Aurora PostgreSQL-এ। গ্রাহকরা দিনরাত recharge করে, তাই database বড়জোর কয়েক মিনিট বন্ধ রাখা যাবে।
• ঢাকার একটা e-commerce shop চালায় RDS for MySQL, আর চায় Aurora MySQL, যাতে failover দ্রুত হয় আর storage নিজে নিজে বাড়ে (লেসন ৭.৩)।

প্রথমটার লাগবে schema বদলানো আর অবিরাম replication। দ্বিতীয়টার এর কোনোটাই লাগবে না, আর সবচেয়ে বুদ্ধিমান উত্তরে কোনো migration service-ই নেই। এই দুই পরিস্থিতি আলাদা করে চেনাটাই পরীক্ষা যাচাই করে।

#AWS DMS: database চালু রেখেই কপি

AWS Database Migration Service (DMS) এক database বা data store থেকে আরেকটায় ডেটা সরায়, দ্রুত আর নিরাপদে, আর এর মধ্যে source database পুরোপুরি চালু থাকে। পুরো কপির সময় application পুরোনো database-এই পড়ে আর লেখে; শুধু শেষে ছোট্ট একটা cutover-এর জন্য থামাতে হয়।

#কোন কোন অংশ

Slide-এ লেখা “replication task চালাতে একটা EC2 instance বানাতে হবে”। আরও ঠিকভাবে বললে, তুমি একটা replication instance বানাও, যেটা DMS EC2-এর ওপর তৈরি করে আর নিজেই সামলায়; তুমি কখনো এতে login করো না। আর DMS Serverless-এ (নিচে আছে) কোনো instance-ই বানাতে হয় না।

DMS resilient আর self-healing: একটা task সাময়িক network error-এ পড়লে আবার চেষ্টা করে, যেখানে ছিল সেখান থেকেই শুরু করে, আর replication instance Multi-AZ করা যায়।

#Source আর target

DMS অনেক engine-এর ভাষা বোঝে। নিচের তালিকা DMS-এর এখনকার documentation থেকে নেওয়া; পরীক্ষায় বেশি আসে relational-গুলো।

#একটাই নিয়ম: অন্তত একটা endpoint AWS-এ

DMS-এর প্রশ্নোত্তর (frequently asked questions) পাতা পরিষ্কার বলে: source অথবা target (বা দুটোই) AWS-এ থাকতে হবে (RDS, Aurora, EC2-তে, বা S3, DynamoDB-র মতো AWS-এর data store-এ), আর on-premises থেকে on-premises replication সমর্থিত না। তাই DMS দিয়ে তোমার ঢাকার data center থেকে চট্টগ্রামের data center-এ কপি করা যাবে না, Azure থেকে Google Cloud-এও না। কপি করা যাবে AWS-এর ভেতরে আনতে, AWS থেকে বের করতে (EC2 বা RDS থেকে on-premises-এ, যেমন AWS ছেড়ে যেতে বা ফেরার একটা পথ রাখতে), আর AWS-এর ভেতরেই (RDS থেকে Redshift, Aurora থেকে S3, এক Region থেকে আরেক Region)।

Replication instance-কে দুটো endpoint-এই network দিয়ে পৌঁছাতে হয়। Data center থেকে মানে Site-to-Site VPN বা Direct Connect (লেসন ২২.৪ আর ২২.৫), অথবা SSL সহ public internet। Private পথ থাকলে replication instance private রাখা যায় (কোনো public IP ছাড়া)।

#Engine একই না ভিন্ন: SCT কোথায় আসে

#Homogeneous আর heterogeneous

• Homogeneous: engine একই থাকে। Oracle থেকে RDS for Oracle, EC2-র MySQL থেকে Aurora MySQL, on-premises PostgreSQL থেকে RDS for PostgreSQL। RDS শুধু platform; engine আর তার ভাষা একই, তাই অনুবাদের কিছু নেই।
• Heterogeneous: engine বদলায়। Oracle থেকে Aurora PostgreSQL, SQL Server থেকে Aurora MySQL, Teradata থেকে Redshift। Data type, SQL-এর লেখার নিয়ম আর procedure-এর ভাষা আলাদা, তাই ডেটা নামার আগে schema আর code নতুন করে লিখতে হয়।

#DMS নিজে কী বানায় (আর কী বানায় না)

নোটে আছে, DMS শুধু ডেটা সরায়, schema না। কথাটা একটু বেশি জোর দিয়ে বলা। Target-এ table না থাকলে DMS সাধারণ table আর তার primary key বানিয়ে নেয় (কখনো কখনো unique index-ও), ডেটা ঠিকঠাক লোড করতে যতটুকু লাগে। কিন্তু secondary index, foreign key, default মান, view, sequence, stored procedure, function বা trigger বানায় না। তাই একই engine-এ সরালেও সাধারণত আগে engine-এর নিজের tool দিয়ে পুরো schema বানিয়ে নাও (যেমন শুধু schema-র একটা pg_dump), তারপর DMS-কে তাতে ডেটা ঢালতে দাও।

#AWS Schema Conversion Tool (SCT)

AWS SCT একটা ফ্রি desktop application (Windows আর Linux-এ চলে), যেটা এক engine-এর database schema আরেক engine-এর উপযোগী করে বদলে দেয়:

• Source-এর table, data type, index, constraint, view, sequence, stored procedure, function আর trigger পড়ে target-এর জন্য নতুন করে লেখে, যেমন Oracle-এর procedure code থেকে PostgreSQL-এর PL/pgSQL, বা SQL Server-এর T-SQL থেকে MySQL।
• এর database migration assessment report বলে কতটা নিজে নিজে বদলানো গেছে, আর action item-এর তালিকা দেয়: যেসব জিনিস বদলাতে পারেনি, সাথে হাতে করতে কত খাটুনি লাগবে তার আন্দাজ। Migration-এ নামার আগে কাজটা কত বড়, team-গুলো এই report দেখেই মাপে।
• বদলানো schema target-এ বসিয়ে দেয়, তারপর DMS তাতে ডেটা আনে।
• OLTP-র উদাহরণ: Oracle বা SQL Server থেকে MySQL, PostgreSQL বা Aurora। Data warehouse-এর উদাহরণ: Teradata, Oracle, Netezza, Greenplum, Vertica বা অন্য warehouse থেকে Amazon Redshift; সেখানে SCT distribution key আর sort key-ও বেছে দেয়, আর এর data extraction agent বিশাল ডেটা S3 হয়ে পাঠায় (লেসন ১৭.২)।
• বদলানোর কাজে CPU খুব খাটে, তাই SCT (আর তার agent) চালাও একটা compute-optimized machine-এ।

Engine একই থাকলে SCT লাগে না: on-premises PostgreSQL থেকে RDS for PostgreSQL মানে তখনো PostgreSQL।

#Full load, CDC আর cutover

#তিন ধরনের migration

CDC (Change Data Capture) source database-এর transaction log পড়ে, মানে engine নিজের recovery-র জন্য প্রতিটা insert, update আর delete (DML)-এর যে হিসাব লিখে রাখে, আর সেই পরিবর্তনগুলো commit-এর ক্রমেই target-এ বসায়। কয়েক terabyte-এর migration-এ কয়েক দিন লাগতে পারে; CDC থাকলে target পিছিয়ে থেকেও ধরে ফেলে, তারপর যতদিন দরকার সমান তালে চলে, তাই শেষ cutover-এ কিছুই হারায় না।

#CDC-র জন্য source-এ কী লাগে

CDC তখনই চলে, যখন source ঠিক log, ঠিক format-এ, যথেষ্ট সময় ধরে রাখে। DMS task ব্যর্থ হওয়ার সবচেয়ে সাধারণ কারণ এটাই, আর নোটে এর কোনো উল্লেখ নেই।

DMS-এর এখনো দরকার এমন log মুছে গেলে (task থামানো থাকার সময় binlog-এর মেয়াদ ফুরিয়ে গেলে), task ব্যর্থ হয় আর ওই table-গুলো আবার লোড করতে হয়। PostgreSQL-এ ঘটে উল্টোটা: থামানো task-এর slot প্রতিটা WAL file ধরে রাখে, আর source-এর disk ভরে যেতে পারে।

#Cutover

1. CDC-কে ধরে ফেলতে দাও

   CloudWatch-এ task-এর CDC latency (source আর target) দেখো, যতক্ষণ না সেটা শূন্যের কাছে স্থির থাকে। Data validation চালাও, যাতে DMS দুই দিকের row মিলিয়ে দেখে।

2. Source-এ লেখা থামাও

   নিরিবিলি সময়ে (telco-র জন্য রাত ৩টা) application থামাও বা read-only করে দাও। এখন থেকে source-এ নতুন কিছু ঢুকবে না।

3. বাকিটা নামতে দাও, মিলিয়ে দেখো

   শেষ পরিবর্তনগুলো বসা পর্যন্ত অপেক্ষা করো (latency শূন্য, কিছু বাকি নেই) আর validation-এ কোনো অমিল নেই কি না দেখো। DMS যা আনেনি, তা এখন বানাও: secondary index, foreign key, trigger, আর শেষ মানের পরে বসানো sequence।

4. Switch করো, ফেরার পথ রাখো

   Application-কে target-এর দিকে ঘুরিয়ে দাও (connection string বদলে, বা তোমার নিজের একটা Route 53 record বদলে)। চাইলে নতুন database থেকে পুরোনোটায় উল্টো দিকে একটা CDC task চালু রাখো, যাতে প্রথম কয়েক দিনে কিছু গোলমাল হলে ফিরে যাওয়া যায়।

#Migration-টাকেই চালু রাখা

#Multi-AZ replication instance

সপ্তাহের পর সপ্তাহ CDC চলা একটা migration একটা server-এর ওপর ভর করে থাকে। Replication instance বিকল হলে task থেমে যায়; এত সময় বন্ধ থাকে যে source log মুছে ফেলে, তাহলে CDC আর শুরুই করা যায় না।

Multi-AZ চালু করলে DMS আরেকটা Availability Zone-এ একটা standby replication instance বানিয়ে রাখে, যার storage primary থেকে synchronous ভাবে replicate হয়। Primary বা তার AZ বিকল হলে DMS নিজে থেকেই standby-তে failover করে, আর task শেষ checkpoint থেকে আবার চলে। অপেক্ষার সময় standby কোনো কাজ করে না; খরচ প্রায় আরেকটা instance-এর সমান। Slide-এ AWS-এর বলা সুবিধাগুলোও আছে: ডেটার বাড়তি কপি, backup-এর সময় I/O আটকে না যাওয়া, আর latency হঠাৎ বেড়ে যাওয়া কম।

#DMS Serverless

DMS Serverless-এ replication instance আর তোমার হাতে থাকে না। তুমি একটা replication configuration বানাও (endpoint, migration type, table mapping, setting), আর capacity-র সর্বনিম্ন আর সর্বোচ্চ সীমা দাও DMS capacity unit (DCU)-তে; এক DCU মানে 2 GB memory। DMS source দেখে capacity হিসাব করে বসায়, replication চলার সময় বাড়ায়-কমায় (full load চলার সময় কমায় না), আর যতটা DCU ব্যবহার হয় ততটার টাকা নেয়। Multi-AZ-ও চলে, আর বেশিরভাগ চেনা engine (source হিসেবে Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, DocumentDB, Db2, S3; target হিসেবে relational engine, Redshift, S3, DynamoDB, Kinesis, MSK, OpenSearch, DocumentDB আর Neptune)। Load আগে থেকে আন্দাজ করা না গেলে বা instance-এর মাপ ঠিক করার ঝামেলায় যেতে না চাইলে এটা বাছো; Serverless যে engine সমর্থন করে না সেটা লাগলে, বা নির্দিষ্ট আর আগে থেকে জানা খরচ চাইলে provisioned instance বাছো।

#Task-এর আরও কিছু জানার মতো জিনিস

• Premigration assessment: task শুরুর আগে যাচাই (অসমর্থিত data type, primary key নেই, log setting ভুল, LOB column), report যায় S3-এ।
• Data validation: load চলার সময় আর পরে source আর target-এর row মিলিয়ে দেখে, প্রতিটা table-এর অমিল জানায়।
• Table mapping: selection rule (কোন schema, কোন table) আর transformation rule (schema-র নাম বদলানো, column যোগ, অক্ষরের ছোট-বড় বদলানো)।
• LOB mode: বড় object-এর column (লম্বা text, JSON, ছবি) DMS-কে ধীর করে দেয়। Limited LOB mode (default) দ্রুত, কিন্তু তোমার বেঁধে দেওয়া সর্বোচ্চ মাপের বেশি হলে কেটে দেয়; full LOB mode সবটা আনে, টুকরো টুকরো করে, ধীরে; inline LOB mode দুটোর মিশেল। বাছার আগে তোমার সবচেয়ে বড় LOB কত, জেনে নাও।
• খরচ: replication instance-এর টাকা (ঘণ্টা ধরে, Multi-AZ-এ বেশি) বা Serverless-এর DCU, সাথে বাড়তি storage; DMS-এ ডেটা ঢোকানো ফ্রি, আর DMS Schema Conversion-ও ফ্রি।

#Native পথ: RDS আর Aurora, MySQL আর PostgreSQL

AWS-এর ভেতরে একই engine পরিবারে সরাতে DMS অনেক সময় সবচেয়ে ভালো tool না। AWS-এর নিজস্ব replication আর snapshot সুবিধা সহজ, সস্তা আর দ্রুত। নোটের নিয়মটা: AWS-এর ভেতরে, একই engine হলে snapshot বা read replica-কে প্রাধান্য দাও; DMS ব্যবহার করো on-premises source-এর জন্য, engine বদলানোর জন্য, বা দুটো database পাশাপাশি চালু রাখতে হলে।

#RDS for MySQL থেকে Aurora MySQL

• উপায় ১: snapshot restore। RDS instance-এর একটা DB snapshot নাও, আর সেটা Aurora MySQL cluster হিসেবে restore (migrate) করো। সহজ আর সস্তা, কিন্তু snapshot থেকে restore শেষ হওয়া পর্যন্ত লেখা বন্ধ রাখতে হয়, যা বড় database-এ কয়েক ঘণ্টা।
• উপায় ২: Aurora read replica, তারপর promote (পরীক্ষার উত্তর)। RDS instance-এর একটা Aurora read replica বানাও: RDS একটা ব্যক্তিগত snapshot নেয়, তা থেকে Aurora cluster বানায়, তারপর binlog দিয়ে প্রতিটা পরিবর্তন replicate করে। Replica lag ০ হলে লেখা থামাও, replica-কে promote করে স্বাধীন cluster বানাও, আর app-কে সেদিকে ঘুরিয়ে দাও। Downtime কয়েক মিনিট। সময় লাগে (AWS বলে প্রথম কপিতে মোটামুটি TiB-প্রতি কয়েক ঘণ্টা), আর এর মধ্যে দুটো database-এরই টাকা দিতে হয়। একটা RDS instance-এর একটাই Aurora read replica, আর promote-এর আগে replica-য় লিখবে না, নইলে replication ভেঙে যাবে।

#বাইরের MySQL থেকে Aurora MySQL

• S3-এ Percona XtraBackup: on-premises MySQL-এর physical backup নাও Percona XtraBackup দিয়ে, file-গুলো একটা S3 bucket-এ তোলো, আর S3 থেকে নতুন একটা Aurora MySQL cluster বানাও (restore-db-cluster-from-s3)। বড় database লোড করার সবচেয়ে দ্রুত উপায়, লেসন ৭.৩-এ আগেই দেখেছ।
• mysqldump: একটা Aurora MySQL cluster বানিয়ে তাতে logical dump ঢালো। সহজ, কিন্তু S3-এর পদ্ধতির চেয়ে ধীর; ছোট database-এর জন্য ঠিক আছে।
• DMS, যখন দুটো database-ই চালু আর source-কে কাজ চালিয়ে যেতে হবে: full load আর CDC, অথবা মূল ডেটার জন্য native backup আর পরিবর্তনের জন্য একটা শুধু-CDC task (বা Aurora-য় MySQL-এর binlog replication)।

#RDS for PostgreSQL থেকে Aurora PostgreSQL

একই দুটো উপায়: RDS for PostgreSQL-এর DB snapshot restore করো Aurora PostgreSQL cluster হিসেবে (চলার পুরো সময় downtime), অথবা RDS for PostgreSQL instance-এর Aurora read replica বানাও আর lag ০ হলে promote করো (কয়েক মিনিটের downtime)।

#বাইরের PostgreSQL থেকে Aurora PostgreSQL

• pg_dump আর pg_restore (অথবা শুধু schema-র dump, আর ডেটার জন্য DMS)।
• Slide বলে: backup S3-এ রাখো, আর aws_s3 extension দিয়ে import করো। ঠিকভাবে বললে, aws_s3.table_import_from_s3 S3 থেকে ডেটার file (CSV, text বা binary COPY format) আগে থেকে থাকা table-এ ঢোকায়; এটা pg_dump backup restore করে না। তাই আগে schema বানাও, প্রতিটা table file-এ export করো, upload করো, তারপর import।
• Native logical replication (publication আর subscription) বা CDC সহ DMS, যখন দুটো database-ই চালু আর downtime কম রাখতে হবে।

#পথ বাছাই

#কোথায় গোলমাল হয়

• Test connection ব্যর্থ: replication instance থেকে কোনো network পথ নেই (VPN-এর route নেই, firewall বা security group-এ rule নেই, private instance কিন্তু পথ নেই), অথবা user, password বা SSL setting ভুল।
• CDC শুরুই হয় না বা থেমে যায়: binary logging বন্ধ, binlog_format ROW না, RDS-এর automated backup বন্ধ, Oracle-এর supplemental logging নেই, PostgreSQL-এর logical replication বন্ধ।
• বিরতির পর task ব্যর্থ: DMS-এর দরকারি log source মুছে ফেলেছে। Log ২৪ ঘণ্টা বা বেশি রাখো, CDC latency-তে alarm রাখো, Multi-AZ চালু করো।
• Source-এর disk ভরে গেছে (PostgreSQL): থামানো বা মুছে ফেলা task-এর replication slot WAL ধরে রেখেছে। Task আবার চালাও বা slot drop করো।
• Target ধীর, latency বাড়ছে: update আর delete-এর জন্য target-এ primary key বা index নেই, replication instance ছোট, বা full LOB mode-এ LOB column।
• Target-এ text বা ছবি কাটা: limited LOB mode, আর বেঁধে দেওয়া সর্বোচ্চ মাপ আসল LOB-এর চেয়ে ছোট।
• Cutover-এর পর application-এ error: target-এ secondary index, foreign key, trigger বা sequence কখনো বানানো হয়নি, অথবা stored code বদলানো হয়নি (SCT-এর action item উপেক্ষা করা)।
• Row হারিয়েছে: লেখা চালু রেখে শুধু full load-এর task, অথবা MySQL-এর cascade delete, যা binlog-এ ওঠে না।
• Aurora read replica ভেঙে গেছে: promote-এর আগে কেউ তাতে লিখেছে। আবার বানাও।
• ভুল tool বাছা: RDS MySQL থেকে Aurora MySQL-এ DMS (চলে, কিন্তু read replica-র চেয়ে ধীর আর দামি), অথবা দুটো on-premises site-এর মধ্যে DMS-এর পরিকল্পনা (সমর্থিত না)।

#System design-এ DMS

• ফেরার পথ সহ migration: নতুন database-এ DMS full load আর CDC, cutover, তারপর এক সপ্তাহ পুরোনো database-এর দিকে উল্টো একটা CDC task, যাতে কোনো খারাপ চমক মানে শুধু ফিরে যাওয়া, restore না।
• Engine আধুনিক করা: license-এর খরচ কমাতে Oracle বা SQL Server থেকে Aurora PostgreSQL-এ SCT আর DMS; SQL Server app নতুন করে লেখা না গেলে Babelfish (লেসন ১৬.১ আর ১৬.২)।
• Analytics-কে ডেটা খাওয়ানো: চালু database থেকে S3 (Parquet), Kinesis Data Streams বা MSK-এ চলমান CDC, যাতে production-এ query না করেই data lake বা Redshift warehouse কয়েক সেকেন্ডের মধ্যে পরিবর্তন পায় (লেসন ১৭.৮)। Aurora আর RDS থেকে Redshift-এ zero-ETL integration এখন এর একটা অংশ সামলায়।
• বিশাল migration: মূল ডেটা Snowball-এ বা native backup হিসেবে পাঠাও, তারপর লিখে রাখা log-এর অবস্থান থেকে একটা শুধু-CDC task চালাও (লেসন ২৩.৫)।
• এক করা আর ভাগ করা: table mapping দিয়ে একটা task বড় database থেকে কয়েকটা schema বের করে আনতে পারে, বা অনেক ছোট database এক জায়গায় আনতে পারে।

#নিজে করে দেখো

এই command-গুলো AWS CLI v2-এর, নাম, ID আর IP সব বানানো। Replication instance-এর জন্য প্রতি ঘণ্টায় টাকা লাগে, তাই শেষে সব মুছে ফেলো।

# ১. Private subnet-এ একটা Multi-AZ replication instance (subnet group আগে থেকেই আছে)
aws dms create-replication-instance \
  --replication-instance-identifier telco-mig-ri \
  --replication-instance-class dms.r5.xlarge \
  --allocated-storage 200 --multi-az --no-publicly-accessible \
  --replication-subnet-group-identifier dms-private-subnets
# "ReplicationInstanceStatus": "creating", "MultiAZ": true

# ২. Source (Direct Connect দিয়ে on-premises Oracle) আর target (Aurora PostgreSQL) endpoint
aws dms create-endpoint --endpoint-identifier oracle-src --endpoint-type source \
  --engine-name oracle --server-name 10.20.1.15 --port 1521 \
  --database-name BILLING --username dms_user --password 'use-a-secret-instead'
aws dms create-endpoint --endpoint-identifier aurora-tgt --endpoint-type target \
  --engine-name aurora-postgresql \
  --server-name billing.cluster-abcdefexample.ap-south-1.rds.amazonaws.com \
  --port 5432 --database-name billing --username dms_user --password 'use-a-secret-instead'

# ৩. Replication instance থেকে দুটো connection-ই test করো
aws dms test-connection \
  --replication-instance-arn arn:aws:dms:ap-south-1:111122223333:rep:EXAMPLERI \
  --endpoint-arn arn:aws:dms:ap-south-1:111122223333:endpoint:EXAMPLESRC
aws dms describe-connections --query 'Connections[].[EndpointIdentifier,Status]'
# [ [ "oracle-src", "successful" ], [ "aurora-tgt", "successful" ] ]

# ৪. BILLING schema-র জন্য full load আর CDC task, validation চালু
cat > mappings.json <<'EOF'
{ "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "billing",
  "object-locator": { "schema-name": "BILLING", "table-name": "%" }, "rule-action": "include" } ] }
EOF
aws dms create-replication-task --replication-task-identifier billing-full-cdc \
  --migration-type full-load-and-cdc \
  --source-endpoint-arn arn:aws:dms:ap-south-1:111122223333:endpoint:EXAMPLESRC \
  --target-endpoint-arn arn:aws:dms:ap-south-1:111122223333:endpoint:EXAMPLETGT \
  --replication-instance-arn arn:aws:dms:ap-south-1:111122223333:rep:EXAMPLERI \
  --table-mappings file://mappings.json \
  --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}'
aws dms start-replication-task --start-replication-task-type start-replication \
  --replication-task-arn arn:aws:dms:ap-south-1:111122223333:task:EXAMPLETASK

# ৫. Table ধরে অগ্রগতি
aws dms describe-table-statistics \
  --replication-task-arn arn:aws:dms:ap-south-1:111122223333:task:EXAMPLETASK \
  --query 'TableStatistics[].[TableName,FullLoadRows,Inserts,Updates,TableState,ValidationState]'
# [ [ "RECHARGES", 81200400, 52311, 0, "Table completed", "Validated" ],
#   [ "SUBSCRIBERS", 9400212, 1180, 40221, "Table completed", "Validated" ] ]

# ৬. একই migration DMS Serverless-এ: ২ থেকে ৩২ DCU-র একটা replication config
aws dms create-replication-config --replication-config-identifier billing-serverless \
  --replication-type full-load-and-cdc \
  --source-endpoint-arn arn:aws:dms:ap-south-1:111122223333:endpoint:EXAMPLESRC \
  --target-endpoint-arn arn:aws:dms:ap-south-1:111122223333:endpoint:EXAMPLETGT \
  --table-mappings file://mappings.json \
  --compute-config 'MinCapacityUnits=2,MaxCapacityUnits=32,MultiAZ=true,ReplicationSubnetGroupId=dms-private-subnets'

-- ৭. RDS for MySQL source-এ binlog ২৪ ঘণ্টা রাখো, যাতে বিরতির পরও CDC টিকে থাকে
call mysql.rds_set_configuration('binlog retention hours', 24);
call mysql.rds_show_configuration;
-- binlog retention hours | 24

# ৮. Native পথে RDS MySQL থেকে Aurora MySQL: Aurora read replica cluster, তারপর promote
aws rds create-db-cluster --db-cluster-identifier shop-aurora --engine aurora-mysql \
  --replication-source-identifier arn:aws:rds:ap-southeast-1:111122223333:db:shop-mysql \
  --db-subnet-group-name shop-db-subnets --vpc-security-group-ids sg-0abcd1234example
aws rds create-db-instance --db-cluster-identifier shop-aurora \
  --db-instance-identifier shop-aurora-1 --db-instance-class db.r6g.large --engine aurora-mysql
# ...replica lag ০ আর RDS-এ লেখা বন্ধ হলে:
aws rds promote-read-replica-db-cluster --db-cluster-identifier shop-aurora

# ৯. S3-এর Percona XtraBackup file থেকে বাইরের MySQL Aurora-য়
aws rds restore-db-cluster-from-s3 --db-cluster-identifier erp-aurora \
  --engine aurora-mysql --master-username admin --manage-master-user-password \
  --source-engine mysql --source-engine-version 8.0.36 \
  --s3-bucket-name erp-backup-example --s3-prefix xtrabackup/2026-11-01 \
  --s3-ingestion-role-arn arn:aws:iam::111122223333:role/aurora-s3-import

# ১০. পরিষ্কার করো
aws dms delete-replication-task --replication-task-arn arn:aws:dms:ap-south-1:111122223333:task:EXAMPLETASK
aws dms delete-replication-instance --replication-instance-arn arn:aws:dms:ap-south-1:111122223333:rep:EXAMPLERI

Console-এও চেষ্টা করো: DMS Schema Conversion-এ একটা migration project খোলো, নমুনা একটা schema-র ওপর assessment চালাও, আর দেখো কোন কোন object-কে সে হাতে কাজ লাগবে বলে চিহ্নিত করে।

#সারসংক্ষেপ

মূল কথাগুলো

• DMS database-এর মধ্যে ডেটা সরায়, আর এর মধ্যে source চালু থাকে: একটা replication instance (বা DCU দিয়ে মাপা DMS Serverless) একটা source endpoint থেকে পড়ে target endpoint-এ লেখে; cutover-এ downtime সামান্য, শূন্য না।
• অন্তত একটা endpoint AWS-এ থাকতেই হবে; on-premises থেকে on-premises, বা এক cloud থেকে আরেক cloud, সমর্থিত না।
• Source-এর মধ্যে Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, SAP ASE, Db2, Azure SQL, RDS, Aurora, S3, DocumentDB; target-এ এর সাথে Redshift, DynamoDB, S3, OpenSearch Service (“Elasticsearch” না), Kinesis, Kafka/MSK, DocumentDB, Neptune, Redis, Babelfish।
• Homogeneous (একই engine): SCT লাগে না। Heterogeneous (Oracle → PostgreSQL, SQL Server → MySQL): SCT (বা DMS Schema Conversion) schema আর code বদলায়, report-এ action item দেখায়, তারপর DMS ডেটা আনে। DMS নিজে শুধু table আর primary key বানায়। SCT warehouse-কেও Redshift-এর উপযোগী করে।
• Task type: full load, full load আর CDC (সাধারণত এটাই), শুধু CDC। CDC transaction log পড়ে, আর log রেখে দিতে হয়: ROW format আর মেয়াদ সহ binlog, Oracle-এর supplemental logging, PostgreSQL-এর logical replication (slot-এর দিকে নজর)।
• Multi-AZ replication instance = অন্য AZ-এ synchronous standby, নিজে থেকে failover: fault-tolerant migration-এর উত্তর।
• AWS-এর ভেতরে, একই engine: RDS MySQL/PostgreSQL → Aurora যায় Aurora read replica + promote (কয়েক মিনিট) বা snapshot restore (কয়েক ঘণ্টা) দিয়ে। বাইরের MySQL → S3-এ Percona XtraBackup বা mysqldump; বাইরের PostgreSQL → pg_dump, aws_s3 দিয়ে file import, বা দুটোই চালু রাখতে হলে DMS।

নিজেকে যাচাই করো: DMS, SCT আর database migration৩০টি প্রশ্ন