RDS, Read Replica আর Multi-AZ

এই lesson শেষে তুমি পারবে

• Amazon RDS তোমার হয়ে কী কী সামলায় আর কোন কাজগুলো তোমার ঘাড়েই থাকে, সেটা বুঝিয়ে বলতে, এর engine-গুলোর নাম বলতে, আর কেন এতে SSH করা যায় না তা ব্যাখ্যা করতে।
• Instance class আর storage type বাছতে, endpoint খুঁজে বের করতে, আর ঠিকঠাক maximum threshold দিয়ে storage auto scaling চালু করতে।
• Read replica কীভাবে কাজ করে (asynchronous, eventually consistent, নিজের endpoint, ১৫টা পর্যন্ত), এক Region-এর ভেতরে আর Region পার হলে খরচ কত, আর replica promote কীভাবে করে, তা বোঝাতে।
• “Post edit করলাম, তবু পুরনোটা দেখাচ্ছে” সমস্যাটাকে replica lag হিসেবে চিনতে আর সারাতে।
• Multi-AZ DB instance (synchronous standby, একটাই DNS name, automatic failover) আর Multi-AZ DB cluster (এক writer, দুটো পড়া-যায় standby) বোঝাতে, আর Single-AZ থেকে Multi-AZ-এ যেতে।
• RDS-এর জন্য cross-Region disaster recovery সাজাতে, আর পরীক্ষার যেকোনো প্রশ্নে read replica, Multi-AZ instance, Multi-AZ cluster আর cross-Region replica-র মধ্যে ঠিকটা বেছে নিতে।

#Amazon RDS: এমন database যাকে সারাক্ষণ পাহারা দিতে হয় না

#Managed database কেন

Relational database (মানে একটা RDBMS) data রাখে row আর column-এর table-এ, key দিয়ে table-গুলো জোড়া লাগায়, SQL query-র উত্তর দেয়, আর প্রতিটা transaction-কে ACID নিশ্চয়তা দিয়ে আগলে রাখে। চাইলে তুমি নিজেই একটা EC2 instance-এ এটা install করতে পারো। কিন্তু তখন চারপাশের সব কাজও তোমার: operating system, patch, backup, replication, failover, monitoring, disk বাড়ানো। এই কাজ কোনোদিন শেষ হয় না, আর একটা ভুলেই data হারাতে পারে।

Amazon RDS (Relational Database Service) তোমার হয়ে database engine চালায়। তুমি শুধু engine, size আর কয়েকটা setting বেছে দাও; server চালানোর দায়িত্ব AWS-এর।

#Engine-গুলো

RDS ছয়টা engine চালায়:

Amazon Aurora-ও RDS console-এ থাকে, কিন্তু এটা AWS-এর নিজের cloud-native engine, MySQL আর PostgreSQL-এর সাথে compatible, storage-এর ডিজাইন একদম আলাদা। এর জন্য আলাদা lesson আছে (7.3)। Owner-এর note-এ পাঁচটা engine আর Aurora আছে; Db2 হলো নতুন যোগ হওয়া ষষ্ঠটা।

#SSH নেই

RDS managed service: host-টা AWS-এর। তুমি database client দিয়ে connect করো database port-এ (PostgreSQL-এ 5432, MySQL আর MariaDB-তে 3306, Oracle-এ 1521, SQL Server-এ 1433, Db2-তে 50000)। Server-এ SSH করা যায় না, file system দেখা যায় না, agent বসানো যায় না, নিজে OS patch করা যায় না। ঠিক এই কারণেই patch, backup আর failover AWS নিরাপদে নিজে নিজে করতে পারে।

কোনো পুরনো application-এর যদি OS-এ ঢোকা, নিজের মতো OS patch, বা database host-এ third-party agent লাগে, তাহলে সাধারণ RDS ভুল উত্তর। ঠিক উত্তর হলো RDS Custom (শুধু Oracle আর SQL Server, lesson 7.2), অথবা EC2-তে নিজে database চালানো।

