เริ่มต้นใช้งาน AWS ฟรี

สร้างบัญชีฟรี

AWS Free Tier ประกอบด้วยสิทธิ์การใช้งานอินสแตนซ์ Micro DB 750 ชม.ต่อเดือนเป็นเวลาหนึ่งปี พื้นที่จัดเก็บข้อมูล 20 GB และการสำรองข้อมูล 20 GB กับ Amazon Relational Database Service (RDS)

ดูรายละเอียด AWS Free Tier »


ถาม: Amazon RDS คืออะไร

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

Amazon RDS จะช่วยให้คุณเข้าถึงขีดความสามารถของฐานข้อมูล MySQL, MariaDB, Oracle, SQL Server หรือ PostgreSQL ที่คุ้นเคย ซึ่งหมายความว่าโค้ด แอปพลิเคชัน และเครื่องมือที่ขณะนี้คุณใช้อยู่แล้วกับฐานข้อมูลที่มีอยู่ควรที่จะทำงานกับ Amazon RDS ได้อย่างราบรื่น Amazon RDS สามารถสำรองข้อมูลในฐานข้อมูลของคุณโดยอัตโนมัติและอัปเดตซอฟแวร์ฐานข้อมูลของคุณให้ทันกับเวอร์ชันล่าสุด คุณจะได้รับประโยชน์จากความยืดหยุ่นที่ช่วยให้สามารถปรับขนาดทรัพยากรการประมวลผลหรือความจุพื้นที่จัดเก็บที่เกี่ยวข้องกับอินสแตนซ์ฐานข้อมูลเชิงสัมพันธ์ได้อย่างง่ายดาย นอกจากนี้ Amazon RDS ยังทำให้สามารถใช้การจำลองแบบได้อย่างง่ายดายเพื่อเสริมสร้างความพร้อมใช้งานของฐานข้อมูล พัฒนาความคงทนของข้อมูล หรือปรับขนาดให้เกินกว่าข้อจำกัดความจุของอินสแตนซ์ฐานข้อมูลเดี่ยวสำหรับปริมาณงานฐานข้อมูลที่อ่านเป็นจำนวนมาก ทั้งนี้ บริการนี้จะเหมือนกันกับ Amazon Web Services ทั้งหมดคือจะไม่มีการเรียกเก็บเงินล่วงหน้า คุณเพียงต้องจ่ายค่าทรัพยากรเท่าที่คุณใช้เท่านั้น

ถาม: กลไกฐานข้อมูลเชิงสัมพันธ์ใดบ้างที่ Amazon RDS รองรับ

Amazon RDS รองรับกลไกฐานข้อมูล Amazon Aurora, MySQL, MariaDB, Oracle, SQL Server และ PostgreSQL

ถาม: Amazon RDS จะจัดการอะไรแทนฉันบ้าง

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

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

ถาม: ฉันจะเลือกใช้ Amazon RDS หรือ Amazon EC2 Relational Database AMI เมื่อใด

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

ถาม: ฉันจะเริ่มต้นใช้งาน Amazon RDS ได้อย่างไร

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

Amazon RDS เป็นส่วนหนึ่งของ AWS Free Tier เพื่อให้ลูกค้า AWS ใหม่สามารถเริ่มต้นใช้บริการฐานข้อมูลที่ได้รับการจัดการในระบบคลาวด์ได้ฟรี


ถาม: อินสแตนซ์ฐานข้อมูล (อินสแตนซ์ DB) คืออะไร

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

ถาม: ฉันจะสร้างอินสแตนซ์ DB ได้อย่างไร

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

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

ถาม: ฉันจะเข้าถึงอินสแตนซ์ DB ที่ทำงานอยู่ของฉันได้อย่างไร

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

ถาม: ฉันสามารถเรียกใช้อินสแตนซ์ DB ด้วย Amazon RDS ได้เป็นจำนวนเท่าไร

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

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

ถาม: ฉันจะสามารถเรียกใช้ฐานข้อมูลหรือแบบแผนได้เท่าใดภายในอินสแตนซ์ DB หนึ่งรายการ

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

ถาม: ฉันจะนำเข้าข้อมูลไปยังอินสแตนซ์ DB Amazon RDS ได้อย่างไร

