คำถามที่พบบ่อยเกี่ยวกับ Amazon RDS

คุณสามารถนึกถึงอินสแตนซ์ DB เป็นสภาพแวดล้อมฐานข้อมูลในระบบคลาวด์พร้อมด้วยทรัพยากรการประมวลผลและพื้นที่จัดเก็บที่คุณระบุ คุณสามารถสร้างและลบอินสแตนซ์ DB, กำหนด/ปรับปรุงแอตทริบิวต์โครงสร้างพื้นฐานของอินสแตนซ์ DB ของคุณ และควบคุมการเข้าถึงและความปลอดภัยผ่าน คอนโซลการจัดการของ AWS, Amazon RDS API และ AWS Command Line Interface คุณสามารถเรียกใช้อินสแตนซ์ DB ตั้งแต่หนึ่งรายการเป็นต้นไป และแต่ละอินสแตนซ์ DB จะสามารถรองรับฐานข้อมูลหรือแบบแผนฐานข้อมูลได้ตั้งแต่หนึ่งรายการเป็นต้นไป ขึ้นอยู่กับประเภทของกลไก

อินสแตนซ์ DB สร้างได้ง่ายๆ โดยใช้คอนโซลการจัดการของ AWS Amazon RDS API หรือ AWS Command Line Interface เมื่อต้องการเปิดใช้อินสแตนซ์ DB โดยใช้คอนโซลการจัดการของ AWS ให้คลิก "RDS" จากนั้นคลิกปุ่ม “เปิดใช้อินสแตนซ์ DB” บนแท็บอินสแตนซ์ ซึ่งจากจุดนั้น คุณจะสามารถกำหนดพารามิเตอร์สำหรับอินสแตนซ์ DB ของคุณ รวมถึงกลไกและเวอร์ชัน DB, โมเดลสิทธิ์การใช้งาน ประเภทอินสแตนซ์ ประเภทและปริมาณของพื้นที่จัดเก็บ และข้อมูลประจำตัวของผู้ใช้หลัก

คุณยังสามารถเปลี่ยนนโยบายการเก็บข้อมูลสำรอง ระยะเวลาการสำรองข้อมูลที่ต้องการ และระยะเวลาการบำรุงรักษาที่กำหนดเวลาไว้แล้วของอินสแตนซ์ DB ของคุณได้ หรือคุณเลือกที่จะสร้างอินสแตนซ์ DB โดยการใช้ CreateDBInstance API หรือคำสั่ง create-db-instance ได้เช่นกัน

เมื่ออินสแตนซ์ DB ของคุณพร้อมให้ใช้งาน คุณสามารถเข้าถึงตำแหน่งข้อมูลของอินสแตนซ์นั้นผ่านคำบรรยายอินสแตนซ์ DB ได้ในคอนโซลการจัดการของ AWS DescribeDBInstances API หรือ คำสั่ง describe-db-instances ซึ่งเมื่อใช้ตำแหน่งข้อมูลนี้ คุณจะสามารถสร้างสายอักขระการเชื่อมต่อที่จำเป็นเพื่อเชื่อมต่อโดยตรงกับอินสแตนซ์ DB ของคุณโดยการใช้เครื่องมือจัดการฐานข้อมูลหรือภาษาการเขียนโปรแกรมที่คุณต้องการ ทั้งนี้ เพื่อให้เครือข่ายสามารถส่งคำขอไปยังอินสแตนซ์ DB ที่ทำงานอยู่ของคุณได้ คุณจะต้องอนุญาตการเข้าถึงก่อน คุณสามารถดูคำอธิบายโดยละเอียดเกี่ยวกับวิธีจัดโครงสร้างสายอักขระการเชื่อมต่อและเริ่มต้นใช้งานได้ที่คู่มือการเริ่มต้นใช้งานของเรา

จากค่าเริ่มต้น ลูกค้าจะได้รับอนุญาตให้มีอินสแตนซ์ Amazon RDS DB ได้สูงสุด 40 รายการ ซึ่งในทั้ง 40 รายการนั้น สามารถเป็นอินสแตนซ์ RDS for Oracle หรือ RDS for SQL Server DB ได้สูงสุด 10 รายการภายใต้รุ่น “License Included” สามารถใช้ทั้ง 40 รายการสำหรับ Amazon Aurora, RDS สำหรับ PostgreSQL, RDS สำหรับ MySQL, RDS สำหรับ MariaDB และ RDS สำหรับ Oracle ภายใต้โมเดล Bring Your Own License (BYOL) โปรดทราบว่า RDS สำหรับ SQL Server จำกัดฐานข้อมูลให้มีได้ 100 รายการบนอินสแตนซ์ DB เดียว หากต้องการเรียนรู้เพิ่มเติม โปรดดูคู่มือผู้ใช้ Amazon RDS สำหรับ SQL Server

• RDS สำหรับ Amazon Aurora: ไม่มีขีดจำกัดที่กำหนดโดยซอฟต์แวร์
• RDS สำหรับ MySQL: ไม่มีขีดจำกัดที่กำหนดโดยซอฟต์แวร์
• RDS สำหรับ MariaDB: ไม่มีขีดจำกัดที่กำหนดโดยซอฟต์แวร์
• RDS for Oracle: 1 ฐานข้อมูลต่ออินสแตนซ์ ไม่มีขีดจำกัดจำนวนแบบแผนต่อฐานข้อมูลที่กำหนดโดยซอฟต์แวร์
• RDS สำหรับ SQL Server: มากถึง 100 ฐานข้อมูลต่ออินสแตนซ์
• RDS สำหรับ PostgreSQL: ไม่มีขีดจำกัดที่กำหนดโดยซอฟต์แวร์
• RDS สำหรับ Db2: มากถึง 8 ฐานข้อมูลต่ออินสแตนซ์

ต่อไปนี้คือหลายวิธีในการนำเข้าข้อมูลไปยัง Amazon RDS:

• MySQL: ยูทิลิตี้ mysqldump หรือ mysqlimport
• Oracle: Data Pump, นำเข้า/ส่งออกหรือ SQL Loader
• SQL Server: ตัวช่วยสร้างการนำเข้า/การส่งออก ไฟล์สำรองข้อมูลทั้งหมด (.bak) หรือ โปรแกรมการคัดลอกจำนวนมาก (BCP)
• PostgreSQL: pg_dump

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการนำเข้าและการส่งออกข้อมูล โปรดดูที่ คู่มือการนำเข้าข้อมูลสำหรับ MySQL, คู่มือการนำเข้าข้อมูลสำหรับ Oracle, คู่มือการนำเข้าข้อมูลสำหรับ SQL Server, คู่มือการนำเข้าข้อมูลสำหรับ PostgreSQL หรือ คู่มือการนำเข้าข้อมูลสำหรับ Db2

นอกจากนี้ AWS Database Migration Serviceยังช่วยให้คุณย้ายฐานข้อมูลไปยัง AWS ได้อย่างปลอดภัยอีกด้วย

กรอบเวลาการบำรุงรักษา Amazon RDS เป็นโอกาสของคุณที่จะควบคุมเมื่อเกิดการแก้ไขอินสแตนซ์ DB การอัปเกรดเวอร์ชันกลไกฐานข้อมูล และการแพตช์ซอฟต์แวร์ ในกรณีที่มีการร้องขอหรือจำเป็น หากมีการกำหนดเวลาที่จะทำการบำรุงรักษาไว้ในสัปดาห์ใด กิจกรรมดังกล่าวจะเริ่มต้นภายในระยะเวลาการบำรุงรักษาที่คุณระบุ

กิจกรรมบำรุงรักษาที่กำหนดให้ Amazon RDS ต้องออฟไลน์อินสแตนซ์ DB ของคุณ คือการดำเนินการประมวลผลการปรับขนาด (ซึ่งโดยปกติจะใช้เวลาตั้งแต่เริ่มจนจบเพียงไม่กี่นาที) อัปเกรดเวอร์ชันกลไกฐานข้อมูล หรือการแพตช์ซอฟต์แวร์ที่จำเป็น การแพตช์ซอฟต์แวร์ที่จำเป็นจะได้รับการกำหนดเวลาอัตโนมัติเฉพาะแพตช์ที่เกี่ยวข้องกับความปลอดภัยและความคงทนเท่านั้น การแพตช์ดังกล่าวไม่ได้เกิดขึ้นบ่อย (โดยทั่วไปจะเป็นหนึ่งครั้งในทุกไม่กี่เดือน) และแทบจะไม่ใช้หน้าต่างการบำรุงรักษาของคุณเกินหนึ่งส่วน

หากระหว่างที่ สร้างอินสแตนซ์ DBของคุณ คุณไม่ได้กำหนดระยะเวลาการบำรุงรักษารายสัปดาห์ที่ต้องการ ระบบจะกำหนดค่าเริ่มต้นให้เป็น 30 นาที หากคุณต้องการแก้ไขระหว่างที่ระบบดำเนินการบำรุงรักษาแทนคุณอยู่ คุณสามารถทำได้โดยการแก้ไขอินสแตนซ์ DB ของคุณในคอนโซลการจัดการของ AWS ModifyDBInstance API หรือ คำสั่ง modify-db-instance โดยคุณสามารถเลือกให้แต่ละอินสแตนซ์ DB มีหน้าต่างการบำรุงรักษาแตกต่างกันได้

การเรียกใช้อินสแตนซ์ DB เป็นการปรับใช้หลาย AZ สามารถช่วยลดผลกระทบของเหตุการณ์การบำรุงรักษาได้มากขึ้น โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการดำเนินการบำรุงรักษาที่ คู่มือผู้ใช้ Amazon RDS

สำหรับฐานข้อมูลการผลิต เราขอแนะนำให้คุณเปิดใช้งาน Enhanced Monitoring ซึ่งจะให้สิทธิ์การเข้าถึง CPU, หน่วยความจำ ระบบไฟล์ และตัวชี้วัดดิสก์ I/O กว่า 50 รายการ คุณสามารถเปิดใช้งานคุณสมบัติเหล่านี้เป็นรายอินสแตนซ์ได้ รวมถึงเลือกเวลาเริ่มต้นและสิ้นสุดได้ (เลือกได้สั้นสุด 1 วินาที) การใช้ CPU ในระดับสูงสามารถลดประสิทธิภาพการสืบค้น และในกรณีนี้ คุณอาจต้องการพิจารณาปรับขนาดคลาสอินสแตนซ์ DB ของคุณ โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการตรวจสอบอินสแตนซ์ DB ที่คู่มือผู้ใช้งาน Amazon RDS

หากคุณกำลังใช้ RDS สำหรับ MySQL หรือ MariaDB คุณสามารถ เข้าถึงข้อมูลบันทึกการสืบค้นที่ช้าสำหรับฐานข้อมูลของคุณ เพื่อตรวจสอบว่ามีการสืบค้น SQL ที่ดำเนินการช้าหรือไม่ และหากใช่ ให้ดูลักษณะการทำงานของแต่ละรายการ คุณสามารถตั้งค่าพารามิเตอร์ DB เป็น "slow_query_log" และค้นหาตาราง mysql.slow_log เพื่อตรวจสอบการค้นหา SQL ที่ดำเนินการช้าได้ โปรดดูที่ คู่มือผู้ใช้งาน Amazon RDS เพื่อเรียนรู้เพิ่มเติม

หากคุณกำลังใช้ RDS สำหรับ Oracle อยู่ คุณสามารถใช้ Oracle ติดตามข้อมูลไฟล์เพื่อดูว่าการสืบค้นใดที่ทำงานช้าได้ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเข้าถึงข้อมูลไฟล์การติดตาม โปรดดูที่ คู่มือผู้ใช้งาน Amazon RDS 

หากคุณกำลังใช้ RDS สำหรับ SQL Server อยู่ คุณสามารถใช้การติดตามเซิร์ฟเวอร์ SQL ฝั่งไคลเอ็นต์เพื่อระบุการสืบค้นที่ช้าได้ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเข้าถึงข้อมูลไฟล์การติดตามฝั่งเซิร์ฟเวอร์ โปรดดูที่คู่มือผู้ใช้งาน Amazon RDS

โปรดดูรายการเวอร์ชันของกลไกฐานข้อมูลที่รองรับในเอกสารของแต่ละกลไก ดังนี้

• Amazon Aurora
• Amazon RDS สำหรับ PostgreSQL
• Amazon RDS สำหรับ MySQL
• Amazon RDS for MariaDB
• Amazon RDS สำหรับ SQL Server
• Amazon RDS สำหรับ Oracle
• Amazon RDS สำหรับ Db2

โปรดตรวจสอบหน้าคำถามที่พบบ่อยเพื่อดูรายละเอียดเฉพาะเกี่ยวกับหมายเลขเวอร์ชันของแต่ละกลไกฐานข้อมูล Amazon RDS:

• Amazon RDS สำหรับ MySQL
• Amazon RDS for MariaDB
• Amazon RDS สำหรับ PostgreSQL
• Amazon RDS สำหรับ Oracle
• Amazon RDS สำหรับ SQL Server
• Amazon Aurora

Amazon RDS เพิ่มการรองรับ กลไกฐานข้อมูลหลักและรองเวอร์ชันใหม่อยู่เรื่อย ๆ จำนวนของเวอร์ชันใหม่ที่รองรับจะแตกต่างกันไป ขึ้นอยู่กับความถี่และเนื้อหาของส่วนที่เผยแพร่ และแพตช์จากผู้ให้บริการของกลไกหรือองค์กรพัฒนา รวมทั้งผลลัพธ์จากการตรวจสอบและแพตช์เหล่านี้อย่างละเอียดโดยทีมวิศวกรฐานข้อมูลของเรา อย่างไรก็ตาม โดยทั่วไปแล้วเราตั้งเป้าที่จะรองรับกลไกเวอร์ชันใหม่ภายใน 5 เดือนนับจากที่พร้อมใช้งานจริง

คุณสามารถระบุเวอร์ชันใดก็ได้ที่รองรับอยู่ในขณะนี้ (หลักและรอง) เมื่อสร้างอินสแตนซ์ DB ใหม่ผ่านกระบวนการเปิดใช้อินสแตนซ์ DB ในคอนโซลการจัดการของ AWS หรือใน CreateDBInstance API โปรดทราบว่ามีเพียงกลไกฐานข้อมูลบางเวอร์ชันเท่านั้นที่มีให้บริการในทุกภูมิภาค AWS

Amazon RDS มุ่งมั่นที่จะทำให้อินสแตนซ์ฐานข้อมูลของคุณทันสมัยอยู่เสมอ ด้วยการมอบเวอร์ชันที่ใหม่กว่าของกลไกฐานข้อมูลที่รองรับแก่คุณ หลังจากที่ผู้ให้บริการหรือองค์กรพัฒนาเปิดตัวกลไกฐานข้อมูลเวอร์ชันใหม่แล้ว เวอร์ชันดังกล่าวจะได้รับการทดสอบอย่างละเอียดโดยทีมวิศวกรฐานข้อมูลของเราก่อนจะเปิดให้ใช้งานใน Amazon RDS

เราขอแนะนำให้คุณ อัปเกรดอินสแตนซ์ฐานข้อมูลของคุณ เป็นเวอร์ชันรองล่าสุด เนื่องจากจะมีการแก้ไขด้านความปลอดภัยและการทำงานล่าสุด การอัปเกรดของเวอร์ชันรองจะมีเฉพาะการเปลี่ยนแปลงฐานข้อมูลที่เข้ากันได้กับเวอร์ชันรองก่อนหน้า (ของเวอร์ชันหลักเดียวกัน) ของกลไกฐานข้อมูลเท่านั้น ซึ่งไม่เหมือนกับการอัปเกรดของเวอร์ชันหลัก 

หากเวอร์ชันรองที่ออกใหม่ไม่มีการแก้ไขที่เป็นประโยชน์กับลูกค้า Amazon RDS เราอาจเลือกที่จะไม่เปิดให้ใช้งานเวอร์ชันนั้นใน Amazon RDS ทั้งนี้ หลังจากที่เปิดให้ใช้งานเวอร์ชันรองที่ออกใหม่ใน Amazon RDS เราจะตั้งค่าเวอร์ชันนั้นให้เป็นเวอร์ชันรองที่แนะนำสำหรับอินสแตนซ์ DB ใหม่ 

หากต้องการอัปเกรดอินสแตนซ์ฐานข้อมูลให้เป็นกลไกเวอร์ชันที่รองรับด้วยตนเอง ให้ใช้คำสั่งแก้ไขอินสแตนซ์ DB บนคอนโซลการจัดการของ AWS หรือ ModifyDBInstance API และตั้งค่าพารามิเตอร์เวอร์ชันกลไก DB ให้เป็นเวอร์ชันที่ต้องการ ซึ่งตามค่าเริ่มต้น ระบบจะดำเนินการอัปเกรดในช่วงของ ระยะเวลาการบำรุงรักษา ถัดไป คุณยังสามารถเลือกที่จะอัปเกรดได้ทันทีโดยการเลือกตัวเลือกดำเนินการทันทีใน API คอนโซล

หากเราตัดสินใจให้กลไกเวอร์ชันรองที่ออกใหม่มีการแก้ไขข้อผิดพลาดที่สำคัญเมื่อเทียบกับเวอร์ชันรองที่เผยแพร่ก่อนหน้านี้ เราจะกำหนดเวลาการอัปเกรดอัตโนมัติให้อินสแตนซ์ DB ที่ตั้งค่าการอัปเกรดเวอร์ชันรองอัตโนมัติเป็น “ใช่” โดยการอัปเกรดเหล่านี้จะถูกกำหนดเวลาให้ดำเนินการในช่วงของหน้าต่างการบำรุงรักษาตามที่ลูกค้าระบุ

เรากำหนดเวลาก็เพื่อให้คุณสามารถวางแผนต่างๆ โดยยึดจากกำหนดเวลานี้ได้ เนื่องจากระบบต้องหยุดทำงานเพื่ออัปเกรดเวอร์ชันของกลไก DB แม้แต่กับอินสแตนซ์แบบ Multi-AZ ก็ตาม หากคุณต้องการปิดการอัปเกรดเวอร์ชันรองอัตโนมัติ คุณก็สามารถทำได้โดยตั้งการตั้งค่าการอัปเกรดเวอร์ชันรองอัตโนมัติให้เป็น “ไม่”

ในกรณีของ RDS สำหรับ Oracle และ RDS for SQL Server หากการอัปเกรดเป็นเวอร์ชันรองถัดไปกำหนดให้ต้องมีการเปลี่ยนแปลงเป็นรุ่นอื่น เราอาจไม่กำหนดเวลาการอัปเกรดอัตโนมัติ ถึงแม้คุณได้เปิดการตั้งค่าการอัปเกรดเวอร์ชันรองอัตโนมัติไว้แล้วก็ตาม จะมีการตัดสินใจว่าจะกำหนดเวลาการอัปเกรดอัตโนมัติหรือไม่ในสถานการณ์นั้นๆ เป็นรายกรณี

เนื่องจากการอัปเกรดเวอร์ชันหลักจะมีความเสี่ยงด้านความเข้ากันได้อยู่บ้าง จึงจะไม่มีการดำเนินการโดยอัตโนมัติ โดยคุณจะต้องเริ่มดำเนินการเอง (เว้นแต่ในกรณีที่มีการยกเลิกเวอร์ชันหลัก โปรดดูที่ด้านล่าง) สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการอัปเกรดอินสแตนซ์ DB เป็นกลไกเวอร์ชัน DB ใหม่ ให้ดูที่ คู่มือผู้ใช้งาน Amazon RDS

ใช่ คุณสามารถทำได้โดยการสร้าง Database Snapshot ของอินสแตนซ์ DB ที่คุณมีอยู่ คืนค่าจาก Database Snapshot เพื่อสร้างอินสแตนซ์ DB ใหม่ จากนั้นก็เริ่มการอัปเกรดเวอร์ชันให้อินสแตนซ์ DB ใหม่ จากนั้นคุณจะสามารถทดสอบการทำงานกับสำเนาอินสแตนซ์ DB ที่อัปเกรดแล้วได้อย่างปลอดภัยก่อนจะตัดสินใจว่าจะอัปเกรดอินสแตนซ์ DB ดั้งเดิมของคุณดีหรือไม่

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการคืนค่า Database Snapshot ให้ดูที่ คู่มือผู้ใช้งาน Amazon RDS

• เราตั้งใจที่จะรองรับเวอร์ชันหลักที่ได้รับการเผยแพร่ (เช่น MySQL 5.6, PostgreSQL 9.6) เป็นเวลาอย่างน้อย 3 ปี นับจากที่เริ่มการรองรับโดย Amazon RDS
• เรามีความตั้งใจที่จะรองรับเวอร์ชันรอง (เช่น MySQL 5.6.37, PostgreSQL 9.6.1) เป็นเวลาอย่างน้อย 1 ปี นับจากที่เริ่มการรองรับโดย Amazon RDS

เราจะยกเลิกกลไกเวอร์ชันหลักและรองเป็นระยะๆ เวอร์ชันหลักมีให้ใช้งานอย่างน้อยจนกว่าชุมชนจะหมดอายุสำหรับเวอร์ชันชุมชนที่เกี่ยวข้อง หรือเวอร์ชันนั้นไม่ได้รับการแก้ไขซอฟต์แวร์หรือการอัปเดตด้านความปลอดภัยอีกต่อไป สำหรับเวอร์ชันรอง การยกเลิกจะเกิดขึ้นเมื่อเวอร์ชันรองมีข้อผิดพลาดหรือมีปัญหาด้านความปลอดภัยอย่างร้ายแรงซึ่งได้รับการแก้ไขในเวอร์ชันรองต่อมาแล้ว

แม้เรามุ่งมั่นที่จะปฏิบัติตามแนวทางเหล่านี้ แต่ในบางกรณีเราอาจยกเลิกเวอร์ชันหลักหรือรองเฉพาะบางเวอร์ชันเร็วขึ้น เช่น ในกรณีที่มีปัญหาด้านความปลอดภัย ในสถานการณ์ที่เกิดกรณีดังกล่าวขึ้นซึ่งมีโอกาสเป็นได้ต่ำนั้น Amazon RDS จะอัปเกรดกลไกฐานข้อมูลของคุณโดยอัตโนมัติเพื่อตอบสนองต่อปัญหานั้น โดยแต่ละสถานการณ์จะใช้ระยะเวลาที่ต่างออกไป ขึ้นอยู่กับปัญหาที่ได้รับการตอบสนองนั้น

เมื่อยกเลิกกลไกฐานข้อมูลเวอร์ชันรองใน Amazon RDS เราจะให้เวลาก่อนที่จะเริ่มการอัปเกรดอัตโนมัติสาม (3) เดือนหลังการประกาศ เมื่อสิ้นสุดระยะเวลานี้ ระบบจะกำหนดเวลาอินสแตนซ์ทั้งหมดที่ยังคงใช้งานเวอร์ชันรองที่ถูกยกเลิกให้อัปเกรดอัตโนมัติเป็นเวอร์ชันรองที่รองรับล่าสุดในช่วงระยะเวลาการบำรุงรักษาที่กำหนดเวลาไว้

