Amazon Aurora-র ভেতর-বাহির

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

• RDS for MySQL বা PostgreSQL থেকে Aurora কোথায় আলাদা, বুঝিয়ে বলতে: compute আর storage আলাদা, একটাই শেয়ার করা cluster volume, ৩টা AZ-এ ৬টা কপি, quorum write (৬-এ ৪) আর read (৬-এ ৩), আর self-healing।
• একটা Aurora DB cluster-এর গঠন বলতে: একটা writer, ১৫টা পর্যন্ত Aurora Replica, failover priority tier, মোটামুটি ৩০ সেকেন্ডে failover আর 100 ms-এর কম replica lag।
• ঠিক endpoint (cluster, reader, instance, custom) বাছতে, আর ব্যাখ্যা করতে কেন Aurora failover-এ connection string কখনো বদলাতে হয় না, অথচ promote করা RDS read replica-র জন্য নতুন string লাগে।
• Replica auto scaling আর Aurora Serverless v2 (ACU, minimum আর maximum, auto-pause দিয়ে 0-তে নামা) সাজাতে, আর কোনটা কখন মানায় বলতে।
• Aurora Global Database দিয়ে কয়েক Region জুড়ে read আর disaster recovery-র design করতে, আর switchover আর failover-এর তফাত বলতে।
• কোনো recovery বা testing-এর দরকারে backup, point-in-time restore, Backtrack আর cloning-এর মধ্যে ঠিকটা বাছতে, আর Aurora machine learning, Babelfish, I/O-Optimized আর zero-ETL চিনতে।
• Aurora-র দিকে ইশারা করা পরীক্ষার প্রতিটা প্রশ্নের ধরন চিনে ফেলতে।

#Aurora কেন এল

লেসন ৭.১-এ RDS দেখেছ: AWS একটা সাধারণ database engine (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2) চালায় EBS volume লাগানো একটা EC2 instance-এ, আর patch, backup, failover-এর ঝামেলা নিজে সামলায়। কিন্তু ওই engine-গুলো বানানো হয়েছিল কয়েক দশক আগে, এক server আর তার নিজের disk-এর কথা ভেবে, আর RDS তাদের সীমাবদ্ধতাগুলোও পেয়েছে: standby বা replica-র লাগে নিজের পুরো একটা কপি, replica-কে primary-র log আবার চালাতে হয় বলে সে পিছিয়ে পড়ে, আর storage মানে একটা EBS volume, যার size তোমাকেই ঠিক করতে হয়।

Amazon Aurora হলো AWS-এর নিজের বানানো relational database engine, শুরু থেকেই cloud-এর জন্য ভেবে বানানো। মূল কথাগুলো:

• Proprietary (open source না), কিন্তু MySQL আর PostgreSQL-এর সাথে compatible: তোমার driver, tool আর বেশিরভাগ SQL যেমন ছিল তেমনই চলে, যেন Aurora আসলে MySQL বা PostgreSQL। Cluster বানানোর সময় বেছে নাও Aurora MySQL না Aurora PostgreSQL।
• এটা চালানো হয় RDS দিয়েই (একই console, একই aws rds command), কিন্তু এর storage পুরোপুরি আলাদা।
• Performance: AWS প্রচার করে একই hardware-এ এটা MySQL-এর চেয়ে ৫ গুণ আর PostgreSQL-এর চেয়ে ৩ গুণ পর্যন্ত throughput দেয়। এগুলোকে AWS-এর marketing-এর সংখ্যা হিসেবেই নাও, AWS-এর নিজের benchmark-এ মাপা; তোমার workload-এ আসল লাভ কত হবে, সেটা workload-এর ওপর নির্ভর করে। পরীক্ষায় “high performance, MySQL/PostgreSQL-compatible” মানেই Aurora।
• খরচ: একই RDS instance-এর চেয়ে ঘণ্টাপ্রতি মোটামুটি ২০% বেশি, কিন্তু storage replication, দ্রুত failover আর বেশি replica পাও বাড়তি কপির টাকা না দিয়েই।

#Storage-এর স্তর: তিন AZ-এ ছয়টা কপি

#Compute আর storage আলাদা

একটা Aurora cluster-এর দুটো স্তর:

• Compute: DB instance-গুলো (একটা writer আর কয়েকটা reader)। এরা database engine চালায়, memory-তে cache রাখে আর SQL প্রসেস করে। স্থায়ী কোনো data এদের কাছে থাকে না।
• Storage: cluster volume, SSD দিয়ে বানানো একটা distributed volume, যেটা ৩টা Availability Zone-এর শত শত storage node-এ ছড়ানো। Cluster-এর সব instance এই একটাই volume-এ পড়ে আর লেখে।

Data যেহেতু instance-এ থাকে না, তাই নতুন reader যোগ করতে কিছু কপি করতে হয় না, instance মুছলে data মোছে না, আর failover মানে শুধু অন্য একটা instance একই volume-এর ওপর writer-এর ভূমিকা নেয়।

#Segment, ছয় কপি আর quorum

Cluster volume কাটা থাকে 10 GiB-এর segment-এ। প্রতিটা segment রাখা হয় ৬ বার: ৩টা AZ-এর প্রতিটায় ২টা করে কপি (৬টা কপির এই দলকে বলে protection group)। Writer পুরো data page storage-এ পাঠায় না; পাঠায় শুধু redo log record (প্রতিটা পরিবর্তনের বিবরণ), আর storage node-গুলো নিজেরাই page বানিয়ে নেয়। ফলে network দিয়ে অনেক কম data যায়।

কোনো কাজ কখন গণ্য হবে, সেটা ঠিক করতে Aurora একটা quorum ব্যবহার করে:

• Write টেকসই হয় যখন ৬টার মধ্যে ৪টা কপি সম্মতি দেয়। Writer ৬টাতেই পাঠায়, আর সবচেয়ে দ্রুত ৪টা উত্তর দিলেই এগিয়ে যায়, তাই একটা ধীর disk কখনো database-কে ধীর করতে পারে না।
• Read-এর লাগে ৬টার মধ্যে ৩টা (বাস্তবে writer জানে কোন কপি হালনাগাদ, তাই একটা থেকেই পড়ে; quorum-এর দরকার পড়ে recovery-র সময়)।
• ৪ + ৩ = ৭, যা ৬-এর চেয়ে বেশি, তাই যেকোনো read quorum শেষ write quorum-এর সাথে অন্তত একটা কপিতে মিলবেই: ৩টার অন্তত একটার কাছে সবচেয়ে নতুন data আছে।

কী কী সহ্য করতে পারে:

মানে পুরো একটা AZ হারালেও Aurora write নিতে থাকে, আর একটা AZ আর তার ওপর আরও একটা কপি হারালেও data পড়া যায় (আর মেরামত করা যায়)।

#Self-healing

Storage node-গুলো সারাক্ষণ নিজেদের কপি পরীক্ষা করে, আর যা নেই তা পাশের কপিগুলোর সাথে আদান-প্রদান করে পূরণ করে (peer-to-peer gossip)। কোনো কপি হারালে Aurora বেঁচে থাকা কপিগুলো থেকে অন্য একটা storage node-এ সেটা আবার বানায়। একটা segment মাত্র 10 GiB, তাই মেরামতে কয়েক সেকেন্ড লাগে; ফলে দ্বিতীয় কোনো বিপদ ক্ষতি করার সময়টা খুব ছোট থাকে। তুমি এর কিছুই দেখো না: কোনো RAID সামলাতে হয় না, কোনো volume বদলাতে হয় না।

এবার নিজে হাতে চেষ্টা করো: কপি আর AZ নষ্ট করে দেখো কখন write আর read থেমে যায়।

#Storage নিজে থেকেই বাড়ে (আর কমে)

• Data যত যোগ হয়, cluster volume নিজে থেকেই বাড়ে; storage বা IOPS কখনো আগে থেকে ঠিক করে দিতে হয় না। সর্বোচ্চ 128 TiB, আর নতুন engine version-এ (Aurora MySQL 3.10 আর তার ওপরে, Aurora PostgreSQL 15.13, 16.9, 17.5 আর তার ওপরে) 256 TiB।
• Table drop করলে বা data মুছলে নতুন version-গুলো bill-এর size আবার কমিয়ে দেয় (dynamic resizing)।
• যতটুকু storage আসলে ব্যবহার করছ, তার দাম একবারই দাও, কপি ধরে ধরে না: ৬টা কপি দামের মধ্যেই ধরা।

Slide-এর “10 GB করে বাড়ে, 256 TB পর্যন্ত” কথাটা আসলে 10 GiB-এর segment-এর কথা বলছে; note-এর “10 GB থেকে 128 TB” ছিল অনেকদিনের পুরনো সীমা। পরীক্ষার জন্য মনে রাখো “নিজে থেকে বাড়ে, 128 TiB পর্যন্ত” (নতুন version-এ 256 TiB)।

#Aurora DB cluster

একটা Aurora DB cluster মানে cluster volume, আর সেটা ব্যবহার করা DB instance-গুলো:

• একটা writer (primary) instance: write (INSERT, UPDATE, DELETE, schema বদল) নেয় শুধু এটাই। Read-ও সামলায়।
• ১৫টা পর্যন্ত Aurora Replica (reader): একই volume-এর ওপর read-only instance, বিভিন্ন AZ-এ ছড়ানো। এরা SELECT query সামলায়, আর এরাই failover-এর লক্ষ্য।
• চাইলে reader-রা serverless (পরের অংশে) বা provisioned হতে পারে, যেকোনো মিশেলে।

#Replica lag

RDS read replica primary-র log নিজের data কপিতে আবার চালায়, তাই সেকেন্ড বা মিনিট পিছিয়ে পড়তে পারে। Aurora Replica পড়ে একই storage থেকে; writer তাকে শুধু জানায় cache-এর কোন page বদলেছে। তাই replica lag সাধারণত 100 ms-এর কম (slide বলে “10 ms-এর কম”; AWS-এর documentation বলে “সাধারণত 100 ms-এর অনেক কম”)। CloudWatch-এর AuroraReplicaLag metric-এ এটা দেখো।

#Failover আর priority tier

Writer নষ্ট হলে (instance crash, AZ বিপর্যয়, বা তুমি নিজেই failover চালালে) Aurora নিজে থেকে একটা reader-কে writer বানায়:

1. সবচেয়ে বেশি priority-র reader বাছে: প্রতিটা reader-এর একটা promotion tier থাকে, 0 (সবচেয়ে বেশি) থেকে 15 (সবচেয়ে কম)।
2. একই tier-এ কয়েকটা থাকলে বাছে সবচেয়ে বড় instance; size-ও সমান হলে যেকোনো একটা।
3. Cluster endpoint ঘুরিয়ে দেওয়া হয় নতুন writer-এর দিকে (পরের অংশ)।

কপি করার বা পিছিয়ে থাকা ধরার কিছু নেই, তাই failover সাধারণত ৩০ সেকেন্ডের কম সময়ে শেষ হয়, RDS Multi-AZ standby-র (৬০–১২০ সেকেন্ড) চেয়ে অনেক দ্রুত। Slide বলে “instantaneous” আর note বলে “millisecond”: দুটোই বাড়িয়ে বলা। Application তবুও connection কাটা দেখে আর আবার connect করতে হয়; AWS-এর Advanced JDBC/Python/Go wrapper আর RDS Proxy (লেসন ৭.৪) বিরতিটা কয়েক সেকেন্ডে নামিয়ে আনে।

একটাও reader না থাকলে Aurora একই বা অন্য AZ-এ নতুন একটা writer instance বানায়। Data নিরাপদ (সেটা ৩-AZ storage-এ আছে), কিন্তু এতে প্রায় ১০ মিনিট লাগে। High availability চাইলে সবসময় অন্য AZ-এ অন্তত একটা reader রাখো।

