Ravindra BagaleCourses & study guides English

Amazon RDS Multi-AZ vs Read Replicas सोप्या भाषेत

By , trainer LinkedIn Last updated:

Web आणि app tiers दुसऱ्या AZ मध्ये copy करता येतात, High availability: two AZs प्रमाणे. Database अवघड आहे: त्यात data असतो, तो भरतो, त्याला backups लागतात, आणि दोन copies कधीच वेगळ्या असता कामा नयेत. हा chapter स्वतःच्या EC2 वरचा MySQL आणि Amazon RDS, म्हणजे managed database service, यांची तुलना करतो. RDS स्वतःहून storage कसा वाढवतो, point-in-time restore दोन backups मधला gap कसा भरतो, synchronous आणि asynchronous copies मधला फरक, primary बंद पडला की Multi-AZ standby जागा कशी घेतो, आणि read replicas read traffic कसं झेलतात, हे बघू. शेवटी कुठलं कधी वापरायचं आणि का, हे तुम्ही सांगू शकाल.

या class मध्ये काय शिकणार

  • स्वतःच्या EC2 वर database vs Amazon RDS
  • भरलेला disk database का थांबवतो, आणि RDS storage autoscaling
  • Backups, आणि point-in-time restore
  • Synchronous vs asynchronous copies
  • "Managed" म्हणजे काय: endpoint, SSH नाही
  • Multi-AZ: standby आणि automatic failover
  • Multi-AZ सोबत maintenance
  • दोन primary databases का चालवता येत नाहीत
  • Read replicas आणि replica lag
  • Cross-region replicas, आणि replica वरून कधी वाचायचं नाही
  • Multi-AZ vs read replicas, आणि console मध्ये बनवणे

1. स्वतःच्या EC2 वर database vs RDS

स्वतःचा EC2: server launch करता, sudo yum install mariadb105-server -y, आणि सगळं तुम्हीच सांभाळता: disk, backups, patches, दुसरी copy.

Amazon RDS (Relational Database Service): MySQL, MariaDB, PostgreSQL आणि इतर engines AWS तुमच्यासाठी चालवतो. तुम्ही database बनवता, एक address (endpoint) मिळतो, आणि त्याला connect होता. बनवायचे details Amazon RDS मध्ये आहेत.

बाकीचा chapter म्हणजे तुम्हाला स्वतः सोडवावे लागणारे problems, आणि RDS प्रत्येक कसा सोडवतो त्याची यादी.

2. Problem 1: disk भरतो

समजा DB server 8 GB disk ने सुरू झाला. एक campaign चालली, आणि रात्रीत sign-ups धडाधड आले.

  1. Disk 100% भरतो.
  2. MySQL ला लिहिता येत नाही: नवीन sign-ups fail, आणि app अडकतो.
  3. कोणीतरी हे बघून EBS volume 16 GB करायचा, आणि filesystem वाढवायचा.
  4. पुढच्या महिन्यात 32 GB, आणि परत.

Classroom line

Lakhs of people came overnight, and you slept peacefully through the night.

पहिल्याच दिवशी सगळ्यात मोठा disk का नाही घ्यायचा? Provision केलेल्या प्रत्येक GB ला पहिल्या दिवसापासून पैसे लागतात, वापरा किंवा नका वापरू.

Classroom line

Our job is not only technical; saving the company's money is also our job.

RDS storage autoscaling:

  1. लहान सुरुवात करा आणि maximum storage threshold ठरवा.
  2. Free space कमी झाली की RDS स्वतःहून storage वाढवतो.
  3. Downtime नाही, रात्री कोणाला जागं राहायला नको.
स्वतःच्या EC2 वर database: disk भरतो समजा DB server 8 GB disk ने सुरू झाला आणि रात्रीत sign-ups वाढले. 8 GB 100% भरला: MySQL लिहिणं थांबवतो 16 GB कोणीतरी हाताने वाढवतो 32 GB आणि परत, परत ... पहिल्याच दिवशी सगळ्यात मोठा disk घेणं म्हणजे पैसे वाया: provisionकेलेल्या प्रत्येक GB ला पहिल्या दिवसापासून पैसे. RDS storage autoscaling: maximum ठरवा, free space कमीझाली की RDS storage वाढवतो.