มีวิธีการง่ายๆ หลายวิธีในการนำเข้าข้อมูลไปยัง Amazon RDS เช่น ด้วยการใช้ยูทิลิตี้ mysqldump หรือ mysqlimport สำหรับ MySQL; Data Pump, Import/Export หรือ SQL Loader สำหรับ Oracle; โปรแกรม Import/Export, Full Backup Files (.bak files) หรือ Bulk Copy Program (BCP) สำหรับ SQL Server หรือ pg_dump for PostgreSQL สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการนำเข้าและส่งออกข้อมูล โปรดดูที่ คู่มือการนำเข้าข้อมูลสำหรับ MySQL หรือ คู่มือการนำเข้าข้อมูลสำหรับ Oracle หรือ คู่มือการนำเข้าข้อมูลสำหรับ SQL Server หรือ คู่มือการนำเข้าข้อมูลสำหรับ PostgreSQL

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

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

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

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

หากระหว่างที่สร้างอินสแตนซ์ DB คุณไม่ได้ระยะเวลาการบำรุงรักษารายสัปดาห์ที่ต้องการ ระบบจะกำหนดค่าเริ่มต้นให้เป็น 30 นาที หากคุณต้องการแก้ไขระหว่างที่ระบบกำลังดำเนินการบำรุงรักษาแทนคุณอยู่ คุณสามารถทำได้โดยการแก้ไขอินสแตนซ์ DB ใน AWS Management Console, 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


ถาม: Amzon RDS รองรับกลไกฐานข้อมูลเชิงสัมพันธ์เวอร์ชันใดบ้าง

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

ถาม: Amazon RDS จะแยกระหว่างกลไก DB เวอร์ชัน “หลัก” และ “รอง” อย่างไร

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

ถาม: Amazon RDS ได้ให้แนวทางเกี่ยวกับการรองรับกลไก DB เวอร์ชันใหม่หรือไม่

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

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

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

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

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

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

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

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

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

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

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

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

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

ถาม: ฉันสามารถทดสอบอินสแตนซ์ DB ของฉันกับโปรแกรมเวอร์ชันใหม่ก่อนการอัปเกรดได้หรือไม่

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

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

ถาม: Amazon RDS ได้ให้แนวทางในการยกเลิกเวอร์ชันกลไกฐานข้อมูลที่รองรับในขณะนี้หรือไม่

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

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

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

ถาม: จะเกิดอะไรขึ้นเมื่อเวอร์ชันกลไก DB RDS ถูกยกเลิก

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

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

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


ถาม: จะมีการคิดค่าใช้จ่ายและเรียกเก็บเงินสำหรับการใช้ Amazon RDS ของฉันอย่างไร

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

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

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

ถาม: การเรียกเก็บเงินอินสแตนซ์ Amazon RDS DB ของฉันจะเริ่มและสิ้นสุดเมื่อไร

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

ถาม: อะไรคือตัวกำหนดว่าชั่วโมงใดบ้างที่เรียกเก็บเงินค่า Amazon RDS ได้

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

ถาม: จะมีการเรียกเก็บเงินสำหรับอินสแตนซ์ DB ที่หยุดทำงานอย่างไร

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

ถาม: ทำไมพื้นที่จัดเก็บข้อมูลสำรองเพิ่มเติมของฉันจึงมีราคาสูงกว่าพื้นจัดเก็บข้อมูลอินสแตนซ์ DB ที่จัดสรรไว้แล้ว

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

ถาม: ฉันจะถูกเรียกเก็บเงินสำหรับการปรับใช้อินสแตนซ์ DB หลาย AZ อย่างไร

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

  • ชั่วโมงอินเทอร์เฟซ DB แบบหลาย AZ อิงตามคลาส (เช่น db.t2.micro, db.m4.large) ของอินสแตนซ์ DB ที่ใช้ เช่นเดียวกับการใช้งานมาตรฐานใน Availability Zone เขตพื้นที่เดียว อินสแตนซ์ 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 มีอะไรบ้าง

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

ถาม: AWS Free Tier สำหรับ Amazon RDS จะเปิดให้ฉันใช้งานได้ถึงเมื่อไร

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