#Instance class, storage আর endpoint

Instance class ঠিক করে CPU আর memory কত, EC2-তে যে family-গুলো দেখেছিলে সেগুলোই (lesson 4.1), শুধু সামনে db. বসে:

• Burstable (db.t4g, db.t3): ছোট আর সস্তা, development বা হালকা load-এর জন্য।
• General purpose (db.m7g, db.m6i…): CPU আর memory সমান তালে।
• Memory optimized (db.r7g, db.x2iedn…): ব্যস্ত database-এর বড় cache-এর জন্য।

Class বদলানো মানে vertical scaling: instance restart হয়, তাই Single-AZ database কয়েক মিনিট বন্ধ থাকে। Multi-AZ থাকলে বদলটা আগে standby-তে হয়, downtime নেমে আসে একটা failover-এর সমান (নিচে দেখবে)।

Storage নিচে আসলে EBS (lesson 5.2), type তুমি বাছো:

বেশিরভাগ engine-এ প্রতি instance-এ 64 TiB পর্যন্ত (SQL Server-এ 16 TiB)।

প্রতিটা DB instance একটা endpoint পায়: mydb.c9akciq32xyz.us-east-1.rds.amazonaws.com-এর মতো একটা DNS name, সাথে একটা port। Application সবসময় এই নামেই connect করে, কখনো IP address-এ না, কারণ failover-এর সময় RDS নামটাকে অন্য machine-এ সরিয়ে নেয়। কথাটা মাথায় গেঁথে রাখো: endpoint-এর জন্যই Multi-AZ failover application টেরই পায় না, আর promote হওয়া read replica রাখে নিজের endpoint, তাই একটা replica promote করলে connection string বদলাতেই হয়।

#RDS বাড়ানোর তিনটা দিক

Database নিজেই যখন CPU বা memory-তে কুলাতে পারছে না, তখন vertical scaling; আর load যখন মূলত read (report, analytics, product page), তখন replica।

#Storage auto scaling

Storage auto scaling চালু থাকলে RDS free space-এর দিকে নজর রাখে আর চালু অবস্থাতেই তোমার হয়ে volume বড় করে দেয়। RDS storage বাড়ানো শুরু করে যখন তিনটা শর্তই মেলে:

1. Free space allocated storage-এর 10% বা তার কম।
2. কম জায়গার এই অবস্থা অন্তত ৫ মিনিট ধরে চলছে।
3. আগের storage বদলের optimization শেষ, আর গত ২৪ ঘণ্টায় ৪টার কম storage বদল হয়েছে।

যোগ করে এই তিনটার মধ্যে যেটা সবচেয়ে বড়: 10 GiB, এখনকার allocation-এর 10%, অথবা গত এক ঘণ্টার FreeStorageSpace metric দেখে পরের ৭ ঘণ্টায় যতটা বাড়বে বলে সে অনুমান করে।

তোমাকে একটা maximum storage threshold দিতেই হবে (--max-allocated-storage): auto scaling সর্বোচ্চ যতদূর যেতে পারবে, তার ছাদ। এটা এখনকার size-এর অন্তত 10% বেশি হতে হয়, আর AWS বলে অন্তত 26% বেশি রাখো, যাতে ছাদে ধাক্কা খাওয়ার আগেই “সীমার কাছে চলে এসেছ” event পাও। আরও কিছু কথা:

• এটা সব RDS engine-এ চলে, কিন্তু magnetic storage-এ না।
• চালু করতে বা threshold বদলাতে reboot লাগে না।
• Storage কখনো ছোট হয় না, auto scaling দিয়েও না, হাতেও না। ছোট করতে চাইলে ছোট একটা instance বানিয়ে data সরাতে হয় (যেমন blue/green deployment দিয়ে)।
• এটা বানানো ধীর, অনিশ্চিত বৃদ্ধির জন্য। হঠাৎ একবারে বিশাল load এলে disk auto scaling-এর চেয়ে দ্রুত ভরে যায়, database তখন storage-full অবস্থায় বসে থাকে, write নেয় না। বড় load-এর আগে নিজেই জায়গা বাড়িয়ে নাও।