Figure 1. समजा 8 GB disk रात्रीत भरला: MySQL लिहिणं थांबवतो, आणि कोणीतरी हाताने 16 GB, मग 32 GB करतो. RDS storage autoscaling तुम्ही ठरवलेल्या maximum पर्यंत तो वाढवतो.

3. Problem 2: दोन backups मधला gap

समजा रोज रात्री 12:00 AM ला एक backup होतो, आणि database दुसऱ्या दिवशी 11:55 PM ला बंद पडतो.

  1. शेवटचा backup 12:00 AM चा.
  2. त्यानंतर लिहिलेलं सगळं, जवळजवळ पूर्ण दिवसाचे sign-ups, गेलं.

RDS automated backups daily snapshot आणि transaction logs (मधला प्रत्येक बदल) ठेवतात.

  1. Crash च्या साधारण 5 minutes आधीपर्यंत कुठल्याही second ला restore करता येतं. याला point-in-time restore म्हणतात.
  2. Restore मुळे नवीन DB instance बनतो; app त्याच्या endpoint कडे वळवायचा.
  3. Retention: 1 ते 35 दिवस.

Snapshots बद्दल आणखी: Backups and snapshots.

दिवसातून एक backup म्हणजे gap; point-in-timerestore तो भरतो समजा रोज रात्री 12:00 AM ला एक backup होतो, आणि database दुसऱ्या दिवशी11:55 PM ला बंद पडतो. 12:00 AM backup 11:55 PM crash फक्त daily backup: जवळजवळ पूर्ण दिवसाचे sign-ups गेले RDS automated backups: daily snapshot आणि transactionlogs Crash च्या साधारण 5 minutes आधीपर्यंत कुठल्याही second ला restore(point-in-time restore). Retention: 1 ते 35 दिवस.

Figure 2. 12:00 AM चा daily backup आणि दुसऱ्या दिवशी 11:55 PM चा crash म्हणजे जवळजवळ एक दिवस गेला. Transaction logs मुळे RDS crash च्या साधारण 5 minutes आधीपर्यंत कुठल्याही second ला restore करतो.

4. Synchronous vs asynchronous copies

Database ची प्रत्येक दुसरी copy या दोनपैकी एका प्रकारची असते.

Synchronous:

  1. App primary वर write करतो.
  2. Primary तो save करतो आणि दुसऱ्या database ला copy करतो.
  3. दोघांनी save केल्यावरच app ला "OK" मिळतो.
  4. काहीच जाऊ शकत नाही; प्रत्येक write थोडा जास्त थांबतो.

Asynchronous:

  1. App primary वर write करतो.
  2. Primary तो save करतो आणि लगेच "OK" देतो.
  3. Copy दुसऱ्या database ला थोड्या वेळाने जाते.
  4. Writes fast; copy थोडी मागे असू शकते.

Multi-AZ पहिला प्रकार वापरतो, read replicas दुसरा.

Synchronous vs asynchronous copy Synchronous (Multi-AZ standby): दोन्ही copies saveझाल्यावरच "OK". Failover ला data जात नाही; प्रत्येक write थोडा जास्त थांबतो. PHP app · INSERT ... 1. write Primary · AZ-a 2. copy Standby · AZ-b 3. OK (दोन्हीकडे saveझाल्यावर) Asynchronous (read replica): आधी "OK", copy मागून. PHP app · INSERT ... 1. write Primary · AZ-a ← 2. लगेच OK 3. copy नंतर Read replica कुठलाही AZ किंवा Region Writes fast; replica थोडा मागे असू शकतो (replica lag).

Figure 3. Animation: synchronous, primary आणि standby दोघांनी write save केल्यावरच "OK"; asynchronous, लगेच "OK" आणि read replica ला copy मागून.

5. Managed म्हणजे: server नाही, endpoint

  1. Operating system, patches, database software, backups आणि failover AWS बघतो.
  2. तुम्हाला endpoint मिळतो, उदा. mydb.xxxx.ap-south-1.rds.amazonaws.com, port 3306 वर.
  3. PHP मध्ये $servername तो endpoint होतो.
  4. DB server ला SSH नाही: cp, mv, mkdir नाही, त्याच्यावर files edit करणं नाही.
  5. Operating system हवा असेल तर स्वतःच्या EC2 वर MariaDB चालवा. (RDS Custom OS access देतो, पण फक्त Oracle आणि SQL Server साठी.)
  6. RDS instance चा security group फक्त app tier च्या security group कडून 3306 allow करतो.