เมื่อมีการเลิกใช้งานกลไกฐานข้อมูลเวอร์ชันหลักใน Amazon RDS เราจะให้ระยะเวลาอย่างน้อยหก (6) เดือนหลังจากการประกาศการเลิกใช้งานเพื่อให้คุณเริ่มต้นการอัปเกรดเป็นเวอร์ชันหลักที่รองรับได้ เมื่อระยะเวลาดังกล่าวสิ้นสุดลง อินสแตนซ์ใดก็ตามที่ยังคงใช้งานเวอร์ชันที่ถูกยกเลิกจะได้รับการอัปเกรดอัตโนมัติเป็นเวอร์ชันหลักใหม่ล่าสุดในช่วงของหน้าต่างการบำรุงรักษาที่กำหนดเวลาไว้

ในบางกรณี เราอาจเลิกใช้งานเวอร์ชันหลักหรือรองโดยไม่ต้องแจ้งให้ทราบล่วงหน้า เช่น เมื่อเราพบว่าเวอร์ชันใดไม่ตรงตามมาตรฐานคุณภาพ ประสิทธิภาพ หรือความปลอดภัยขั้นสูง ในกรณีที่ไม่น่าเกิดขึ้น Amazon RDS จะยุติการสร้างอินสแตนซ์ฐานข้อมูลใหม่และคลัสเตอร์ที่มีเวอร์ชันเหล่านี้ ลูกค้าปัจจุบันสามารถเรียกใช้ฐานข้อมูลต่อไปได้ โดยแต่ละสถานการณ์จะใช้ระยะเวลาที่ต่างออกไป ขึ้นอยู่กับปัญหาที่ได้รับการตอบสนองนั้น

คุณจ่ายเท่าที่คุณใช้ และไม่มีค่าใช้จ่ายขั้นต่ำหรือค่าธรรมเนียมการติดตั้งใดๆ คุณจะถูกเรียกเก็บเงินตาม:

• ชั่วโมงที่ใช้อินสแตนซ์ DB – เก็บตามคลาส (เช่น db.t2.micro, db.m4.large) ของอินสแตนซ์ DB ที่ใช้ไป เศษเวลาของอินสแตนซ์ DB ที่ใช้ไปไม่ครบชั่วโมงจะคิดค่าบริการเป็นส่วนเพิ่มต่อหนึ่งวินาที โดยคิดค่าบริการขั้นต่ำที่ 10 นาทีหลังจากการเปลี่ยนแปลงสถานะที่เรียกเก็บค่าบริการได้ เช่น การสร้าง การเริ่ม หรือการแก้ไขคลาสอินสแตนซ์ DB สำหรับรายละเอียดเพิ่มเติม โปรดอ่าน ประกาศมีอะไรใหม่ ของเรา
• พื้นที่จัดเก็บ (ต่อ GB ต่อเดือน) – ความจุของพื้นที่จัดเก็บ ที่คุณได้จัดสรรไว้สำหรับอินสแตนซ์ DB หากคุณปรับขนาดความจุของพื้นที่จัดเก็บที่จัดเตรียมไว้ภายในหนึ่งเดือน การเรียกเก็บเงินของคุณจะถูกแบ่งเป็นส่วนๆ
• คำขอ I/O ต่อเดือน – จำนวน คำขอพื้นที่จัดเก็บ I/O ที่คุณมีทั้งหมด (สำหรับพื้นที่จัดเก็บ Amazon RDS Magnetic และ Amazon Aurora เท่านั้น)
• IOPS ที่จัดสรรไว้ต่อเดือน – อัตรา IOPS ที่จัดสรรไว้โดยไม่คำนึงถึง IOPS ที่ใช้ไป (สำหรับพื้นที่เก็บข้อมูล SSD สำหรับ IOPS ที่จัดสรรไว้ของ Amazon RDS เท่านั้น)
• พื้นที่จัดเก็บข้อมูลสำรอง – พื้นที่จัดเก็บข้อมูลสำรองเป็นพื้นที่จัดเก็บข้อมูลที่เชื่อมโยงกับการสำรองข้อมูลของฐานข้อมูลโดยอัตโนมัติและ Snapshot ฐานข้อมูลที่ลูกค้าเริ่ม การเพิ่มระยะเวลาการเก็บข้อมูลสำรองหรือการรับ Snapshot ฐานข้อมูลเพิ่มจะช่วยเพิ่มพื้นที่จัดเก็บข้อมูลสำรองที่ฐานข้อมูลของคุณใช้
• การถ่ายโอนข้อมูล – การถ่ายโอนข้อมูลอินเทอร์เน็ตเข้าและออกจากอินสแตนซ์ DB ของคุณ

หากต้องการดูข้อมูลเกี่ยวกับราคา Amazon RDS โปรดไปที่ ส่วนราคาบนหน้าผลิตภัณฑ์ Amazon RDS

การเรียกเก็บเงินจะเริ่มต้นสำหรับอินสแตนซ์ DB ทันทีที่มีอินสแตนซ์ DB ที่พร้อมใช้งาน การเรียกเก็บเงินจะดำเนินต่อไปจนกว่าอินสแตนซ์ DB จะสิ้นสุดลง ซึ่งอาจเกิดจากการลบหรือเกิดเหตุอินสแตนซ์ขัดข้อง

ชั่วโมงอินสแตนซ์ DB จะถูกเรียกเก็บเงินในแต่ละชั่วโมงที่อินสแตนซ์ DB ของคุณกำลังทำงานอยู่ในสถานะที่พร้อมใช้งาน หากคุณไม่ต้องการให้มีการเรียกเก็บเงินอินสแตนซ์ DB อีกต่อไป คุณจะต้องหยุดหรือลบอินสแตนซ์เพื่อหลีกเลี่ยงการเรียกเก็บเงินสำหรับชั่วโมงอินสแตนซ์เพิ่มเติม ชั่วโมงอินสแตนซ์ DB บางส่วนที่ใช้ไปจะถูกเรียกเก็บเงินโดยเพิ่มขึ้นทีละหนึ่งวินาทีโดยมีค่าใช้จ่ายขั้นต่ำ 10 นาทีหลังจากการเปลี่ยนแปลงสถานะที่เรียกเก็บเงินได้ เช่น การสร้าง เริ่ม หรือแก้ไขคลาสอินสแตนซ์ DB

ในขณะที่อินสแตนซ์ฐานข้อมูลของคุณหยุดลง คุณจะถูกเรียกเก็บเงินสำหรับพื้นที่จัดเก็บที่จัดเตรียมไว้ (รวมถึง IOPS ที่จัดเตรียมไว้) และพื้นที่จัดเก็บข้อมูลสำรอง (รวมถึง Snapshot และการสำรองข้อมูลอัตโนมัติภายในหน้าต่างการเก็บข้อมูลที่ระบุ) แต่ไม่ใช่สำหรับชั่วโมงอินสแตนซ์ DB

มีบริการพื้นที่เก็บข้อมูลสำรองฟรีตามพื้นที่จัดเก็บฐานข้อมูลที่จัดเตรียมไว้ทั้งหมดของบัญชีของคุณทั่วทั้งรีเจี้ยน ตัวอย่างเช่น หากคุณมีอินสแตนซ์ MySQL DB ที่มีพื้นที่จัดเก็บที่จัดเตรียมไว้ 100 GB ต่อเดือน และอินสแตนซ์ PostgreSQL DB ที่มีพื้นที่จัดเก็บที่จัดเตรียมไว้ 150 GB ต่อเดือน ทั้งในรีเจี้ยนเดียวกันและบัญชีเดียวกัน เราจะมอบพื้นที่เก็บข้อมูลจำนวน 250 GB พื้นที่เก็บข้อมูลสำรองในบัญชีและรีเจี้ยนนี้โดยไม่มีค่าใช้จ่ายเพิ่มเติม คุณจะถูกเรียกเก็บเงินสำหรับพื้นที่เก็บข้อมูลสำรองที่เกินจำนวนนี้เท่านั้น

ในแต่ละวัน พื้นที่เก็บฐานข้อมูลที่จัดเตรียมไว้ทั้งหมดของบัญชีของคุณในรีเจี้ยนนี้จะถูกเปรียบเทียบกับพื้นที่จัดเก็บข้อมูลสำรองทั้งหมดของคุณในรีเจี้ยน และจะมีการเรียกเก็บเฉพาะพื้นที่จัดเก็บข้อมูลสำรองส่วนเกินเท่านั้น ตัวอย่างเช่น หากคุณมีพื้นที่จัดเก็บข้อมูลสำรองเกิน 10 GB ในแต่ละวัน คุณจะถูกเรียกเก็บเงินสำหรับพื้นที่จัดเก็บข้อมูลสำรอง 10 GB ต่อเดือนสำหรับเดือนนั้น หรือหากคุณมีพื้นที่จัดเก็บข้อมูลที่จัดเตรียมไว้ 300 GB ในแต่ละวัน และพื้นที่จัดเก็บข้อมูลสำรอง 500 GB ในแต่ละวัน แต่เพียงครึ่งเดือน คุณจะถูกเรียกเก็บเงินสำหรับพื้นที่จัดเก็บข้อมูลสำรองเพียง 100 GB ต่อเดือน (ไม่ใช่ 200 GB ต่อเดือน) เนื่องจากการเรียกเก็บเงินจะคำนวณเป็นรายวัน (ตามสัดส่วน) และไม่มีการสำรองข้อมูลตลอดทั้งเดือน โปรดทราบว่าพื้นที่จัดเก็บข้อมูลสำรองฟรีนั้นมีไว้สำหรับเฉพาะบัญชีและเฉพาะรีเจี้ยน

ขนาดการสำรองข้อมูลของคุณเป็นสัดส่วนโดยตรงกับปริมาณข้อมูลบนอินสแตนซ์ของคุณ ตัวอย่างเช่น หากคุณมีอินสแตนซ์ DB ที่มีพื้นที่เก็บข้อมูลที่จัดไว้ 100 GB แต่เก็บข้อมูลเพียง 5 GB ไว้ในนั้นการสำรองข้อมูลครั้งแรกของคุณจะอยู่ที่ประมาณ 5 GB เท่านั้น (ไม่ใช่ 100 GB) การสำรองข้อมูลที่ตามมาจะเพิ่มขึ้นและจะจัดเก็บข้อมูลที่เปลี่ยนแปลงไว้ในอินสแตนซ์ DB ของคุณเท่านั้น โปรดทราบว่าขนาดพื้นที่จัดเก็บข้อมูลสำรองจะไม่แสดงในคอนโซล RDS หรือในการตอบกลับ DescribeDBSnapshots API

พื้นที่จัดเก็บข้อมูลที่จัดเตรียมไว้สำหรับอินสแตนซ์ DB ของคุณสำหรับข้อมูลหลักจะอยู่ภายใน Availability Zone เพียงเขตพื้นที่เดียว เมื่อฐานข้อมูลของคุณได้รับการสำรองข้อมูลแล้ว ข้อมูลสำรอง (รวมถึงข้อมูลบันทึกธุรกรรม) จะถูกจำลองแบบซ้ำซ้อนตามพื้นที่ใน Availability Zone ต่างๆเพื่อให้ระดับความทนทานของข้อมูลมากยิ่งขึ้น โดยการจำลองแบบพิเศษที่เกิดขึ้นเพื่อเพิ่มความคงทนของข้อมูลสำรองที่สำคัญของคุณ จะแสดงออกมาเป็นราคาสำหรับพื้นที่จัดเก็บข้อมูลสำรองนอกเหนือจากส่วนที่คุณได้รับการจัดสรรให้ไม่ต้องเสียค่าใช้จ่าย

หากคุณระบุว่าอินสแตนซ์ DB ของคุณควรเป็นการใช้งานอินสแตนซ์แบบ Multi-AZ คุณจะถูกเรียกเก็บเงินตามการกำหนดราคาแบบหลาย AZ ที่แสดงไว้ในหน้าการกำหนดราคาของ Amazon RDS การเรียกเก็บเงินหลาย AZ จะเป็นไปตามขั้นตอนต่อไปนี้

• ชั่วโมงอินสแตนซ์ DB แบบ Multi-AZ – โดยอิงตามคลาส (เช่น db.t2.micro, db.m4.large) ของอินสแตนซ์ DB ที่ใช้ไป เช่นเดียวกับการปรับใช้แบบมาตรฐานใน Availability Zone เดียว เศษเวลาของอินสแตนซ์ DB ที่ใช้ไปไม่ครบชั่วโมงจะคิดค่าบริการเป็นส่วนเพิ่มต่อหนึ่งวินาที โดยคิดค่าบริการขั้นต่ำที่ 10 นาทีหลังจากการเปลี่ยนแปลงสถานะที่เรียกเก็บค่าบริการได้ เช่น การสร้าง การเริ่ม หรือการแก้ไขคลาสอินสแตนซ์ DB หากคุณแปลงการใช้งานฐานข้อมูล DB ระหว่างมาตรฐานและแบบหลาย AZ ภายในหนึ่งชั่วโมง คุณจะถูกเรียกเก็บเงินทั้งสองอัตราสำหรับชั่วโมงที่ใช้
• พื้นที่จัดเก็บข้อมูลที่จัดเตรียมไว้ (สำหรับอินสแตนซ์ DB หลาย AZ) – หากคุณแปลงการใช้งานระหว่าง AZ มาตรฐานกับหลาย AZ ภายในหนึ่งชั่วโมง คุณจะถูกเรียกเก็บเงินด้วยอัตราที่สูงกว่าสำหรับชั่วโมงนั้น
• คำขอ I/O ต่อเดือน – จำนวนคำขอเก็บข้อมูล I/O ทั้งหมดที่คุณมี การปรับใช้หลาย AZ ใช้คำขอ I/O เป็นจำนวนมากกว่าการใช้งานอินสแตนซ์ DB แบบมาตรฐาน โดยขึ้นอยู่กับอัตราส่วนการเขียน/อ่านฐานข้อมูลของคุณ การใช้งาน I/O ที่เขียนซึ่งเกี่ยวข้องกับการอัปเดตฐานข้อมูลจะเพิ่มเป็นสองเท่าเนื่องจาก Amazon RDS จำลองข้อมูลของคุณไปยังอินสแตนซ์ DB แบบสแตนด์บายแบบซิงโครนัส การใช้งาน I/O ที่อ่านจะไม่เปลี่ยนแปลง
• พื้นที่จัดเก็บข้อมูลสำรอง – การใช้พื้นที่จัดเก็บข้อมูลสำรองของคุณจะไม่เปลี่ยนแปลง ไม่ว่าอินสแตนซ์ DB ของคุณจะเป็นแบบมาตรฐานหรือเป็นการปรับใช้หลาย AZ ก็ตาม ระบบจะดึงสำรองข้อมูลจากสแตนด์บายของคุณเพื่อหลีกเลี่ยงการหยุดชะงักของ I/O บนอินสแตนซ์ DB หลัก
• การถ่ายโอนข้อมูล – จะไม่มีการคิดค่าใช้จ่ายในการถ่ายโอนข้อมูลที่เกิดขึ้นในการจำลองข้อมูลระหว่างข้อมูลหลักและการสแตนด์บายของคุณ การถ่ายโอนข้อมูลทางอินเทอร์เน็ตเข้าและออกจากอินสแตนซ์ DB ของคุณจะมีการคิดค่าใช้จ่ายเหมือนการปรับใช้แบบมาตรฐาน

ราคาของเราไม่รวมภาษีและอากร ซึ่งรวมถึง VAT และภาษีการขายที่เกี่ยวข้อง เว้นแต่ระบุไว้เป็นอย่างอื่น สำหรับลูกค้าที่มีที่อยู่สำหรับเรียกเก็บเงินประเทศในญี่ปุ่น การใช้บริการของ AWS จะต้องเสียภาษีการบริโภคของประเทศญี่ปุ่น เรียนรู้เพิ่มเติม

ข้อเสนอ AWS Free Tier สำหรับ Amazon RDS มีอินสแตนซ์ Micro DB แบบ AZ เดียวที่เรียกใช้ MySQL, MariaDB, PostgreSQL และ SQL Server Express Edition ให้ใช้ฟรี Free Usage Tier จะจำกัดไว้ที่ 750 ชั่วโมงอินสแตนซ์ต่อเดือน อีกทั้งลูกค้าจะได้รับพื้นที่จัดเก็บฐานข้อมูลสำหรับการใช้งานทั่วไป (SSD) ขนาด 20 GB และพื้นที่จัดเก็บข้อมูลสำรองขนาด 20 GB ฟรีต่อเดือน

บัญชี AWS ใหม่จะได้รับการเข้าถึง AWS Free Tier เป็นเวลา 12 เดือน โปรดดูข้อมูลเพิ่มเติมที่ คำถามที่พบบ่อยเกี่ยวกับ AWS Free Tier

ใช่ คุณสามารถเรียกใช้อินสแตนซ์ Micro DB แบบ AZ เดียวมากกว่าหนึ่งรายการขึ้นไปพร้อมกันได้ และมีสิทธิ์ใช้งานภายใต้ AWS Free Tier สำหรับ Amazon RDS อย่างไรก็ตาม ส่วนใดก็ตามที่ใช้เกินจาก 750 ชั่วโมงอินสแตนซ์ โดยนับรวมทั่วทุกอินสแตนซ์ Micro DB แบบ AZ เดียวของ Amazon RDS และทั่วทุกกลไกฐานข้อมูลและรีเจี้ยนที่เข้าเกณฑ์ จะเรียกเก็บค่าบริการตามราคา Amazon RDS มาตรฐาน

ตัวอย่างเช่น หากคุณเรียกใช้อินสแตนซ์ Micro DB แบบ AZ เดียวสองรายการเป็นเวลา 400 ชั่วโมงต่อรายการภายในหนึ่งเดือน จะเท่ากับว่าคุณมีชั่วโมงอินสแตนซ์ที่ใช้ไปทั้งหมด 800 ชั่วโมง โดยจะใช้งานได้ฟรี 750 ชั่วโมง คุณจะถูกเรียกเก็บเงินส่วนของ 50 ชั่วโมงที่เหลือในราคา Amazon RDS มาตรฐาน

ไม่มี ลูกค้าที่มีสิทธิ์เข้าถึง AWS Free Tier สามารถใช้งานอินสแตนซ์ Micro ได้สูงสุด 750 ชั่วโมงที่ใช้งาน MySQL, PostgreSQL หรือ SQL Server Express Edition ส่วนใดก็ตามที่ใช้เกินจาก 750 ชั่วโมงอินสแตนซ์ โดยนับรวมทั่วทุกอินสแตนซ์ Micro DB แบบ AZ เดียวของ Amazon RDS และทั่วทุกกลไกฐานข้อมูลและรีเจี้ยนที่เข้าเกณฑ์ จะเรียกเก็บค่าบริการตามราคา Amazon RDS มาตรฐาน

จะมีการเรียกเก็บเงินที่ราคา Amazon RDS มาตรฐานสำหรับชั่วโมงอินสแตนซ์ที่นอกเหนือจากที่ Free Tier มีให้ โปรดดูรายละเอียดที่ หน้าราคาของ Amazon RDS

อินสแตนซ์แบบเหมาจ่ายของ Amazon RDS ให้ทางเลือกแก่คุณในการเหมาจ่ายอินสแตนซ์ DB เป็นระยะเวลาหนึ่งหรือสามปี และรับส่วนลดจำนวนมากตามลำดับเมื่อเปรียบเทียบกับราคา On-Demand Instance สำหรับอินสแตนซ์ DB มีตัวเลือกการชำระเงิน RI สามแบบ ได้แก่ ไม่มีค่าบริการล่วงหน้า ชำระเงินล่วงหน้าบางส่วน และชำระล่วงหน้าเต็มจำนวน ซึ่งจะช่วยให้คุณจัดสรรจำนวนที่คุณจะชำระล่วงหน้าตามราคารายชั่วโมงที่คุ้มค่าและเหมาะสำหรับคุณได้

ในด้านฟังก์ชันการทำงาน อินสแตนซ์แบบเหมาจ่ายและอินสแตนซ์ DB แบบตามความต้องการนั้นไม่ต่างกันเลย ข้อแตกต่างเพียงอย่างเดียวคือวิธีเรียกเก็บเงินอินสแตนซ์ DB ของคุณ ด้วยอินสแตนซ์แบบเหมาจ่าย คุณจะซื้อแบบเหมาจ่ายหนึ่งหรือสามปี และรับอัตราการใช้งานรายชั่วโมงที่คุ้มค่าและถูกกว่า (เมื่อเทียบกับอินสแตนซ์ DB แบบตามความต้องการ) ตลอดระยะเวลาของสัญญาได้ เว้นแต่ว่าคุณจะซื้ออินสแตนซ์แบบเหมาจ่ายในภูมิภาค อินสแตนซ์ DB ทั้งหมดจะถูกเรียกเก็บตามอัตรารายชั่วโมงตามความต้องการ

คุณสามารถซื้ออินสแตนซ์แบบเหมาจ่ายได้ที่ส่วน "อินสแตนซ์แบบเหมาจ่าย" ของคอนโซลการจัดการของ AWS สำหรับ Amazon RDS หรือคุณสามารถใช้ Amazon RDS API หรือ AWS Command Line Interface เพื่อแสดงรายการจองที่มีให้ซื้อ แล้วซื้อการเหมาจ่ายอินสแตนซ์ DB

เมื่อคุณซื้อแบบเหมาจ่าย การใช้อินสแตนซ์ DB แบบเหมาจ่ายจะไม่ต่างจากอินสแตนซ์ DB แบบตามความต้องการ เปิดใช้อินสแตนซ์ DB โดยใช้คลาส กลไก และรีเจี้ยนอินสแตนซ์เดียวกันกับที่คุณเหมาจ่าย ตราบใดที่การเหมาจ่ายของคุณทำงานอยู่ Amazon RDS จะใช้อัตรารายชั่วโมงที่มีราคาต่ำลงซึ่งคุณมีสิทธิ์ใช้งานกับอินสแตนซ์ DB ใหม่

อินสแตนซ์แบบเหมาจ่าย Amazon RDS จะเปิดให้ซื้อใช้กับภูมิภาคเสียมากกว่าซื้อใช้กับ Availability Zone แห่งใดแห่งหนึ่ง และเนื่องจาก RI ไม่ได้ถูกกำหนดว่าต้องใช้เฉพาะกับ Availability Zone ใด จึงไม่จัดเป็นการเหมาจ่ายความจุ ซึ่งหมายความว่า แม้ว่าความจุใน Availability Zone แห่งหนึ่งจะถูกจำกัด แต่จะยังคงซื้อแบบเหมาจ่ายภายในภูมิภาคดังกล่าวได้ และจะได้รับส่วนลดสำหรับการใช้งานที่ตรงตามเงื่อนไขซึ่งอยู่ใน Availability Zone ใดก็ตามในภูมิภาคนั้นๆ