Slide আর অনেক পুরনো course-এ তৃতীয় শর্তটা লেখা আছে “শেষ storage বদলের পর ৬ ঘণ্টা”। AWS বদলানোর আগ পর্যন্ত নিয়মটা তাই ছিল; এখন নিয়ম হলো “optimization শেষ, আর ২৪ ঘণ্টায় ৪টার কম বদল”। পরীক্ষার কোনো option-এ ৬ ঘণ্টা দেখলে বুঝবে পুরনো নিয়মের কথা বলছে; বাকি দুটো সংখ্যা (10% free, ৫ মিনিট) একই আছে।

#Read replica

#কীভাবে কাজ করে

Read replica হলো একটা DB instance-এর read-only কপি। বানানোর সময় RDS source-এর একটা snapshot নেয়, তা থেকে নতুন instance বানায়, তারপর engine-এর নিজের replication দিয়ে সেটাকে হালনাগাদ রাখে। Source-টা তখন হয়ে যায় primary।

• Replication asynchronous: primary commit করে, application-কে উত্তর দেয়, আর পরিবর্তনটা replica-তে পাঠায় তার পরে। তাই replica একটু পিছিয়ে চলে, আর replica থেকে পড়া data eventually consistent।
• Replica শুধু read-only connection নেয়: SELECT চলে; INSERT, UPDATE, DELETE ব্যর্থ হয়।
• প্রতিটা replica-র নিজের endpoint আছে। RDS তোমার হয়ে read আর write ভাগ করে না: application (বা একটা proxy, বা তোমার বানানো একটা Route 53 record)-কেই read পাঠাতে হবে replica-র endpoint-এ আর write পাঠাতে হবে primary-তে।
• Replica থাকতে পারে একই AZ-এ, অন্য AZ-এ, বা অন্য Region-এ।
• Replica-র bill সাধারণ DB instance-এর মতোই, নিজের class আর storage সহ (primary-র চেয়ে ছোট রেখো না, নইলে পিছিয়ে পড়বে)।
• RDS-এ replica-র auto scaling নেই: যোগ-বিয়োগ তোমাকেই করতে হয়। (Aurora নিজের replica auto scale করতে পারে, lesson 7.3।)
• Replica-কে promote করে স্বাধীন database বানানো যায় (নিচে দেখো), আর replica নিজেও Multi-AZ হতে পারে।

একটা source থেকে কয়টা replica?

Owner-এর note-এ আছে “সাধারণত ৫টা”। এটা পুরনো সীমা, পুরনো material-এ এখনো দেখবে; এখন বেশিরভাগ engine-এ quota প্রতি source-এ ১৫টা, slide-ও এই সংখ্যাই বলে।

#Replica কীসের জন্য

মূল কাজ read-এর চাপ সরিয়ে নেওয়া। ধরো production database স্বাভাবিক traffic নিয়েই ব্যস্ত। এখন ব্যবসার লোকজন একটা reporting বা analytics application চায়, যার ভারী query লাখ লাখ row ঘাঁটে (একটা OLAP workload)। এটা primary-তে চালালে প্রতিটা customer তার ধাক্কা টের পাবে। তাই একটা read replica বানাও, reporting tool-কে replica-র endpoint দেখিয়ে দাও, production primary-র গায়ে আঁচও লাগবে না। Replica শুধু SELECT ধরনের statement-এরই উত্তর দেয়।

আরও কাজ: primary অল্প সময়ের জন্য বন্ধ থাকলে (যেমন maintenance-এ) read চালিয়ে যাওয়া, পুরনো data মেনে নিয়ে; অন্য Region-এর user-দের কাছে একটা কপি রাখা; আর promote করে disaster recovery।

#Network-এর খরচ