Tier নিয়ে একটা পরামর্শ: যে reader-এর দায়িত্ব নেওয়ার কথা, তাকে কম tier (0 বা 1) দাও আর writer-এর সমান size রাখো। Analytics বা report-এর reader-দের বেশি tier (2–15) দাও, যাতে তারা promote না হয়।

#Endpoint: যে নামে তোমার app connect করে

Instance-এর ঠিকানার বদলে Aurora তোমাকে কয়েকটা DNS নাম (endpoint) দেয়। প্রতিটা endpoint একটা CNAME, যেটা Aurora সবসময় ঠিক instance-এর দিকে ঘুরিয়ে রাখে।

দুটো জিনিস নিয়ে অনেকে হোঁচট খায়:

• Reader endpoint ভাগ করে connection, query না। DNS প্রতিটা নতুন connection-কে একটা আলাদা reader দেয়; একটা connection-এর সব query একই reader-এ যায়। যে app একটাই connection অনেকক্ষণ খুলে রাখে, সে কোনো ভাগাভাগি পায় না। Connection pool ব্যবহার করো।
• Reader endpoint-এ সব reader থাকে। বিশেষ instance-এর জন্য custom endpoint বানালে সাধারণ traffic-ও সাধারণ reader-দের একটা custom endpoint-এ পাঠাও, নইলে customer-এর query analytics instance-এ গিয়ে পড়তে পারে। (AWS-এর ভাষায়: custom endpoint বানানোর পর reader endpoint সাধারণত আর ব্যবহার হয় না।)

#“Failover-এর সময় connection string বদলানো যাবে না”: আসল মানে কী

পরীক্ষার একটা পুরনো প্রশ্ন: “Failover-এর সময় বারবার connection string না বদলে application কীভাবে read আর write traffic আলাদা করবে?” উত্তর: write-এর জন্য cluster endpoint, read-এর জন্য reader endpoint। এখানে owner-এর মনে খুব স্বাভাবিক একটা প্রশ্ন জাগে: “একদিকে বলছে connection string বদলানো যাবে না, আবার বলছে দুটো আলাদা endpoint ব্যবহার করতে! এটা কীভাবে সম্ভব?”

আসল চাবি হলো “failover-এর সময়” কথাটা। দুটো নাম তুমি বসাও একবারই, app বানানোর সময়। প্রশ্নটা জানতে চায় তারপর কী হয়, যখন একটা database নষ্ট হয়।

1. শুরুর setup, একবারই

   App-এর config file-এ দুটো connection string বসানো হয়: write → mycluster.cluster-12345.us-east-1.rds.amazonaws.com, read → mycluster.cluster-ro-12345.us-east-1.rds.amazonaws.com। এটা app বানানোর স্বাভাবিক একটা ধাপ।

2. সাধারণ RDS আর একটা read replica: সমস্যাটা

   Primary মারা গেল। Read replica নিজে থেকে promote হয় না, তাই তুমি হাতে promote করলে। Promote হওয়া replica হয়ে যায় একটা আলাদা স্বাধীন database, নিজের endpoint নিয়েই (mydb-replica…), যা পুরনো primary-র (mydb…) থেকে আলাদা। App তখনো মরা নামটাই দেখছে: কাউকে config খুলে নতুন URL বসাতে হবে, তারপর app restart বা redeploy করতে হবে। এটাই “failover-এর সময় connection string বদলানো”: হাতে করা, ধীর, আর যতক্ষণ চলে ততক্ষণ downtime।

3. Aurora: একই বিপদ

   Cluster-এ একটা writer আর দুটো replica। Writer crash করল। Aurora নিজে থেকেই tier দেখে একটা replica-কে promote করল। তারপর cluster endpoint-এর পেছনের DNS record বদলে দিল, যাতে একই নাম এখন নতুন writer-এর ঠিকানা দেয়।

4. ফলাফল

   App হুবহু একই নামে আবার connect করে নতুন writer-এ পৌঁছায়, সাধারণত ৩০ সেকেন্ডের মধ্যে। কাউকে কোনো file খুলতে বা কিছু restart করতে হয় না। Reader endpoint-ও একইভাবে যে reader-রা আছে, তাদেরই দেখাতে থাকে।

পরীক্ষার জন্য এক লাইনে: cluster endpoint (write) আর reader endpoint (read) একবার বসাও; failover হলে এগুলো পেছনে নিজে থেকেই সরে যায়, তাই connection string কখনো বদলাতে হয় না। (RDS Multi-AZ-ও failover-এ একটাই endpoint রাখে, কারণ standby একই নামের দায়িত্ব নেয়; কিন্তু Multi-AZ-এর standby instance কোনো read সামলায় না। লেসন ৭.১-এ এটা আছে।)

#Replica auto scaling

Aurora Auto Scaling, Application Auto Scaling ব্যবহার করে, নিজে থেকেই Aurora Replica যোগ করে আর সরায়:

• একটা metric-এর ওপর target tracking policy: reader-দের গড় CPU (RDSReaderAverageCPUUtilization) বা reader-দের গড় connection (RDSReaderAverageDatabaseConnections)। যেমন: reader-দের গড় CPU 60%-এ রাখো।
• Replica-র একটা minimum আর maximum সংখ্যা (maximum ১৫ পর্যন্ত)।
• নতুন replica শেয়ার করা volume-এ যুক্ত হয় (কোনো data কপি না), নিজে থেকেই reader endpoint-এ ঢুকে যায়, আর load কমলে (একটা cooldown-এর পর) সরে যায়। চালু হতে কয়েক মিনিট লাগে, তাই ৩০ সেকেন্ডের হঠাৎ লাফের চেয়ে টানা বাড়তে থাকা load-এ বেশি কাজে দেয়।
• তুমি হাতে যে replica যোগ করেছ, policy সেটা কখনো সরায় না; আর Global Database-এর secondary cluster-এ auto scaling চলে না।

মুহূর্তের মধ্যে, খুব সূক্ষ্মভাবে scale দরকার হলে এর সাথে Serverless v2 reader মিশিয়ে নাও।