คุณสามารถซื้ออินสแตนซ์ DB แบบเหมาจ่ายได้สูงสุด 40 อินสแตนซ์ หากคุณต้องการเรียกใช้อินสแตนซ์ DB มากกว่า 40 อินสแตนซ์ โปรดกรอกแบบฟอร์มคำขออินสแตนซ์ DB ของ Amazon RDS

เพียงซื้ออินสแตนซ์ DB แบบเหมาจ่ายด้วยคลาสอินสแตนซ์ DB, กลไก DB, ตัวเลือกแบบ Multi-AZ และโมเดลสิทธิ์การใช้งานเดียวกันภายในรีเจี้ยนเดียวกับอินสแตนซ์ DB ที่คุณเรียกใช้อยู่และต้องการเหมาจ่าย หากซื้อแบบเหมาจ่ายได้สำเร็จ Amazon RDS จะคิดค่าใช้จ่ายรายชั่วโมงแบบใหม่กับอินสแตนซ์ DB ที่คุณมีอยู่โดยอัตโนมัติ

หากได้รับคำขอของคุณระหว่างที่กำลังดำเนินการอนุญาตชำระเงิน การเปลี่ยนแปลงราคาที่เกี่ยวข้องกับอินสแตนซ์แบบเหมาจ่ายจะมีผลใช้งานทันที คุณสามารถติดตามสถานะของการเหมาจ่ายได้ในหน้ากิจกรรมบัญชี AWS โดยใช้ DescribeReservedDBInstances API หรือคำสั่ง describe-reserved-db-instances หากการชำระเงินแบบครั้งเดียวไม่ได้รับการอนุมัติภายในระยะเวลาการเรียกเก็บเงินถัดไป ราคาที่ลดแล้วจะไม่มีผล

เมื่อระยะเวลาการเหมาจ่ายของคุณหมดอายุ อินสแตนซ์แบบเหมาจ่ายของคุณจะเปลี่ยนกลับเป็นอัตราการใช้งานรายชั่วโมงตามความต้องการที่เหมาะสำหรับคลาสและภูมิภาคอินสแตนซ์ DB ของคุณ

การดำเนินการของ Amazon RDS สำหรับการสร้าง การแก้ไข และการลบอินสแตนซ์ DB ไม่ได้แยกระหว่างอินสแตนซ์แบบตามความต้องการและอินสแตนซ์แบบเหมาจ่าย เมื่อคำนวณการเรียกเก็บเงิน ระบบของเราจะใช้เหมาจ่ายของคุณโดยอัตโนมัติเพื่อให้มีการเรียกเก็บเงินตามอัตราอินสแตนซ์ DB แบบเหมาจ่ายรายชั่วโมงที่ต่ำกว่ากับทุกอินสแตนซ์ DB ที่เข้าเกณฑ์

การเหมาจ่ายแต่ละรายการจะเกี่ยวข้องกับชุดคุณลักษณะต่อไปนี้ ได้แก่ กลไก DB, คลาสอินสแตนซ์ DB, ตัวเลือกการติดตั้งใช้งานแบบ Multi-AZ, โมเดลสิทธิ์การใช้งาน และรีเจี้ยน

การเหมาจ่ายกลไก DB และโมเดลสิทธิ์การใช้งานที่เข้าเกณฑ์สำหรับความยืดหยุ่นของขนาด (MySQL, MariaDB, PostgreSQL, Amazon Aurora หรือ Oracle “Bring Your Own License”) จะใช้กับอินสแตนซ์ DB ที่ใช้งานอยู่ทุกขนาดภายในกลุ่มประเภทอินสแตนซ์เดียวกันโดยอัตโนมัติ (เช่น M4, T2 หรือ R3) สำหรับกลไกฐานข้อมูลและรีเจี้ยนเดียวกัน นอกจากนี้การเหมาจ่ายยังสามารถใช้กับอินสแตนซ์ DB ที่ใช้งานได้ทั้งแบบ AZ เดียวหรือหลาย AZ

ตัวอย่างเช่น สมมติว่าคุณซื้อการเหมาจ่าย db.m4.2xlarge MySQL หากคุณเลือกที่จะปรับขนาดอินสแตนซ์ DB ที่ใช้งานอยู่ให้เป็น db.m4.4xlarge อัตราการลดของ RI นี้จะครอบคลุม 1/2 ของการใช้งานอินสแตนซ์ DB ที่มีขนาดใหญ่กว่า

หากคุณใช้กลไก DB หรือรูปแบบใบอนุญาตที่ไม่เข้าเกณฑ์สำหรับขนาดที่ยืดหยุ่น (Microsoft SQL Server หรือ Oracle "License Included") การเหมาจ่ายแต่ละครั้งสามารถใช้ได้เฉพาะกับอินสแตนซ์ DB ที่มีคุณลักษณะเดียวกันในช่วงระยะเวลาของสัญญา หากคุณเลือกที่จะปรับเปลี่ยนคุณลักษณะใดๆ ของอินสแตนซ์ DB ที่ใช้งานของคุณก่อนสิ้นสุดสัญญาการเหมาจ่าย อัตราการใช้งานรายชั่วโมงของอินสแตนซ์ DB นั้นจะกลับมาเป็นอัตรารายชั่วโมงตามความต้องการ

หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับความยืดหยุ่นทางขนาด โปรดดูคู่มือผู้ใช้ Amazon RDS

อินสแตนซ์แบบเหมาจ่ายแต่ละอินสแตนซ์จะเชื่อมโยงกับภูมิภาคเฉพาะ ซึ่งจะไม่มีการเปลี่ยนแปลงตลอดอายุการเหมาจ่ายและไม่สามารถแก้ไขได้ อย่างไรก็ตาม การเหมาจ่ายแต่ละครั้งจะต้องใช้ใน AZ ที่ใช้ได้ภายในภูมิภาคที่เกี่ยวข้อง

ใช่ เมื่อคุณซื้ออินสแตนซ์แบบเหมาจ่าย คุณสามารถเลือกตัวเลือกแบบหลาย AZ ในการกำหนดค่าอินสแตนซ์ของ DB ที่วางจำหน่ายได้ นอกจากนี้ หากคุณกำลังใช้กลไก DB และโมเดลสิทธิ์การใช้งานที่รองรับความยืดหยุ่นในการใช้ขนาดของอินสแตนซ์แบบเหมาจ่าย อินสแตนซ์ Multi-AZ แบบเหมาจ่ายจะครอบคลุมการใช้งานอินสแตนซ์ DB แบบ AZ เดียวสองรายการ

การเหมาจ่ายอินสแตนซ์ DB สามารถใช้กับแบบจำลองการอ่านได้โดยที่คลาสอินสแตนซ์ DB และรีเจี้ยนต้องคงเดิม เมื่อระบบของเราประมวลใบเรียกเก็บเงินของคุณ ระบบจะใช้การเหมาจ่ายของคุณโดยอัตโนมัติ ดังนั้นอินสแตนซ์ DB ที่เข้าเกณฑ์จะถูกเรียกเก็บเงินด้วยอัตราเหมาจ่ายที่ต่ำกว่ารายชั่วโมง

ไม่ได้ คุณไม่สามารถยกเลิกอินสแตนซ์ DB แบบเหมาจ่าย และการจ่ายในครั้งเดียว (ถ้ามี) จะไม่สามารถรับเงินคืนได้ คุณจะต้องชำระเงินต่อไปในทุกๆ ชั่วโมงตลอดระยะเวลาการใช้งานอินสแตนซ์ DB แบบเหมาจ่ายโดยไม่คำนึงถึงการใช้งาน

เมื่อคุณซื้อ RI ภายใต้ตัวเลือกการชำระล่วงหน้าเต็มจำนวน คุณจะต้องจ่ายเงินตลอดระยะเวลาการใช้งาน RI ในการชำระล่วงหน้าครั้งเดียว คุณสามารถเลือกที่จะไม่จ่ายเงินล่วงหน้าโดยเลือกตัวเลือกไม่ต้องชำระล่วงหน้า มูลค่าทั้งหมดของ RI ที่ไม่ต้องจ่ายล่วงหน้าจะกระจายไปทั่วทุกๆ ชั่วโมงในระยะสัญญา และคุณจะถูกเรียกเก็บเงินในระยะสัญญาทุกๆ ชั่วโมงโดยไม่คำนึงถึงการใช้งาน ตัวเลือกชำระล่วงหน้าบางส่วนคือการผสมกันระหว่างตัวเลือกการชำระล่วงหน้าทั้งหมดและการไม่ต้องชำระล่วงหน้า คุณชำระเงินล่วงหน้าด้วยจำนวนเงินเพียงเล็กน้อย และคุณถูกเรียกเก็บเงินรายชั่วโมงแบบต่ำในทุกๆ ชั่วโมงโดยไม่คำนึงถึงการใช้

เพื่อที่จะเลือกระดับอินสแตนซ์ DB และความจุของพื้นที่จัดเก็บเริ่มต้นคุณจะต้องการประเมินความต้องการด้านการประมวลผล หน่วยความจำ และพื้นที่จัดเก็บของแอปพลิเคชันของคุณ หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับคลาสอินสแตนซ์ DB ที่มีให้ใช้งาน โปรดดูที่คู่มือผู้ใช้ Amazon RDS

คุณสามารถปรับขนาดทรัพยากรการประมวลผลและ ความจุของพื้นที่จัดเก็บ ที่จัดสรรให้กับอินสแตนซ์ DB ของคุณด้วยคอนโซลการจัดการของ AWS (เลือกอินสแตนซ์ DB ที่ต้องการแล้วคลิกปุ่มแก้ไข) Amazon RDS API หรือ AWS Command Line Interface ทรัพยากรหน่วยความจำและ CPU จะแก้ไขโดยการเปลี่ยนแปลงคลาสอินสแตนซ์ DB ของคุณ และพื้นที่จัดเก็บที่พร้อมใช้งานจะเปลี่ยนแปลงเมื่อคุณแก้ไขการจัดสรรพื้นที่จัดเก็บของคุณ 

โปรดทราบว่าเมื่อคุณปรับเปลี่ยนคลาสอินสแตนซ์ DB หรือพื้นที่จัดเก็บที่จัดสรร การเปลี่ยนแปลงที่คุณขอจะใช้ในระหว่างหน้าต่างการบำรุงรักษาที่คุณระบุ หรือคุณสามารถใช้ค่าสถานะ "ใช้ทันที" เพื่อใช้คำขอปรับขนาดของคุณทันที พึงระลึกเสมอว่าการเปลี่ยนแปลงระบบที่รอดำเนินการอื่นๆ จะถูกนำไปใช้ด้วยเช่นกัน

อินสแตนซ์ RDS for SQL Server ที่เก่ากว่าอาจไม่เข้าเกณฑ์สำหรับพื้นที่จัดเก็บที่มีการปรับขนาด ดูข้อมูลเพิ่มเติมใน คำถามที่พบบ่อยของ RDS for SQL Server

Amazon RDS ใช้โวลุ่ม EBS เป็นพื้นที่จัดเก็บฐานข้อมูลและบันทึกการใช้งาน Amazon RDS จะตัดข้อมูลทั่วทั้งโวลุ่ม EBS หลายโวลุ่มเพื่อเพิ่มประสิทธิภาพของ IOPS โดยขึ้นอยู่กับขนาดพื้นที่จัดเก็บที่ต้องการ สำหรับ MySQL และ Oracle สำหรับอินสแตนซ์ DB ที่มีอยู่ คุณอาจสังเกตเห็นการปรับปรุงความจุ I/O บางอย่างหากคุณเพิ่มทรัพยากรพื้นที่จัดเก็บข้อมูลของคุณ คุณสามารถปรับขนาดความจุพื้นที่จัดเก็บที่จัดสรรให้กับอินสแตนซ์ DB ของคุณได้ โดยใช้คอนโซลการจัดการของ AWS ModifyDBInstance API หรือคำสั่ง modify-db-instance

หากต้องการดูข้อมูลเพิ่มเติม ให้ไปที่ พื้นที่จัดเก็บสำหรับ Amazon RDS

ความจุที่จัดสรรให้กับอินสแตนซ์ DB ของคุณสามารถเพิ่มขึ้นได้ในขณะที่รักษาความพร้อมใช้งานของอินสแตนซ์ DB อย่างไรก็ตาม เมื่อคุณตัดสินใจที่จะ ปรับขนาดทรัพยากรการประมวลผลที่พร้อมใช้งานสำหรับอินสแตนซ์ DB ของคุณขึ้นหรือลง ฐานข้อมูลของคุณจะใช้งานไม่ได้ชั่วคราวในขณะที่คลาสอินสแตนซ์ DB ได้รับการแก้ไข ช่วงเวลาที่ไม่มีให้บริการนี้มักใช้เวลาเพียงไม่กี่นาทีและจะเกิดขึ้นในระหว่างหน้าต่างการบำรุงรักษาสำหรับอินสแตนซ์ DB ของคุณ เว้นแต่คุณจะระบุว่าควรใช้การปรับเปลี่ยนทันที

Amazon RDS รองรับคลาสอินสแตนซ์ DB และการจัดสรรพื้นที่จัดเก็บที่หลากหลายเพื่อให้ตรงตามความต้องการของแอปพลิเคชันที่แตกต่างกัน หากแอปพลิเคชันของคุณต้องการทรัพยากรการคำนวณมากกว่าคลาสอินสแตนซ์ DB ที่ใหญ่ที่สุดหรือพื้นที่จัดเก็บมากกว่าการจัดสรรสูงสุด คุณสามารถใช้การแบ่งพาร์ติชันเพื่อกระจายข้อมูลของคุณไปยังอินสแตนซ์ DB หลายอินสแตนซ์

พื้นที่จัดเก็บฐานข้อมูลสำหรับการใช้ทั่วไป (SSD) Amazon RDS เหมาะสำหรับเวิร์กโหลดหลากหลายรูปแบบที่มีความจำเป็นต้องใช้ I/O ในระดับปานกลาง ด้วยค่าเริ่มต้นจำนวน 3 IOPS/GB และความสามารถในการเพิ่มขึ้นถึง 3,000 IOPS ตัวเลือกพื้นที่จัดเก็บข้อมูลนี้จะให้ประสิทธิภาพการทำงานที่คาดการณ์ได้เพื่อตอบสนองความต้องการของแอปพลิเคชันส่วนใหญ่

พื้นที่จัดเก็บข้อมูล IOPS ที่จัดสรรไว้ Amazon RDS (SSD) เป็นตัวเลือกการจัดเก็บข้อมูลที่รองรับด้วย SSD ที่ออกแบบมาเพื่อมอบประสิทธิภาพการทำงาน I/O ที่รวดเร็ว คาดการณ์ได้ และต่อเนื่อง ด้วยพื้นที่จัดเก็บข้อมูล IOPS ที่จัดสรรไว้ Amazon RDS (SSD) คุณสามารถระบุอัตรา IOPS เมื่อสร้างอินสแตนซ์ DB และการจัดเตรียม Amazon RDS ที่ระบุอัตรา IOPS สำหรับอายุการใช้งานของอินสแตนซ์ DB พื้นที่จัดเก็บข้อมูล IOPS ที่จัดสรรไว้ Amazon RDS (SSD) ได้รับการปรับปรุงเพื่อเวิร์กโหลดของฐานข้อมูล I/O ปริมาณธุรกรรม (OLTP) ที่มีปริมาณมาก หากต้องการดูข้อมูลเพิ่มเติม โปรดดู คู่มือผู้ใช้ Amazon RDS

พื้นที่จัดเก็บแบบแม่เหล็ก Amazon RDS มีประโยชน์สำหรับเวิร์กโหลดฐานข้อมูลขนาดเล็กที่เข้าถึงไม่บ่อยครั้ง ไม่แนะนำให้ใช้พื้นที่จัดเก็บแบบแม่เหล็กในอินสแตนซ์ฐานข้อมูลการผลิต

เลือกพื้นที่จัดเก็บที่เหมาะกับปริมาณงานของคุณ

• เวิร์กโหลด OLTP ที่มีประสิทธิภาพสูง: พื้นที่จัดเก็บ IOPS ที่จัดสรรไว้ของ Amazon RDS (SSD)
• ปริมาณงานฐานข้อมูลที่มีความต้องการใช้ I/O ในระดับปานกลาง: พื้นที่จัดเก็บฐานข้อมูลสำหรับการใช้ทั่วไป Amazon RDS (SSD)

IOPS ที่ Amazon RDS รองรับจะแตกต่างกันไปตามกลไกฐานข้อมูล หากต้องการดูข้อมูลเพิ่มเติม โปรดดูคู่มือผู้ใช้ Amazon RDS

Amazon RDS มีสองวิธีที่แตกต่างกันสำหรับการสำรองข้อมูลและการกู้คืนอินสแตนซ์ DB การสำรองข้อมูลอัตโนมัติ และ Database Snapshot ของคุณ

คุณสมบัติการสำรองข้อมูลโดยอัตโนมัติของ Amazon RDS ช่วยให้สามารถทำ การกู้คืนอินสแตนซ์ DB ของคุณที่จุดเวลาเฉพาะได้ เมื่อเปิดใช้งานการสำรองข้อมูลอัตโนมัติสำหรับอินสแตนซ์ DB ของคุณ Amazon RDS จะทำการบันทึกข้อมูลทั้งหมดของคุณโดยอัตโนมัติในแต่ละวัน (ในช่วงหน้าต่างสำรองที่คุณต้องการ) และเก็บข้อมูลบันทึกการทำธุรกรรม (เมื่อมีการอัปเดตอินสแตนซ์ DB) เมื่อคุณเริ่มต้นการกู้คืนในเวลาเดียว บันทึกการทำธุรกรรมจะถูกนำไปใช้กับข้อมูลสำรองรายวันที่เหมาะสมที่สุดเพื่อกู้คืนค่าอินสแตนซ์ DB ของคุณตามเวลาที่คุณขอ 

Amazon RDS เก็บข้อมูลสำรองของอินสแตนซ์ DB ในระยะเวลาที่จำกัด และระยะเวลาที่ผู้ใช้ระบุไว้ซึ่งเรียกว่าระยะเวลาการเก็บรักษา โดยค่าเริ่มต้นคือ 7 วัน แต่สามารถตั้งค่าได้สูงสุดถึง 35 วัน คุณสามารถเริ่มต้นการกู้คืนในเวลาเดียวและระบุช่วงเวลาใดๆ ในระยะเวลาเก็บรักษาจนถึงเวลาที่สามารถเรียกคืนล่าสุดได้ คุณสามารถใช้ DescribeDBInstances API เพื่อคืนเวลาที่สามารถกู้คืนล่าสุดของอินสแตนซ์ DB ของคุณได้ ซึ่งโดยปกติแล้วจะใช้เวลาไม่เกินห้านาที 

หรือคุณสามารถค้นหาเวลาที่สามารถกู้คืนล่าสุดสำหรับอินสแตนซ์ DB โดยเลือกในคอนโซลการจัดการของ AWS แล้วดูในแท็บ "คำอธิบาย" ในแผงด้านล่างของคอนโซล

Database Snapshot เป็นข้อมูลที่ผู้ใช้เริ่มต้นและช่วยให้คุณสามารถสำรองข้อมูลอินสแตนซ์ DB ของคุณในสถานะที่รู้จักได้บ่อยเท่าที่ต้องการ จากนั้นให้กู้คืนสถานะเฉพาะดังกล่าวได้ตลอดเวลา Database Snapshot สามารถสร้างได้ด้วยคอนโซลการจัดการของ AWS CreateDBSnapshot API หรือคำสั่ง create-db-snapshot และจะถูกเก็บไว้จนกว่าคุณจะตั้งใจลบออก

สแนปช็อตที่ Amazon RDS ดำเนินการเพื่อเปิดใช้งานการสำรองข้อมูลอัตโนมัติจะให้คุณใช้สำหรับคัดลอก (โดยใช้คอนโซล AWS หรือ คำสั่ง copy-db-snapshot) หรือสำหรับฟังก์ชันการกู้คืนสแนปช็อตได้ คุณสามารถระบุได้โดยใช้ประเภท Snapshot "อัตโนมัติ" นอกจากนี้คุณสามารถระบุเวลาที่มีการถ่าย Snapshot ด้วยการดูฟิลด์ "เวลาที่สร้างโดย Snapshot" 

ตัวระบุของภาพรวม "อัตโนมัติ" ยังประกอบด้วยเวลา (ใน UTC) ที่ถ่าย Snapshot

โปรดทราบว่าเมื่อคุณทำการกู้คืนไปยังจุดหนึ่งในเวลาหรือจาก Database Snapshot หนึ่ง ระบบจะสร้างอินสแตนซ์ DB ใหม่ขึ้นโดยใช้ตำแหน่งข้อมูลใหม่ (อินสแตนซ์ DB เก่าสามารถลบได้หากต้องการ) การดำเนินการนี้จะช่วยให้คุณสามารถสร้างอินสแตนซ์ DB ได้หลายแบบจาก Database Snapshot เฉพาะหรือในเวลาเดียว

โดยค่าเริ่มต้น Amazon RDS จะเปิดใช้การสำรองข้อมูลอินสแตนซ์ DB ของคุณแบบอัตโนมัติ โดยมีระยะเวลาเก็บรักษา 7 วัน หากคุณต้องการแก้ไขระยะเวลาการเก็บข้อมูลสำรองของคุณ คุณสามารถทำได้โดยใช้ RDS Console หรือ CreateDBInstance API (เมื่อสร้างอินสแตนซ์ DB ใหม่) หรือ ModifyDBInstance API (สำหรับอินสแตนซ์ที่มีอยู่) คุณสามารถใช้วิธีการเหล่านี้เพื่อ เปลี่ยนพารามิเตอร์ RetentionPeriod ให้เป็นตัวเลขใดก็ได้ตั้งแต่ 0 (ซึ่งจะปิดใช้งานการสำรองข้อมูลอัตโนมัติ) ให้เป็นจำนวนวันที่ต้องการสูงสุด 35 วัน โดยจะไม่สามารถตั้งค่าเป็น 0 ได้ หากอินสแตนซ์ DB เป็นต้นทางของแบบจำลองการอ่าน สำหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อมูลสำรองอัตโนมัติ โปรดดู คู่มือผู้ใช้ Amazon RDS