AWS সাধারণত AZ-এর সীমানা পার হওয়া data-র জন্য টাকা নেয়, Region থেকে বেরোনো data-র জন্যও। RDS এখানে একটা বিশেষ ছাড় দেয়:

Replica instance আর তার storage-এর টাকা সবসময়ই দিতে হয়; প্রশ্নটা শুধু replication traffic নিয়ে।

#Replica lag আর “পুরনো post” সমস্যা

পরীক্ষার সবচেয়ে বিখ্যাত scenario-গুলোর একটা।

এই ফাঁকটার নাম replica lag (replication lag-ও বলে), আর এই আচরণের নাম eventual consistency: পরিবর্তনটা replica-গুলোতে সাথে সাথে থাকে না, কিন্তু শেষমেশ সবাই এক জায়গায় মিলে যায়। Lag সেকেন্ডে দেখা যায় CloudWatch-এর ReplicaLag metric-এ। এটা বাড়ে যখন:

• primary-তে হঠাৎ অনেক ভারী write আসে;
• replica primary-র চেয়ে ছোট class-এর, বা IOPS কম;
• replica-তে লম্বা query চলে পরিবর্তন বসানোর কাজ ধীর করে দেয়;
• replica অন্য Region-এ (network-এর দূরত্ব বেশি)।

কী চাই তার ওপর নির্ভর করে সমাধান:

Multi-AZ standby এখানে কোনো কাজে আসে না: সেটা synchronous ঠিকই, কিন্তু তাকে কেউ পড়তে পারে না।

#Replica promote করা

একটা কাজেই (aws rds promote-read-replica) read replica-কে স্বাধীন DB instance বানানো যায়। কী হয়:

1. Replica replication থামায়; source-এর সাথে বাঁধন চিরতরে ছিঁড়ে যায় (আর জোড়া যায় না)।
2. Reboot হয় (কয়েক মিনিট), ফিরে আসে নিজের backup-সহ একটা সাধারণ read/write instance হয়ে।
3. নিজের endpoint-ই রাখে, তাই application-কে নতুন এই নামের দিকে দেখাতে হয়।
4. Primary যা তখনো পাঠায়নি (lag-এর অংশটুকু), তা promote হওয়া কপিতে নেই।

“Read replica দিয়ে write করব কীভাবে?” প্রশ্নের উত্তর এটাই: promote না করা পর্যন্ত পারবে না, আর promote করলে সেটা আর replica থাকে না। Promote কাজে লাগে disaster recovery-তে, একটা database ভেঙে দুটো করতে, আর ঝামেলাহীন migration-এ। এটা সবসময় হাতে করতে হয় (বা তোমার নিজের automation দিয়ে); RDS নিজে থেকে কখনো replica promote করে না।

#Multi-AZ DB instance: availability-র জন্য, গতির জন্য না

#কীভাবে কাজ করে

Multi-AZ DB instance deployment-এ RDS একই Region-এর অন্য একটা AZ-এ একটা standby বানায়, আর synchronous replication দিয়ে তাকে তাল মিলিয়ে রাখে: application “committed” শোনার আগেই প্রতিটা write primary আর standby দুই জায়গাতেই জমা হয়।

• একটাই DNS name। Application শুধু endpoint চেনে। Failover-এর সময় RDS নামটাকে standby-র দিকে ঘুরিয়ে দেয়, তাই application-এ কিছুই বদলাতে হয় না, শুধু আবার connect করতে হয়।
• Automatic failover, সাধারণত ৬০–১২০ সেকেন্ডে, কারও হাত লাগাতে হয় না।
• Standby পড়া যায় না। এর কোনো endpoint নেই, connection নেয় না। Multi-AZ read capacity বাড়ায় না, এটা scaling-এর জিনিস না।
• Commit হওয়া transaction-এর কোনো data হারায় না, কারণ দুই কপিতেই আছে।
• দাম: standby-এর টাকাও দিতে হয় (Single-AZ-এর মোটামুটি দ্বিগুণ), আর commit একটু ধীর হয়, কারণ প্রতিটা commit দ্বিতীয় AZ-এর জন্য অপেক্ষা করে।
• Backup নেওয়া হয় standby থেকে, তাই primary-কে backup-এর জন্য থামতে হয় না।