RDS managed आहे: तुम्हाला server नाही, endpointमिळतो AWS करतो • Operating system आणि patching • Database software install आणि upgrades • Automated backups • Standby आणि failover (Multi-AZ) • Storage वाढवणे (autoscaling) तुम्ही करता • Tables, users आणि queries • Endpoint ला port 3306 वर connect • Security group: फक्त app SG कडून 3306 DB server ला SSH नाही: cp, mv, mkdir नाही. OS हवा? स्वतःच्या EC2 वर MariaDB (किंवा RDS Custom: फक्त Oracle/ SQL Server).

Figure 4. AWS OS, patching, software, backups, failover आणि storage वाढवणे करतो. तुम्ही tables, users आणि queries करता, endpoint ला 3306 वर connect होता, आणि फक्त app SG कडून 3306 allow करता. SSH नाही.

6. Multi-AZ: जागा घेणारा standby

का: एका AZ मधला एकच database म्हणजे single point of failure.

कसं चालतं:

  1. ap-south-1a मधला primary app कडचे सगळे reads आणि writes घेतो.
  2. RDS ap-south-1b मध्ये एक standby ठेवतो आणि प्रत्येक write त्याला synchronously copy करतो.
  3. Standby कुठलंही traffic serve करत नाही. तो थांबून असतो.
  4. Primary बंद पडला (instance, त्याचं storage किंवा पूर्ण AZ), तर RDS standby ला primary बनवतो, साधारण 1-2 minutes मध्ये.
  5. Endpoint नाव तेच राहतं; RDS ते नवीन primary कडे वळवतो. App code न बदलता परत connect होतो.

Classroom line

They are all people; only their roles are different.

Primary, standby आणि replica हे सगळे साधे database instances च; फक्त त्यांचे roles वेगळे.

Multi-AZ: दुसऱ्या AZ मधला standby जागा घेतो PHP app mydb.xxxx.rds.amazonaws.com 1. App endpoint वापरतो; primary प्रत्येक write standby लाsynchronously copy करतो. ap-south-1a Primary   सगळे reads आणि writes ap-south-1b Standby   sync copy, काहीच serve नाही ap-south-1a Primary बंद पडला   AZ किंवा instance problem 2. Primary बंद पडतो. RDS ते ओळखून standby ला promote करतो, साधारण1-2 minutes मध्ये. ap-south-1b नवीन primary   तेच endpoint नाव 3. Endpoint नाव आता नवीन primary कडे. App परत connect होतो; codeबदलत नाही.

Figure 5. Animation: ap-south-1a मधला primary ap-south-1b मधल्या standby ला copy करतो; primary बंद पडतो; RDS साधारण 1-2 minutes मध्ये standby promote करतो, आणि तोच endpoint आता त्याच्याकडे.

7. Multi-AZ सोबत maintenance

Operating system maintenance (patches) एका वेळी एका copy वर होतं:

  1. Primary serve करत असताना RDS standby patch करतो.
  2. Failover: patched standby primary होतो. App ला थोडा blip दिसतो.
  3. जुना primary, जो आता standby आहे, तो patch होतो.

म्हणजे patching साठी मोठ्या downtime ऐवजी फक्त थोडा blip.

Database engine version upgrade वेगळं: primary आणि standby एकत्र upgrade होतात, म्हणून त्यासाठी downtime plan करा.

Multi-AZ वर OS maintenance: आधी standby, मगfailover 1. Standby patch Primary: serving · Standby: patching App ला काहीच कळत नाही. 2. Failover जुना standby: आता primary · जुना primary: standby Switch होताना थोडा blip. 3. जुना primary patch Primary: serving · Standby: patching दोन्ही patched, फक्त थोडा downtime. Database engine version upgrade वेगळं: primary आणि standby एकत्रupgrade होतात, downtime सोबत.