ถาม: ฉันสามารถเรียกใช้อินสแตนซ์ DB ภายใต้ AWS Free Usage Tier สำหรับ Amazon RDS ได้หรือไม่

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

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

ถาม: ฉันมีสิทธิ์ใช้ AWS Free Tier เพื่อเข้าถึงอินสแตนซ์ Micro DB ของ MySQL, MariaDB, PostgreSQL, Oracle และ SQL Serve เป็นเวลา 750 ชั่วโมงอินสแตนซ์สำหรับแต่ละรายการใช่หรือไม่

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

ถาม: AWS Free Tier สำหรับ Amazon RDS มีให้บริการในภูมิภาค AWS ทั้งหมดหรือไม่

AWS Free Tier สำหรับ Amazon RDS มีให้บริการในภูมิภาค AWS ทั้งหมด ยกเว้น GovCloud (สหรัฐฯ)

ถาม: จะมีการเรียกเก็บเงินอย่างไรหากการใช้ชั่วโมงอินสแตนซ์ของฉันเกินขอบเขตสิทธิประโยชน์ของ Free Tier

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


ถาม: อินสแตนซ์แบบเหมาจ่ายคืออะไร (RI)

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

ถาม: อินสแตนซ์แบบเหมาจ่ายแตกต่างจากอินสแตนซ์ DB ตามความต้องการอย่างไร

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

ถาม: ฉันจะสร้างและซื้ออินสแตนซ์แบบเหมาจ่ายได้อย่างไร

คุณสามารถซื้ออินสแตนซ์แบบเหมาจ่ายได้ที่ส่วน "อินสแตนซ์แบบเหมาจ่าย" ของ AWS Management Console สำหรับ 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, กลไก DB, ตัวเลือกหลาย AZ และรูปแบบใบอนุญาตเดียวกันภายในภูมิภาคเดียวกับอินสแตนซ์ DB ที่คุณกำลังเรียกใช้อยู่และต้องการเหมาจ่าย หากซื้อแบบเหมาจ่ายได้สำเร็จ Amazon RDS จะคิดค่าใช้จ่ายรายชั่วโมงแบบใหม่กับอินสแตนซ์ DB ที่คุณมีอยู่โดยอัตโนมัติ

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

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

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

ถาม: ฉันจะควบคุมอินสแตนซ์ DB ที่มีการเรียกเก็บเงินอัตราแบบเหมาจ่ายได้อย่างไร

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

ถาม: หากฉันปรับขนาดอินสแตนซ์ DB ขึ้นหรือลง จะเกิดอะไรขึ้นกับการเหมาจ่ายของฉัน

การเหมาจ่ายแต่ละรายการเกี่ยวข้องกับชุดของคุณลักษณะต่อไปนี้: กลไก DB คลาสอินสแตนซ์ DB ตัวเลือกการปรับใช้หลาย 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

ถาม: ฉันสามารถย้ายอินสแตนซ์แบบเหมาจ่ายจากภูมิภาคหนึ่งไปยังอีกภูมิภาคหนึ่ง หรือจาก Availability Zone หนึ่งไปยังอีกโซนหนึ่งได้หรือไม่

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

ถาม: อินสแตนซ์แบบเหมาจ่ายมีให้บริการสำหรับการปรับใช้หลาย AZ หรือไม่

ได้ เมื่อคุณเรียกใช้ DescribeReservedDBInstancesOfferings API หรือ describe-reserved-db-instances-offerings command ให้มองหาตัวเลือกหลาย AZ ที่ระบุในระหว่างการกำหนดค่าอินสแตนซ์ DB ที่มีให้ซื้อ หากคุณต้องการซื้อการเหมาจ่ายสำหรับอินสแตนซ์ DB ที่มีการจำลองระบบซิงโครนัสผ่านหลาย Availability Zone โปรดระบุข้อเสนอหนึ่งในข้อเสนอเหล่านี้ในการสั่งซื้อ PurchaseReservedDBInstancesOffering ของคุณ

ถาม: มีอินสแตนซ์แบบเหมาจ่ายสำหรับ Read Replica หรือไม่

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

ถาม: ฉันสามารถยกเลิกการเหมาจ่ายได้หรือไม่

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