#Aurora Serverless v2

Provisioned instance-এ তুমি একটা instance class (db.r6g.large, …) বাছো আর ব্যস্ত থাকুক বা অলস, প্রতি ঘণ্টার টাকা দাও। Aurora Serverless v2-এ তুমি বাছো একটা capacity range, আর Aurora সেকেন্ডে সেকেন্ডে instance-এর size ঠিক করে দেয়।

• Capacity মাপা হয় ACU (Aurora capacity unit)-তে: 1 ACU ≈ 2 GiB memory, সাথে মানানসই CPU আর network।
• Cluster-এর জন্য একটা minimum আর maximum দাও: 0 (বা 0.5) থেকে 256 ACU পর্যন্ত (নতুন Aurora PostgreSQL version-এ 384)। প্রতিটা serverless instance এই range-এর ভেতরে আলাদাভাবে ওঠানামা করে।
• Scale হয় জায়গায় দাঁড়িয়েই, কয়েক সেকেন্ডে, 0.5 ACU-র মতো ছোট ধাপে, failover ছাড়া, connection না কেটে। তোমার দেওয়া maximum কখনো পার হয় না।
• টাকা দাও ব্যবহার করা ACU-র জন্য প্রতি সেকেন্ডে (ACU-hour হিসেবে), সাথে যথারীতি storage আর I/O।
• 0-তে নামা (auto-pause), ২০২৪-এর শেষ থেকে: minimum 0 ACU দাও, তাহলে কোনো instance-এ একটা নির্দিষ্ট সময় কোনো user connection না এলে (SecondsUntilAutoPause, default ৩০০ সেকেন্ড, সর্বোচ্চ ১ দিন) সে pause হয়ে যায়। Pause থাকা অবস্থায় compute-এর খরচ শূন্য; storage-এর bill অবশ্য চলে। পরের connection তাকে জাগায় প্রায় ১৫ সেকেন্ডে (২৪ ঘণ্টার বেশি pause থাকলে ৩০ সেকেন্ড বা তার বেশি), তাই client-এর connection timeout আর retry লাগবে। খোলা connection, RDS Proxy, binlog বা logical replication, zero-ETL integration আর Global Database-এর cluster হওয়া, এগুলোর যেকোনোটা pause আটকে দেয়।
• মিশ্র cluster: একটা cluster-এ serverless (db.serverless) আর provisioned দুই ধরনের instance-ই থাকতে পারে, যেমন বড় একটা provisioned writer আর serverless reader, বা serverless writer আর স্থির provisioned reader।
• Tier 0 বা 1-এর serverless reader writer-এর capacity মেনে চলে (যাতে দায়িত্ব নিতে তৈরি থাকে); tier 2–15-এর reader-রা আলাদাভাবে ওঠানামা করে।
• Aurora-র সব feature এতে আছে: Multi-AZ reader, Global Database, RDS Proxy, Backtrack, cloning।

Aurora Serverless v1 (প্রথম সংস্করণ, যেটা 0-তে pause করতে পারত কিন্তু ধীরে scale করত আর reader রাখতে পারত না) ৩১ মার্চ ২০২৫-এ বন্ধ (end of life) হয়েছে; বাকি v1 cluster-গুলো v2-তে সরিয়ে নেওয়া হয়েছে। Slide-এর “proxy fleet” ওয়ালা ছবিটা v1-এর গঠন। পরীক্ষায় “Aurora Serverless” দেখলে v2 ভাবো।

কখন ব্যবহার করবে:

• কালেভদ্রে, থেমে থেমে বা আন্দাজ করা যায় না এমন workload: অজানা traffic-এর নতুন app, মাঝেমধ্যে promotion চলা site, মাসের শেষে চালানো report-এর database।
• রাতে আর ছুটির দিনে অলস dev আর test database (auto-pause সহ)।
• অনেকগুলো ছোট database (প্রতি tenant-এ একটা), যেগুলো বেশিরভাগ সময় অলস।
• স্থির, আন্দাজ করা যায় এমন ২৪×৭ load-এর জন্য আদর্শ না: সেখানে Reserved Instance সহ provisioned instance সাধারণত সস্তা।

#Aurora Global Database

Multi-AZ তোমাকে বাঁচায় একটা Region-এর ভেতরে। পুরো Region বসে গেলে, বা অন্য মহাদেশের user-দের জন্য, Aurora-র দুটো cross-Region উপায় আছে।

Aurora Global Database (AWS এটাই সুপারিশ করে):

• ১টা primary Region (read/write) আর ১০টা পর্যন্ত secondary Region (শুধু read)। Note-এ লেখা ৫টা; AWS সেটা বাড়িয়ে ১০ করেছে, slide-এও তাই আছে।
• Replication হয় storage-এর স্তরে, AWS-এর নিজস্ব আলাদা পথে, lag সাধারণত ১ সেকেন্ডের কম, আর primary-র database engine-এর ওপর প্রায় কোনো চাপ নেই।
• প্রতিটা secondary cluster-এ ১৬টা পর্যন্ত read-only instance থাকতে পারে (সাধারণ ১৫-র চেয়ে একটা বেশি, কারণ সেখানে writer নেই)। কাছের user-রা কাছের latency-তে পড়ে।
• Write forwarding: secondary cluster app-এর write নিয়ে নিজেই primary-তে পৌঁছে দিতে পারে, তাই secondary Region-এর app একটা কাছের endpoint দিয়েই চলতে পারে। তবে write-কে Region পার হয়ে যাওয়া-আসার সময়টা দিতেই হয়।
• একটা global writer endpoint সবসময় বর্তমান primary cluster-কে দেখায়, primary অন্য Region-এ সরে গেলেও।

Primary সরানোর দুই উপায়:

Aurora PostgreSQL-এ একটা managed RPO সেট করা যায়: কোনো secondary ওই কয়েক সেকেন্ডের মধ্যে না থাকলে primary commit নেওয়াই বন্ধ করে দেয়, ফলে failover-এ কতটা data হারাতে পারে তার একটা সীমা থাকে।