Figure 6. OS maintenance: standby patch, failover, जुना primary patch; फक्त थोडा blip. Engine version upgrade दोन्ही एकत्र करतो, downtime सोबत.

8. Database bottleneck बनतो तेव्हा

समजा आपण Instagram आहोत. Load balancer users चार web servers मध्ये वाटतो (Load balancing). चारही एकाच database शी बोलतात, आणि आता database busy आहे.

  1. Scale up: मोठा DB instance class. मदत होते, पण सगळ्यात मोठी size कधीतरी संपते.
  2. दोन primary databases? मग एक write DB 1 वर आणि पुढचा DB 2 वर पडतो. User चा like एकावर, comment दुसऱ्यावर. Data जुळत नाही.

Classroom line

When does the data mismatch problem come up?

Classroom line

We'll have to find a workaround.

9. Reads vs writes

Users नक्की काय करतात ते बघा.

  1. Writes: reel post करणे, like, comment. हे INSERT, UPDATE, DELETE.
  2. Reads: feed scroll करणे, reels बघणे, profiles उघडणे. हे SELECT.
  3. बहुतेक traffic reads असतं.

म्हणून writes साठी एकच जागा ठेवा, आणि reads साठी आणखी जागा add करा.

10. Read replicas

  1. Primary सगळे writes घेतो.
  2. RDS प्रत्येक बदल एक किंवा जास्त read replicas ना asynchronously copy करतो. MySQL आणि MariaDB मध्ये 15 पर्यंत.
  3. प्रत्येक replica चा स्वतःचा endpoint असतो.
  4. App writes primary endpoint ला आणि SELECTs replica endpoint ला पाठवतो. समजा आपण Instagram: upload आणि like APIs primary वापरतात; "view reel" API replica वापरतो.
  5. Copy asynchronous असल्यामुळे replica थोडा मागे असू शकतो: like count एका second साठी एकाने कमी दिसू शकतो. याला replica lag म्हणतात. काहीच जात नाही; replica मागून पोचतो.

Classroom line

There will be a separate API for uploading a reel.

समजा आपण Instagram: बहुतेक traffic reads PHP app Writes Reads (बहुतेक) post, like, comment scroll, reels बघणे, profiles INSERT UPDATE DELETE SELECT Primary सगळे writes ↓ arrow = प्रत्येक replica लाasync copy (MySQL/MariaDB:15 replicas पर्यंत) Read replica 1 फक्त SELECTs Read replica 2 फक्त SELECTs Read replica 3 फक्त SELECTs

Figure 7. Writes (post, like, comment) primary कडे; reads (scroll, reels, profiles), म्हणजे बहुतेक traffic, read replicas कडे, ज्यांना asynchronous copy मिळते. MySQL/MariaDB: 15 replicas पर्यंत.

11. Users जवळ replicas, आणि ते कधी वापरायचे नाहीत

  1. प्रत्येक AZ मध्ये: ap-south-1a मधले web servers ap-south-1a मधल्या replica वरून वाचतात, आणि ap-south-1b मधले ap-south-1b मधल्या replica वरून. Cross-AZ traffic कमी, उत्तर लवकर.
  2. दुसऱ्या Regions मध्ये: primary Mumbai मध्ये, replicas Singapore, N. Virginia किंवा London मध्ये, म्हणजे लांबचे users जवळून वाचतात. Replica जितका लांब, lag तितका जास्त; seconds पण होऊ शकतात.
  3. चालतं: likes, comments, reels, profiles.
  4. चालत नाही: जो read latest value च हवा, उदा. bank balance किंवा stock trade. ते primary वरून वाचा.

Classroom line

In the stock market you can't use this read replica.

लांबच्या users साठी cross-region read replicas Primary: Mumbai ap-south-1 Replica: Singapore ap-southeast-1 Replica: N. Virginia us-east-1 Replica: London eu-west-2 यासाठी चालतं likes, comments, reels जे reads latest च हवेत त्यांसाठी नाही: bank balance,stock trades. लांबचे replicas जास्त मागे, कधी seconds. अशा values primary वरूनचवाचा.

Figure 8. Primary Mumbai मध्ये, replicas Singapore, N. Virginia आणि London मध्ये. Likes, comments आणि reels साठी चालतं; bank balance किंवा stock trades साठी नाही, ते primary वरूनच वाचायचे.