ถาม: ตัวเลือกการชำระเงินมีผลกระทบต่อใบเรียกเก็บเงินของฉันอย่างไรบ้าง

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


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

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

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

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

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

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

ถาม: การกำหนดค่าฮาร์ดแวร์สำหรับพื้นที่จัดเก็บข้อมูล Amazon RDS คืออะไร

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

แต่สำหรับ SQL Server เนื่องจากการขยายพื้นที่จัดเก็บข้อมูลแบบ Stripe ที่เชื่อมต่อกับระบบปฏิบัติการ Windows Server นั้นมีข้อจำกัด Amazon RDS จึงไม่รองรับการเพิ่มพื้นที่จัดเก็บข้อมูลในปัจจุบัน

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

ถาม: อินสแตนซ์ DB ของฉันจะยังใช้งานในระหว่างที่ปรับขนาดได้หรือไม่

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

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

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

ถาม: พื้นที่จัดเก็บฐานข้อมูลสำหรับการใช้ทั่วไป (SSD) Amazon RDS คืออะไร

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

ถาม: พื้นที่จัดเก็บข้อมูล Amazon RDS Provisioned IOPS (SSD) คืออะไร

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

ถาม: พื้นที่จัดเก็บ Amazon RDS Magnetic คืออะไร

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

ถาม: ฉันจะเลือกประเภทพื้นที่จัดเก็บข้อมูล Amazon RDS อย่างไร

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

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

ถาม: IOPS ขั้นต่ำและสูงสุดที่ Amazon RDS รองรับคืออะไร

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

ถาม: ความแตกต่างระหว่างข้อมูลสำรองอัตโนมัติและ Database Snapshot คืออะไร

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

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

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

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

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

ถาม: ฉันจะต้องเปิดใช้งานข้อมูลสำรองสำหรับ DB อินสแตนซ์หรือข้อมูลสำรองดังกล่าวสามารถเปิดใช้งานโดยอัตโนมัติ

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

ถาม: หน้าต่างสำรองคืออะไร และทำไมฉันจึงต้องใช้หน้าต่างดังกล่าว ฐานข้อมูลของฉันสามารถใช้งานในช่วงหน้าต่างสำรองข้อมูลหรือไม่

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

ถาม: ข้อมูลสำรองอัตโนมัติและ Database Snapshot ของฉันมีการจัดเก็บที่ใด และฉันจะจัดการการเก็บรักษาข้อมูลได้อย่างไร

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

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

ถาม: ทำไมฉันจึงมี Database Snapshot อัตโนมัติมากกว่าจำนวนวันในช่วงเวลาการเก็บข้อมูลสำหรับอินสแตนซ์ DB ของฉัน

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

ถาม: จะเกิดอะไรขึ้นกับข้อมูลสำรองและ Database Snapshot หากฉันลบอินสแตนซ์ DB ออก

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

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


ถาม: Amazon Virtual Private Cloud (VPC) คืออะไรและทำงานกับ Amazon RDS อย่างไร

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

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

ถาม: วิธีการใช้ Amazon RDS ภายใน VPC แตกต่างจากการใช้งานบนแพลตฟอร์ม EC2-Classic (ไม่ใช่ VPC) อย่างไร

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

ถาม: กลุ่มเครือข่ายย่อย DB คืออะไร และทำไมฉันจึงต้องใช้

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

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

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

ถาม: ฉันจะสร้างอินสแตนซ์ DB Amazon RDS ใน VPC ได้อย่างไร

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

ถาม: ฉันจะควบคุมการเข้าถึงเครือข่ายไปยังอินสแตนซ์ DB ของฉันได้อย่างไร

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

ถาม: ฉันจะเชื่อมต่ออินสแตนซ์ DB RDS ใน VPC ได้อย่างไร

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

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

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

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

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

ถาม: ฉันสามารถย้ายฐานข้อมูล DB ที่มีอยู่ภายนอก VPC ลงใน VPC ได้หรือไม่

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

ถาม: ฉันสามารถย้ายอินสแตนซ์ DB ที่มีอยู่จากภายใน VPC ไปยังภายนอก VPC ได้หรือไม่

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

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

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

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

ถาม: ฉันสามารถเปลี่ยน DB Subnet Group ของอินสแตนซ์ DB ของฉันได้หรือไม่

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