Aurora cross-Region read replica (পুরনো উপায়, binlog replication দিয়ে Aurora MySQL-এ) দিয়েও অন্য Region-এ একটা কপি পাওয়া যায়, বানানো সহজ আর DR-এ কাজে লাগে, কিন্তু replication যায় database engine দিয়ে (ধীর, বেশি lag, writer-এর ওপর চাপ), আর promote হাতে করতে হয়, সময়ও বেশি লাগে। Global Database-ই বেছে নাও।

#Aurora machine learning

সাধারণত app-এ একটা prediction যোগ করতে হলে data export করো, ML service-এ পাঠাও, ফলাফল আবার লিখে ফেরত আনো। Aurora machine learning দিয়ে AWS-এর ML service-গুলোকে সরাসরি SQL থেকেই ডাকা যায়:

• Amazon SageMaker AI: তোমার train করে deploy করা যেকোনো model (জালিয়াতি ধরা, product সুপারিশ, বিজ্ঞাপন কাকে দেখাবে)।
• Amazon Comprehend: তৈরি করা natural language processing, যেমন একটা review-এর sentiment (ভালো, খারাপ, নিরপেক্ষ), কোনো model train করতে হয় না।
• Amazon Bedrock (নতুন): foundation model, যেমন SQL থেকেই লেখা সংক্ষেপ করা বা embedding বানানো।

ML-এর অভিজ্ঞতা লাগে না: একটা IAM role cluster-কে service ডাকার অনুমতি দেয়, আর তুমি SQL function ব্যবহার করো, যেমন Aurora PostgreSQL-এ:

SELECT review_id,
       (aws_comprehend.detect_sentiment(review_text, 'en')).sentiment
FROM product_reviews
WHERE created_at > now() - interval '1 day';

Slide আর note-এর ব্যবহারগুলো: জালিয়াতি ধরা, বিজ্ঞাপনের লক্ষ্য ঠিক করা, sentiment analysis, product সুপারিশ (“এই customer-কে কোন product দেখাব?”)।

#Babelfish for Aurora PostgreSQL

অনেক কোম্পানির app চলে Microsoft SQL Server-এ; তার SQL-এর নিজস্ব ভাষা T-SQL, আর app-গুলো SQL Server-এর driver দিয়ে SQL Server-এর নিজস্ব wire protocol-এ কথা বলে। PostgreSQL-এ সরতে গেলে সাধারণত query, stored procedure আর driver সব নতুন করে লিখতে হয়।

Babelfish হলো Aurora PostgreSQL-এর একটা feature, যেটা T-SQL আর SQL Server-এর protocol বোঝে। চালু করলে:

• App তার SQL Server client driver রেখেই Babelfish-এর SQL Server port-এ (1433) connect করে; Babelfish পেছনে T-SQL-কে PostgreSQL-এ অনুবাদ করে। App ভাবে সে SQL Server-এর সাথেই কথা বলছে।
• Code বদলাতে হয় খুব কম বা একদমই না। কিছু T-SQL feature চলে না; Babelfish Compass tool আগেই জানিয়ে দেয় কী কী বদলাতে হবে।
• একই database সাধারণ PostgreSQL connection-ও নেয়, তাই ধীরে ধীরে, অংশ ধরে আধুনিক করা যায়।
• Schema আর data সরাও AWS SCT আর AWS DMS দিয়ে (বা Babelfish-এর নিজের tool দিয়ে), তারপর app-কে Aurora-র দিকে ঘুরিয়ে দাও।

#Backup আর restore

#Automated backup

• Aurora cluster volume-এর backup নেয় অবিরাম, ধাপে ধাপে (incremental), S3-তে, performance-এ কোনো প্রভাব ছাড়া, backup window-তে কিছু থমকে যায় না (RDS for MySQL দিনে একবার snapshot নেয়, Single-AZ-এ তাতে অল্পক্ষণের I/O থমকে যেতে পারে)।
• Automated backup সবসময় চালু: retention ১ থেকে ৩৫ দিন, বন্ধ করা যায় না (RDS-এ 0 দিলে বন্ধ হয়)।
• Retention-এর ভেতরে যেকোনো সেকেন্ডে point-in-time recovery (PITR), সাধারণত প্রায় ৫ মিনিট আগে পর্যন্ত।
• Retention সময়ে তোমার cluster volume-এর size পর্যন্ত backup storage ফ্রি।

#Manual snapshot

• তুমি (বা AWS Backup) চালাও, রাখো যতদিন খুশি, cluster মুছে ফেলার পরেও।
• অন্য Region-এ কপি করা যায়, অন্য account-এর সাথে শেয়ার করা যায়।
• ৩৫ দিনের বেশি রাখতে হলে (compliance-এর জন্য ১, ৩, ৭ বছর) AWS Backup-এর plan ব্যবহার করো; লেসন ৭.২-এ RDS-এর জন্য এটা দেখানো আছে, Aurora-তেও একইভাবে চলে।

#Restore-এর উপায়

• Backup বা snapshot থেকে restore সবসময় নতুন endpoint সহ একটা নতুন cluster বানায়। আগের cluster যেমন ছিল তেমনই থাকে। তারপর নতুন cluster-এ instance যোগ করো।
• S3 থেকে restore (Aurora MySQL): অফিসের নিজস্ব server-এর (on-premises) MySQL database সরাতে Percona XtraBackup দিয়ে physical backup নাও, file-গুলো S3-তে তোলো, আর সেখান থেকে নতুন একটা Aurora MySQL cluster বানাও। বড় database-এ logical dump-এর চেয়ে দ্রুত। (সাধারণ RDS for MySQL-ও S3-এর XtraBackup থেকে restore করা যায়।)
• সরানোর আরও উপায়: logical dump (mysqldump, pg_dump), AWS DMS, বা RDS for MySQL/PostgreSQL instance-এর একটা Aurora read replica বানিয়ে সেটাকে promote করা।

#Backtrack: জায়গায় দাঁড়িয়েই পেছনে ফেরা (Aurora MySQL)