खर्च आणि storage: replica म्हणजे पूर्ण copy, म्हणून त्याला primary इतका तरी storage लागतो (instance size वेगळी असू शकते). प्रत्येक replica म्हणजे bill वर आणखी एक instance, म्हणून read load ला जितके लागतील तितकेच add करा.

12. Multi-AZ vs read replicas

  1. Multi-AZ availability साठी: failure मधून वाचणे. Synchronous, एक standby, काहीच serve नाही, failover नंतर तोच endpoint.
  2. Read replicas performance साठी: reads झेलणे. Asynchronous, 15 पर्यंत, प्रत्येक स्वतःच्या endpoint वर SELECTs serve करतो.
  3. Production databases बहुतेक दोन्ही वापरतात: Multi-AZ primary, आणि reads साठी replicas.
Multi-AZ vs read replicas उद्देश Multi-AZ: Failure मधून वाचणे (availability)   Read replicas: जास्त reads झेलणे (performance) Copy Multi-AZ: Synchronous   Read replicas: Asynchronous (replica lag) Traffic serveकरतो? Multi-AZ: नाही, standby थांबून असतो   Read replicas: हो, SELECTs कुठे Multi-AZ: दुसरा AZ, तोच Region   Read replicas: तोच AZ, दुसरा AZ किंवा दुसराRegion Endpoint Multi-AZ: Failover नंतर तोच endpoint   Read replicas: प्रत्येक replica चा स्वतःचाendpoint किती Multi-AZ: एक standby   Read replicas: 15 पर्यंत (MySQL/MariaDB)

Figure 9. Multi-AZ: availability, synchronous, standby काहीच serve करत नाही, तोच endpoint, एक standby. Read replicas: performance, asynchronous, SELECTs serve, स्वतःचे endpoints, MySQL/MariaDB साठी 15 पर्यंत.

आणखी तुलना Multi-AZ and read replicas मध्ये आहे.

13. Console मध्ये बनवा

Part A: database

  1. RDS > Databases > Create database, Standard create, engine MySQL.
  2. Templates: Production, किंवा practice साठी Dev/Test.
  3. Availability and durability: Multi-AZ DB instance deployment (primary + standby). Free practice साठी Single-AZ निवडा.
  4. Settings: DB instance identifier mydb, master username, आणि सुरक्षित ठेवलेला password.
  5. Storage: लहान सुरुवात करा, Enable storage autoscaling tick करा, Maximum storage threshold ठरवा.
  6. Connectivity: तुमचा VPC, किमान दोन AZs मधल्या private subnets असलेला DB subnet group, Public access: No, security group db-sg (app-sg कडून 3306).
  7. Additional configuration: initial database name insta, Enable automated backups, backup retention period दिवसांत.
  8. Create database. Status Available झाला की Endpoint copy करून app server वरच्या $servername मध्ये ठेवा.

Part B: एक read replica

  1. mydb select करा, Actions > Create read replica. (Automated backups चालू हवेत.)
  2. नाव mydb-replica-1, instance class आणि AZ (किंवा दुसरा Region) निवडा.
  3. Create read replica. त्याला स्वतःचा endpoint मिळतो; तो फक्त SELECTs साठी वापरा.

Part C: failover test करा (फक्त Multi-AZ)

  1. mydb select करा, Actions > Reboot, Reboot with failover tick करा.
  2. Logs & events बघा: standby primary होतो, आणि endpoint तोच राहतो.

14. दोन झटपट उत्तरं

Server चा public IP बदलतो का?

  1. Auto-assigned public IP reboot ला तोच राहतो.
  2. Stop → start ला बदलतो.
  3. Elastic IP दोन्हीमध्ये तसाच राहतो (What an Elastic IP is).

Classroom line

Unless you stop the server, the IP doesn't change.

App database साठी कुठला port वापरतो? Browsers web servers शी HTTP/HTTPS वर 80/443 ने बोलतात. App MySQL किंवा MariaDB शी 3306 वर, MySQL protocol ने बोलतो, HTTP ने नाही. म्हणून DB security group ला 80 नाही, 3306 लागतो.