ระยะเวลาสำรองข้อมูลที่ต้องการคือช่วงเวลาที่กำหนดโดยผู้ใช้ในระหว่างที่มีการกู้คืนอินสแตนซ์ DB ของคุณ Amazon RDS ใช้การสำรองข้อมูลเป็นระยะๆ ร่วมกับบันทึกการทำธุรกรรมของคุณเพื่อให้คุณสามารถกู้คืนอินสแตนซ์ DB ของคุณได้ทุกเมื่อภายในระยะเวลาการเก็บรักษาของคุณ ซึ่งทำได้จนถึงเวลาที่สามารถเรียกคืนล่าสุด (โดยปกติจะได้จนถึงเวลาไม่กี่นาทีที่ผ่านมาล่าสุด) ในช่วงระยะเวลาสำรองข้อมูล พื้นที่จัดเก็บ I/O อาจถูกระงับเป็นเวลาสั้นๆ ในขณะที่กระบวนการสำรองข้อมูลเริ่มต้นขึ้น (โดยปกติจะใช้เวลาไม่กี่วินาที) และอาจมีช่วงเวลาแฝงเพิ่มขึ้นเล็กน้อย ไม่มีการหยุดชะงัก I/O สำหรับการใช้งาน DB หลาย AZ เนื่องจากข้อมูลสำรองนั้นมาจากโหมดสแตนด์บาย

สแนปช็อต Amazon RDS DB และการสำรองข้อมูลอัตโนมัติจะจัดเก็บไว้ใน S3

คุณสามารถใช้คอนโซลการจัดการของ AWS ModifyDBInstance API หรือคำสั่ง modify-db-instance เพื่อจัดการระยะเวลาที่ข้อมูลสำรองอัตโนมัติของคุณจะถูก Retain ไว้โดยการแก้ไขพารามิเตอร์ RetentionPeriod หากคุณต้องการปิดข้อมูลสำรองอัตโนมัติทั้งหมด คุณสามารถทำได้โดยกำหนดระยะเวลาการเก็บข้อมูลเป็น 0 (ไม่แนะนำ) คุณสามารถจัดการ Database Snapshot ที่ผู้ใช้สร้างขึ้นผ่านส่วน "Snapshot" ของ Amazon RDS Console หรือคุณสามารถดูรายการสแนปช็อต DB ที่ผู้ใช้สร้างขึ้นสำหรับอินสแตนซ์ DB ที่กำหนดโดยใช้ DescribeDBSnapshots API หรือคำสั่ง db-snapshots แล้วลบสแนปช็อตด้วย DeleteDBSnapshot API หรือคำสั่ง delete-db-snapshot command

การมี Database Snapshot อัตโนมัติมากกว่าจำนวนวันในระยะเวลาเก็บรักษา 1 หรือ 2 ภาพเป็นเรื่องปกติ จะมีการเก็บ Snapshot อัตโนมัติไว้หนึ่งภาพเพื่อให้แน่ใจว่าสามารถทำจุดคืนเวลาได้ตลอดเวลาในช่วงเวลาเก็บรักษา

ตัวอย่างเช่น หากกำหนดกรอบเวลาการสำรองข้อมูลเป็น 1 วัน คุณจะต้องใช้ 2 Snapshot อัตโนมัติเพื่อรองรับการเรียกคืนข้อมูลภายใน 24 ชั่วโมงก่อนหน้า นอกจากนี้คุณยังอาจเห็น Snapshot อัตโนมัติเพิ่มเติมนื่องจาก Snapshot อัตโนมัติใหม่ถูกสร้างขึ้นก่อนที่ Snapshot อัตโนมัติที่เก่าที่สุดจะถูกลบออก

เมื่อคุณลบอินสแตนซ์ DB คุณสามารถสร้าง Database Snapshot สุดท้ายเมื่อลบ หากคุณทำเช่นนี้ คุณสามารถใช้ Snapshot DB นี้เพื่อคืนค่าอินสแตนซ์ DB ที่ถูกลบในภายหลัง Amazon RDS เก็บข้อมูล Database Snapshot ที่ผู้ใช้สร้างขึ้นมานี้ไว้พร้อมกับ Database Snapshot อื่นๆ ที่สร้างขึ้นเองหลังจากที่ลบอินสแตนซ์ DB แล้ว โปรดดูที่ หน้าราคา เพื่อดูรายละเอียดของค่าใช้จ่ายของพื้นที่จัดเก็บข้อมูลสำรอง

ข้อมูลสำรองอัตโนมัติจะถูกลบออกเมื่อมีการลบอินสแตนซ์ DB จะมีเพียง Database Snapshot ที่สร้างด้วยตนเองเท่านั้นที่ถูกเก็บไว้หลังจากที่ลบอินสแตนซ์ DB แล้ว

Amazon VPC ช่วยให้คุณสามารถสร้างสภาพแวดล้อมของระบบเครือข่ายเสมือนในส่วนแบบส่วนตัวที่แยกกันของ AWS Cloud ได้ ซึ่งคุณสามารถใช้การควบคุมด้านต่าง ๆ เช่น ช่วงที่อยู่ IP ส่วนตัว ซับเน็ต ตารางเส้นทาง และเกตเวย์เครือข่าย Amazon VPC ช่วยให้คุณสามารถกำหนดโครงสร้างเครือข่ายเสมือนและปรับแต่งการกำหนดค่าเครือข่ายให้คล้ายกับเครือข่าย IP แบบเดิมที่คุณอาจใช้งานได้ในศูนย์ข้อมูลของคุณเอง

วิธีหนึ่งที่คุณสามารถใช้ประโยชน์จาก VPC ได้คือเมื่อคุณต้องการเรียกใช้เว็บแอปพลิเคชันแบบสาธารณะในขณะที่ยังคงรักษาเซิร์ฟเวอร์แบ็กเอนด์ที่ไม่สามารถเข้าถึงได้แบบสาธารณะในซับเน็ตส่วนตัว คุณสามารถสร้างซับเน็ตแบบสาธารณะสำหรับเว็บเซิร์ฟเวอร์ของคุณที่มีการเข้าถึงอินเทอร์เน็ต และวางอินสแตนซ์ Amazon RDS DB แบบแบ็กเอนด์ของคุณในซับเน็ตแบบส่วนตัวโดยไม่มีการเข้าถึงอินเทอร์เน็ต สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ Amazon VPC โปรดดู คู่มือผู้ใช้ Amazon Virtual Private Cloud

หากบัญชี AWS ของคุณถูกสร้างขึ้นก่อน 2013-12-04 คุณอาจใช้ Amazon RDS ในสภาพแวดล้อม Amazon Elastic Compute Cloud (EC2) Classic ได้ ฟังก์ชันการทำงานพื้นฐานของ Amazon RDS นั้นเหมือนกัน ไม่ว่าจะใช้ EC2-Classic หรือ EC2-VPC Amazon RDS จะจัดการกับการสำรองข้อมูล การแพตช์ซอฟต์แวร์ การตรวจหาความผิดพลาดโดยอัตโนมัติ แบบจำลองการอ่าน และการกู้คืน ไม่ว่าจะปรับใช้อินสแตนซ์ DB ของคุณภายในหรือภายนอก VPC สำหรับข้อมูลเพิ่มเติมเกี่ยวกับความแตกต่างระหว่าง EC2-Classic และ EC2-VPC โปรดดู เอกสารประกอบ EC2

กลุ่มซับเน็ต DB คือชุดซับเน็ตที่คุณอาจต้องการกำหนดให้กับอินสแตนซ์ Amazon RDS DB ของคุณใน VPC กลุ่มซับเน็ต DB แต่ละกลุ่มควรมีซับเน็ตอย่างน้อยหนึ่งรายการสำหรับทุกๆ Availability Zone ในรีเจี้ยนที่กำหนด เมื่อสร้างอินสแตนซ์ DB ใน VPC คุณจะต้องเลือกกลุ่มเครือข่ายย่อย DB Amazon RDS ใช้กลุ่มเครือข่ายย่อย DB และ Availability Zone ที่คุณต้องการเพื่อเลือกกลุ่มเครือข่ายย่อยและที่อยู่ IP ภายในกลุ่มเครือข่ายย่อยนั้น Amazon RDS สร้างและเชื่อมโยงเครือข่ายแบบยืดหยุ่นเข้ากับอินสแตนซ์ DB ของคุณโดยใช้ที่อยู่ IP ดังกล่าว

โปรดทราบว่าเราขอแนะนำอย่างยิ่งให้คุณใช้ ชื่อ DNS เพื่อเชื่อมต่อกับอินสแตนซ์ DB ของคุณ เนื่องจากที่อยู่ IP พื้นฐานสามารถเปลี่ยนแปลงได้ (เช่น ระหว่างการใช้ระบบสำรองเพื่อกู้คืนข้อมูล)

สำหรับการใช้งานอินสแตนซ์แบบ Multi-AZ การกำหนดซับเน็ตสำหรับ Availability Zone ทั้งหมดในรีเจี้ยนจะช่วยให้ Amazon RDS สามารถสร้างสแตนด์บายใหม่ใน Availability Zone อื่นได้หากมีความจำเป็นเกิดขึ้น คุณต้องทำเช่นนี้แม้แต่กับการปรับใช้ AZ เดียว เพื่อเผื่อสำหรับกรณีที่คุณต้องการแปลงให้เป็นแบบหลาย AZ

หากต้องการทราบขั้นตอนที่นำคุณมาสู่กระบวนการนี้ โปรดดู การสร้างอินสแตนซ์ DB ใน VPC ในคู่มือผู้ใช้ Amazon RDS

ไปที่ส่วน กลุ่มมาตรการรักษาความปลอดภัย ของคู่มือผู้ใช้ Amazon RDS เพื่อเรียนรู้เกี่ยวกับวิธีต่าง ๆ ในการควบคุมการเข้าถึงอินสแตนซ์ DB ของคุณ

อินสแตนซ์ DB ที่ปรับใช้ภายใน VPC สามารถเข้าถึงได้โดย EC2 instance ที่ใช้งานใน VPC เดียวกัน หากอินสแตนซ์ EC2 เหล่านี้ถูกใช้งานในเครือข่ายย่อยสาธารณะที่มี Elastic IP ที่เกี่ยวข้อง คุณสามารถเข้าถึงอินสแตนซ์ EC2 ผ่านทางอินเทอร์เน็ตได้ อินสแตนซ์ DB ที่ปรับใช้ภายใน VPC สามารถเข้าถึงได้จากอินเทอร์เน็ตหรือจากอินสแตนซ์ EC2 ภายนอก VPC ผ่าน VPN หรือโฮสต์ Bastion ที่คุณสามารถเปิดใช้ในซับเน็ตสาธารณะของคุณหรือใช้ตัวเลือกที่เข้าถึงได้แบบสาธารณะของ Amazon RDS:

• หากต้องการใช้โฮสต์ Bastion คุณจะต้องตั้งค่าซับเน็ตสาธารณะที่มีอินสแตนซ์ EC2 ที่ทำหน้าที่เป็น SSH Bastion ซับเน็ตสาธารณะนี้ต้องมีอินเทอร์เน็ตเกตเวย์และกฎการกำหนดเส้นทางที่อนุญาตให้มีการรับส่งข้อมูลผ่านโฮสต์ SSH ซึ่งจะต้องส่งต่อคำขอไปยังที่อยู่ IP ส่วนตัวของอินสแตนซ์ Amazon RDS DB ของคุณ
• หากต้องการใช้การเชื่อมต่อแบบสาธารณะ เพียงสร้างอินสแตนซ์ DB ของคุณโดยตั้งค่าตัวเลือก Publicly Accessible เป็น “ใช่” เมื่อเปิด Publicly Accessible แล้ว ระบบจะสามารถเข้าถึงอินสแตนซ์ DB ใน VPC ได้อย่างสมบูรณ์ภายนอก VPC ตามค่าเริ่มต้น ซึ่งหมายความว่าคุณไม่จำเป็นต้องกำหนดค่า VPN หรือโฮสต์ Bฺastion เพื่อให้สามารถเข้าถึงอินสแตนซ์ของคุณได้

คุณยังสามารถตั้งค่าเกตเวย์ VPN ที่จะขยายเครือข่ายองค์กรของคุณไปยัง VPC ของคุณ และอนุญาตให้เข้าถึงอินสแตนซ์ Amazon RDS DB ใน VPC นั้นได้ โปรดดู คู่มือผู้ใช้ Amazon VPC สำหรับรายละเอียดเพิ่มเติม

เราขอแนะนำให้คุณใช้ชื่อ DNS เพื่อเชื่อมต่อกับอินสแตนซ์ DB ของคุณเป็นอย่างยิ่ง เนื่องจากที่อยู่ IP พื้นฐานสามารถเปลี่ยนแปลงได้ (เช่น ระหว่างเกิดข้อผิดพลาด)

หากอินสแตนซ์ DB ของคุณไม่อยู่ใน VPC คุณสามารถใช้คอนโซลการจัดการของ AWS เพื่อย้ายอินสแตนซ์ DB ของคุณไปยัง VPC ได้อย่างง่ายดาย โปรดดูรายละเอียดเพิ่มเติมใน คู่มือผู้ใช้ Amazon RDS นอกจากนี้คุณยังสามารถถ่ายภาพอินสแตนซ์ DB ของคุณภายนอก VPC และกู้คืนไปยัง VPC โดยระบุกลุ่มเครือข่ายย่อย DB ที่คุณต้องการใช้ หรือคุณสามารถดำเนินการ "กู้คืนไปยังจุดก่อนหน้า" เช่นกัน

ไม่รับรอง การย้ายอินสแตนซ์ DB จากภายในสู่ภายนอก VPC ด้วยเหตุผลด้านความปลอดภัย ไม่สามารถกู้คืน DB Snapshot ของอินสแตนซ์ DB ภายใน VPC ไปยัง VPC ภายนอกได้ เช่นเดียวกับฟังก์ชัน "กู้คืนในเวลาเดียว" 

คุณมีหน้าที่รับผิดชอบในการแก้ไขตารางเส้นทางและ ACL ของระบบเครือข่ายใน VPC ของคุณเพื่อให้แน่ใจว่าอินสแตนซ์ DB ของคุณสามารถเข้าถึงได้จากอินสแตนซ์ไคลเอ็นต์ของคุณใน VPC หลังจากการการใช้ระบบสำรองเพื่อกู้คืนข้อมูล ไคลเอนต์ของคุณเปลี่ยนระบบอินสแตนซ์ EC2 และอินสแตนซ์ Amazon RDS DB อาจอยู่ใน Availability Zone ที่แตกต่างกันสำหรับการใช้งานอินสแตนซ์แบบ Multi-AZ คุณควร กำหนดค่า ACL ของระบบเครือข่าย เพื่อให้แน่ใจว่าจะสามารถสื่อสารข้าม AZ ได้

คุณสามารถอัปเดตกลุ่มซับเน็ต DB ที่มีอยู่เพื่อเพิ่มเครือข่ายย่อยได้มากขึ้นสำหรับ Available Zone ที่มีอยู่หรือสำหรับ Availability Zone ใหม่ที่เพิ่มเข้ามาตั้งแต่สร้างอินสแตนซ์ DB การลบซับเน็ตจากกลุ่มซับเน็ต DB ที่มีอยู่ อาจทำให้ไม่สามารถใช้อินสแตนซ์ได้ถ้ากำลังใช้งานอยู่ใน AZ เฉพาะที่ถูกลบออกจากกลุ่มซับเน็ต คุณสามารถดูข้อมูลเพิ่มเติมได้ใน คู่มือผู้ใช้ Amazon RDS

หากต้องการเริ่มใช้ Amazon RDS คุณจะต้องมีบัญชีนักพัฒนา AWS หากคุณยังไม่มีบัญชีก่อนลงชื่อสมัครใช้ Amazon RDS คุณจะได้รับการแจ้งเตือนให้สร้างบัญชีดังกล่าวเมื่อคุณเริ่มขั้นตอนการลงชื่อสมัครใช้ บัญชีผู้ใช้หลักแตกต่างจากบัญชีนักพัฒนา AWS และใช้เฉพาะภายในบริบทของ Amazon RDS เพื่อควบคุมการเข้าถึงอินสแตนซ์ DB ของคุณเท่านั้น บัญชีผู้ใช้หลักคือบัญชีผู้ใช้ฐานข้อมูลภายในระบบที่คุณสามารถใช้เพื่อเชื่อมต่อกับอินสแตนซ์ DB ของคุณได้ 

คุณสามารถระบุชื่อผู้ใช้หลักและรหัสผ่านที่คุณต้องการเชื่อมโยงกับอินสแตนซ์ DB แต่ละรายการเมื่อคุณสร้างอินสแตนซ์ DB ได้ เมื่อคุณสร้างอินสแตนซ์ DB ของคุณแล้ว คุณสามารถเชื่อมต่อกับฐานข้อมูลโดยใช้ข้อมูลประจำตัวของผู้ใช้หลัก จากนั้นคุณอาจต้องการสร้างบัญชีผู้ใช้เพิ่มเติมเพื่อให้คุณสามารถจำกัดบุคคลที่สามารถเข้าถึงอินสแตนซ์ DB ได้

สำหรับ MySQL สิทธิ์เริ่มต้นสำหรับผู้ใช้หลัก ได้แก่ สร้าง วาง อ้างอิง เหตุการณ์ เปลี่ยนแปลง ลบ ดัชนี แทรก เลือก อัปเดต สร้างตารางชั่วคราว ล็อกตาราง เรียกใช้ สร้างมุมมอง แสดงมุมมอง เปลี่ยนแปลงงานประจำ สร้างงานประจำ ดำเนินการ เรียกใช้ สร้างผู้ใช้ ประมวลผล แสดงฐานข้อมูล ให้ตัวเลือก

สำหรับ Oracle ผู้ใช้หลักจะได้รับบทบาท “dba” ผู้ใช้หลักจะรับช่วงสิทธิ์ส่วนใหญ่ที่เกี่ยวข้องกับบทบาท โปรดดู คู่มือผู้ใช้ Amazon RDS สำหรับรายการของสิทธิ์ที่จำกัดและทางเลือกที่สอดคล้องกันในการดำเนินงานด้านการดูแลระบบที่อาจต้องใช้สิทธิ์เหล่านี้

สำหรับ SQL Server ผู้ใช้ที่สร้างฐานข้อมูลจะได้รับบทบาท "db_owner" โปรดดู คู่มือผู้ใช้ Amazon RDS สำหรับรายการของสิทธิ์ที่จำกัดและทางเลือกที่สอดคล้องกันในการดำเนินงานด้านการดูแลระบบที่อาจต้องใช้สิทธิ์เหล่านี้

ไม่มี ทุกอย่างทำงานตามที่คุณคุ้นเคยเมื่อใช้ฐานข้อมูลเชิงสัมพันธ์ที่คุณจัดการด้วยตนเอง

ใช่ คุณต้องเปิดความสามารถในการเข้าถึงฐานข้อมูลของคุณทางอินเทอร์เน็ตโดยกำหนดค่า กลุ่มมาตรการรักษาความปลอดภัย คุณสามารถอนุญาตการเข้าถึง IP เฉพาะเจาะจง, ช่วง IP หรือเครือข่ายย่อยที่ตรงกับเซิร์ฟเวอร์ในศูนย์ข้อมูลของคุณเอง

ได้ ตัวเลือกนี้ได้รับการรองรับบนกลไก Amazon RDS ทั้งหมด Amazon RDS จะ สร้างใบรับรอง SSL/TLS สำหรับแต่ละอินสแตนซ์ DB เมื่อมีการเชื่อมต่อที่เข้ารหัสแล้ว ข้อมูลที่ถ่ายโอนระหว่างอินสแตนซ์ DB และแอปพลิเคชันของคุณจะได้รับการเข้ารหัสระหว่างการถ่ายโอน

ในขณะที่ SSL มีประโยชน์ด้านความปลอดภัย โปรดทราบว่าการเข้ารหัส SSL/TLS คือการดำเนินงานที่ใช้การประมวลผลสูงและจะเพิ่มเวลาในการเชื่อมต่อฐานข้อมูลของคุณ การรองรับ SSL/TLS ใน Amazon RDS มีไว้สำหรับการเข้ารหัสการเชื่อมต่อระหว่างแอปพลิเคชันกับอินสแตนซ์ DB ของคุณ คุณไม่ควรใช้สำหรับการยืนยันความถูกต้องของอินสแตนซ์ DB

หากต้องการดูรายละเอียดเกี่ยวกับการสร้างการเชื่อมต่อที่เข้ารหัสด้วย Amazon RDS โปรดไปที่คู่มือผู้ใช้ MySQL, คู่มือผู้ใช้ MariaDB, คู่มือผู้ใช้ PostgreSQL หรือคู่มือผู้ใช้ Oracle ของ Amazon RDS หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีที่ SSL/TLS ทำงานร่วมกับกลไกเหล่านี้ คุณสามารถดู เอกสารประกอบ MySQL, เอกสารประกอบ MariaDB, เอกสารประกอบ MSDN SQL Server, เอกสารประกอบ PostgreSQL หรือ เอกสารประกอบ Oracle ได้โดยตรง

Amazon RDS รองรับการเข้ารหัสขณะพักอยู่สำหรับเครื่องมือฐานข้อมูลทั้งหมดโดยใช้คีย์ที่คุณจัดการโดยใช้ AWS Key Management Service (KMS) บนอินสแตนซ์ฐานข้อมูลที่รันด้วยการเข้ารหัส Amazon RDS ข้อมูลที่เก็บพักไว้ในพื้นที่จัดเก็บข้อมูลพื้นฐานจะถูกเข้ารหัส เช่นเดียวกับข้อมูลสำรองอัตโนมัติ แบบจำลองการอ่าน และสแน็ปช็อต การเข้ารหัสและถอดรหัสได้รับการจัดการอย่างโปร่งใส หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ KMS กับ Amazon RDS โปรดดู คู่มือผู้ใช้ Amazon RDS

คุณยังสามารถเพิ่มการเข้ารหัสไปยังอินสแตนซ์ DB หรือคลัสเตอร์ DB ที่ไม่ได้เข้ารหัสก่อนหน้านี้ได้ด้วยการสร้างสแน็ปช็อต DB จากนั้นสร้างสำเนาของสแน็ปช็อตนั้นและระบุคีย์การเข้ารหัส KMS จากนั้นคุณสามารถกู้คืนอินสแตนซ์ DB หรือคลัสเตอร์ DB ที่เข้ารหัสจาก Snapshot ที่เข้ารหัส

Amazon RDS สำหรับ Oracle และ SQL Server รองรับเทคโนโลยี การเข้ารหัสข้อมูลที่โปร่งใส (TDE) ของกลไกเหล่านั้น หากต้องการดูข้อมูลเพิ่มเติม โปรดดูคู่มือผู้ใช้ Amazon RDS สำหรับ Oracle และ SQL Server

คุณสามารถควบคุมการดำเนินการที่ผู้ใช้ AWS IAM และกลุ่มของคุณสามารถดำเนินการกับทรัพยากร Amazon RDS ได้ คุณสามารถทำเช่นนี้ได้โดยอ้างอิงแหล่งข้อมูล Amazon RDS ใน นโยบาย AWS IAM ที่คุณปรับใช้กับผู้ใช้และกลุ่มของคุณ ทรัพยากร Amazon RDS ที่สามารถอ้างอิงได้ในนโยบาย IAM ของ AWS ประกอบด้วยอินสแตนซ์ DB, สแนปช็อต DB, แบบจำลองการอ่าน, กลุ่มมาตรการรักษาความปลอดภัย DB, กลุ่มตัวเลือก DB, กลุ่มพารามิเตอร์ DB, การสมัครรับข้อมูลกิจกรรม และกลุ่มซับเน็ต DB 