Restore নতুন একটা cluster বানায়, তাতে সময় লাগে আর নতুন একটা endpoint-এ যেতে হয়। Backtrack উল্টো কাজ করে: চলতি cluster-টাকেই আগের কোনো মুহূর্তে পিছিয়ে দেয়, ঘড়ির কাঁটা পেছনে ঘোরানোর মতো:

• নতুন cluster নেই, endpoint একই, কাজ শেষ কয়েক মিনিটে, সেকেন্ড ধরে (Aurora সবচেয়ে কাছের consistent মুহূর্তটা বাছে)।
• ভুলের ঠিক আগের মুহূর্তটা খুঁজতে আগে-পিছে যাওয়া যায় (৩ ঘণ্টা পেছনে, তারপর ১ ঘণ্টা সামনে…)।
• Backtrack window সর্বোচ্চ ৭২ ঘণ্টা। তোমার target window পর্যন্ত Aurora change record রেখে দেয়, আর তার জন্য ঘণ্টাপ্রতি টাকা দাও; খুব বেশি write হলে আসল window এর চেয়ে ছোট হতে পারে।
• শুধু Aurora MySQL-এ, Aurora PostgreSQL-এ না।
• Cluster বানানোর সময়ই চালু করতে হয় (বা snapshot থেকে নতুন cluster-এ restore করার সময়); চলতি cluster-এ পরে চালু করা যায় না।
• পেছায় পুরো cluster, একটা table না: ওই মুহূর্তের পরে যা লেখা হয়েছে, সবই মুছে যায়।
• একটু বিরতি হয়: app থামাও, Aurora connection বন্ধ করে, পেছায়, তারপর আবার খোলে।
• Global Database-এ চলে না, cross-Region read replica-র সাথেও না (জোর করে চালালে binlog replica ভেঙে যায়)।

এটা backup না। শেষ কয়েক ঘণ্টার মানুষের ভুল থেকে বাঁচায়, cluster হারানো থেকে না।

#Cloning: মুহূর্তে test-এর কপি

Aurora cloning copy-on-write protocol দিয়ে একটা চলতি cluster থেকে নতুন একটা cluster বানায়:

• শুরুতে clone উৎসের একই storage page শেয়ার করে; কিছুই কপি হয় না। কয়েক terabyte-এর database-এর clone-ও কয়েক মিনিটে তৈরি, আর শুরুতে storage-এর বাড়তি খরচ প্রায় শূন্য।
• যেকোনো দিক কোনো page বদলালে শুধু সেই page কপি হয়ে আলাদা থাকে; প্রত্যেকে নিজের বদলানো page-এর টাকা দেয়।
• উৎস ধীর হয় না, আর clone-এ আলাদা instance size, serverless, বা একটাই instance রাখা যায়।
• একটা উৎস থেকে ১৫টা পর্যন্ত copy-on-write clone; তারপরেরগুলো পুরো কপি। শুধু একই Region-এ (অন্য VPC-তে, বা AWS RAM দিয়ে অন্য account-এ হতে পারে)।

Snapshot থেকে restore-এর সাথে তুলনা: restore S3 থেকে সব data কপি করে ফেরত আনে (বড় database-এ ধীর, পুরো storage-এর খরচ), আর clone প্রায় মুহূর্তে তৈরি, storage শেয়ার করে। Read replica-র সাথে তুলনা: replica read-only আর production-এরই অংশ; clone একটা আলাদা, লেখা যায় এমন cluster।

#১৪:০৫-এ একটা table drop হলো: কোন tool?

#দাম আর নতুন feature

#Aurora Standard বনাম Aurora I/O-Optimized

Storage-এর দুই ধরন, cluster ধরে বাছতে হয়:

• Aurora Standard: instance-এর ঘণ্টা + storage + প্রতি ১০ লাখ I/O request-এর জন্য আলাদা দাম। মাঝারি I/O-তে সবচেয়ে সস্তা।
• Aurora I/O-Optimized (২০২৩): instance আর storage-এর দাম বেশি, কিন্তু I/O-র কোনো দাম নেই। AWS-এর নিয়ম: তোমার Aurora bill-এর ২৫% বা তার বেশি I/O হলে এটা লাভজনক। I/O-ভারী app-এ খরচ আগে থেকে আন্দাজ করা যায়।
• Standard থেকে I/O-Optimized-এ ৩০ দিনে একবার যাওয়া যায়, ফেরত আসা যায় যেকোনো সময়।

#Redshift-এর সাথে zero-ETL integration

Zero-ETL integration Aurora-র data প্রায় সাথে সাথে Amazon Redshift-এ কপি করে, ফলে analyst-রা কোনো ETL pipeline না বানিয়েই warehouse-এ টাটকা data-য় query চালাতে পারে। পরীক্ষার সূত্র: “ETL pipeline ছাড়া Redshift-এ Aurora-র data নিয়ে analytics”।

#পাশের কথা: Aurora DSQL (২০২৫)

Aurora DSQL একটা আলাদা serverless, distributed, PostgreSQL-compatible database (মে ২০২৫ থেকে সবার জন্য চালু), যেখানে কোনো instance নেই আর কয়েকটা Region-এ একসাথে write (active-active) নেওয়া যায়। এটা সাধারণ Aurora cluster-এর feature না, আর SAA পরীক্ষায় এখনো আসে না; সেখানে “multi-Region relational DR” মানে এখনো Global Database।

#আরও কিছু জানার মতো

• Aurora-তে IAM database authentication, KMS দিয়ে রাখা অবস্থায় encryption (বানানোর সময় বাছতে হয়) আর চলার পথে TLS, সবই RDS-এর মতো (লেসন ৭.৪)।
• একটা cluster ৭ দিন পর্যন্ত stop রাখা যায় (তারপর নিজে থেকে চালু হয়), তখন শুধু storage-এর টাকা লাগে।
• বেশিরভাগ ছোট update-এ zero-downtime patching সহ automated patching, আর Performance Insights ও Enhanced Monitoring ভেতরেই আছে।

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