15. काही चुकलं तर

  1. App RDS endpoint पर्यंत पोचत नाही: db-sg ने app-sg कडून 3306 allow करायला हवं, आणि DB त्याच VPC मध्ये हवा (Public access: No बरोबरच आहे).
  2. "Create read replica" greyed out आहे: automated backups बंद आहेत. किमान 1 दिवसाचा retention period ठेवा.
  3. User ला त्याचीच नवीन comment दिसत नाही: app ने ती write केल्या केल्या replica वरून वाचली. स्वतः नुकताच लिहिलेला data primary वरून वाचा.
  4. Failover वेळी app एक minute errors देतो: त्याने जुनं connection धरून ठेवलं. त्याला reconnect करायला लावा, आणि DB IP cache करू नका; नेहमी endpoint नाव वापरा.
  5. Bill दुप्पट झालं: Multi-AZ मध्ये standby चे पण पैसे लागतात, आणि प्रत्येक replica हा पूर्ण instance.

Ravindra Bagale's Tip

दोन वेगळे प्रश्न विचारा. "Database बंद पडला तर?" याचं उत्तर Multi-AZ आणि point-in-time restore. "Database खूप slow झाला तर?" याचं उत्तर read replicas (आणि caching). Availability साठी replicas किंवा speed साठी Multi-AZ घेऊ नका. आणि नेहमी endpoint नावाने connect करा, IP ने कधीच नाही.

16. संपूर्ण class एका page वर

  1. स्वतःच्या EC2 वर disk, backups, patches आणि copies तुम्ही सांभाळता; RDS ही ते करणारी managed service.
  2. भरलेला disk MySQL चं लिहिणं थांबवतो. RDS storage autoscaling तुम्ही ठरवलेल्या maximum पर्यंत storage वाढवतो; provision केलेल्याचे पैसे लागतात.
  3. Automated backups + transaction logs: crash च्या साधारण 5 minutes आधीपर्यंत point-in-time restore; retention 1-35 दिवस.
  4. Synchronous: दोन्ही copies save झाल्यावर "OK". Asynchronous: आधी "OK", copy नंतर.
  5. RDS 3306 वर endpoint देतो, SSH नाही. OS हवा: EC2 वर MariaDB, किंवा RDS Custom (फक्त Oracle/SQL Server).
  6. Multi-AZ: दुसऱ्या AZ मध्ये synchronous standby, काहीच serve नाही, साधारण 1-2 minutes मध्ये automatic failover, तोच endpoint.
  7. OS patches: आधी standby, failover, मग जुना primary. Engine upgrades: दोन्ही एकत्र, downtime सोबत.
  8. दोन primaries मुळे data जुळत नाही; writes साठी एकच primary ठेवा.
  9. Read replicas: SELECTs साठी asynchronous copies, स्वतःचे endpoints, MySQL/MariaDB साठी 15 पर्यंत; replica lag, data loss नाही.
  10. Cross-region replicas जास्त मागे; balances आणि trades primary वरून वाचा.
  11. Reboot ला auto-assigned public IP तोच राहतो; stop/start ला बदलतो. Apps MySQL शी 3306 वर बोलतात.

17. घरी करून बघा

घरी करून बघा

Task 1: कागदावर

  1. समजा backups रोज 12:00 AM ला होतात आणि DB 6:00 PM ला fail होतो. फक्त daily backup असेल तर किती तासांचा data जातो? Point-in-time restore ने किती जातो?
  2. Posts, likes, profile views आणि wallet balance असलेल्या app साठी, प्रत्येक read "replica OK" की "primary only" ते mark करा.

Task 2: console मध्ये

  1. Private DB subnet group मध्ये storage autoscaling आणि automated backups सोबत Single-AZ MySQL database बनवा.
  2. App server वरून mysql -h <endpoint> -u admin -p ने connect होऊन एक table बनवा.
  3. Read replica बनवा, primary वर एक row insert करा, आणि replica वर ती SELECT करा.

Task 3: clean up

  1. आधी read replica delete करा, मग database. Final snapshot ठेवायचा का ते ठरवा (snapshots चे पण पैसे लागतात).

Recap

