Multi-AZ และการสำรองข้อมูลอัตโนมัติ
เปิดใช้ Multi-AZ เพื่อจำลองแบบไปยังเครื่องสำรองแบบซิงโครนัส และทำความเข้าใจช่วงเวลาสำรองข้อมูลอัตโนมัติกับระยะเวลาเก็บรักษา
Multi-AZ และการสำรองข้อมูลอัตโนมัติ เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
Multi-AZ บน RDS คืออะไร
Multi-AZ เป็นฟีเจอร์ความพร้อมใช้งานสูงของ RDS ที่จัดสรรแบบจำลองสำรองแบบซิงโครนัสโดยอัตโนมัติใน Availability Zone อื่นภายในรีเจียนเดียวกัน AWS จัดการการจำลองข้อมูลอย่างโปร่งใส คุณเชื่อมต่อผ่านปลายทาง DNS เดียว และ RDS จะกำหนดเส้นทางการรับส่งข้อมูลไปยังฐานข้อมูลหลัก
หากอินสแตนซ์หลักล้มเหลวเนื่องจากปัญหาฮาร์ดแวร์ เครือข่าย หรือ OS, RDS จะสลับระบบไปยังอินสแตนซ์สำรองโดยอัตโนมัติภายในประมาณ 60–120 วินาที แอปพลิเคชันของคุณจะเชื่อมต่อใหม่ผ่านปลายทาง DNS เดิม ซึ่งขณะนี้ชี้ไปยังที่อยู่ IP ของอินสแตนซ์สำรอง
การเปิดใช้ Multi-AZ บนอินสแตนซ์ที่มีอยู่
คุณสามารถเปิดใช้ Multi-AZ ขณะสร้างอินสแตนซ์ RDS หรือแก้ไขอินสแตนซ์ที่มีอยู่ได้ เมื่อเปิดใช้กับอินสแตนซ์ที่กำลังทำงาน AWS จะสร้างสแนปช็อตของฐานข้อมูลหลัก กู้คืนไปยัง AZ ที่สอง แล้วซิงโครไนซ์โดยใช้การจำลองข้อมูลดั้งเดิมของเอนจิน กระบวนการนี้อาจทำให้การทำงาน I/O บนฐานข้อมูลหลักหยุดชะงักชั่วครู่ ดังนั้นควรกำหนดเวลาในช่วงที่มีการใช้งานน้อย หรือยอมรับเวลาที่กำหนดไว้ในช่วงเวลาบำรุงรักษา
Multi-AZ รองรับเอนจิน RDS ทั้งหมด รวมถึง MySQL, PostgreSQL, MariaDB, Oracle และ SQL Server และไม่จำเป็นต้องเปลี่ยนแปลงระดับแอปพลิเคชัน
# Enable Multi-AZ on an existing RDS instance
aws rds modify-db-instance \
--db-instance-identifier mydb \
--multi-az \
--apply-immediatelyกลไกการสลับระบบของ Multi-AZ
เมื่อเกิดการสลับระบบ RDS จะอัปเดต CNAME ของปลายทางฐานข้อมูลให้ชี้ไปยังอินสแตนซ์สำรองภายในเวลาประมาณ 60 วินาที แอปพลิเคชันของคุณต้องเชื่อมต่อใหม่หลังตรวจพบว่าการเชื่อมต่อ TCP หลุด หากต้องการลดความล่าช้าในการเชื่อมต่อใหม่:
- ใช้ TTL ของ DNS ที่สั้น (โดยทั่วไป RDS ตั้งไว้ที่ 5 วินาทีอยู่แล้ว)
- ใช้ การหน่วงเวลาแบบทวีคูณร่วมกับการลองใหม่ ในตรรกะการเชื่อมต่อ
- ใช้เครื่องมือจัดการพูลการเชื่อมต่อ เช่น RDS Proxy ซึ่งเชื่อมต่อใหม่โดยอัตโนมัติ
การสลับระบบยังสามารถเริ่มด้วยตนเองเพื่อการบำรุงรักษาหรือการเปลี่ยนคลาสอินสแตนซ์ได้ ทำให้การอัปเกรดแทบไม่มีช่วงหยุดให้บริการเมื่อเปิดใช้ Multi-AZ
# Force a manual failover for testing
aws rds reboot-db-instance \
--db-instance-identifier mydb \
--force-failoverMulti-AZ เทียบกับ Read Replicas
สิ่งที่มักสับสนในการสอบคือ Multi-AZ (สำหรับความพร้อมใช้งาน) กับ Read Replicas (สำหรับการปรับขนาด) ความแตกต่างสำคัญมีดังนี้:
- อินสแตนซ์สำรอง Multi-AZ: การจำลองข้อมูลแบบซิงโครนัส ไม่รองรับการรับส่งข้อมูลสำหรับอ่าน สลับระบบโดยอัตโนมัติ และอยู่ในรีเจียนเดียวกัน
- Read Replica: การจำลองข้อมูลแบบไม่พร้อมกัน รองรับการรับส่งข้อมูลสำหรับอ่าน ไม่สลับระบบโดยอัตโนมัติ และสามารถอยู่ข้ามรีเจียนได้
Multi-AZ ไม่ช่วยเพิ่มประสิทธิภาพการอ่าน เนื่องจากอินสแตนซ์สำรองไม่สามารถใช้สืบค้นได้ หากต้องการเพิ่มทั้งความพร้อมใช้งานและความสามารถในการรองรับการอ่าน ให้ใช้ Multi-AZ กับฐานข้อมูลหลักและเพิ่ม Read Replicas แยกต่างหาก
ภาพรวมการสำรองข้อมูลอัตโนมัติ
RDS จะสร้างสแนปช็อตฐานข้อมูลแบบเต็มทุกวันโดยอัตโนมัติ และบันทึกบันทึกธุรกรรมทุก 5 นาที ทั้งสองอย่างนี้ช่วยให้สามารถ กู้คืน ณ จุดเวลาใดเวลาหนึ่ง (PITR) ได้ทุกวินาทีภายในระยะเวลาเก็บรักษาข้อมูลสำรอง คุณสามารถกู้คืนฐานข้อมูลกลับไปยังสถานะ ณ เวลาใดก็ได้ภายในช่วงเวลาดังกล่าว
การสำรองข้อมูลอัตโนมัติเปิดใช้เป็นค่าเริ่มต้น และสามารถเก็บรักษาไว้ได้ตั้งแต่ 1 ถึง 35 วัน การตั้งค่าระยะเวลาเก็บรักษาเป็น 0 จะปิดใช้การสำรองข้อมูลอัตโนมัติ (รวมถึง PITR) ช่วงเวลาสำรองข้อมูลมีระยะเวลา 30 นาที ซึ่งคุณสามารถกำหนดเองหรือให้ AWS เลือกให้ในช่วงนอกเวลาเร่งด่วน
ช่วงเวลาสำรองข้อมูลและช่วงเวลาบำรุงรักษา
ช่วงเวลาสำรองข้อมูล คือช่วงเวลาที่ระบบสร้างสแนปช็อตประจำวัน ในช่วงเวลานี้ การทำงานของ I/O บนพื้นที่จัดเก็บอาจหยุดชั่วครู่สำหรับการติดตั้งแบบ Single-AZ ส่วนการติดตั้งแบบ Multi-AZ จะสร้างสแนปช็อตจากอินสแตนซ์สแตนด์บาย จึงไม่ส่งผลกระทบต่อ I/O ของอินสแตนซ์หลัก
ช่วงเวลาบำรุงรักษา คือช่วงเวลารายสัปดาห์ที่แยกต่างหาก ซึ่ง AWS จะใช้สำหรับติดตั้งแพตช์ OS อัปเกรดเอ็นจินรุ่นย่อย และปรับเปลี่ยนอินสแตนซ์ แนวทางปฏิบัติที่ดีที่สุดคือกำหนดช่วงเวลาทั้งสองให้ตรงกับช่วงที่มีการใช้งานน้อย และตรวจสอบให้แน่ใจว่าช่วงเวลาเหล่านี้ไม่ทับซ้อนกัน
# Set backup window and retention on create
aws rds create-db-instance \
--db-instance-identifier mydb \
--engine mysql \
--db-instance-class db.t3.micro \
--master-username admin \
--master-user-password MyPass123! \
--allocated-storage 20 \
--backup-retention-period 7 \
--preferred-backup-window '03:00-04:00'การกู้คืน ณ จุดเวลา (PITR)
เมื่อต้องการกู้คืนไปยังจุดเวลาที่กำหนด RDS จะกู้คืนจากสแนปช็อตประจำวันที่ใหม่ล่าสุดก่อน จากนั้นจึงเล่นบันทึกธุรกรรมซ้ำจนถึงเวลาที่ร้องขอ ผลลัพธ์คือ อินสแตนซ์ DB ใหม่—PITR จะไม่เขียนทับอินสแตนซ์ต้นทาง จึงมีเส้นทางการกู้คืนที่ปลอดภัยและไม่รบกวนระบบที่ใช้งานจริง
เมื่ออินสแตนซ์ที่กู้คืนพร้อมใช้งานแล้ว ให้ปรับสตริงการเชื่อมต่อของแอปพลิเคชันให้ชี้ไปยังปลายทางใหม่ ตรวจสอบความถูกต้องครบถ้วนของข้อมูล แล้วจึงลบอินสแตนซ์เดิมหากการกู้คืนนี้เป็นการดำเนินการโดยตั้งใจ โดยทั่วไป เวลาที่ใช้กู้คืนจะแปรผันตามขนาดฐานข้อมูลและปริมาณบันทึกนับจากสแนปช็อตล่าสุด
# Restore to a specific point in time
aws rds restore-db-instance-to-point-in-time \
--source-db-instance-identifier mydb \
--target-db-instance-identifier mydb-restored \
--restore-time 2026-06-20T14:30:00Zสแนปช็อต DB ด้วยตนเอง
นอกเหนือจากการสำรองข้อมูลอัตโนมัติแล้ว คุณยังสามารถสร้าง สแนปช็อตด้วยตนเอง ได้ทุกเมื่อ ซึ่งแตกต่างจากการสำรองข้อมูลอัตโนมัติ สแนปช็อตด้วยตนเอง ไม่อยู่ภายใต้ระยะเวลาเก็บรักษา—สแนปช็อตเหล่านี้จะคงอยู่จนกว่าคุณจะลบด้วยตนเอง
สแนปช็อตด้วยตนเองเหมาะสำหรับบันทึกสถานะก่อนการย้ายโครงสร้างฐานข้อมูลครั้งใหญ่ ก่อนอัปเกรดแอปพลิเคชัน หรือเมื่อสิ้นสุดรอบการเรียกเก็บเงินเพื่อจัดเก็บเป็นหลักฐานตามข้อกำหนด คุณยังสามารถแชร์สแนปช็อตด้วยตนเองกับบัญชี AWS อื่น หรือคัดลอกข้ามรีเจียนเพื่อการกู้คืนจากภัยพิบัติได้
# Create a manual snapshot
aws rds create-db-snapshot \
--db-instance-identifier mydb \
--db-snapshot-identifier mydb-before-migration-2026-06-20การคัดลอกสแนปช็อตข้ามรีเจียน
คุณสามารถคัดลอกสแนปช็อตอัตโนมัติหรือสแนปช็อตด้วยตนเองไปยังรีเจียน AWS อื่นเพื่อการกู้คืนจากภัยพิบัติ สำเนาดังกล่าวเป็นสแนปช็อตแบบเต็มที่จัดเก็บอยู่ในโครงสร้างพื้นฐาน S3 ของรีเจียนปลายทาง เมื่อคัดลอกแล้ว คุณสามารถกู้คืนอินสแตนซ์ RDS ใหม่ในรีเจียนนั้นได้ หากรีเจียนหลักไม่พร้อมใช้งาน
สแนปช็อตสำเนาสามารถเข้ารหัสที่ปลายทางได้ แม้ต้นทางจะไม่ได้เข้ารหัส (และในทางกลับกัน) การคัดลอกข้ามรีเจียนมีค่าใช้จ่ายในการถ่ายโอนข้อมูล ให้ใช้ AWS Backup หรือ Lambda ที่ทริกเกอร์โดย EventBridge เพื่อทำให้การคัดลอกสแนปช็อตข้ามรีเจียนเป็นระยะทำงานโดยอัตโนมัติ
# Copy a snapshot to another region
aws rds copy-db-snapshot \
--source-db-snapshot-identifier arn:aws:rds:us-east-1:123456789:snapshot:mydb-snap \
--target-db-snapshot-identifier mydb-snap-copy \
--source-region us-east-1 \
--region us-west-2RDS Proxy สำหรับการรวมการเชื่อมต่อ
Amazon RDS Proxy ทำหน้าที่คั่นกลางระหว่างแอปพลิเคชันกับ RDS และรวมการเชื่อมต่อฐานข้อมูลไว้ด้วยกัน ซึ่งมีประโยชน์อย่างยิ่งสำหรับฟังก์ชัน Lambda ที่อาจเปิดการเชื่อมต่ออายุสั้นหลายพันรายการจนใช้จำนวนการเชื่อมต่อฐานข้อมูลเต็มขีดจำกัด RDS Proxy จะมัลติเพล็กซ์การเชื่อมต่อ ทำให้ฐานข้อมูลเห็นการเชื่อมต่อที่ใช้งานอยู่จำนวนน้อยลงมาก
ระหว่างการสลับระบบเมื่อเกิดข้อขัดข้องของ Multi-AZ RDS Proxy จะรักษาการเชื่อมต่อของแอปพลิเคชันไว้ และสร้างการเชื่อมต่อฐานข้อมูลไปยังอินสแตนซ์หลักใหม่ ทำให้เวลาเชื่อมต่อแอปพลิเคชันใหม่ลดลงเหลือไม่กี่วินาทีแทนที่จะเป็นหลายนาที RDS Proxy ยังผสานการทำงานกับ Secrets Manager เพื่อหมุนเวียนข้อมูลรับรองโดยไม่ทำให้แอปพลิเคชันหยุดทำงาน
คลัสเตอร์ Multi-AZ เทียบกับอินสแตนซ์ Multi-AZ
ปัจจุบัน RDS มีตัวเลือก Multi-AZ สองแบบ ได้แก่ อินสแตนซ์ DB แบบ Multi-AZ (แบบดั้งเดิม มีสแตนด์บายหนึ่งตัว) และ คลัสเตอร์ DB แบบ Multi-AZ (มีอินสแตนซ์สแตนด์บายที่อ่านได้สองตัวใน AZ ที่แตกต่างกัน) โหมดคลัสเตอร์ใช้การจำลองแบบกึ่งซิงโครนัส และอนุญาตให้ส่งทราฟฟิกการอ่านไปยังสแตนด์บายได้ จึงมีความพร้อมใช้งานและความสามารถในการรองรับการอ่านสูงขึ้นโดยไม่ต้องใช้ Read Replicas แยกต่างหาก
สำหรับการสอบ SAA-C03 มักทดสอบอินสแตนซ์ DB แบบ Multi-AZ รุ่นดั้งเดิมมากที่สุด โปรดจำไว้ว่า คลัสเตอร์ Multi-AZ เป็นตัวเลือกใหม่ที่สแตนด์บายสามารถให้บริการการอ่านได้ ขณะที่สแตนด์บายแบบดั้งเดิมทำไม่ได้
ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า Multi-AZ มีการจำลองแบบไปยังสแตนด์บายแบบซิงโครนัสพร้อมการสลับระบบอัตโนมัติภายใน 60–120 วินาที การสำรองข้อมูลอัตโนมัติทำให้ใช้ PITR ได้ถึงทุกวินาทีภายในช่วงเวลาเก็บรักษา (1–35 วัน) และ สแนปช็อตด้วยตนเองจะคงอยู่โดยไม่มีกำหนดและสามารถคัดลอกข้ามรีเจียนเพื่อ DR ได้ บทถัดไป เราจะสำรวจ Read Replicas สำหรับกระจายทราฟฟิกการอ่านและเพิ่มปริมาณงานการอ่าน
คำถามที่พบบ่อย
บทเรียน “Multi-AZ และการสำรองข้อมูลอัตโนมัติ” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “Multi-AZ และการสำรองข้อมูลอัตโนมัติ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “Multi-AZ และการสำรองข้อมูลอัตโนมัติ”
เปิดใช้ Multi-AZ เพื่อจำลองแบบไปยังเครื่องสำรองแบบซิงโครนัส และทำความเข้าใจช่วงเวลาสำรองข้อมูลอัตโนมัติกับระยะเวลาเก็บรักษา คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “Multi-AZ และการสำรองข้อมูลอัตโนมัติ” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม
ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- เอนจิน RDS และคลาสอินสแตนซ์
- Multi-AZ และการสำรองข้อมูลอัตโนมัติ
- รีดเรพลิกาสำหรับการขยายการอ่าน
- ความปลอดภัยของ RDS: การเข้ารหัสและกลุ่มพารามิเตอร์