RDS নিজে থেকে failover করে যখন:

Failover-এর পর RDS একটা নতুন standby বানায়, যাতে আবার সুরক্ষা ফিরে আসে।

হাতে-কলমে দুটো কথা: connection কেটে গেলে application-কে retry করতে হবে, আর DNS চিরকাল cache করে রাখা চলবে না। যেসব Java application JDBC দিয়ে connect করে, সেগুলো JVM-এ DNS উত্তর cache করে রাখে; AWS বলে DNS TTL ৬০ সেকেন্ড বা কম রাখো (networkaddress.cache.ttl=60)। Failover শুরু আর শেষ হলে RDS event-ও পাঠায়, সেগুলো email বা SNS-এ নিতে পারো।

#Downtime ছাড়া Single-AZ থেকে Multi-AZ

চালু থাকা একটা Single-AZ instance-কে Modify → Multi-AZ: Yes দিয়ে (বা aws rds modify-db-instance --multi-az দিয়ে) Multi-AZ বানানো যায়। Database বন্ধ হয় না। ভেতরে RDS:

1. Primary-র storage volume-এর একটা snapshot নেয়;
2. সেই snapshot থেকে অন্য AZ-এ standby-র জন্য নতুন volume restore করে;
3. দুটোর মধ্যে synchronous replication চালু করে, status আবার available হয়।

নতুন volume-গুলো পেছনে পেছনে block লোড করে, তাই standby পুরো গরম না হওয়া পর্যন্ত write latency বাড়তে পারে। এজন্য AWS বলে কাজটা ফাঁকা সময়ে করো, অথবা খুব স্পর্শকাতর production database হলে আগে একটা read replica বানাও, সেটাকে Multi-AZ করো, তাল মিলিয়ে নিতে দাও, তারপর promote করো।

#Multi-AZ কি disaster recovery?

Slide-এ Multi-AZ-এর শিরোনাম “Disaster Recovery”, আর note বলে “HA & DR”। একটু সূক্ষ্ম হও: Multi-AZ বাঁচায় একটা instance, তার storage বা একটা AZ হারানো থেকে, সবকিছু একটাই Region-এর ভেতরে। এটা high availability। পুরো Region বন্ধ হয়ে গেলে primary আর standby দুটোই গেল। Region বিভ্রাট থেকে বাঁচতে লাগে cross-Region read replica (বা cross-Region backup, lesson 7.2)। পরীক্ষার উত্তরে “high availability”, “automatic failover”, “AZ পড়ে গেলেও টিকে থাকা” মানে Multi-AZ; আর “অন্য Region” মানে cross-Region replica।

#Multi-AZ DB cluster: পড়া-যায় standby

তুলনামূলক নতুন একটা deployment option, Aurora cluster-এর সাথে গুলিয়ে ফেলা খুব সহজ:

• তিনটা AZ-এ তিনটা DB instance: একটা writer আর দুটো reader instance।
• Semi-synchronous replication: অন্তত একটা reader পরিবর্তনটা পেলেই commit সফল। প্রতিটা commit অন্তত দুটো AZ-এ থাকে, কিন্তু ধীর reader-এর জন্য writer অপেক্ষা করে না।
• দুটো standby-ই পড়া যায়। একটা writer endpoint সবসময় writer-কে দেখায়, আর একটা reader endpoint connection-গুলো reader-দের মধ্যে ভাগ করে দেয় (প্রতিটা instance-এর নিজের endpoint-ও আছে)।
• Failover সাধারণত ৩৫ সেকেন্ডের কম, সবচেয়ে সাম্প্রতিক পরিবর্তন থাকা reader-এর দিকে; writer endpoint তার সাথে সরে যায়।
• Multi-AZ instance-এর চেয়ে write latency কম, কারণ instance-গুলো transaction log-এর জন্য দ্রুত local NVMe storage ব্যবহার করে।
• শুধু RDS for MySQL আর RDS for PostgreSQL, local NVMe থাকা instance class-এ (db.m6gd, db.r6gd এই ধরনের)।
• Reader-রা তবু একটু পরে পরিবর্তন বসায়, তাই replica lag আর read-after-write সমস্যা এখানেও আছে।
• এটা Aurora না: Aurora একটাই storage volume ১৫টা পর্যন্ত replica-র মধ্যে ভাগ করে (lesson 7.3)।