थोडक्यात

  1. RDS disk, backups, patches आणि copies तुमच्या डोक्यावरून काढतो; तुम्हाला endpoint मिळतो, SSH नाही.
  2. Storage autoscaling आणि point-in-time restore भरलेला disk आणि backup gap चे problems सोडवतात.
  3. Multi-AZ = availability साठी synchronous standby, त्याच endpoint वर automatic failover.
  4. Read replicas = reads साठी asynchronous copies, थोड्या lag सोबत.
  5. Writes साठी एकच primary; बहुतेक reads replicas कडे, पण महत्त्वाच्या values primary वरून.
  6. "बंद पडला तर" साठी Multi-AZ, "slow झाला तर" साठी read replicas.

सराव Tasks

या scenario बद्दल

London Legal LLP हा लंडन मधला कायदा सेवा व्यवसाय आहे. Oliver Hughes त्यांचं IT व cloud काम पाहतात. त्यांचे पैसे GBP मध्ये मोजले जातात आणि AWS resources eu-west-2 Region मध्ये चालतात. खालच्या tasks मध्ये तुम्ही या lesson मध्ये शिकलेलं वापरून त्यांची खरी कामं करता. सगळी नावं, account IDs, IP addresses व numbers सरावासाठी काल्पनिक आहेत.

0 / 12

सोपं Database endpoint शोधा

का: App endpoint नावाने connect होतं, IP ने नाही.

काय करायचं: DB instance londonlegal-db describe करा.

कसं करायचं:
  1. Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
  2. aws लिहा, मग service चं नाव, मग operation (action शब्द).
  3. प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
  4. Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

सोपं मोठ्या orders आधी

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: Order id व amount, मोठी amount आधी.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

सोपं City नुसार customers

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: Pune मधल्या customers ची नावं.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

मध्यम लहान orders काढा

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: 200 पेक्षा कमी amount चे orders delete.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

मध्यम Customer नावांसह orders

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: प्रत्येक customer नाव व order amount.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

मध्यम एकूण sales

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: सगळ्या order amounts ची बेरीज.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

मध्यम City दुरुस्त करा

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: Customer 5 Rome ला गेले. Record update करा.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

मध्यम Multi-AZ सुरू करा

का: Multi-AZ दुसऱ्या AZ मध्ये standby ठेवतो व आपोआप failover करतो.

काय करायचं: londonlegal-db Multi-AZ करा व बदल लगेच लागू करा.

कसं करायचं:
  1. Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
  2. aws लिहा, मग service चं नाव, मग operation (action शब्द).
  3. प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
  4. Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

अवघड Customer नुसार sales

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: Customer नुसार total, फक्त 1000 पेक्षा जास्त.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

अवघड Orders नसलेले customers

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: कधीच order न केलेल्या customers ची नावं.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

अवघड MySQL database बनवा

का: RDS database तुमच्यासाठी चालवतं: backups, patches व failover managed.

काय करायचं: RDS instance londonlegal-db बनवा: engine mysql, class db.t3.micro, 20 GiB storage, master user admin, master password $DB_PASS मधून.

कसं करायचं:
  1. Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
  2. aws लिहा, मग service चं नाव, मग operation (action शब्द).
  3. प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
  4. Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

अवघड Read replica बनवा

का: Read replicas reports व read traffic main database वरून कमी करतात.

काय करायचं: Source londonlegal-db पासून londonlegal-db-ro read replica बनवा.

कसं करायचं:
  1. Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
  2. aws लिहा, मग service चं नाव, मग operation (action शब्द).
  3. प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
  4. Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

सगळे सराव tasks Task Hub मध्ये पाहा →

झटपट उजळणी cards

हा lesson दोन मिनिटांत revise करा. Cards phone वर save करा किंवा PNG download करा. प्रत्येक card वरचा QR त्याचा lesson उघडतो.