นอกจากนี้ คุณยังสามารถแท็กแหล่งข้อมูลเหล่านี้เพื่อเพิ่มเมตาดาต้าเพิ่มเติมลงในทรัพยากรของคุณ เมื่อใช้การแท็ก คุณสามารถจัดหมวดหมู่ทรัพยากรได้ (เช่น อินสแตนซ์ DB "การพัฒนา", อินสแตนซ์ DB "การผลิต" และอินสแตนซ์ DB "การทดสอบ") และเขียนนโยบาย AWS IAM ที่แสดงรายการสิทธิ์ (ซึ่งก็คือการดำเนินการ) ที่สามารถใช้ทรัพยากรที่มีแท็กเหมือนกันได้ สำหรับข้อมูลเพิ่มเติม โปรดดูที่ การติดแท็กทรัพยากร Amazon RDS

ใช่ AWS CloudTrail เป็นบริการทางเว็บที่จะบันทึกการเรียกใช้ AWS API ให้กับบัญชีของคุณและส่งไฟล์ข้อมูลบันทึกให้กับคุณ ประวัติการเรียกใช้ AWS API ที่สร้างโดย CloudTrail ช่วยให้สามารถดำเนินการวิเคราะห์ความปลอดภัย การติดตามการเปลี่ยนแปลงของทรัพยากร และการตรวจสอบการปฏิบัติตามข้อกำหนดได้ 

ได้ กลไกฐานข้อมูล Amazon RDS ทั้งหมด มีคุณสมบัติตรงตาม HIPAA คุณจึงสามารถใช้สร้างแอปพลิเคชันที่ปฏิบัติตามข้อกำหนดของ HIPAA และจัดเก็บข้อมูลที่เกี่ยวข้องกับการดูแลสุขภาพได้ เช่น ข้อมูลสุขภาพที่ได้รับการคุ้มครอง (PHI) ภายใต้สัญญาผู้ร่วมธุรกิจ (BAA) ที่ดำเนินการกับ AWS

หากคุณมี BAA ที่ทำงานอยู่ ไม่จำเป็นต้องเริ่มใช้บริการเหล่านี้ในบัญชีที่ได้รับการคุ้มครองโดย BAA ของคุณ หากคุณไม่มี BAA ที่ทำงานอยู่กับ AWS หรือมีคำถามอื่นๆ เกี่ยวกับแอปพลิเคชันที่เป็นไปตาม HIPAA ใน AWS โปรดติดต่อผู้จัดการบัญชีของคุณ

ตามค่าเริ่มต้น Amazon RDS จะเลือกพารามิเตอร์การกำหนดค่าที่เหมาะสมให้อินสแตนซ์ DB โดยพิจารณาคลาสของอินสแตนซ์และความจุของพื้นที่จัดเก็บ อย่างไรก็ตาม หากคุณต้องการเปลี่ยน คุณสามารถทำได้โดยใช้ AWS Management Console, Amazon RDS API หรือ AWS Command Line Interface โปรดทราบว่า การเปลี่ยนพารามิเตอร์การกำหนดค่า จากค่าที่แนะนำอาจทำให้เกิดผลกระทบที่ไม่คาดคิดได้ อาจเป็นได้ตั้งแต่ประสิทธิภาพที่ลดลงจนถึงระบบล่ม และการเปลี่ยนพารามิเตอร์ควรทำโดยผู้ใช้ระดับสูงที่สามารถยอมรับความเสี่ยงเหล่านี้ได้เท่านั้น

กลุ่มพารามิเตอร์ฐานข้อมูล (กลุ่มพารามิเตอร์ DB) ทำหน้าที่เป็น “ที่จัดเก็บ” ค่าการกำหนดค่ากลไกที่สามารถปรับใช้กับอินสแตนซ์ DB ได้ตั้งแต่หนึ่งรายการขึ้นไป หากคุณสร้างอินสแตนซ์ DB โดยไม่ระบุกลุ่มพารามิเตอร์ DB ระบบจะใช้กลุ่มพารามิเตอร์ DB ตามค่าเริ่มต้นแทน กลุ่มตามค่าเริ่มต้นนี้ประกอบด้วยกลไกเริ่มต้นและระบบตามค่าเริ่มต้นของ Amazon RDS ที่ได้รับการเพิ่มประสิทธิภาพสำหรับอินสแตนซ์ DB ที่คุณกำลังใช้งานอยู่

อย่างไรก็ตาม หากคุณต้องการให้อินสแตนซ์ DB ของคุณทำงานโดยใช้ค่าการกำหนดค่ากลไกที่คุณปรับแต่งเอง คุณสามารถสร้างกลุ่มพารามิเตอร์ DB ใหม่ แล้วปรับแก้พารามิเตอร์ตามต้องการ จากนั้นปรับแก้ให้อินสแตนซ์ DB ใช้กลุ่มพารามิเตอร์ DB ใหม่ เมื่อเชื่อมโยงแล้ว อินสแตนซ์ DB ทั้งหมดที่ใช้กลุ่มพารามิเตอร์ DB เฉพาะจะได้รับการอัปเดตพารามิเตอร์ทั้งหมดเป็นกลุ่มพารามิเตอร์ DB นั้น

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการกำหนดค่ากลุ่มพารามิเตอร์ DB โปรดอ่าน คู่มือผู้ใช้ Amazon RDS

คุณสามารถใช้ AWS Config เพื่อบันทึกการเปลี่ยนแปลงการกำหนดค่าของอินสแตนซ์ Amazon RDS DB, กลุ่มซับเน็ต DB, Database Snapshot กลุ่มมาตรการรักษาความปลอดภัย DB และการสมัครรับข้อมูลกิจกรรมได้อย่างต่อเนื่อง พร้อมรับการแจ้งเตือนการเปลี่ยนแปลงผ่าน Amazon Simple Notification Service (SNS) นอกจากนี้ คุณยังสามารถ สร้างกฎของ AWS Config เพื่อประเมินว่าทรัพยากร Amazon RDS เหล่านี้มีการกำหนดค่าตามที่ต้องการแล้วหรือไม่

เมื่อคุณสร้างหรือปรับแก้อินสแตนซ์ DB ให้ทำงานเป็น การใช้งานอินสแตนซ์แบบ Multi-AZ จะทำให้ Amazon RDS จัดเตรียมและรักษาแบบจำลอง “สแตนด์บาย” ไปพร้อมกันโดยอัตโนมัติใน Availability Zone ต่างๆ การอัปเดตไปยังอินสแตนซ์ DB จะถูกจำลองขึ้นพร้อมๆ กันทั่ว Availability Zone ไปยังสแตนด์บายเพื่อให้ทั้งสองซิงค์และป้องกันการอัปเดตฐานข้อมูลล่าสุดของคุณจากความล้มเหลวอินสแตนซ์ DB 

ระหว่างการบำรุงรักษาที่วางแผนไว้บางประเภท หรือในกรณีที่เกิดความล้มเหลวของอินสแตนซ์ DB หรือความล้มเหลวของ Availability Zone ที่ไม่คาดคิด Amazon RDS จะสร้างข้อผิดพลาดโดยอัตโนมัติไปยังสแตนด์บายเพื่อให้คุณสามารถเริ่มการเขียนและอ่านฐานข้อมูลต่ออีกครั้งทันทีที่เลื่อนระดับสแตนด์บาย เนื่องจากการบันทึกชื่อสำหรับอินสแตนซ์ DB ของคุณยังคงอยู่เหมือนเดิม แอปพลิเคชันของคุณจะกลับมาเริ่มดำเนินการฐานข้อมูลต่อได้โดยไม่จำเป็นต้องมีการแทรกแซงด้วยตนเองจากผู้ดูแล การติดตั้งใช้งานแบบ Multi-AZ ทำให้การจำลองแบบมีความโปร่งใส คุณจึงไม่ต้องโต้ตอบโดยตรงกับสแตนด์บาย และไม่สามารถใช้เพื่อให้บริการรับส่งข้อมูลการอ่านได้ ข้อมูลเพิ่มเติมเกี่ยวกับการใช้งานอินสแตนซ์แบบ Multi-AZ อยู่ใน คู่มือผู้ใช้ Amazon RDS

Availability Zone คือตำแหน่งต่าง ๆ ภายในรีเจี้ยนที่ได้รับการออกแบบมาให้แยกจากความล้มเหลวใน Availability Zone อื่นๆ แต่ละ Availability Zone จะเรียกใช้บนโครงสร้างพื้นฐานทางกายภาพเฉพาะของตนอย่างเป็นอิสระ และได้รับการออกแบบมาให้มีความน่าเชื่อถือสูง โดยจะไม่มีการใช้จุดที่เกิดข้อผิดพลาดทั่วไปร่วมกันระหว่าง Availability Zone เช่น เครื่องกำเนิดไฟฟ้าและอุปกรณ์ทำความเย็น นอกจากนี้ยังแยกออกจากกันทางกายภาพ เพื่อให้ภัยพิบัติที่ไม่ธรรมดาอย่างยิ่ง เช่น อัคคีภัย พายุทอร์นาโด หรืออุทกภัย เกิดผลกระทบต่อ Availability Zone เพียงแห่งเดียว Availability Zone ภายในภูมิภาคเดียวกันจะได้รับประโยชน์จากการเชื่อมต่อเครือข่ายที่มีเวลาแฝงต่ำ

เมื่อคุณเรียกใช้อินสแตนซ์ DB เป็นการปรับใช้หลาย AZ อินสแตนซ์ “หลัก” จะถูกใช้สำหรับการเขียนและการอ่านฐานข้อมูล นอกจากนี้ Amazon RDS ยังจัดเตรียมและรักษา “สแตนด์บาย” อยู่เบื้องหลัง ซึ่งเป็นแบบจำลองของอินสแตนซ์หลักที่อัปเดต สแตนด์บายได้รับการ “เลื่อนระดับ” หากเกิดข้อผิดพลาด หลังจากการเกิดข้อผิดพลาด สแตนด์บายจะกลายมาเป็นอินสแตนซ์หลักและรับการดำเนินการของฐานข้อมูลคุณ คุณไม่ต้องโต้ตอบโดยตรงกับสแตนด์บาย (เช่น สำหรับการอ่าน) ก่อนการเลื่อนระดับ หากคุณสนใจการปรับขนาดของการรับส่งข้อมูลการอ่านให้เกินข้อจำกัดความจุของอินสแตนซ์ DB เดี่ยว โปรดดูคำถามที่พบบ่อยเกี่ยวกับ แบบจำลองการอ่าน

ประโยชน์หลักๆ ของการเรียกใช้อินสแตนซ์ DB เป็นการปรับใช้หลาย AZ คือความทนทานและความพร้อมใช้งานของฐานข้อมูลที่มีประสิทธิภาพมากขึ้น ความพร้อมใช้งานและความทนทานต่อความเสียหายที่เพิ่มขึ้นที่มาพร้อมกับการปรับใช้หลาย AZ ทำให้การปรับใช้เหมาะสำหรับสภาพแวดล้อมการผลิตมาก
 

การเรียกใช้อินสแตนซ์ DB เป็นการปรับใช้หลาย AZ จะปกป้องข้อมูลของคุณหากเกิดความล้มเหลวของส่วนประกอบอินสแตนซ์ DB ที่ไม่คาดคิดขึ้นหรือเสียความพร้อมใช้งานใน Availability Zone หนึ่งไป ตัวอย่างเช่น หากปริมาณพื้นที่จัดเก็บบนอินสแตนซ์หลักของคุณล้มเหลว Amazon RDS จะเริ่มต้นการเกิดข้อผิดพลาดไปที่สแตนด์บายโดยอัตโนมัติ ซึ่งเป็นที่ที่รายการอัปเดตของฐานข้อมูลของคุณยังคงอยู่ครบสมบูรณ์ นี่มอบความทนทานของข้อมูลเพิ่มเติมสำหรับการปรับใช้มาตรฐานใน AZ เดี่ยว ซึ่งจำเป็นต้องมีการดำเนินการกู้คืนที่ผู้ใช้สั่งการและจะไม่สามารถใช้งานรายการอัปเดตที่เกิดขึ้นหลังจากเวลาที่สามารถกู้คืนได้ล่าสุด (โดยปกติมักไม่เกินห้านาทีล่าสุด)

นอกจากนี้คุณยังได้ประโยชน์จากความพร้อมใช้งานฐานข้อมูลที่มีประสิทธิภาพมากขึ้นเมื่อเรียกใช้อินสแตนซ์ DB เป็นการปรับใช้หลาย AZ หาก Availability Zone หรืออินสแตนซ์ DB ล้มเหลว ผลกระทบความพร้อมใช้งานของคุณจะถูกจำกัดอยู่แค่เวลาที่ใช้จนกว่าจะย้ายไปใช้สแตนด์บายเสร็จ ประโยชน์ความพร้อมใช้งานของการปรับใช้หลาย AZ ยังครอบคลุมถึงการบำรุงรักษาที่วางแผนไว้อีกด้วย

ตัวอย่างเช่น ด้วยการสำรองข้อมูลอัตโนมัติ กิจกรรม I/O บนอินสแตนซ์หลักของคุณจะไม่หยุดชะงักระหว่างระยะเวลาการสำรองข้อมูลที่ต้องการอีกต่อไป เนื่องจากการสำรองข้อมูลมาจากสแตนด์บาย ในกรณีของการแพตช์หรือการปรับขนาดคลาสอินสแตนซ์ DB การดำเนินการเหล่านี้จะเกิดที่สแตนด์บายเป็นอันดับแรก ก่อนที่จะมีการเปลี่ยนระบบโดยอัตโนมัติ ดังนั้นผลกระทบความพร้อมใช้งานของคุณจะถูกจำกัดอยู่แค่เวลาที่ใช้จนกว่าจะย้ายไปใช้สแตนด์บายเสร็จ

ประโยชน์อีกนัยหนึ่งของการเรียกใช้อินสแตนซ์ DB เป็นการปรับใช้หลาย AZ คือการเปลี่ยนไปใช้สแตนด์บายเมื่อเกิดความล้มเหลวอินสแตนซ์ DB นั้นเป็นอัตโนมัติและไม่จำเป็นต้องได้รับการดูแล ในบริบท Amazon RDS นี่หมายความว่าคุณไม่จำเป็นต้องติดตามเหตุการณ์อินสแตนซ์ DB และเริ่มการกู้คืนอินสแตนซ์ DB แบบแมนนวล (ผ่าน RestoreDBInstanceToPointInTime หรือ RestoreDBInstanceFromSnapshot API) ในกรณที่เกิดความล้มเหลวของ Availability Zone หรือความล้มเหลวของอินสแตนซ์ DB

คุณอาจสังเกตเห็นเวลาแฝงที่เพิ่มขึ้นที่เกี่ยวข้องกับการปรับใช้อินสแตนซ์ DB มาตรฐานใน Availability Zone เขตพื้นที่เดียวอันเป็นผลมาจากการจำลองแบบข้อมูลพร้อมกันที่ดำเนินการภายใต้ชื่อคุณ

ไม่ได้ สแตนด์บายหลาย AZ ไม่สามารถทำงานตามคำขอการอ่านได้ การปรับใช้หลาย AZ ออกแบบมาเพื่อความพร้อมใช้งานและความทนทานของฐานข้อมูลที่ดียิ่งขึ้น มากกว่าเพื่อประโยชน์ด้านการปรับขนาดการอ่าน ดังนั้น คุณสมบัติจะใช้การจำลองแบบพร้อมกันระหว่างอินสแตนซ์หลักและสแตนด์บาย การใช้งานของเราช่วยให้แน่ใจว่าระบบหลักและโหมดสแตนด์บายมีการซิงค์กันอยู่ตลอดเวลา แต่ไม่อนุญาตให้ใช้โหมดสแตนด์บายสำหรับการดำเนินการอ่านหรือเขียน หากคุณสนใจโซลูชันการปรับขนาดการอ่าน โปรดดูคำถามที่พบบ่อยเกี่ยวกับ แบบจำลองการอ่าน

เพื่อสร้างการนำไปใช้จริงของอินสแตนซ์ DB แบบ Multi-AZ ให้คลิกตัวเลือก “ใช่” สำหรับ “การใช้งานอินสแตนซ์แบบ Multi-AZ” เมื่อเปิดใช้อินสแตนซ์ DB ด้วยคอนโซลการจัดการของ AWS

หรืออีกทางหนึ่ง หากคุณใช้ Amazon RDS API คุณจะต้องเรียกใช้ CreateDBInstance API และตั้งพารามิเตอร์ “แบบ Multi-AZ” ให้เป็นค่า “จริง” หากต้องการแปลงอินสแตนซ์ DB (แบบ AZ เดียว) มาตรฐานที่มีอยู่ให้เป็นแบบ Multi-AZ ให้แก้ไขอินสแตนซ์ DB ใน AWS Management Console หรือใช้ ModifyDBInstance API แล้วตั้งค่าพารามิเตอร์แบบ Multi-AZ เป็นจริง

สำหรับกลไกฐานข้อมูล RDS สำหรับ PostgreSQL, RDS สำหรับ MySQL, RDS สำหรับ MariaDB, RDS สำหรับ SQL Server, RDS สำหรับ Oracle และ RDS สำหรับ Db2 เมื่อคุณเลือกที่จะแปลงอินสแตนซ์ Amazon RDS จากแบบ AZ เดียวเป็นแบบ Multi-AZ สิ่งต่าง ๆ ต่อไปนี้จะเกิดขึ้น:

• ระบบจะบันทึกสแนปช็อตอินสแตนซ์หลักของคุณ
• อินสแตนซ์สแตนด์บายใหม่ถูกสร้างจาก Snapshot ใน Availability Zone ต่างๆ
• การจำลองแบบพร้อมกันถูกกำหนดค่าระหว่างอินสแตนซ์หลักและสแตนด์บาย

ดังนั้น ไม่ควรมีการหยุดทำงานเกิดขึ้นเมื่ออินสแตนซ์ถูกแปลงจาก AZ เดียวเป็นหลาย AZ อย่างไรก็ตาม คุณอาจพบกับเวลาแฝงที่เพิ่มขึ้นขณะที่ข้อมูลในสแตนด์บายจะปรับให้ทันกับข้อมูลหลัก

Amazon RDS ตรวจจับและกู้คืนจากสถานการณ์ความล้มเหลวที่พบได้บ่อยสำหรับการปรับใช้หลาย AZ โดยอัตโนมัติ เพื่อให้คุณสามารถเริ่มการดำเนินการของฐานข้อมูลต่อได้อีกครั้งเร็วที่สุดเท่าที่ทำได้โดยไม่มีการแทรกแซงด้านการบริหารจัดการ Amazon RDS จะดำเนินการเกิดข้อผิดพลาดโดยอัตโนมัติในกรณีที่เกิดสถานการณ์ต่างๆ ดังนี้

• สูญเสียความพร้อมใช้งานใน Availability Zone หลัก
• สูญเสียการเชื่อมต่อเครือข่ายไปยังอินสแตนซ์หลัก
• ความล้มเหลวของคอมพิวเตอร์ในอินสแตนซ์หลัก
• ความล้มเหลวของพื้นที่จัดเก็บในอินสแตนซ์หลัก

หมายเหตุ: เมื่อเริ่มการดำเนินการ เช่น การปรับขนาดอินสแตนซ์ DB หรือการอัปเกรดระบบอย่างการแพตช์ OS สำหรับการติดตั้งใช้งานแบบ Multi-AZ เพื่อความพร้อมใช้งานที่ดียิ่งขึ้น การดำเนินการเหล่านี้จะปรับใช้กับสแตนด์บายเป็นอันดับแรก ก่อนที่จะมีการเปลี่ยนระบบโดยอัตโนมัติ ดังนั้น ผลกระทบด้านความพร้อมใช้งานของคุณจึงถูกจำกัดตามเวลาที่ใช้จนกว่าจะเปลี่ยนระบบโดยอัตโนมัติเสร็จสิ้น โปรดทราบว่าการติดตั้งใช้งานแบบ Multi-AZ ของ Amazon RDS (Amazon RDS Multi-AZ) จะไม่ดำเนินการเปลี่ยนระบบโดยอัตโนมัติเพื่อตอบสนองต่อการดำเนินการของฐานข้อมูล เช่น การสืบค้นที่ใช้เวลานาน การหยุดชะงัก หรือข้อผิดพลาดด้านความเสียหายของฐานข้อมูล

ใช่ Amazon RDS จะส่งเหตุการณ์อินสแตนซ์ DB เพื่อแจ้งให้คุณทราบว่ามีการเกิดข้อผิดพลาดขึ้น คุณสามารถคลิกส่วน “เหตุการณ์” ของ Amazon RDS Console หรือใช้ DescribeEvents API เพื่อส่งกลับข้อมูลเกี่ยวกับเหตุการณ์ที่เกี่ยวข้องกับอินสแตนซ์ DB ของคุณ คุณยังสามารถใช้ Amazon RDS Event Notifications เพื่อรับการแจ้งเตือนเมื่อเกิดเหตุการณ์ DB ที่เฉพาะเจาะจงขึ้น

การเกิดข้อผิดพลาดจะได้รับการจัดการโดย Amazon RDS โดยอัตโนมัติเพื่อให้คุณสามารถเริ่มการดำเนินการของฐานข้อมูลต่อได้อีกครั้งเร็วที่สุดเท่าที่ทำได้โดยไม่มีการแทรกแซงจากผู้ดูแล เมื่อการเกิดข้อผิดพลาดเกิดขึ้น Amazon RDS เพียงแค่พลิกระเบียนชื่อมาตรฐาน (CNAME) สำหรับอินสแตนซ์ DB ไปยังจุดของสแตนด์บาย ซึ่งได้รับการเลื่อนระดับให้เป็นอินสแตนซ์หลักใหม่แทน เราแนะนำให้คุณทำตามแนวทางการปฏิบัติที่ดีที่สุดและปรับใช้การลองเชื่อมต่อฐานข้อมูลอีกครั้งในเลเยอร์แอปพลิเคชัน

การเกิดข้อผิดพลาดคือช่วงระหว่างการตรวจจับความล้มเหลวบนอินสแตนซ์หลักและการกลับสู่สภาพเดิมของการทำธุรกรรมบนสแตนด์บาย ซึ่งโดยปกติจะเสร็จสิ้นภายในหนึ่งหรือสองนาที เวลาที่ใช้ในการแทนที่เมื่อเกิดข้อผิดพลาดอาจได้รับผลกระทบไม่ว่าจะต้องกู้คืนการทำธุรกรรมที่ไม่ถูกยอมรับจำนวนมากหรือไม่ก็ตาม จึงแนะนำให้ใช้ประเภทอินสแตนซ์จำนวนมากอย่างเพียงพอกับการปรับใช้หลาย AZ เพื่อผลลัพธ์ที่ดีที่สุด นอกจากนี้ AWS ยังแนะนำให้ใช้ IOPS ที่จัดเตรียมไว้กับอินสแตนซ์แบบหลาย AZ เพื่อประสิทธิภาพอัตราความเร็วที่รวดเร็ว คาดการณ์ได้ และสม่ำเสมอ