#Region পেরিয়ে disaster recovery

#ফাঁদের প্রশ্নটা

Owner-এর note-এ পরীক্ষার এই প্রশ্নটা আছে:

তোমার RDS PostgreSQL database-এর জন্য এমন disaster recovery কৌশল চাই, যাতে একটা Region বিভ্রাটে database দ্রুত অন্য Region-এ read আর write দুটোই সামলাতে পারে। DR database-কে highly available হতেই হবে। কী সুপারিশ করবে?

ঠিক উত্তর: অন্য Region-এ একটা read replica বানাও, আর সেই read replica-তে Multi-AZ চালু করো। লোভনীয় ভুল উত্তর: “মূল database-এ Multi-Region option চালু করো।” তিনটা কথা বুঝলেই পরিষ্কার:

1. Read replica write নিতে পারে, promote করার পর

   সাধারণ সময়ে replica শুধু পড়া যায়। দুর্যোগে তুমি DR Region-এর replica-টাকে (ধরো us-west-2-এর, যখন us-east-1 বন্ধ) promote করো। সেটা আর replica থাকে না, হয়ে যায় একটা স্বাধীন primary, যে read আর write দুটোই নেয়। তাই প্রশ্নে “read আর write” লেখা থাকলেও read replica বাদ পড়ে না।

2. Replica-তে Multi-AZ দিলে DR database highly available

   সাধারণ একটা replica promote হলে সেটা Single-AZ database: DR Region-এ একটা AZ পড়ে গেলেই আবার সব বন্ধ। শুরু থেকেই replica-তে Multi-AZ চালু রাখলে replica-র নিজের একটা synchronous standby থাকে, আর promote হওয়া database প্রথম মিনিট থেকেই highly available। এজন্যই slide-এ লেখা আছে, DR-এর জন্য read replica-কে Multi-AZ করে রাখা যায়।

3. “Enable Multi-Region” বলে কিছু নেই

   সাধারণ RDS-এ Multi-Region নামের কোনো checkbox নেই। Multi-AZ কাজ করে শুধু এক Region-এর ভেতরে। RDS-এর কপি অন্য Region-এ নেওয়ার আসল উপায় cross-Region read replica (cross-Region automated backup replication হলো ধীর কিন্তু সস্তা বিকল্প)। Option-টা বানানোই হয়েছে তোমাকে বিভ্রান্ত করতে।

#একই দরকার, আলাদা service, আলাদা উত্তর

পরীক্ষা যারা বানায়, তারা এক service-এর feature আরেক service-এর option-এ ঢুকিয়ে দিতে খুব ভালোবাসে। প্রশ্নে কোন service-এর নাম আছে, সেই অনুযায়ী cross-Region DR feature মেলাও:

#ঠিকটা বেছে নেওয়া

Feature-গুলো একসাথেও চলে: একটা primary Multi-AZ হতে পারে আর তার read replica-ও থাকতে পারে, আবার replica নিজেও Multi-AZ হতে পারে।

#System design-এ RDS কোথায় বসে