• কোনো reader নেই, তারপর writer গেল: Aurora-কে নতুন instance চালু করতে হয় (প্রায় ১০ মিনিট)। সবসময় অন্য AZ-এ writer-এর সমান size-এর একটা reader রাখো, tier 0 বা 1-এ।
• App instance endpoint ব্যবহার করে: failover-এ writer সরে যায়, আর app এমন একটা instance-এ লিখতে থাকে যেটা এখন reader (“read-only” error)। Cluster endpoint ব্যবহার করো।
• Client অনেকক্ষণ DNS cache করে রাখে (Java-র default চিরকাল cache করতে পারে): failover-এর পরেও পুরনো writer-এ যেতে থাকে। Client-এ ছোট DNS TTL দাও (যেমন ৫ সেকেন্ড), বা AWS-এর driver / RDS Proxy ব্যবহার করো।
• যে read-কে নিজের লেখা data দেখতেই হবে, সেটা reader endpoint-এ গিয়ে শেষ 50 ms-এর পরিবর্তন দেখে না। লিখেই পড়তে হয় এমন query cluster endpoint-এ পাঠাও।
• Reader endpoint ভাগ করছে না: app একটাই connection খুলে রেখেছে। Pool ব্যবহার করো, বা মাঝে মাঝে আবার connect করো।
• Failover-এর লক্ষ্য খুব ছোট: tier 0-এর ছোট্ট একটা reader writer হয়ে চাপে ভেঙে পড়ে। Size মিলিয়ে রাখো।
• Serverless-এর maximum খুব কম: capacity আটকে যাওয়ায় চূড়ার সময় query ধীর। ACUUtilization 100%-এর কাছে গেলে খেয়াল করো।
• Auto-pause-এর চমক: pause-এর পর প্রথম request time out হয় (জাগতে প্রায় ১৫ সেকেন্ড), বা pause থাকা অবস্থায় নির্ধারিত job (pg_cron, MySQL event) চলে না।
• PostgreSQL-এ Backtrack আশা করা, বা এমন cluster-এ যেটা Backtrack ছাড়া বানানো: পাওয়া যাবে না। PITR-এর পরিকল্পনা রাখো।
• পরিকল্পনা ছাড়া Global Database failover: DNS, app-এর config আর RPO কখনো পরীক্ষা করা হয়নি। Switchover-এর মহড়া দাও।
• Aurora Standard-এ write-ভারী app-এ I/O-র bill দেখে চমকে যাওয়া: I/O-Optimized সস্তা কি না দেখো।

#System design-এ Aurora

• AWS-এ high availability আর read scaling দরকার এমন relational OLTP database-এর default পছন্দ: একটা writer, আলাদা AZ-এ দুই বা তার বেশি reader, write-এ cluster endpoint, read-এ reader (বা custom) endpoint, আর অনেক ছোট-আয়ুর connection (Lambda) থাকলে সামনে RDS Proxy।
• Read-ভারী app: auto scaling সহ ১৫টা পর্যন্ত reader, আর গরম data-র জন্য একটা cache (ElastiCache, লেসন ৭.৫)।
• লাফানো বা অজানা traffic, dev/test, অনেক tenant-এর SaaS: Serverless v2, অলস database-এ auto-pause সহ।
• কয়েক Region: DR (RTO এক মিনিটের কম, RPO প্রায় এক সেকেন্ড) আর কাছের read-এর জন্য Global Database; মাঝেমধ্যের দূরের write-এর জন্য write forwarding।
• রোজকার কাজ: test আর analytics-এর পরীক্ষার জন্য clone, মানুষের ভুলের জন্য Backtrack (MySQL), লম্বা সময় রাখার জন্য AWS Backup, analytics-এর জন্য Redshift-এ zero-ETL।
• কখন Aurora না: Babelfish ছাড়া Oracle, SQL Server বা Db2 (RDS নাও), স্থির কম load-এর ছোট সস্তা database (RDS Single-AZ সস্তা হতে পারে), বা বিশাল মাপের key-value access (DynamoDB)।

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

# 1. Create an Aurora PostgreSQL cluster (the volume) with a serverless range, then a writer and a reader
aws rds create-db-cluster --db-cluster-identifier shop \
  --engine aurora-postgresql --engine-version 16.9 \
  --master-username dbadmin --manage-master-user-password \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=16,SecondsUntilAutoPause=600 \
  --storage-type aurora-iopt1 \
  --db-subnet-group-name db-private --vpc-security-group-ids sg-0abc1234def567890

aws rds create-db-instance --db-instance-identifier shop-writer \
  --db-cluster-identifier shop --engine aurora-postgresql --db-instance-class db.r7g.large
aws rds create-db-instance --db-instance-identifier shop-reader-1 \
  --db-cluster-identifier shop --engine aurora-postgresql --db-instance-class db.serverless \
  --promotion-tier 1 --availability-zone us-east-1b

# 2. See the cluster endpoint, the reader endpoint and who is the writer
aws rds describe-db-clusters --db-cluster-identifier shop \
  --query "DBClusters[0].[Endpoint,ReaderEndpoint,DBClusterMembers[].[DBInstanceIdentifier,IsClusterWriter,PromotionTier]]"

# 3. Watch the endpoint move: resolve it, fail over, resolve again (same name, new address)
dig +short shop.cluster-c1a2b3.us-east-1.rds.amazonaws.com
aws rds failover-db-cluster --db-cluster-identifier shop --target-db-instance-identifier shop-reader-1
dig +short shop.cluster-c1a2b3.us-east-1.rds.amazonaws.com

# 4. A custom endpoint for analytics instances
aws rds create-db-cluster-endpoint --db-cluster-identifier shop \
  --db-cluster-endpoint-identifier reports --endpoint-type READER \
  --static-members shop-analytics-1

# 5. Replica auto scaling: 1 to 8 readers, keep average reader CPU at 60%
aws application-autoscaling register-scalable-target --service-namespace rds \
  --resource-id cluster:shop --scalable-dimension rds:cluster:ReadReplicaCount \
  --min-capacity 1 --max-capacity 8