Amazon RDS จะดำเนินการเปลี่ยนระบบโดยอัตโนมัติโดยที่ไม่ต้องมีการแทรกแซงจากผู้ใช้ภายใต้เงื่อนไขความล้มเหลวต่างๆ นอกจากนี้ Amazon RDS ยังมอบตัวเลือกในการเริ่มการเปลี่ยนระบบเมื่อรีบูตอินสแตนซ์ของคุณอีกด้วย คุณสามารถเข้าถึงคุณสมบัตินี้ได้ผ่าน AWS Management Console หรือเมื่อใช้การเรียกใช้ API RebootDBInstance

ด้วยการปรับใช้หลาย AZ คุณเพียงแค่ตั้งพารามิเตอร์ “แบบหลาย AZ” ให้เป็นค่าจริงเท่านั้น การสร้างสแตนด์บาย การจำลองแบบพร้อมกัน และการเกิดข้อผิดพลาดจะได้รับการจัดการโดยอัตโนมัติ นี่หมายความว่าคุณไม่สามารถเลือก Availability Zone ที่จะปรับใช้สแตนด์บายหรือแก้ไขจำนวนสแตนด์บายที่พร้อมใช้งานได้ (Amazon RDS ได้จัดเตรียมสแตนด์บายหนึ่งรายการต่ออินสแตนซ์ DB หลักไว้แล้ว) นอกจากนี้ สแตนด์บายยังไม่สามารถถูกกำหนดค่าเพื่อให้ยอมรับกิจกรรมการอ่านฐานข้อมูลได้อีกด้วย เรียนรู้เพิ่มเติมเกี่ยวกับการกำหนดค่าแบบหลาย AZ

ใช่ สแตนด์บายของคุณจะถูกจัดเตรียมโดยอัตโนมัติใน Availability Zone ต่าง ๆ ใน รีเจี้ยนเดียวกัน กับอินสแตนซ์ DB หลักของคุณ

ได้ คุณสามารถดูตำแหน่งปัจจุบันของอินสแตนซ์หลักได้โดยใช้คอนโซลการจัดการของ AWS หรือ DescribeDBInstances API

Availability Zone ถูกออกแบบมาให้มอบการเชื่อมต่อเครือข่ายที่มีเวลาแฝงต่ำแก่ Availability Zone อื่นๆ ในภูมิภาคเดียวกัน นอกจากนี้ คุณอาจลองพิจารณาการสร้างสถาปัตยกรรมของแอปพลิเคชันและทรัพยากร AWS อื่นๆ ที่มีความซ้ำซ้อนภายใน Availability Zone ต่างๆ เพื่อให้แอปพลิเคชันของคุณยืดหยุ่นหากเกิดความล้มเหลวของ Availability Zone การปรับใช้หลาย AZ แก้ไขปัญหาความต้องการนี้สำหรับลำดับชั้นฐานข้อมูลโดยไม่ต้องใช้การจัดการจากฝั่งคุณ

คุณโต้ตอบกับการสำรองข้อมูลอัตโนมัติและการทำงาน Database Snapshot ในแบบเดียวกัน ไม่ว่าคุณจะเรียกใช้การปรับใช้มาตรฐานในการปรับใช้ AZ เดียวหรือหลาย AZ ก็ตาม หากคุณเรียกใช้การปรับใช้หลาย AZ การสำรองข้อมูลอัตโนมัติและ Database Snapshot จะถูกดึงจากสแตนด์บายเพื่อหลีกเลี่ยงการหยุดชะงักของ I/O บนอินสแตนซ์หลัก โปรดทราบว่าคุณอาจประสบกับเวลาแฝง I/O ที่เพิ่มขึ้น (โดยทั่วไปเกิดขึ้นไม่กี่นาที) ระหว่างการสำรองข้อมูลสำหรับการปรับใช้ AZ เดียวและการปรับใช้หลาย AZ

การเริ่มต้นการดำเนินการกู้คืน (กู้คืนจากจุดใดจุดหนึ่งของเวลาหรือกู้คืนจาก Database Snapshot) ทำงานเช่นเดียวกันกับการปรับใช้หลาย AZ และการปรับใช้ AZ หรือการปรับใช้แบบมาตรฐาน สามารถสร้างการปรับใช้อินสแตนซ์ DB ใหม่ด้วย RestoreDBInstanceFromSnapshot หรือ RestoreDBInstanceToPointInTime API ได้ การปรับใช้อินสแตนซ์ DB ใหม่สามารถเป็นได้ทั้งแบบมาตรฐานหรือแบบหลาย AZ ไม่ว่าข้อมูลสำรองต้นทางจะถูกเริ่มต้นบนการปรับใช้แบบมาตรฐานหรือหลาย AZ ก็ตาม

แบบจำลองการอ่าน ทำให้ใช้ประโยชน์ได้ง่ายขึ้นจากการทำงานของแบบจำลองในตัวของกลไกที่รองรับการเพิ่มจำนวนอินสแตนซ์แบบยืดหยุ่นเกินขอบเขตข้อจำกัดความจุของอินสแตนซ์ DB เดี่ยวสำหรับเวิร์กโหลดฐานข้อมูลที่ต้องอ่านจำนวนมาก

คุณสามารถ สร้างแบบจำลองการอ่าน ได้ภายในไม่กี่คลิกในคอนโซลการจัดการของ AWS หรือโดยการใช้ CreateDBInstanceReadReplica API เมื่อสร้าง Read Replica แล้ว การอัปเดตฐานข้อมูลอินสแตนซ์ DB ต้นทางจะได้รับการจำลองแบบโดยใช้การจำลองแบบเนทีฟและแบบอะซิงโครนัสของกลไกที่รองรับ คุณสามารถสร้าง Read Replica หลายรายการสำหรับอินสแตนซ์ DB ต้นทางที่กำหนดและกระจายการรับส่งข้อมูลการอ่านของแอปพลิเคชันไปยังรายการเหล่านั้นได้

เนื่องจาก Read Replica ใช้การจำลองแบบในตัวของกลไกที่รองรับ ดังนั้นจึงขึ้นอยู่กับความแรงและข้อจำกัดของแต่ละตัว โดยเฉพาะอย่างยิ่ง การอัปเดตจะปรับใช้กับแบบจำลองการอ่านของคุณหลังจากที่ปรับใช้กับอินสแตนซ์ DB ต้นทางและความล่าช้าของการจำลองแบบอาจแตกต่างกันมาก แบบจำลองการอ่านสามารถเชื่อมโยงกับการใช้งานอินสแตนซ์แบบ Multi-AZ เพื่อรับประโยชน์ด้านการปรับขนาดการอ่านนอกเหนือจากความพร้อมใช้งานการเขียนฐานข้อมูลและความทนทานของข้อมูลที่ได้รับการปรับปรุงที่การใช้งานอินสแตนซ์แบบ Multi-AZ มอบให้

อาจมีหลายสถานการณ์ที่จำเป็นต้องปรับใช้แบบจำลองการอ่านตั้งแต่หนึ่งรายการขึ้นไปกับอินสแตนซ์ DB ต้นทางที่กำหนด เหตุผลทั่วไปในการปรับใช้แบบจำลองการอ่านมีดังนี้

• การปรับขนาดเกินความจุการประมวลผลหรือ I/O ของอินสแตนซ์ DB เดี่ยวสำหรับปริมาณงานฐานข้อมูลที่ต้องอ่านจำนวนมาก การรับส่งข้อมูลการอ่านที่มากเกินไปอาจทำให้ถูกนำไปยังแบบจำลองการอ่านหนึ่งแบบจำลองขึ้นไป
• มอบการรับส่งข้อมูลการอ่านในขณะที่อินสแตนซ์ DB ต้นทางไม่พร้อมใช้งาน หากอินสแตนซ์ DB ต้นทางไม่สามารถรับคำขอ I/O ได้ (เช่น เนื่องจากการระงับ I/O เพื่อสำรองข้อมูลหรือการบำรุงรักษาที่วางแผนไว้) คุณสามารถนำการรับส่งข้อมูลการอ่านไปยัง Read Replica ของคุณได้ สำหรับกรณีการใช้งานนี้ โปรดทราบว่าข้อมูลบน Read Replica อาจเป็นข้อมูล “เก่า” เนื่องจากอินสแตนซ์ DB ต้นทางไม่พร้อมใช้งาน
• สถานการณ์การรายงานทางธุรกิจหรือคลังข้อมูล คุณอาจต้องการสืบค้นการรายงานทางธุรกิจเพื่อเรียกใช้กับแบบจำลองการอ่านแทนที่จะใช้อินสแตนซ์ DB หลักที่ใช้งานจริงของคุณ
• คุณสามารถใช้แบบจำลองการอ่านสำหรับกระบวนการกู้คืนจากความเสียหายของอินสแตนซ์ DB ต้นทางทั้งในภูมิภาค AWS Region เดียวกันหรือในภูมิภาคอื่น

ใช่ เปิดใช้งานการสำรองข้อมูลอัตโนมัติบนอินสแตนซ์ DB ต้นทางก่อนเพิ่มแบบจำลองการอ่าน โดยตั้งค่าระยะเวลาการเก็บข้อมูลสำรองให้เป็นค่าอื่นที่ไม่ใช่ 0 ต้องเปิดใช้งานการสำรองข้อมูลเพื่อให้แบบจำลองการอ่านทำงาน

Amazon Aurora: คลัสเตอร์ DB ทั้งหมด

Amazon RDS สำหรับ MySQL: อินสแตนซ์ DB ทั้งหมดรองรับการสร้างแบบจำลองการอ่าน การสำรองข้อมูลอัตโนมัติจะต้องเปิดใช้งานไว้ตลอดเวลาบนอินสแตนซ์ DB ต้นทางสำหรับการดำเนินการของ Read Replica การสำรองข้อมูลอัตโนมัติบนแบบจำลองได้รับการรองรับในแบบจำลองการอ่าน Amazon RDS ที่ใช้ MySQL 5.6 ขึ้นไป ไม่ใช่เวอร์ชัน 5.5

Amazon RDS สำหรับ PostgreSQL: อินสแตนซ์ DB ที่มี PostgreSQL เวอร์ชัน 9.3.5 ขึ้นไปที่รองรับการสร้างแบบจำลองการอ่าน อินสแตนซ์ PostgreSQL ที่มีอยู่ก่อนเวอร์ชัน 9.3.5 จะต้องอัปเกรดเป็น PostgreSQL เวอร์ชัน 9.3.5 เพื่อใช้ประโยชน์จากแบบจำลองการอ่าน Amazon RDS

Amazon RDS สำหรับ MariaDB: อินสแตนซ์ DB ทั้งหมดรองรับการสร้างแบบจำลองการอ่าน การสำรองข้อมูลอัตโนมัติจะต้องเปิดใช้งานไว้ตลอดเวลาบนอินสแตนซ์ DB ต้นทางสำหรับการดำเนินการของ Read Replica

Amazon RDS สำหรับ Oracle: รองรับสำหรับ Oracle เวอร์ชัน 12.1.0.2.v12 และใหม่กว่า และเวอร์ชัน 12.2 ทั้งหมดโดยใช้โมเดล Bring Your Own License ร่วมกับ Oracle Database Enterprise Edition และที่มีสิทธิ์การใช้งานตัวเลือก Active Data Guard

Amazon RDS สำหรับ SQL Server: แบบจำลองการอ่านรองรับ Enterprise Edition ในการกำหนดค่าแบบ Multi-AZ เมื่อเทคโนโลยีการจำลองแบบพื้นฐานใช้กลุ่มให้บริการ Always On สำหรับ SQL Server เวอร์ชัน 2016 และ 2017

คุณสามารถสร้างแบบจำลองการอ่านได้ภายในไม่กี่นาทีโดยใช้ CreateDBInstanceReadReplica API แบบมาตรฐานหรือคลิกเพียงไม่กี่ขั้นตอนบนคอนโซลการจัดการของ AWS เมื่อสร้างแบบจำลองการอ่าน คุณสามารถระบุให้เป็นแบบจำลองการอ่านได้โดยระบุ SourceDBInstanceIdentifier SourceDBInstanceIdentifier คือตัวระบุอินสแตนซ์ของ Database ของอินสแตนซ์ DB “ต้นทาง” ซึ่งเป็นอินสแตนซ์ที่คุณต้องการจำลองแบบ เช่นเดียวกันสำหรับอินสแตนซ์ DB มาตรฐาน คุณยังสามารถระบุ Availability Zone, คลาสอินสแตนซ์ DB และช่วงเวลาการบำรุงรักษาที่เลือก เวอร์ชันกลไก (เช่น PostgreSQL 9.3.5) และการแบ่งพื้นที่จัดเก็บแบบจำลองการอ่านมาจากอินสแตนซ์ DB ต้นทาง 

เมื่อคุณเริ่มต้นการสร้างแบบจำลองการอ่าน Amazon RDS จะถ่ายภาพ Snapshot ของอินสแตนซ์ DB ต้นทางแล้วเริ่มการจำลองแบบ ดังนั้น คุณจะประสบกับการหยุดชะงักของ I/O สั้นๆ บนอินสแตนซ์ DB ต้นทางของคุณในขณะที่สแนปช็อตเกิดขึ้น โดยปกติการหยุดชะงักของ I/O จะเกิดขึ้นนานหนึ่งนาที และจะไม่เกิดขึ้นหากอินสแตนซ์ DB ต้นทางเป็นการติดตั้งใช้งานแบบ Multi-AZ (ในกรณีการติดตั้งใช้งานแบบ Multi-AZ ระบบจะบันทึกสแนปช็อตจากสแตนด์บาย)

นอกจากนี้ Amazon RDS ยังทำงานอย่างมีประสิทธิภาพอีกด้วย (เพื่อให้สามารถเผยแพร่ได้รวดเร็ว) ดังนั้นหากคุณสร้าง Read Replica หลายรายการภายในเวลา 30 นาที Read Replica ทั้งหมดจะใช้ Snapshot ต้นทางเดียวกันเพื่อลดผลกระทบ I/O (การจำลองแบบ “ติดตาม” สำหรับ Read Replica แต่ละรายการที่จะเริ่มหลังการสร้าง)

คุณสามารถเชื่อมต่อกับ Read Replica แบบเดียวกันกับที่คุณเชื่อมต่อกับอินสแตนซ์ DB มาตรฐานโดยใช้ DescribeDBInstance API หรือ AWS Management Console เพื่อเรียกใช้ตำแหน่งข้อมูลสำหรับ Read Replica ของคุณ หากคุณมี Read Replica หลายรายการ แอปพลิเคชันของคุณคือตัวกำหนดการกระจายการรับส่งข้อมูลการอ่านระหว่างรายการต่างๆ

Amazon RDS สำหรับ MySQL, MariaDB และ PostgreSQL ยังช่วยให้คุณสามารถสร้างแบบจำลองการอ่านได้สูงสุดถึง 15 รายการสำหรับอินสแตนซ์ DB ต้นทางที่กำหนด Amazon RDS สำหรับ Oracle และ SQL Server ยังช่วยให้คุณสามารถสร้างแบบจำลองการอ่านได้สูงสุดถึง 5 รายการสำหรับอินสแตนซ์ DB ต้นทางที่กำหนด

ได้ Amazon RDS (ยกเว้น RDS for SQL Server) รองรับแบบจำลองการอ่านข้ามภูมิภาค ระยะเวลาที่ใช้ระหว่างการเขียนข้อมูลไปยังอินสแตนซ์ DB ต้นทางและเมื่อพร้อมใช้ในแบบจำลองการอ่านจะขึ้นอยู่กับเวลาแฝงเครือข่ายระหว่างสองภูมิภาค

ไม่ แบบจำลองการอ่านใน Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle และ SQL Server จะปรับใช้โดยใช้การจำลองแบบภายในระบบแบบอะซิงโครนัสของกลไกเหล่านั้น Amazon Aurora ใช้กลไกการจำลองแบบที่แตกต่างกันแต่ยังคงเป็นแบบอะซิงโครนัส

หากคุณต้องการใช้การจำลองแบบเพื่อเพิ่มความพร้อมใช้งานในการเขียนของฐานข้อมูลและปกป้องการอัปเดตฐานข้อมูลล่าสุดจากสภาวะความล้มเหลวต่างๆ เราแนะนำให้คุณเรียกใช้อินสแตนซ์ DB เป็นการปรับใช้หลาย AZ ด้วยแบบจำลองการอ่าน Amazon RDS ซึ่งใช้การจำลองแบบภายในระบบแบบอะซิงโครนัสของกลไกที่รองรับ การเขียนฐานข้อมูลจะเกิดขึ้นบนแบบจำลองการอ่านหลังจากที่เกิดขึ้นแล้วบนอินสแตนซ์ DB ต้นทางและ “ความล่าช้า” ของการจำลองแบบอาจแตกต่างกันมาก 

ในทางตรงกันข้าม การจำลองแบบที่ใช้โดยการปรับใช้หลาย AZ จะเกิดขึ้นพร้อมกัน หมายความว่าการเขียนฐานข้อมูลทั้งหมดจะเกิดขึ้นในเวลาเดียวกันทั้งบนอินสแตนซ์หลักและอินสแตนซ์สำรอง เป็นการปกป้องการอัปเดตฐานข้อมูลล่าสุดของคุณ เนื่องจากการอัปเดตเหล่านี้ควรพร้อมใช้งานบนอินสแตนซ์สำรองในกรณีที่ต้องมีการย้ายเมื่อเกิดข้อผิดพลาด 

นอกจากนี้ ด้วยการปรับใช้หลาย AZ ทำให้การจำลองแบบมีการจัดการเต็มรูปแบบ Amazon RDS จะติดตามสภาวะการล้มเหลวของอินสแตนซ์ DB หรือการล้มเหลวของ Availability Zone โดยอัตโนมัติ แล้วเริ่ม Failover อัตโนมัติไปยังสแตนด์บาย (หรือไปยังแบบจำลองการอ่าน ในกรณีของ Amazon Aurora) หากเกิดความผิดพลาดขึ้น

ใช่ เนื่องจากการปรับใช้อินสแตนซ์ DB หลาย AZ ทำให้ต้องใช้สิ่งอื่นๆ นอกเหนือจากแบบจำลองการอ่าน จึงสามารถใช้ทั้งสองอย่างนี้ร่วมกันได้สำหรับการปรับใช้ในการใช้งานจริง และเพื่อเชื่อมโยงแบบจำลองการอ่านกับการปรับใช้อินสแตนซ์ DB หลาย AZ อินสแตนซ์ DB หลาย AZ “ต้นทาง” ช่วยให้มีความพร้อมในการเขียน และความทนทานของข้อมูลที่ได้รับการปรับปรุง และแบบจำลองการอ่านที่เชื่อมโยงจะช่วยปรับปรุงการปรับขนาดการรับส่งข้อมูลการอ่าน

ใช่ Amazon RDS สำหรับ MySQL, MariaDB, PostgreSQL และ Oracle ช่วยให้คุณกำหนดค่าการปรับใช้แบบหลาย AZ บน Read Replica เพื่อรองรับการกู้คืนข้อมูลจากความเสียหายและลดการหยุดทำงานการอัปเกรดกลไกได้

ในกรณีที่มีการย้ายแบบหลาย AZ เมื่อเกิดข้อผิดพลาด จะทำให้ Read Replica ที่เชื่อมโยงและพร้อมใช้งานจะกลับมาดำเนินการจำลองแบบต่อเมื่อการย้ายเมื่อเกิดข้อผิดพลาดเสร็จสมบูรณ์ (รับการอัปเดตจากอินสแตนซ์ที่เพิ่งได้รับการเลื่อนระดับ)

Amazon Aurora, Amazon RDS สำหรับ MySQL และ MariaDB: คุณสามารถสร้างแบบจำลองการอ่านได้สามระดับ แบบจำลองการอ่านระดับที่สองจากแบบจำลองการอ่านระดับแรกที่มีอยู่ และแบบจำลองระดับที่สามจากแบบจำลองการอ่านระดับที่สอง ด้วยการสร้างแบบจำลองการอ่านระดับที่สองและระดับที่สาม คุณอาจสามารถย้ายโหลดการจำลองบางส่วนจากอินสแตนซ์ฐานข้อมูลหลักไปยังระดับต่าง ๆ ของแบบจำลองการอ่านตามความต้องการแอปพลิเคชันของคุณ

โปรดทราบว่าแบบจำลองการอ่านลำดับชั้นที่สองอาจล่าช้ากว่าอินสแตนซ์หลักเนื่องจากเวลาแฝงของการจำลองแบบเพิ่มเติมที่เกิดขึ้นในขณะจำลองแบบการทำธุรกรรมจากอินสแตนซ์หลักไปยังแบบจำลองลำดับชั้นที่หนึ่ง แล้วจึงไปยังแบบจำลองลำดับชั้นที่สอง ในทำนองเดียวกัน แบบจำลองระดับที่สามอาจล้าหลังแบบจำลองการอ่านระดับที่สอง

Amazon RDS สำหรับ Oracle และ Amazon RDS สำหรับ SQL Server: ขณะนี้ยังไม่รองรับแบบจำลองการอ่านของแบบจำลองการอ่าน

Read Replica ถูกออกแบบมาสำหรับการรับส่งข้อมูลการอ่าน อย่างไรก็ตาม อาจมีกรณีใช้งานที่ผู้ใช้ระดับสูงต้องการดำเนินการคำสั่ง Data Definition Language (DDL) SQL ต่อแบบจำลองการอ่านให้เสร็จสมบูรณ์ ตัวอย่างอาจรวมถึงการเพิ่มดัชนีฐานข้อมูลไปยังแบบจำลองการอ่านที่ใช้สำหรับการรายงานทางธุรกิจโดยไม่ต้องเพิ่มดัชนีเดียวกันไปยังอินสแตนซ์ DB ต้นทางที่เกี่ยวข้อง

Amazon RDS for MySQL สามารถกำหนดค่าให้อนุญาตคำสั่ง DDL SQL ต่อแบบจำลองการอ่านได้ หากคุณต้องการเปิดใช้งานการดำเนินการอื่นๆ นอกเหนือจากการอ่านแบบจำลองการอ่านที่กำหนด ให้แก้ไขกลุ่มพารามิเตอร์ DB ที่ทำงานอยู่ของแบบจำลองการอ่านโดยตั้งค่าพารามิเตอร์ “read_only” ให้เป็น “0”