• Production-এ যা-ই চালাও, শুরু করো Multi-AZ দিয়ে। বাড়তি খরচে পাও automatic failover, আর maintenance-এ শুধু ছোট্ট একটা ঝাঁকুনি। MySQL বা PostgreSQL-এ failover-এর সময় জরুরি হলে, বা পড়া-যায় standby কাজে লাগাতে পারলে, Multi-AZ DB cluster নাও।
• Read বেশি হলে read replica যোগ করো, আর application সেভাবে সাজাও: primary-তে একটা write connection, replica endpoint-গুলো জুড়ে একটা read pool, user সদ্য যা বদলেছে তার জন্য read-your-own-writes, আর ReplicaLag-এ alarm।
• Disaster recovery Region ধরে পরিকল্পনা করো: কয়েক মিনিটের RTO আর কয়েক সেকেন্ডের RPO চাইলে cross-Region replica (DR কপিকে HA হতে হলে Multi-AZ), সস্তা আর ধীর পরিকল্পনা চাইলে cross-Region backup। দরকারের আগেই promote আর connection string বদলের মহড়া দাও, সম্ভব হলে endpoint-গুলোর সামনে একটা Route 53 record (যেমন db.example.com) রেখে।
• Storage auto scaling চালু রাখো, বাস্তবসম্মত threshold দিয়ে, কিন্তু পরিকল্পিত বড় load-এর আগে storage নিজেই বাড়াও।
• Connection সামলানো মজবুত রাখো: retry, অল্প সময়ের DNS cache, connection pooling। RDS Proxy (lesson 7.4) failover আরও ছোট করে, connection-ও pool করে।
• Migration: AWS DMS source চালু রেখেই on-premises database RDS-এ কপি করে; upgrade-এ replica promote বা blue/green deployment সাহায্য করে।

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

# 1. একটা PostgreSQL instance: Multi-AZ, gp3, 500 GiB পর্যন্ত storage auto scaling
aws rds create-db-instance \
  --db-instance-identifier shop-db \
  --engine postgres --db-instance-class db.m7g.large \
  --allocated-storage 100 --storage-type gp3 --max-allocated-storage 500 \
  --multi-az --master-username app --manage-master-user-password \
  --db-subnet-group-name private-db --vpc-security-group-ids sg-0abc1234def567890

# 2. Endpoint (app যে DNS name ব্যবহার করে) আর কোন কোন AZ ব্যবহার হচ্ছে, দেখো
aws rds describe-db-instances --db-instance-identifier shop-db \
  --query "DBInstances[0].[Endpoint.Address,Endpoint.Port,AvailabilityZone,SecondaryAvailabilityZone,MultiAZ]"

# 3. অন্য AZ-এ একটা read replica, আর অন্য Region-এ একটা (inter-Region transfer-এর bill হয়)
aws rds create-db-instance-read-replica --db-instance-identifier shop-db-rr1 \
  --source-db-instance-identifier shop-db --availability-zone us-east-1c
aws rds create-db-instance-read-replica --region us-west-2 \
  --db-instance-identifier shop-db-dr --multi-az \
  --source-db-instance-identifier arn:aws:rds:us-east-1:111122223333:db:shop-db

# 4. Replica-তে replica lag (সেকেন্ডে) দেখো
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=shop-db-rr1 \
  --start-time 2026-10-25T10:00:00Z --end-time 2026-10-25T11:00:00Z \
  --period 60 --statistics Maximum

# 5. Failover পরীক্ষা: failover সহ reboot, তারপর AZ অদলবদল দেখো
aws rds reboot-db-instance --db-instance-identifier shop-db --force-failover
aws rds describe-events --source-identifier shop-db --source-type db-instance --duration 60

# 6. Single-AZ instance-কে Multi-AZ বানাও (downtime নেই)
aws rds modify-db-instance --db-instance-identifier legacy-db --multi-az --apply-immediately

# 7. দুর্যোগ: cross-Region replica promote (replication চিরতরে শেষ)
aws rds promote-read-replica --region us-west-2 --db-instance-identifier shop-db-dr

# 8. একটা Multi-AZ DB cluster (শুধু MySQL বা PostgreSQL): writer + 2টা পড়া-যায় standby
aws rds create-db-cluster --db-cluster-identifier orders-cluster \
  --engine postgres --db-cluster-instance-class db.r6gd.large \
  --storage-type io2 --iops 3000 --allocated-storage 100 \
  --master-username app --manage-master-user-password