ถาม: บัญชีผู้ใช้ Amazon RDS หลักคืออะไร และแตกต่างจากบัญชี AWS อย่างไร

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

ถาม: ผู้ใช้หลักของอินสแตนซ์ DB ของฉันจะได้สิทธิประโยชน์อะไรบ้าง

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

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

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

ถาม: มีอะไรที่แตกต่างเกี่ยวกับการจัดการผู้ใช้กับ Amazon RDS หรือไม่

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

ถาม: โปรแกรมที่ใช้งานบนเซิร์ฟเวอร์ในศูนย์ข้อมูลของฉันสามารถเข้าถึงฐานข้อมูล Amazon RDS ได้หรือไม่

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

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

ได้ ตัวเลือกนี้มีการรองรับสำหรับกลไก MySQL, MariaDB, SQL Server, PostgreSQL และ Oracle เท่านั้น

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

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

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

ถาม: ฉันสามารถเข้ารหัสข้อมูลในส่วนที่เหลือได้จากฐานข้อมูล Amazon RDS ของฉันหรือไม่

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

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

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

ถาม: ฉันจะควบคุมการกระทำที่ระบบและผู้ใช้ของฉันสามารถใช้ทรัพยากร RDS เฉพาะได้อย่างไร

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

ถาม: ฉันต้องการวิเคราะห์ความปลอดภัยหรือแก้ไขปัญหาเกี่ยวกับการปรับใช้ RDS ของฉัน ฉันสามารถขอประวัติการเข้าชม RDS API ทั้งหมดที่ทำไว้ในบัญชีของฉันได้หรือไม่

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

ถาม: ฉันสามารถใช้ Amazon RDS กับแอปพลิเคชันที่ต้องสอดคล้องกับ HIPAA ได้หรือไม่

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


ถาม: ฉันจะเลือกพารามิเตอร์การกำหนดค่าที่ถูกต้องสำหรับอินสแตนซ์ DB ได้อย่างไร

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

ถาม: กลุ่มพารามิเตอร์ DB มีอะไรบ้าง มีประโยชน์อย่างไร

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

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

ถาม: ฉันจะติดตามการกำหนดค่าทรัพยากร Amazon RDS ของฉันได้อย่างไร

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


ถาม: แบบจำลองประเภทใดบ้างที่ Amazon RDS รองรับและฉันควรใช้ประเภทใดและเมื่อไร

Amazon RDS มอบตัวเลือกการจำลองแบบสองประเภทที่ไม่เหมือนกันเพื่อใช้ในวัตถุประสงค์ที่แตกต่างกัน

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

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

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

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

ถาม: การเรียกใช้อินสแตนซ์ DB เป็นการปรับใช้หลาย AZ คืออะไร

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

ถาม: Availability Zone คืออะไร

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

ถาม: “หลัก” และ “สแตนด์บาย” หมายถึงอะไรในบริบทของการปรับใช้หลาย AZ

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

ถาม: ประโยชน์ของการปรับใช้หลาย AZ มีอะไรบ้าง

ประโยชน์หลักๆ ของการเรียกใช้อินสแตนซ์ 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 เป็นการปรับใช้หลาย AZ บ้างหรือไม่

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

ถาม: เมื่อเรียกใช้อินสแตนซ์ DB เป็นการปรับใช้หลาย AZ ฉันสามารถใช้สแตนด์บายเพื่ออ่านหรือเขียนการดำเนินการได้หรือไม่

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

ถาม: ฉันสามารถตั้งค่าการปรับใช้อินสแตนซ์ DB แบบหลาย AZ ได้อย่างไร

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

ถาม: จะเกิดอะไรขึ้นเมื่อฉันแปลงอินสแตนซ์ RDS จาก AZ เดียวเป็นหลาย AZ

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

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

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

ถาม: เหตุการณ์ใดจะทำให้ Amazon RDS เริ่มย้ายไปที่แบบจำลองสแตนด์บายเมื่อเกิดความล้มเหลว

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

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

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

ถาม: ฉันจะถูกเตือนหรือไม่เมื่อการเกิดข้อผิดพลาดเกิดขึ้น

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