ปัจจุบัน Amazon RDS for PostgreSQL ยังไม่รองรับการทำงานของคำสั่ง DDL SQL ต่อแบบจำลองการอ่าน

ใช่ โปรดดู คู่มือผู้ใช้ Amazon RDS สำหรับรายละเอียดเพิ่มเติม

การอัปเดตอินสแตนซ์ DB ต้นทางจะได้รับการจำลองแบบโดยอัตโนมัติไปยังแบบจำลองการอ่านที่เชื่อมโยงอยู่ อย่างไรก็ตาม ด้วยเทคโนโลยีการจำลองแบบอะซิงโครนัสของกลไกที่รองรับแบบจำลองการอ่านอาจอัปเดตช้ากว่าอินสแตนซ์ DB ต้นทางของตัวเองโดยมีสาเหตุหลายประการ สาเหตุที่พบได้โดยทั่วไป มีดังนี้

• ปริมาณ I/O ที่เขียนไปยังอินสแตนซ์ DB ต้นทางเกินอัตราที่สามารถปรับใช้การเปลี่ยนแปลงไปยังแบบจำลองการอ่านได้ (ปัญหานี้มีแนวโน้มจะเกิดขึ้นหากความจุในการประมวลผลของแบบจำลองการอ่านน้อยกว่าอินสแตนซ์ DB ต้นทาง)
• การทำธุรกรรมที่ซับซ้อนหรือทำงานนานต่ออินสแตนซ์ DB ต้นทางที่เก็บการจำลองแบบไปยังแบบจำลองการอ่าน
• พาร์ติชั่นเครือข่ายหรือเวลาแฝงระหว่างอินสแตนซ์ DB ต้นทางและแบบจำลองการอ่าน

แบบจำลองการอ่านขึ้นอยู่กับจุดแข็งและจุดอ่อนของการจำลองแบบภายในระบบของกลไกที่รองรับ หากคุณใช้แบบจำลองการอ่าน คุณควรคำนึงถึงความล่าช้าที่อาจเกิดขึ้นระหว่างแบบจำลองการอ่านและอินสแตนซ์ DB ต้นทาง หรือที่เรียกว่า “ความไม่สม่ำเสมอ”

คุณสามารถใช้ DescribeDBInstances API มาตรฐานเพื่อเรียกคืนรายชื่ออินสแตนซ์ DB ทั้งหมดที่คุณปรับใช้แล้ว (รวมถึงแบบจำลองการอ่าน) หรือเพียงคลิกที่แท็บ “อินสแตนซ์” ใน Amazon RDS Console

Amazon RDS ช่วยให้คุณสามารถดูได้ว่าแบบจำลองการอ่านล่าช้ากว่าอินสแตนซ์ DB ต้นทางมากน้อยเพียงใด ระบบจะเผยแพร่จำนวนวินาทีที่แบบจำลองการอ่านนั้นล่าช้ากว่าแบบจำลองหลักเป็นตัวชี้วัด Amazon CloudWatch (“ความล่าช้าของแบบจำลอง”) ซึ่งสามารถดูได้ในคอนโซลการจัดการของ AWS หรือ Amazon CloudWatch API

สำหรับ Amazon RDS for MySQL แหล่งที่มาของข้อมูลนี้มาจากแหล่งที่มาเดียวกันกับที่แสดงโดยการออกคำสั่ง MySQL “Show Slave Status” มาตรฐานกับแบบจำลองการอ่าน สำหรับ Amazon RDS for PostgreSQL คุณสามารถใช้มุมมอง pg_stat_replication บนอินสแตนซ์ DB ต้นทางเพื่อสำรวจตัววัดการจำลองแบบได้

Amazon RDS จะตรวจสอบสถานะการจำลองแบบของแบบจำลองการอ่านและอัปเดตช่องสถานะของการจำลองแบบในคอนโซลการจัดการของ AWS ให้เป็น “ข้อผิดพลาด” หากการจำลองแบบหยุดทำงานไม่ว่าด้วยสาเหตุใดก็ตาม (เช่น การพยายามสืบค้น DML บนแบบจำลองซึ่งขัดแย้งกับการอัปเดตที่เกิดขึ้นบนอินสแตนซ์ฐานข้อมูลหลักนั้นอาจทำให้เกิดข้อผิดพลาดในการจำลองแบบได้) คุณสามารถอ่านรายละเอียดของข้อผิดพลาดที่เกี่ยวข้องที่กลไก MySQL ละทิ้งได้โดยดูที่ช่องข้อผิดพลาดของการจำลองแบบและดำเนินการตามความเหมาะสมเพื่อกู้คืน คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับการแก้ไขปัญหาการจำลองแบบได้ใน ส่วนการแก้ไขปัญหาแบบจำลองการอ่านของคู่มือผู้ใช้ Amazon RDS สำหรับ MySQL หรือ PostgreSQL 

หากข้อผิดพลาดการจำลองแบบได้รับการแก้ไขแล้ว Replication State จะเปลี่ยนเป็น Replicating

เพื่อให้การจำลองแบบทำงานอย่างมีประสิทธิภาพ เราแนะนำให้แบบจำลองการอ่านมีทรัพยากรในการประมวลผลและพื้นที่จัดเก็บให้ได้มากที่สุดหรือมากกว่าอินสแตนซ์ DB ต้นทางที่เกี่ยวข้องของตัวเอง มิฉะนั้นความล่าช้าในการจำลองแบบของคุณอาจเพิ่มขึ้นหรือแบบจำลองการอ่านของคุณอาจไม่มีพื้นที่สำหรับจัดเก็บการอัปเดตที่ได้รับการจำลองแบบ

คุณสามารถลบแบบจำลองการอ่านได้ภายในไม่กี่ขั้นตอนในคอนโซลการจัดการของ AWS หรือโดยส่งตัวระบุอินสแตนซ์ DB ไปยัง DeleteDBInstance API 

แบบจำลอง Amazon Aurora จะยังทำงานอยู่และยอมรับการรับส่งข้อมูลการอ่านต่อไปแม้หลังจากที่ลบอินสแตนซ์ DB ต้นทางที่เกี่ยวข้องไปแล้วก็ตาม แบบจำลองหนึ่งรายการในคลัสเตอร์จะเลื่อนระดับเป็นอินสแตนซ์หลักใหม่โดยอัตโนมัติ และจะเริ่มยอมรับการรับส่งข้อมูลการเขียน

แบบจำลองการอ่านของ Amazon RDS for MySQL หรือ MariaDB จะยังทำงานอยู่และยอมรับการรับส่งข้อมูลการอ่านต่อไปแม้หลังจากที่ลบอินสแตนซ์ DB ต้นทางที่เกี่ยวข้องไปแล้วก็ตาม หากคุณต้องการลบแบบจำลองการอ่านเพิ่มเติมจากอินสแตนซ์ DB ต้นทางคุณต้องดำเนินการโดยใช้ DeleteDBInstance API หรือ AWS Management Console

หากคุณลบอินสแตนซ์ DB ของ Amazon RDS for PostgreSQL ที่มีแบบจำลองการอ่านจะทำให้แบบจำลองการอ่านทั้งหมดได้รับการเลื่อนระดับเป็นอินสแตนซ์ DB แบบสแตนด์อโลนและจะสามารถยอมรับได้ทั้งการอ่านและเขียนการรับส่งข้อมูล อินสแตนซ์ DB ที่เพิ่งได้รับการเลื่อนระดับจะทำงานอย่างเป็นอิสระต่อกัน หากคุณต้องการลบอินสแตนซ์ DB นอกเหนือจากอินสแตนซ์ DB ต้นทางดั้งเดิม คุณต้องดำเนินการเช่นนั้นโดยใช้ DeleteDBInstance API หรือ AWS Management Console

แบบจำลองการอ่านจะถูกเรียกเก็บค่าบริการในฐานะอินสแตนซ์ DB มาตรฐานและในอัตราเดียวกัน เช่นเดียวกันกับอินสแตนซ์ DB มาตรฐาน อัตราต่อ “ชั่วโมงอินสแตนซ์ DB” สำหรับแบบจำลองการอ่านจะขึ้นอยู่กับคลาสอินสแตนซ์ DB ของแบบจำลองการอ่าน โปรดดู หน้าราคา สำหรับราคาในปัจจุบัน จะไม่มีการเรียกเก็บค่าบริการสำหรับการถ่ายโอนข้อมูลที่เกิดขึ้นในขณะจำลองแบบข้อมูลระหว่างอินสแตนซ์ DB ต้นทางและแบบจำลองการอ่านของคุณภายในภูมิภาค AWS เดียวกัน

การเรียกเก็บค่าบริการสำหรับแบบจำลองการอ่านจะเริ่มทันทีที่สร้างแบบจำลองขึ้นโดยสมบูรณ์ (เมื่อสถานะเปลี่ยนเป็น “Active” (เปิดใช้งาน)) แบบจำลองการอ่านจะเรียกเก็บค่าบริการตามอัตราชั่วโมงอินสแตนซ์ DB ของ Amazon RDS มาตรฐานจนกว่าคุณจะออกคำสั่งลบ

Enhanced Monitoring สำหรับ Amazon RDS ช่วยให้คุณเห็นสภาพของอินสแตนซ์ Amazon RDS ได้ดียิ่งขึ้น เพียง เปิดตัวเลือก “Enhanced Monitoring” สำหรับอินสแตนซ์ Amazon RDS DB ของคุณและตั้งค่าความละเอียด จากนั้น Enhanced Monitoring จะรวบรวมตัววัดของระบบปฏิบัติการที่สำคัญและข้อมูลกระบวนการตามความละเอียดที่กำหนด

สำหรับการวินิจฉัยและการแสดงผลของโหลดฐานข้อมูลของคุณในระดับที่ลึกขึ้น รวมถึงระยะเวลาการเก็บรักษาข้อมูลที่นานขึ้น คุณสามารถลองใช้ ข้อมูลเชิงลึกด้านประสิทธิภาพได้

Enhanced Monitoring จะบันทึกตัววัดในระดับระบบของอินสแตนซ์ Amazon RDS เช่น CPU, หน่วยความจำ, ระบบไฟล์ และดิสก์ I/O เป็นต้น คุณสามารถดูรายชื่อตัววัดฉบับสมบูรณ์ได้ใน เอกสารประกอบ

Enhanced Monitoring รองรับกลไกฐานข้อมูล Amazon RDS ทั้งหมด

Enhanced Monitoring รองรับอินสแตนซ์ทุกประเภท ยกเว้น t1.micro และ m1.small ซอฟต์แวร์นี้ใช้ CPU, หน่วยความจำ และ I/O จำนวนไม่มากสำหรับการตรวจสอบโดยทั่วไป เราขอแนะนำให้เปิดความละเอียดสูงขึ้นสำหรับอินสแตนซ์ที่มีขนาดกลางหรือใหญ่กว่า สำหรับอินสแตนซ์ DB แบบไม่ได้ใช้งานจริง การตั้งค่าเริ่มต้นสำหรับ Enhanced Monitoring จะเป็น “ปิด” และคุณสามารถเลือกที่จะปิดใช้งานต่อไปหรือแก้ไขความละเอียดเมื่อเปิดอยู่ได้

คุณสามารถดูตัววัดระบบและข้อมูลกระบวนการสำหรับอินสแตนซ์ Amazon RDS DB ในรูปแบบกราฟิกบน Console คุณสามารถจัดการตัววัดที่คุณต้องการติดตามสำหรับอินสแตนซ์แต่ละรายการและปรับแต่งแดชบอร์ดเองตามความต้องการของคุณ

ไม่ คุณสามารถตั้งค่าความละเอียดที่แตกต่างกันสำหรับอินสแตนซ์ DB แต่ละรายการในบัญชี Amazon RDS ของคุณได้ คุณยังสามารถเลือกอินสแตนซ์ที่คุณต้องการเปิดใช้งาน Enhanced Monitoring และปรับแก้การแตกส่วนย่อยของอินสแตนซ์ใดๆ เมื่อใดก็ได้ตามที่คุณต้องการ

คุณสามารถย้อนดูค่าประสิทธิภาพของตัววัดทั้งหมดได้สูงสุด 1 ชั่วโมงที่ความละเอียดสูงสุด 1 วินาทีตามการตั้งค่าของคุณ

ตัววัดจาก Enhanced Monitoring สำหรับ Amazon RDS จะส่งไปยังบัญชี CloudWatch Logs ของคุณ คุณสามารถสร้างตัวกรองตัววัดใน CloudWatch จาก CloudWatch Logs และแสดงกราฟบนแดชบอร์ด CloudWatch ได้ หากต้องการรายละเอียดเพิ่มเติม โปรดไปที่หน้า Amazon CloudWatch

คุณควรใช้ CloudWatch หากคุณต้องการดูข้อมูลในอดีตเพิ่มเติมจากข้อมูลที่มีอยู่บนแดชบอร์ด Amazon RDS Console คุณสามารถตรวจสอบอินสแตนซ์ Amazon RDS ของคุณใน CloudWatch เพื่อวินิจฉัยสภาพของสแต็ก AWS ทั้งหมดได้ในตำแหน่งเดียว ปัจจุบัน CloudWatch รองรับการแตกส่วนย่อยสูงสุด 1 นาที และค่าจะถูกนำมาเฉลี่ยออกสำหรับการแตกส่วนย่อยที่ต่ำกว่านี้

ใช่ คุณสามารถสร้างสัญญาณเตือนใน CloudWatch ที่จะส่งการแจ้งเตือนเมื่อสัญญาณเตือนเปลี่ยนสถานะได้ สัญญาณเตือนจะเฝ้าดูตัววัดเดียวตามช่วงระยะเวลาที่คุณกำหนด และดำเนินการอย่างน้อยหนึ่งรายการตามค่าของตัววัดที่สอดคล้องกับค่าเกณฑ์ที่ระบุตามช่วงระยะเวลาที่กำหนด สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับสัญญาณเตือน CloudWatch โปรดไปที่ คู่มือนักพัฒนา Amazon CloudWatch

Enhanced Monitoring สำหรับ Amazon RDS มอบชุดตัววัดที่อยู่ในรูปแบบเพย์โหลด JSON ซึ่งจะส่งไปยังบัญชี CloudWatch Logs ของคุณ เพย์โหลด JSON จะส่งที่ความละเอียดที่กำหนดค่าล่าสุดสำหรับอินสแตนซ์ Amazon RDS

คุณสามารถใช้ตัววัดผ่านแดชบอร์ดหรือแอปพลิเคชันของของบริษัทอื่นได้สองวิธี เครื่องมือการตรวจสอบสามารถใช้ การสมัครรับสมาชิกข้อมูลบันทึก CloudWatch Logs เพื่อตั้งค่าฟีดแบบใกล้เคียงเรียลไทม์สำหรับตัวชี้วัดได้ หรือคุณสามารถใช้ตัวกรองใน CloudWatch Logs เพื่อเชื่อมโยงตัววัดข้ามไปยัง CloudWatch และผสานรวมแอปพลิเคชันของคุณกับ CloudWatch ได้ โปรดไปที่ เอกสารประกอบ Amazon CloudWatch เพื่อดูรายละเอียดเพิ่มเติม

เนื่องจาก Enhanced Monitoring ส่งมอบส่วนข้อมูล JSON ไปยังบันทึกในบัญชี CloudWatch Logs จึงทำให้คุณสามารถควบคุมระยะเวลาจัดเก็บข้อมูลได้เช่นเดียวกับการสตรีม CloudWatch Logs อื่นๆ ระยะเวลาจัดเก็บข้อมูลตามค่าเริ่มต้นที่กำหนดค่าสำหรับ Enhanced Monitoring ใน CloudWatch Logs คือ 30 วัน สำหรับรายละเอียดเกี่ยวกับวิธีเปลี่ยนการตั้งค่าการจัดเก็บ โปรดไปที่ คู่มือนักพัฒนา Amazon CloudWatch

เนื่องตัววัดถูกนำเข้าใน CloudWatch Logs ค่าใช้จ่ายของคุณจะขึ้นอยู่กับการถ่ายโอนข้อมูล CloudWatch Logs และอัตราพื้นที่จัดเก็บเมื่อคุณใช้งานเกิน Free Tier ของ CloudWatch Logs ดูรายละเอียดราคาได้ ที่นี่ จำนวนข้อมูลที่ถ่ายโอนสำหรับอินสแตนซ์ Amazon RDS จะเป็นไปตามสัดส่วนของความละเอียดที่กำหนดสำหรับคุณสมบัติ Enhanced Monitoring ทันที ผู้ดูแลระบบสามารถกำหนดการแตกส่วนย่อยที่แตกต่างกันสำหรับอินสแตนซ์ต่างๆ ในบัญชีเพื่อควบคุมค่าใช้จ่าย

ปริมาณโดยประมาณของข้อมูลที่นำเข้าไปยัง CloudWatch Logs โดย Enhanced Monitoring สำหรับอินสแตนซ์แสดงอยู่ด้านล่าง ดังนี้

พร็อกซีของ Amazon RDS เป็นคุณสมบัติของพร็อกซีฐานข้อมูลที่สามารถจัดการได้อย่างเต็มรูปแบบและมีความพร้อมใช้งานสูงสำหรับ Amazon RDS RDS Prozy ช่วยให้แอปพลิเคชันสามารถปรับขนาดได้มากขึ้น ทนทานต่อการล้มเหลวของฐานข้อมูลได้มากขึ้น และปลอดภัยยิ่งขึ้น

พร็อกซีของ Amazon RDS เป็นคุณสมบัติพร็อกซีฐานข้อมูลที่มีการจัดการเต็มรูปแบบ พร้อมใช้งานสูงและใช้งานง่ายของ Amazon RDS ซึ่งช่วยให้แอปพลิเคชันของคุณสามารถ: 1) ปรับปรุงความสามารถในการเพิ่มทรัพยากรโดยการรวมกลุ่มและแบ่งปันการเชื่อมต่อฐานข้อมูล; 2) ปรับปรุงความพร้อมใช้งานโดยลดเวลาการใช้ระบบสำรองเพื่อกู้คืนข้อมูลของฐานข้อมูลลงได้ถึง 66% และคงการเชื่อมต่อแอปพลิเคชันไว้ระหว่างที่เกิดข้อผิดพลาด และ 3) ปรับปรุงความปลอดภัยด้วยการบังคับใช้การรับรองความถูกต้องของ AWS IAM กับฐานข้อมูลและจัดเก็บข้อมูลประจำตัวอย่างปลอดภัยใน AWS Secrets Manager

Amazon RDS Proxy สามารถเพิ่มเวลาแฝงของเครือข่ายโดยเฉลี่ย 5 มิลลิวินาทีสำหรับเวลาในการตอบสนองของการสืบค้นหรือการทำธุรกรรมได้ตามปริมาณงานของคุณ หากแอปพลิเคชันของคุณไม่สามารถทนต่อเวลาแฝง 5 มิลลิวินาทีหรือไม่ต้องการการจัดการการเชื่อมต่อและคุณสมบัติอื่นๆ ที่พร็อกซี RDS เปิดให้ใช้งาน คุณอาจต้องการให้แอปพลิเคชันของคุณเชื่อมต่อกับตำแหน่งข้อมูลของฐานข้อมูลโดยตรง

พร็อกซีของ Amazon RDS จะเปลี่ยนแปลงแนวทางการในการสร้าง แอปพลิเคชันแบบไม่ต้องใช้เซิร์ฟเวอร์ ยุคใหม่โดยจะใช้ประโยชน์จากความสามารถและความเรียบง่ายของระบบฐานข้อมูลแบบเชิงสัมพันธ์ ประการแรก พร็อกซี RDS จะทำให้แอปพลิเคชันแบบไม่ต้องใช้เซิร์ฟเวอร์สามารถปรับขนาดได้อย่างมีประสิทธิภาพโดยการรวมและการนำการเชื่อมต่อกับฐานข้อมูลกลับมาใช้ใหม่ ประการที่สอง ด้วยการใช้งานพร็อกซี RDS คุณไม่จำเป็นต้องจัดการข้อมูลการรับรองของฐานข้อมูลในโค้ด Lambda ของคุณอีกต่อไป คุณสามารถใช้บทบาทการดำเนินการ IAM ที่เชื่อมโยงกับฟังก์ชัน Lanbda เพื่อยืนยันตัวตนกับพร็อกซี RDS และฐานข้อมูลของคุณได้ ประการที่สาม คุณไม่จำเป็นต้องจัดการโครงสร้างพื้นฐานหรือโค้ดใหม่ๆ เพื่อใช้ประโยชน์สูงสุดจากแอปพลิเคชันแบบไร้เซิร์ฟเวอร์ที่ได้รับการสนับสนุนโดยระบบฐานข้อมูลเชิงสัมพันธ์ พร็อกซี RDS ได้รับการจัดการอย่างเต็มรูปแบบและปรับขนาดความจุของตัวเองโดยอัตโนมัติตามความต้องการในการใช้งานแอปพลิเคชันของคุณ

พร็อกซีของ RDS พร้อมใช้งานสําหรับ Amazon Aurora ที่เข้ากันได้กับ MySQL, Amazon Aurora ที่เข้ากันได้กับ PostgreSQL, Amazon RDS สำหรับ MariaDB, Amazon RDS สำหรับ MySQL, Amazon RDS สำหรับ PostgreSQL และ Amazon RDS สำหรับ SQL Server สำหรับรายการเวอร์ชันของกลไกที่รองรับ โปรดดู คู่มือผู้ใช้ Amazon Aurora หรือ คู่มือผู้ใช้ Amazon RDS

คุณสามารถเปิดใช้งาน Amazon RDS Proxy สำหรับฐานข้อมูล Amazon RDS ของคุณได้โดยการคลิกเพียงไม่กี่ครั้งใน Amazon RDS Console ขณะที่เปิดใช้งานพร็อกซี RDS คุณต้องระบุ VPC และซับเน็ตที่คุณต้องการเข้าถึงพร็อกซี RDS ด้วย ในฐานะผู้ใช้งาน Lambda คุณสามารถเปิดใช้งานพร็อกซีของ Amazon RDS สำหรับฐานข้อมูล Amazon RDS และตั้งค่าฟังก์ชัน Lambda เพื่อให้เข้าถึงได้โดยการคลิกเพียงไม่กี่ครั้งใน Lambda Console

ใช่ คุณสามารถใช้ Amazon RDS Proxy ในการสร้างพร็อกซี จากนั้นกำหนดกลุ่มเป้าหมายเพื่อเชื่อมโยงพร็อกซีกับอินสแตนซ์ฐานข้อมูลหรือคลัสเตอร์ ตัวอย่างเช่น

aws rds create-db-proxy 
        --db-proxy-name '…' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '…'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