तुलना card: Database on your own EC2 vs Amazon RDS. Database on your own EC2: तुम्ही स्वतः EC2 वर MySQL install करता. Amazon RDS: AWS तुमच्यासाठी database चालवतो.
तुलना: Database on your own EC2 vs Amazon RDS · PNG download करा
तुलना card: Multi-AZ vs Read replica. Multi-AZ: दुसऱ्या AZ मध्ये database ची standby copy. Read replica: Database ची read-only copy.
तुलना: Multi-AZ vs Read replica · PNG download करा
तुलना card: Synchronous copy vs Asynchronous copy. Synchronous copy: दोन्ही copies मध्ये लिहिल्यावरच write पूर्ण. Asynchronous copy: Primary वर write पूर्ण; copy थोड्या वेळाने मागून येते.
तुलना: Synchronous copy vs Asynchronous copy · PNG download करा
तुलना card: Reads vs Writes. Reads: फक्त data आणणाऱ्या queries. Writes: Data बदलणाऱ्या queries.
तुलना: Reads vs Writes · PNG download करा
उजळणी card: Amazon RDS म्हणजे काय?. स्वतःच्या EC2 वर MySQL म्हणजे backups, patching, failover सगळं तुम्हीच. RDS ही managed database service. Server AWS चालवतं; तुम्ही database वापरता. RDS › Create database › engine, size, subnet group निवडा. Endpoint ने connect करा. App इथे connect होतं:
उजळणी card: Amazon RDS म्हणजे काय? · PNG download करा
उजळणी card: RDS Multi-AZ. एकच database server किंवा त्याचा AZ बंद पडला तर पूर्ण app थांबतं. Multi-AZ दुसऱ्या AZ मध्ये standby copy ठेवतं, synchronously update. त्यावर traffic नसतं. DB बनवताना किंवा modify करताना Multi-AZ tick करा. Failover आपोआप; endpoint तोच राहतो. ap-south-1a मधला primary बंद. 1b मधला standby साधारण 1-2 minutes मध्ये काम घेतो.
उजळणी card: RDS Multi-AZ · PNG download करा
उजळणी card: RDS read replica. बहुतेक apps लिहितात त्यापेक्षा खूप जास्त वाचतात. अनेक SELECTs ने एक server slow होतो. Read replica म्हणजे read-only copy, asynchronously update. त्याचा स्वतःचा endpoint असतो. Actions › Create read replica. SELECTs replica कडे, writes primary कडे पाठवा. Product page चे reads replica कडे; orders चा INSERT primary कडे.
उजळणी card: RDS read replica · PNG download करा
उजळणी card: RDS endpoint आणि subnet group. Failover नंतर IP बदलू शकतो. Apps ना नेहमी चालणारं एक नाव हवं. Endpoint = database चं DNS नाव. DB subnet group = 2+ AZs मधले private subnets जिथे RDS राहू शकतो. दोन private subnets चा subnet group बनवा, DB बनवताना तो निवडा. Subnet group: 10.0.32.0/20 (1a) आणि 10.0.48.0/20 (1b).
उजळणी card: RDS endpoint आणि subnet group · PNG download करा
मुलाखत card: Multi-AZ vs read replica: high availability कोण देतं?. Multi-AZ. Primary बंद पडला तर standby आपोआप काम घेतो. Read replica reads scale करायला; ती async आहे, auto failover नाही. Production: safety साठी Multi-AZ + जड SELECT traffic साठी 1-2 replicas.
मुलाखत card: Multi-AZ vs read replica: high availability कोण देतं? · PNG download करा
मुलाखत card: EC2 वरच्या MySQL ऐवजी RDS का निवडाल?. RDS automated backups, patching, Multi-AZ आणि सोपे replicas देतं. EC2 वर हे सगळं तुम्हीच करता, आणि चुकीत data जातो. OS access किंवा unsupported setup हवा असेल तेव्हाच EC2.
मुलाखत card: EC2 वरच्या MySQL ऐवजी RDS का निवडाल? · PNG download करा
मुलाखत card: Multi-AZ failover मध्ये endpoint चं काय होतं?. Endpoint चं नाव तेच; त्याचा DNS आता नवीन primary कडे. Apps मध्ये config बदल नको; फक्त reconnect. App config मध्ये endpoint वापरा, IP कधीच नाही.
मुलाखत card: Multi-AZ failover मध्ये endpoint चं काय होतं? · PNG download करा
मुलाखत card: RDS database publicly accessible असावा का?. नाही. Private subnets मध्ये, Public access = No. Public database वर port 3306 वर scan आणि attack होतात. DB SG मध्ये 3306 फक्त app server SG कडून allow.
मुलाखत card: RDS database publicly accessible असावा का? · PNG download करा

अजून cards: Ravi Sir's Cards.