ถาม: เกิดอะไรขึ้นระหว่างการเกิดข้อผิดพลาดแบบหลาย AZ และเกิดขึ้นนานเท่าใด

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

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

ถาม: ฉันสามารถเริ่มต้น “การเกิดข้อผิดพลาดแบบบังคับ” สำหรับการปรับใช้อินสแตนซ์ DB แบบหลาย AZ ได้หรือไม่

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

ถาม: ฉันจะควบคุม/กำหนดค่าการจำลองแบบหลาย AZ พร้อมกันได้อย่างไร

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

ถาม: สแตนด์บายของฉันจะอยู่ในภูมิภาคเดียวกันกับอินสแตนซ์หลักของฉันใช่หรือไม่

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

ถาม: ฉันสามารถดูได้หรือไม่ว่าอินสแตนซ์หลักของฉันอยู่ใน Availability Zone ใด

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

ถาม: หลังจากการเกิดข้อผิดพลาด อินสแตนซ์หลักของฉันไปอยู่ใน Availability Zone อื่นที่คนละตำแหน่งกับทรัพยากร AWS ต่างๆ ของฉัน (เช่น อินสแตนซ์ EC2) ฉันควรกังวลเกี่ยวกับเวลาแฝงหรือไม่

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

ถาม: Database Snapshot และการสำรองข้อมูลทำงานกับการปรับใช้หลาย 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 เป็น Read Replica คืออะไร

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

ถาม: ฉันควรพิจารณาใช้ Amazon RDS Read Replica เมื่อใด

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

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

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

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

ถาม: กลไกฐานข้อมูลเวอร์ชันใดที่รองรับ Amazon RDS Read Replica

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

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

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

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

ถาม: ฉันจะสามารถปรับใช้ Read Replica สำหรับอินสแตนซ์ DB ที่กำหนดได้อย่างไร

คุณสามารถสร้าง Read Replica ได้ภายในไม่กี่นาทีโดยใช้ CreateDBInstanceReadReplica API มาตรฐานหรือคลิกเพียงไม่กี่คลิกบน AWS Management Console เมื่อสร้าง Read Replica คุณสามารถระบุให้เป็น Read Replica ได้โดยระบุ SourceDBInstanceIdentifier SourceDBInstanceIdentifier คือตัวระบุอินสแตนซ์ DB ของอินสแตนซ์ DB “ต้นทาง” ซึ่งเป็นอินสแตนซ์ที่คุณต้องการจำลองแบบ เช่นเดียวกันสำหรับอินสแตนซ์ DB มาตรฐาน คุณยังสามารถระบุ Availability Zone, คลาสอินสแตนซ์ DB และหน้าต่างการบำรุงรักษาที่เลือก เวอร์ชันกลไก (เช่น PostgreSQL 9.3.5) และการแบ่งพื้นที่จัดเก็บ Read Replica มาจากอินสแตนซ์ DB ต้นทาง เมื่อคุณเริ่มต้นการสร้าง Read Replica จากนั้น Amazon RDS จะถ่ายภาพ Snapshot ของอินสแตนซ์ DB ต้นทางแล้วเริ่มการจำลองแบบ ดังนั้น คุณจะประสบกับการหยุดชะงักของ I/O สั้นๆ บนอินสแตนซ์ DB ต้นทางในขณะที่การถ่ายภาพ Snapshot เกิดขึ้น โดยปกติการหยุดชะงักของ I/O จะเกิดขึ้นนานหนึ่งนาที และจะไม่เกิดขึ้นหากอินสแตนซ์ DB ต้นทางเป็นการปรับใช้หลาย AZ (ในกรณีการปรับใช้หลาย AZ การถ่ายภาพ Snapshot จะเป็นการถ่ายภาพจากสแตนด์บาย) นอกจากนี้ Amazon RDS ยังทำงานอย่างมีประสิทธิภาพอีกด้วย (เพื่อให้สามารถเผยแพร่ได้รวดเร็ว) ดังนั้นหากคุณสร้าง Read Replica หลายรายการภายในเวลา 30 นาที Read Replica ทั้งหมดจะใช้ Snapshot ต้นทางเดียวกันเพื่อลดผลกระทบ I/O (การจำลองแบบ “ติดตาม” สำหรับ Read Replica แต่ละรายการที่จะเริ่มหลังการสร้าง)