ส่วนขยายภาษาที่เชื่อถือได้ (TLE) สำหรับ PostgreSQL ช่วยให้นักพัฒนาสามารถสร้างส่วนขยาย PostgreSQL ที่มีประสิทธิภาพสูง และเรียกใช้ได้อย่างปลอดภัยบน Amazon Aurora และ Amazon RDS ด้วยวิธีนี้ TLE จะปรับปรุงเวลาของคุณในการออกสู่ตลาดและกำจัดภาระที่ผู้ดูแลระบบฐานข้อมูลต้องรับรองรหัสที่กำหนดเองและรหัสบุคคลที่สามเพื่อใช้ในเวิร์กโหลดของฐานข้อมูลที่ใช้งานจริง คุณสามารถก้าวไปข้างหน้าได้ทันทีที่คุณตัดสินใจเลือกส่วนขยายที่ตรงกับความต้องการของคุณ การใช้งาน TLE จะทำให้ผู้จำหน่ายซอฟต์แวร์อิสระ (ISV) สามารถจัดหาส่วนขยาย PostgreSQL ใหม่ ๆ ให้กับลูกค้าที่ทำงานบน Aurora และ Amazon RDS ได้

ส่วนขยาย PostgreSQL จะดำเนินการในพื้นที่กระบวนการเดียวกันเพื่อให้เกิดประสิทธิภาพสูง อย่างไรก็ตาม ส่วนขยายเหล่านี้อาจมีข้อบกพร่องของซอฟต์แวร์ที่อาจทำให้ฐานข้อมูลเสียหายได้

TLE สำหรับ PostgreSQL มีการป้องกันหลายชั้นเพื่อลดความเสี่ยงนี้ลง TLE ได้รับการออกแบบมาเพื่อจำกัดการเข้าถึงทรัพยากรของระบบ บทบาท rds_superuser สามารถกำหนดได้ว่าใครบ้างที่จะได้รับอนุญาตให้ติดตั้งส่วนขยายเฉพาะ อย่างไรก็ตาม จะสามารถทำการเปลี่ยนแปลงเหล่านี้ได้ผ่าน TLE API เท่านั้น TLE ได้รับการออกแบบมาเพื่อจำกัดผลกระทบของข้อบกพร่องของส่วนขยายต่อการเชื่อมต่อฐานข้อมูลเดียว นอกเหนือจากการป้องกันเหล่านี้แล้ว TLE ยังได้รับการออกแบบมาเพื่อจัดเตรียม DBA ไว้ในบทบาท rds_superuser แบบละเอียด การควบคุมแบบออนไลน์ว่าใครสามารถติดตั้งส่วนขยายได้ รวมถึงสามารถสร้างโมเดลสิทธิ์สำหรับการเรียกใช้ส่วนขยายได้

เฉพาะผู้ใช้ที่มีสิทธิ์มากพอเท่านั้นจึงจะสามารถเรียกใช้และสร้าง โดยใช้คำสั่ง “CREATE EXTENSION” บนส่วนขยาย TLE นอกจากนี้ DBA ยังสามารถอนุญาตรายการ “PostgreSQL Hook” ที่จำเป็นสำหรับส่วนขยายที่ซับซ้อนมากขึ้นได้อีกด้วย ซึ่งจะปรับเปลี่ยนพฤติกรรมภายในของฐานข้อมูล และโดยทั่วไปแล้วจำเป็นต้องใช้สิทธิ์ระดับสูง

TLE สำหรับ PostgreSQL พร้อมใช้งานสำหรับ Amazon Aurora รุ่นที่ใช้งานร่วมกับ PostgreSQL ได้และ Amazon RDS on PostgreSQL ในเวอร์ชัน 14.5 และสูงกว่า TLE ได้รับการปรับใช้เป็นส่วนขยาย PostgreSQL และคุณสามารถเปิดใช้งานได้จากบทบาท rds_superuser ซึ่งคล้ายกับส่วนขยายอื่น ๆ ที่รองรับบน Aurora และ Amazon RDS

คุณสามารถเรียกใช้ TLE สำหรับ PostgreSQL ได้ใน PostgreSQL 14.5 หรือสูงกว่าใน Amazon Aurora และ Amazon RDS  

ในปัจจุบัน TLE สำหรับ PostgreSQL มีให้บริการในทุก AWS Region (ยกเว้นรีเจี้ยนจีนของ AWS) และรีเจี้ยนต่าง ๆ ของ AWS GovCloud

TLE for PostgreSQL พร้อมให้บริการแก่ลูกค้า Aurora และ Amazon RDS โดยไม่มีค่าใช้จ่ายเพิ่มเติม

Aurora และ Amazon RDS รองรับ ชุดส่วนขยาย PostgreSQL ที่ได้รับการดูแลจัดการมากกว่า 85 รายการ AWS จัดการความเสี่ยงด้านความปลอดภัยสำหรับแต่ละส่วนขยายเหล่านี้ภายใต้ รูปแบบความรับผิดชอบร่วมกันของ AWS ส่วนขยายที่ใช้ TLE สำหรับ PostgreSQL รวมอยู่แล้วในชุดนี้ ส่วนขยายที่คุณเขียนหรือที่คุณได้รับจากแหล่งที่มาของบุคคลที่สามและติดตั้งใน TLE ถือว่าเป็นส่วนหนึ่งของโค้ดแอปพลิเคชันของคุณ คุณจะต้องรับผิดชอบต่อความปลอดภัยของแอปพลิเคชันของคุณที่ใช้ส่วนขยาย TLE

คุณสามารถสร้างฟังก์ชันสำหรับนักพัฒนาได้ เช่น การบีบอัดบิตแมปและความเป็นส่วนตัวที่แตกต่างกัน (เช่น แบบสอบถามทางสถิติที่สาธารณะเข้าถึงได้ที่ปกป้องความเป็นส่วนตัวของแต่ละบุคคล)

ในปัจจุบัน TLE สำหรับ PostgreSQL รองรับ JavaScript, PL/pgSQL, Perl และ SQL

เมื่อบทบาท rds_superuser เปิดใช้งาน TLE สำหรับ PostgreSQL คุณจะสามารถปรับใช้ส่วนขยาย TLE ได้โดยใช้คำสั่ง SQL CREATE EXTENSION จากไคลเอ็นต์ PostgreSQL เช่น psql ซึ่งคล้ายกับวิธีสร้างฟังก์ชันที่ผู้ใช้กำหนดซึ่งเขียนด้วยภาษาขั้นตอน เช่น PL/pgSQL หรือ PL/Perl คุณสามารถควบคุมได้ว่าผู้ใช้รายใดมีสิทธิ์ในการปรับใช้ส่วนขยาย TLE และใช้ส่วนขยายเฉพาะได้

TLE สำหรับ PostgreSQL สามารถเข้าถึงฐานข้อมูล PostgreSQL ของคุณผ่านทาง TLE API โดยเฉพาะ ภาษาที่เชื่อถือได้ที่รองรับ TLE ประกอบด้วยฟังก์ชันทั้งหมดของอินเทอร์เฟซการเขียนโปรแกรมเซิร์ฟเวอร์ PostgreSQL (SPI) และการรองรับ PostgreSQL Hook รวมถึง Hook ตรวจสอบรหัสผ่าน

คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับโปรเจกต์ของ TLE สำหรับ PostgreSQL ได้ที่หน้าอย่างเป็นทางการของ TLE GitHub

การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS พร้อมใช้งานใน Amazon Aurora MySQL-Compatible Edition, Amazon Aurora PostgreSQL-Compatible Edition, Amazon RDS สำหรับ MySQL, Amazon RDS สำหรับ MariaDB, และAmazon RDS สำหรับ PostgreSQL 

การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS พร้อมใช้งานใน Amazon Aurora MySQL-Compatible Edition เวอร์ชัน 5.6 ขึ้นไป, RDS สำหรับ MySQL เวอร์ชัน 5.7 ขึ้นไป และ RDS สำหรับเวอร์ชัน MariaDB เวอร์ชัน 10.2 ขึ้นไป นอกจากนี้ การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ยังรองรับ Amazon Aurora PostgreSQL-Compatible Edition และ Amazon RDS สำหรับ PostgreSQL สำหรับเวอร์ชัน 11.21 และสูงกว่า, 12.16 และสูงกว่า, 13.12 และสูงกว่า, 14.9 และสูงกว่า และ 15.4 และสูงกว่า เรียนรู้เพิ่มเติมเกี่ยวกับเวอร์ชันที่มีอยู่ใน เอกสารประกอบของ Amazon Aurora และ Amazon RDS 

การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS มีให้บริการในทุก ๆ AWS Region ที่เกี่ยวข้องและรีเจี้ยนต่าง ๆ ของ AWS GovCloud

การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS ช่วยให้คุณเปลี่ยนแปลงฐานข้อมูลได้อย่างปลอดภัย ง่ายขึ้น และรวดเร็วยิ่งขึ้น การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) เหมาะอย่างยิ่งสําหรับกรณีการใช้งานอย่างเช่น การอัปเกรดกลไกฐานข้อมูลเวอร์ชันหลักหรือเวอร์ชันรอง การอัปเดตระบบปฏิบัติการ การเปลี่ยนแปลงสคีมาในสภาพแวดล้อม Green ที่ไม่ทำให้การจําลองแบบตรรกะเสียหาย เช่น การเพิ่มคอลัมน์ใหม่ที่ส่วนท้ายของตาราง หรือการเปลี่ยนแปลงการตั้งค่าพารามิเตอร์ฐานข้อมูล คุณสามารถใช้การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) เพื่อทําการอัปเดตฐานข้อมูลหลายรายการพร้อมกันโดยใช้การสลับเปลี่ยนเพียงครั้งเดียวได้ ซึ่งจะช่วยให้คุณได้รับแพตช์ความปลอดภัยเวอร์ชันล่าสุดเสมอ สามารถปรับปรุงประสิทธิภาพของฐานข้อมูล และเข้าถึงคุณสมบัติฐานข้อมูลที่ใหม่กว่าอย่างคาดการณ์ได้โดยไม่ต้องหยุดทํางานเป็นระยะเวลานาน

คุณจะต้องเสียค่าใช้จ่ายในการเรียกใช้เวิร์กโหลดบนอินสแตนซ์ Green เท่ากันกับที่คุณดำเนินการกับอินสแตนซ์ Blue ค่าใช้จ่ายในการใช้งานอินสแตนซ์ Blue และ Green ประกอบด้วย ราคามาตรฐานปัจจุบัน สำหรับ db.instances ต้นทุนด้านพื้นที่จัดเก็บ ต้นทุน I/O การอ่าน/เขียน และคุณสมบัติที่เปิดใช้งานต่าง ๆ เช่น ต้นทุนการสำรองข้อมูลและ ข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพการทำงานของ Amazon RDS จริงๆ แล้ว คุณจะต้องจ่ายประมาณ 2 เท่าของต้นทุนการเรียกใช้งานเวิร์กโหลดบน db.instance ตลอดอายุการใช้งานของการติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green)

ตัวอย่างเช่น: คุณมี RDS สำหรับฐานข้อมูล MySQL 5.7 ที่ทำงานบนอินสแตนซ์ r5.2xlarge db.instances สองตัว อินสแตนซ์ฐานข้อมูลหลัก และแบบจำลองการอ่าน ใน AWS Region สหรัฐอเมริกาฝั่งตะวันออก-1 ที่มีการกำหนดค่า Multi-AZ (MAZ) แต่ละอินสแตนซ์ r5.2xlarge db.instances ได้รับการกำหนดค่าสำหรับ Amazon Elastic Block Storge (EBS) ใช้งานทั่วไป 20 GiB คุณสร้างโคลนของโทโพโลยีอินสแตนซ์ Blue โดยใช้การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS ใช้งานเป็นเวลา 15 วัน (360 ชั่วโมง) จากนั้นลบอินสแตนซ์ Blue หลังจากการสลับเปลี่ยนสำเร็จแล้ว อินสแตนซ์ Blue มีราคาอยู่ที่ 1,387 USD เป็นเวลา 15 วัน ในเรตแบบ On-Demand 1.926 USD/ชม. (ค่าใช้จ่ายอินสแตนซ์ + EBS) ค่าใช้จ่ายทั้งหมดของคุณสำหรับการติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ในช่วง 15 วัน ดังกล่าวคือ 2,774 USD ซึ่งคิดเป็นประมาณ 2 เท่า ของค่าใช้จ่ายในการเรียกใช้อินสแตนซ์ Blue ในช่วงเวลาดังกล่าว

การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS ช่วยให้คุณทำการเปลี่ยนแปลงฐานข้อมูลได้อย่างปลอดภัยยิ่งขึ้น ง่ายยิ่งขึ้น และรวดเร็วยิ่งขึ้น เช่น การอัปเกรดเวอร์ชันหลักหรือรอง การเปลี่ยนแปลงสคีมา การปรับขนาดอินสแตนซ์ การเปลี่ยนแปลงพารามิเตอร์กลไก และการอัปเดตการบำรุงรักษา

ในการติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS สภาพแวดล้อม Blue คือสภาพแวดล้อมการใช้งานจริงในปัจจุบันของคุณ สภาพแวดล้อม Green คือสภาพแวดล้อมชั่วคราวของคุณซึ่งจะกลายเป็นสภาพแวดล้อมการใช้งานจริงใหม่ของคุณหลังจากมีการสลับเปลี่ยน

เมื่อการติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS เริ่มต้นการสลับเปลี่ยนแล้ว ระบบจะบล็อกการเขียนไปยังทั้งสภาพแวดล้อม Blue และ Green จนกว่าการสลับเปลี่ยนจะเสร็จสมบูรณ์ ในระหว่างการสลับเปลี่ยน สภาพแวดล้อมชั่วคราวหรือสภาพแวดล้อม Green จะอัปเดตกับระบบการผลิต ทำให้มั่นใจได้ว่าข้อมูลจะสอดคล้องกันระหว่างสภาพแวดล้อมชั่วคราวและสภาพแวดล้อมการใช้งานจริง เมื่อสภาพแวดล้อมการใช้งานจริงและสภาพแวดล้อมชั่วคราวซิงค์กันอย่างสมบูรณ์ การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) จะเลื่อนระดับสภาพแวดล้อมชั่วคราวให้เป็นสภาพแวดล้อมการใช้งานจริง โดยจะเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังสภาพแวดล้อมการใช้งานจริงที่เพิ่งได้รับการเลื่อนขั้นขึ้นมาแทน การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ถูกออกแบบมาเพื่อเปิดใช้งานการเขียนในสภาพแวดล้อม Green หลังจากมีการสลับเปลี่ยนเสร็จสมบูรณ์ ทำให้มั่นใจได้ว่าจะไม่มีข้อมูลสูญหายในระหว่างกระบวนการสลับเปลี่ยน

หากสภาพแวดล้อม Blue ของคุณเป็นแบบจําลองเชิงตรรกะที่จัดการด้วยตนเองหรือผู้สมัครรับข้อมูล เราจะบล็อกการสลับเปลี่ยน เราขอแนะนําให้คุณหยุดการจําลองแบบไปยังสภาพแวดล้อม Blue ก่อน จากนั้นดําเนินการต่อไปด้วยการสลับเปลี่ยน แล้วค่อยกลับมาดําเนินการจําลองต่อ ในทางตรงกันข้าม ถ้าสภาพแวดล้อม Blue ของคุณเป็นแหล่งข้อมูลสําหรับแบบจําลองเชิงตรรกะที่จัดการด้วยตนเองหรือตัวเผยแพร่ข้อความ คุณสามารถดำเนินการสลับเปลี่ยนต่อไปได้เลย อย่างไรก็ตาม คุณจะต้องอัปเดตแบบจําลองที่จัดการด้วยตนเองเพื่อจําลองจากสภาพแวดล้อม Green หลังการสลับเปลี่ยน

การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS จะไม่ลบสภาพแวดล้อมการใช้งานจริงอันเก่าของคุณทิ้ง หากจำเป็น คุณจะยังสามารถเข้าถึงเพื่อตรวจสอบความถูกต้องเพิ่มเติมและการทดสอบประสิทธิภาพ/รีเกรสชันได้ หากคุณไม่ต้องการสภาพแวดล้อมการใช้งานจริงแบบเก่าอีกต่อไปแล้ว คุณก็สามารถลบออกได้ การเรียกเก็บเงินแบบมาตรฐานจะยังคงมีผลกับอินสแตนซ์การผลิตอันเก่าจนกว่าคุณจะลบออก

กฎควบคุมระบบการสลับเปลี่ยนการติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS จะบล็อกการเขียนบนสภาพแวดล้อม Blue และ Green ของคุณจนกว่าสภาพแวดล้อม Green ของคุณจะมีการอัปเดตจนเป็นปัจจุบันก่อนที่จะมีการสลับเปลี่ยน นอกจากนี้การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ยังดำเนินการตรวจสอบสถานะประสิทธิภาพหลักและแบบจำลองของคุณในสภาพแวดล้อม Blue และ Green อีกด้วย นอกจากนี้ยังทำการการตรวจสอบสถานะประสิทธิภาพของการจำลองด้วย ตัวอย่างเช่น เพื่อดูว่าการจำลองแบบหยุดทำงานแล้วหรือมีข้อผิดพลาดหรือไม่ การติดตั้งใช้งานดังกล่าวจะตรวจจับธุรกรรมที่ใช้เวลานานระหว่างสภาพแวดล้อม Blue และ Green ของคุณ คุณสามารถระบุเวลาหยุดทำงานสูงสุดที่ยอมรับได้ มากถึง 30 วินาที และหากคุณมีธุรกรรมที่กำลังดำเนินอยู่ซึ่งเกินกว่านี้ การสลับเปลี่ยนจะหยุดทำงาน

ไม่ การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS ไม่รองรับฐานข้อมูลทั่วโลก พร็อกซีของ Amazon RDS แบบจำลองการอ่านข้ามรีเจี้ยนหรือแบบจำลองการอ่านแบบเรียงซ้อน

ไม่ได้ ในขณะนี้คุณไม่สามารถใช้การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS เพื่อย้อนกลับการเปลี่ยนแปลงได้

MySQL ปกป้องผู้ใช้จากการสูญเสียข้อมูลโดยการเขียนข้อมูลในหน้า 16KiB ในหน่วยความจำสองครั้งเพื่อการจัดเก็บที่คงทน—ในตอนแรกไปยัง “บัฟเฟอร์การเขียนซ้ำ” จากนั้นไปยังพื้นที่จัดเก็บตาราง การเขียนประสิทธิภาพสูงของ Amazon RDS เขียนหน้าข้อมูล 16KiB ของคุณไปยังไฟล์ข้อมูลของคุณโดยตรงอย่างน่าเชื่อถือและทนทานในขั้นตอนเดียวโดยใช้คุณสมบัติ ป้องกันการลดประสิทธิภาพการเขียน ของ AWS Nitro System

การเขียนประสิทธิภาพสูงของ Amazon RDS มีให้ใช้งานใน MySQL เวอร์ชันหลัก 8.0.30 ขึ้นไป

การเขียนประสิทธิภาพสูงของ Amazon RDS มีให้ใช้งานในอินสแตนซ์ db.r6i และ db.r5b มีให้ใช้งานในทุก Region ที่มีอินสแตนซ์เหล่านี้ ยกเว้น AWS China Region

ไม่ Amazon Aurora รุ่นที่รองรับ MySQL หลีกเลี่ยงการใช้ “บัฟเฟอร์การเขียนซ้ำ” แล้ว แต่ Amazon Aurora จะจำลองข้อมูลหกวิธีใน Availability Zone (AZ) สามแห่ง และใช้วิธีการตามองค์ประชุมเพื่อเขียนข้อมูลอย่างคงทนและอ่านข้อมูลได้อย่างถูกต้องหลังจากนั้น

ในขณะนี้ รุ่นเริ่มต้นนี้ไม่รองรับการเปิดใช้งาน การเขียนประสิทธิภาพสูงของ Amazon RDS สำหรับอินสแตนซ์ฐานข้อมูลที่มีอยู่ของคุณ แม้ว่าคลาสอินสแตนซ์จะรองรับการเขียนประสิทธิภาพสูงก็ตาม

การเขียนประสิทธิภาพสูงของ Amazon RDS มีให้สำหรับลูกค้า RDS สำหรับ MySQL โดยไม่มีค่าใช้จ่ายเพิ่มเติม

เวิร์กโหลดที่ใช้วัตถุชั่วคราวใน MySQL และ MariaDB ในการประมวลผลการสืบค้นจาก การอ่านประสิทธิภาพสูงของ Amazon RDS การอ่านที่ปรับให้เหมาะสมจะวางวัตถุชั่วคราวไว้ในที่เก็บอินสแตนซ์ที่ใช้ NVME ของอินสแตนซ์ฐานข้อมูล แทนที่จะเป็นโวลุม Amazon Elastic Block Store สิ่งนี้ช่วยเร่งการประมวลผลการสืบค้นได้ถึง 2 เท่า

การอ่านประสิทธิภาพสูงของ Amazon RDS มีให้ใช้งานใน RDS สำหรับ MySQL โดยที่ MySQL ต้องเป็นเวอร์ชัน 8.0.28 ขึ้นไป และ RDS สำหรับ MariaDB โดยที่ MariaDB ต้องเป็นเวอร์ชัน 10.4.25, 10.5.16, 10.6.7 ขึ้นไป

การอ่านประสิทธิภาพสูงของ Amazon RDS มีให้ใช้งานในทุกรีเจี้ยนที่มีอินสแตนซ์ db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn และ X2iedn มีให้ใช้งาน ดูข้อมูลเพิ่มเติมได้ที่ เอกสารประกอบคลาสของอินสแตนซ์ Amazon RDS DB

ลูกค้าควรใช้ การอ่านประสิทธิภาพสูงของ Amazon RDS เมื่อมีเวิร์กโหลดที่ต้องใช้การสืบค้นที่ซับซ้อน การวิเคราะห์วัตถุประสงค์ทั่วไป หรือต้องมีกลุ่มที่ซับซ้อน การเรียงลำดับ การรวมแฮช การเชื่อมต่อที่มีโหลดสูง และ Common Table Expressions (CTE) กรณีการใช้งานเหล่านี้จะส่งผลให้มีการสร้างตารางชั่วคราวเพื่อทำให้การอ่านประสิทธิภาพสูงสามารถเร่งการประมวลผลการสืบค้นของเวิร์กโหลดให้เร็วขึ้นได้

ได้ ลูกค้าสามารถแปลงฐานข้อมูล Amazon RDS ที่มีอยู่ให้ใช้ การอ่านประสิทธิภาพสูงของ Amazon RDS โดยย้ายเวิร์กโหลดของคุณไปยังอินสแตนซ์ที่เปิดใช้งานการอ่านประสิทธิภาพสูง การอ่านประสิทธิภาพสูงยังสามารถใช้ได้ตามค่าเริ่มต้นในคลาสอินสแตนซ์ที่รองรับทั้งหมด หากคุณกำลังรันเวิร์กโหลดบนอินสแตนซ์ db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn และ X2iedn คุณก็ได้รับประโยชน์จากการอ่านประสิทธิภาพสูงอยู่แล้ว