aws rds describe-db-clusters --db-cluster-identifier orders-cluster \
  --query "DBClusters[0].[Endpoint,ReaderEndpoint]"

Replica-তে write ব্যর্থ হয়, read চলে, আর কতটা পিছিয়ে আছে তাও দেখা যায়:

-- PostgreSQL replica
SELECT pg_is_in_recovery();                         -- replica-তে true
SELECT now() - pg_last_xact_replay_timestamp() AS lag;
UPDATE posts SET title = 'x' WHERE id = 1;          -- ERROR: cannot execute UPDATE in a read-only transaction

-- MySQL replica
SHOW REPLICA STATUS\G                                -- Seconds_Behind_Source

#সারসংক্ষেপ

মূল কথাগুলো

• RDS হলো managed relational database: hardware, OS আর engine-এর patch, backup, Multi-AZ failover আর replica সামলায় AWS; schema, query, size আর access সামলাও তুমি। Engine: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, IBM Db2 (Aurora আলাদা)। SSH নেই; OS-এ ঢুকতে হলে RDS Custom (Oracle, SQL Server) বা EC2।
• Connect করো endpoint (একটা DNS name) দিয়ে। Storage আসলে EBS: বেশিরভাগের জন্য gp3, স্থির বেশি IOPS-এর জন্য io2। Instance class বদলানো মানে reboot-সহ vertical scaling।
• Storage auto scaling: free space 10% বা কম, ৫ মিনিট ধরে, আর আগের বদলের optimization শেষ (২৪ ঘণ্টায় ৪টার কম বদল; পুরনো material বলে ৬ ঘণ্টা) হলে RDS যোগ করে 10 GiB, 10% বা অনুমিত ৭ ঘণ্টার বৃদ্ধি, যেটা বড়, তোমার maximum storage threshold পর্যন্ত। Downtime নেই; storage কখনো ছোট হয় না।
• Read replica: প্রতি source-এ ১৫টা পর্যন্ত (Db2: ৩), একই AZ, অন্য AZ বা অন্য Region-এ, asynchronous, eventually consistent, শুধু read (SELECT), প্রত্যেকের নিজের endpoint; read সেখানে পাঠানো app-এর কাজ। Reporting আর read-heavy load-এর জন্য। একই Region-এ replication ফ্রি, Region পার হলে টাকা লাগে।
• “আপডেট করলাম, তবু পুরনো দেখাচ্ছে”-এর ব্যাখ্যা replica lag। সমাধান: primary থেকে read-your-own-writes, cache, বা Aurora; ReplicaLag-এ চোখ রাখো।
• Replica promote করলে সেটা স্বাধীন read/write database হয়, replication শেষ হয়, নিজের endpoint রাখে, আর কাজটা সবসময় হাতে করতে হয়। Replica নিজে থেকে কখনো failover করে না।
• Multi-AZ DB instance: অন্য AZ-এ synchronous standby, একটাই DNS name, ৬০–১২০ সেকেন্ডে automatic failover, standby পড়া যায় না, scaling-এর জন্য না, খরচ প্রায় দ্বিগুণ। Single-AZ → Multi-AZ চালু অবস্থাতেই হয়: snapshot, অন্য AZ-এ restore, তারপর sync।
• Multi-AZ DB cluster: তিন AZ-এ এক writer + দুটো পড়া-যায় standby, semi-synchronous, reader endpoint, failover ৩৫ সেকেন্ডের কম, শুধু MySQL আর PostgreSQL।
• RDS-এর cross-Region DR = cross-Region read replica, হাতে promote; DR database-কে HA হতে হলে replica-তে Multi-AZ চালু করো। “Multi-Region option” বলে কিছু নেই। Aurora → Global Database; DynamoDB → Global Tables।

নিজেকে যাচাই করো: RDS, read replica আর Multi-AZ৩০টি প্রশ্ন