ถาม: ฉันจะเชื่อมต่อกับ Read Replica ของฉันได้อย่างไร

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

ถาม: ฉันสามารถสร้าง Read Replica ได้กี่รายการในอินสแตนซ์ DB ต้นทางที่กำหนด

Amazon Aurora ช่วยให้คุณสามารถสร้าง Read Replica ได้สูงสุดถึง 15 รายการสำหรับคลัสเตอร์ DB ที่กำหนด

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

ถาม: ฉันสามารถสร้าง Read Replica ในภูมิภาค AWS ที่แตกต่างจากภูมิภาคของอินสแตนซ์ DB ต้นทางได้หรือไม่

ได้ RDS รองรับ Read Replica ข้ามภูมิภาค

ถาม: Amazon RDS Read Replica รองรับการจำลองแบบพร้อมกันหรือไม่

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

ถาม: ฉันสามารถ Read Replica เพื่อเพิ่มความพร้อมใช้ในการเขียนฐานข้อมูลหรือป้องกันความล้มเหลวของข้อมูลบนอินสแตนซ์ DB ต้นทางได้หรือไม่

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

ถาม: ฉันสามารถสร้าง Read Replica โดยใช้อินสแตนซ์ DB แบบหลาย AZ เป็นต้นทางได้หรือไม่

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

ถาม: ฉันสามารถทำให้ Amazon RDS Read Replica กลายเป็นการปรับใช้แบบหลาย AZ ได้หรือไม่

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

ถาม: หาก Read Replica ใช้การปรับใช้อินสแตนซ์ DB แบบหลาย AZ เป็นต้นทาง จะเกิดอะไรขึ้นหากเกิดข้อผิดพลาดแบบหลาย AZ ขึ้น

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

ถาม: ฉันสามารถสร้าง Read Replica ของ Read Replica อื่นได้หรือไม่

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

Amazon RDS สำหรับ PostgreSQL: ปัจจุบันยังไม่รองรับ Read Replica ของ Read Replica

ถาม: Read Replica ของฉันสามารถยอมรับเฉพาะการดำเนินการอ่านฐานข้อมูลเท่านั้นได้หรือไม่

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

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

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

ถาม: ฉันสามารถเลื่อนระดับ Read Replica เป็นอินสแตนซ์ DB แบบ “สแตนด์อโลน” ได้หรือไม่

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

ถาม: Read Replica ของฉันจะอัปเดตอยู่เสมอกับอินสแตนซ์ DB ต้นทางหรือไม่

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

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

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

ถาม: ฉันจะดูสถานะของ Read Replica ที่กำลังทำงานอยู่ได้อย่างไร

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

Amazon RDS ช่วยให้คุณสามารถดูได้ว่า Read Replica ล่าช้ากว่าอินสแตนซ์ DB ต้นทางของตัวเองมากน้อยแค่ไหน จำนวนวินาทีที่ Read Replica ล่าช้ากว่าต้นแบบจะถูกแสดงเป็นตัววัด Amazon CloudWatch ("Replica Lag") ซึ่งสามารถดูได้ใน AWS Management Console หรือ Amazon CloudWatch API สำหรับ Amazon RDS สำหรับ MySQL ที่มาของข้อมูลนี้มาจากที่เดียวกันกับข้อมูลที่แสดงโดยการออกคำสั่ง MySQL “Show Slave Status” มาตรฐานต่อ Read Replica Amazon RDS สำหรับ PostgreSQL คุณสามารถใช้มุมมอง pg_stat_replication บนอินสแตนซ์ DB ต้นทางเพื่อสำรวจตัววัดการจำลองแบบได้

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

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

ถาม: Read Replica ของฉันล่าช้ากว่าอินสแตนซ์ DB ต้นทางของตัวเองมาก ฉันควรทำอย่างไร

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

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

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

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

ถาม: สามารถนำ Database Snapshot หรือการสำรองข้อมูลอัตโนมัติออกจาก Read Replica ได้หรือไม่

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

ถาม: ฉันจะลบ Read Replica ของฉันได้อย่างไร จะเป็นการลบโดยอัตโนมัติหรือไม่หากอินสแตนซ์ DB ต้นทางถูกลบ

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

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

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

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