aws application-autoscaling put-scaling-policy --service-namespace rds \
  --resource-id cluster:shop --scalable-dimension rds:cluster:ReadReplicaCount \
  --policy-name reader-cpu-60 --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
  '{"TargetValue":60,"PredefinedMetricSpecification":{"PredefinedMetricType":"RDSReaderAverageCPUUtilization"}}'

# 6. Clone production for testing (copy-on-write), then give it an instance
aws rds restore-db-cluster-to-point-in-time --source-db-cluster-identifier shop \
  --db-cluster-identifier shop-test --restore-type copy-on-write --use-latest-restorable-time

# 7. Point-in-time restore to 14:04:59 (always a NEW cluster)
aws rds restore-db-cluster-to-point-in-time --source-db-cluster-identifier shop \
  --db-cluster-identifier shop-1404 --restore-to-time 2026-10-25T14:04:59Z

# 8. Backtrack an Aurora MySQL cluster (created with --backtrack-window 86400) in place
aws rds backtrack-db-cluster --db-cluster-identifier shop-mysql \
  --backtrack-to 2026-10-25T14:04:59Z
aws rds describe-db-cluster-backtracks --db-cluster-identifier shop-mysql

# 9. Global Database: wrap the cluster, add a secondary Region, later switch over
aws rds create-global-cluster --global-cluster-identifier shop-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:111122223333:cluster:shop
aws rds create-db-cluster --region eu-west-1 --db-cluster-identifier shop-eu \
  --engine aurora-postgresql --engine-version 16.9 --global-cluster-identifier shop-global
aws rds switchover-global-cluster --global-cluster-identifier shop-global \
  --target-db-cluster-identifier arn:aws:rds:eu-west-1:111122223333:cluster:shop-eu

# 10. Watch replica lag and serverless capacity
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name AuroraReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=shop-reader-1 \
  --start-time 2026-10-25T13:00:00Z --end-time 2026-10-25T14:00:00Z --period 300 --statistics Maximum

#সারসংক্ষেপ

মূল কথাগুলো

• Aurora AWS-এর নিজের MySQL- আর PostgreSQL-compatible engine: compute আর storage আলাদা, প্রচার অনুযায়ী MySQL-এর ৫ গুণ আর PostgreSQL-এর ৩ গুণ পর্যন্ত throughput, instance-প্রতি RDS-এর চেয়ে প্রায় ২০% বেশি দাম।
• Cluster volume কাটা থাকে 10 GiB-এর segment-এ, প্রতিটা ৩টা AZ জুড়ে ৬ বার রাখা। Write-এ লাগে ৬-এ ৪, read-এ ৩: একটা AZ হারালেও write চলে, আর একটা AZ আর আরও একটা কপি হারালেও data পড়া যায়। এটা self-healing, আর নিজে থেকে 128 TiB পর্যন্ত বাড়ে (নতুন version-এ 256 TiB)।
• একটা cluster-এ একটা writer আর ১৫টা পর্যন্ত Aurora Replica, একই storage-এ: replica lag প্রায় 100 ms-এর কম, promotion tier (0–15) দেখে নিজে থেকে failover, সাধারণত ৩০ সেকেন্ডের কম। Reader না থাকলে লাগে প্রায় ১০ মিনিট।
• Endpoint: cluster (সবসময় writer), reader (connection ধরে ভাগ), instance (একটা instance, app-এ এড়িয়ে চলো), custom (বেছে নেওয়া কয়েকটা, যেমন analytics)। একবার বসাও; failover-এ একই নামের পেছনে DNS সরে যায়, তাই connection string কখনো বদলায় না। Promote করা RDS read replica পায় নতুন endpoint।
• Replica auto scaling: reader CPU বা connection-এর ওপর target tracking, একটা min আর max-এর মধ্যে।
• Serverless v2: capacity ACU-তে (প্রতিটা প্রায় 2 GiB), min থেকে max (0–256), কয়েক সেকেন্ডে জায়গায় দাঁড়িয়ে scale, প্রতি সেকেন্ডের দাম; min 0 = auto-pause, জাগতে প্রায় ১৫ সেকেন্ড। কালেভদ্রে, থেমে থেমে, আন্দাজের বাইরের load-এর জন্য। Provisioned-এর সাথে মেশানো যায়। v1 ২০২৫-এ বন্ধ।
• Global Database: ১টা primary + ১০টা পর্যন্ত secondary Region, storage replication ১ সেকেন্ডের কম, secondary-প্রতি ১৬টা reader, write forwarding; switchover (পরিকল্পিত, data হারায় না) বনাম failover (বিপর্যয়, RTO ১ মিনিটের কম, RPO কয়েক সেকেন্ড)।
• Aurora ML SQL থেকে SageMaker, Comprehend বা Bedrock ডাকে। Babelfish Aurora PostgreSQL-কে T-SQL বোঝায়, তাই SQL Server-এর app অল্প বদলেই চলে।
• Backup অবিরাম, সবসময় চালু, ১–৩৫ দিন, performance-এ প্রভাব নেই; PITR আর snapshot restore বানায় নতুন cluster; on-premises MySQL সরে S3-এ Percona XtraBackup দিয়ে।
• Backtrack (Aurora MySQL, সর্বোচ্চ ৭২ ঘণ্টা, বানানোর সময় চালু) পুরো cluster-কে জায়গায় দাঁড়িয়েই পেছায়, endpoint একই। Cloning (copy-on-write) দ্রুত আর সস্তায় test-এর কপি বানায়; staging-এর জন্য snapshot restore-এর চেয়ে এটাই ভালো।
• I/O bill-এর ২৫% বা তার বেশি হলে I/O-Optimized; zero-ETL Redshift-এ data পাঠায়; Aurora DSQL (২০২৫) কয়েক Region-এ active-active একটা আলাদা product।

নিজেকে যাচাই করো: Amazon Aurora৩৩টি প্রশ্ন