ถาม: ฉันสามารถเข้าถึงบันทึกเหตุการณ์สำหรับอินสแตนซ์ฐานข้อมูลได้โดยตรงหรือไม่

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

ถาม: Read Replica มีค่าใช้จ่ายเท่าไร การเก็บค่าบริการจะเริ่มต้นและสิ้นสุดเมื่อใด

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

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

ถาม: การรองรับสำหรับ Read Replica แตกต่างกันอย่างไรบ้างระหว่างกลไก Amazon RDS ที่รองรับคุณสมบัตินี้

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

คุณสมบัติ PostgreSQL MySQL MariaDB
Read Replica สูงสุดที่ใช้ได้ต่อหนึ่งอินสแตนซ์ DB ต้นทาง
5 5 5
วิธีการจำลองแบบ อะซิงโครนัส
เชิงกายภาพ
อะซิงโครนัส
เชิงตรรกะ
อะซิงโครนัส
เชิงตรรกะ
ต้องเปิดใช้งานการสำรองข้อมูลอัตโนมัติสำหรับการสนับสนุน Read Replica หรือไม่ ใช้ได้ ใช้ได้ ใช้ได้
เวอร์ชันกลไกที่มี Read Replica พร้อมใช้งาน 9.3.5 ขึ้นไป 5.5 ขึ้นไป 10.0 ขึ้นไป
การเลื่อนระดับ Read Replica ไปยังอินสแตนซ์ DB แบบสแตนด์อโลนใหม่ รองรับ รองรับ รองรับ
การสร้างดัชนีบน Read Replica ยังไม่รองรับ รองรับ รองรับ
การสร้างข้อมูลสำรองของ Read Replica ยังไม่รองรับ รองรับ รองรับ
การผูก Read Replica
(เช่น Read Replica ของ Read Replica)
ยังไม่รองรับ รองรับ รองรับ
Read Replica ข้ามภูมิภาค รองรับ รองรับ รองรับ
Read Replica ของการปรับใช้หลาย AZ
รองรับ รองรับ รองรับ

ถาม: Enhanced Monitoring สำหรับ RDS คืออะไร

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

ถาม: ฉันสามารถติดตามตัววัดและกระบวนการใดได้บ้างใน Enhanced Monitoring

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

ถาม: Enhanced Monitoring รองรับกลไกใดบ้าง

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

ถาม: Enhanced Monitoring รองรับอินสแตนซ์ประเภทใดบ้าง

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

ถาม: ฉันสามารถดูข้อมูลใดได้บ้างบนแดชบอร์ด RDS

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

ถาม: อินสแตนซ์ทั้งหมดในบัญชี RDS ของฉันจะแสดงตัวอย่างตัววัดที่ส่วนย่อยเดียวกันหรือไม่

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

ถาม: ฉันสามารถย้อนดูตัววัดในอดีตบน RDS Console ได้มากน้อยเพียงใด

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

ถาม: ฉันจะสามารถดูตัววัดที่สร้างโดย RDS Enhanced Monitoring ใน CloudWatch ได้อย่างไร

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

ถาม: ฉันควรใช้ CloudWatch แทนแดชบอร์ด RDS Console เมื่อใด

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

ถาม: ฉันสามารถตั้งค่าสัญญาณเตือนและการแจ้งเตือนตามตัววัดแบบเฉพาะเจาะจงได้หรือไม่

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

ถาม: ฉันจะผนวกรวม Enhanced Monitoring กับเครื่องมือที่ฉันใช้งานอยู่ในปัจจุบันได้อย่างไร

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

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

ถาม: ฉันจะสามารถลบข้อมูลในอดีตได้อย่างไร

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

ถาม: Enhanced Monitoring จะส่งผลอย่างไรต่อค่าใช้จ่ายรายเดือนของฉัน

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

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

ส่วนประกอบ

60 วินาที

30 วินาที

15 วินาที

10 วินาที

5 วินาที

1 วินาที

ข้อมูลที่ถูกนำเข้าในบันทึก* CloudWatch (GB ต่อเดือน)

0.27

0.53

1.07

1.61

3.21

16.07