ข้อมูลทั่วไป

Amazon Aurora คืออะไร

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

Aurora มีระบบจัดเก็บข้อมูลแบบกระจาย ทนทานต่อข้อผิดพลาด และซ่อมแซมตัวเองได้ ซึ่งแยกออกจากทรัพยากรการประมวลผลและปรับขนาดอัตโนมัติสูงสุด 128 TiB ต่ออินสแตนซ์ฐานข้อมูล โดยมอบประสิทธิภาพและความพร้อมใช้งานสูงที่มีแบบจำลองการอ่านที่มีเวลาแฝงต่ำสูงสุด 15 แบบ การกู้ข้อมูล ณ เวลาใดเวลาหนึ่ง การสำรองข้อมูลอย่างต่อเนื่องไปยัง Amazon Simple Storage Service (Amazon S3) และมีการจำลองทั่วทั้ง Availability Zone (AZ) สามแห่ง

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

สามารถใช้ Amazon Aurora กับ MySQL ได้หรือไม่

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

สามารถดูข้อมูลความเข้ากันได้ของรุ่นปัจจุบันของ Amazon Aurora และ MySQL ได้ในเอกสารประกอบ

สามารถใช้ Amazon Aurora กับ PostgreSQL ได้หรือไม่

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

สามารถดูข้อมูลความเข้ากันได้ของรุ่นปัจจุบันของ Amazon Aurora และ PostgreSQL ได้ในเอกสารประกอบ

Amazon รองรับ Aurora PostgreSQL อย่างเต็มที่และส่วนขยายทั้งหมดที่มีใน Aurora หากต้องการการสนับสนุนสำหรับ Aurora PostgreSQL โปรดติดต่อ AWS Support หากมีบัญชี AWS Premium Support ที่ใช้งานอยู่ สามารถติดต่อ AWS Premium Support สำหรับปัญหาเฉพาะของ Amazon Aurora

ฉันจะเริ่มต้นใช้งาน Aurora อย่างไร

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

Aurora พร้อมให้บริการใน AWS Region ใดบ้าง

คุณสามารถดูรีเจี้ยนที่พร้อมให้บริการสำหรับ Aurora ได้ที่นี่

ฉันจะย้ายเข้าและออกระหว่าง MySQL และAurora ได้อย่างไร

หากคุณต้องการย้ายเข้าและออกระหว่าง MySQL และ Aurora มีหลายวิธีให้เลือก:

  • คุณสามารถใช้ยูทิลิตี้ mysqldump มาตรฐานเพื่อส่งออกและนำเข้าข้อมูลจาก MySQL และการใช้งาน mysqlimport เพื่อนำข้อมูลเข้าและออกจาก Aurora
  • คุณยังสามารถใช้คุณสมบัติการย้ายข้อมูล DB Snapshot ของ Amazon RDS เพื่อย้ายข้อมูล Amazon RDS สำหรับ MySQL DB Snapshot ไปยัง Aurora โดยใช้คอนโซลการจัดการของ AWS

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

ฉันจะย้ายเข้าและออกระหว่าง PostgreSQL และAurora ได้อย่างไร

หากคุณต้องการย้ายเข้าและออกระหว่าง PostgreSQL และ Aurora มีหลายวิธีให้เลือก:

  • คุณสามารถใช้ยูทิลิตี้ pg_dump มาตรฐานเพื่อส่งออกและนำเข้าข้อมูลจาก PostgreSQL และการใช้งาน pg_restore เพื่อนำข้อมูลเข้าและออกจาก Aurora
  • คุณยังสามารถใช้คุณสมบัติการย้ายข้อมูล DB Snapshot ของ RDS เพื่อย้ายข้อมูล Amazon RDS สำหรับ PostgreSQL DB Snapshot ไปยัง Aurora โดยใช้คอนโซลการจัดการของ AWS

การย้ายไปยัง Aurora สำหรับลูกค้าส่วนใหญ่จะเสร็จสมบูรณ์ภายในเวลาไม่ถึงชั่วโมง แม้ว่าระยะเวลาจะขึ้นอยู่กับรูปแบบและขนาดชุดข้อมูล

หากต้องการย้ายฐานข้อมูล SQL Server ไปยัง Amazon Aurora รุ่นที่รองรับ PostgreSQL อย่างสมบูรณ์แบบ คุณสามารถใช้ Babelfish สำหรับ Aurora PostgreSQL แอปพลิเคชันจะทำงานโดยไม่มีการเปลี่ยนแปลงใดๆ ดูเอกสารประกอบ Babelfish สำหรับข้อมูลเพิ่มเติม

จำเป็นต้องเปลี่ยนไคลเอนต์ไดรเวอร์เพื่อใช้ Amazon Aurora รุ่นที่รองรับ PostgreSQL ได้หรือไม่

ไม่ต้อง Amazon Aurora สามารถใช้งานได้กับไดรเวอร์ฐานข้อมูล PostgreSQL มาตรฐาน

ประสิทธิภาพ

“มีประสิทธิภาพสูงกว่า MySQL 5 เท่า" หมายความว่าอย่างไร

Amazon Aurora มีประสิทธิภาพสูงกว่า MySQL อย่างมีนัยสำคัญโดยการผสานอย่างแน่นหนาของโปรแกรมฐานข้อมูลรวมกับชั้นพื้นที่จัดเก็บเสมือนที่ใช้ SSD ที่สร้างมาสำหรับเวิร์กโหลดของฐานข้อมูล ลดการเขียนไปยังระบบพื้นที่จัดเก็บ ลดความขัดแย้งของล็อก และขจัดความล่าช้าที่เกิดจากเธรดประมวลผลฐานข้อมูล

การทดสอบของเราร่วมกับ SysBench บนอินสแตนซ์ r3.8xlarge แสดงให้เห็นว่า Amazon Aurora ส่งมอบกว่า 500,000 SELECT/วินาที และ 100,000 UPDATE/วินาที ซึ่งสูงกว่า MySQL ที่เรียกใช้เกณฑ์มาตรฐานบนฮาร์ดแวร์เดียวกันถึงห้าเท่า ดูคำแนะนำอย่างละเอียดเกี่ยวกับเกณฑ์มาตรฐานนี้รวมทั้งวิธีจำลองด้วยตนเองในคู่มือการสร้างเกณฑ์มาตรฐานด้านประสิทธิภาพของ Amazon Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้

“มีประสิทธิภาพสูงกว่า PostgreSQL สามเท่า" หมายความว่าอย่างไร

Amazon Aurora มีประสิทธิภาพสูงกว่า PostgreSQL อย่างมีนัยสำคัญโดยการผสานอย่างแน่นหนาของโปรแกรมฐานข้อมูลรวมกับชั้นพื้นที่จัดเก็บเสมือนที่ใช้ SSD ที่สร้างมาสำหรับเวิร์กโหลดของฐานข้อมูล ช่วยลดความขัดแย้งของล็อกและความล่าช้าที่เกิดจากเธรดประมวลผลฐานข้อมูล

การทดสอบของเราร่วมกับ SysBench บนอินสแตนซ์ r4.16xlarge แสดงให้เห็นว่า Amazon Aurora ส่งมอบจำนวน SELECT/วินาที และ UPDATE/วินาที สูงกว่า PostgreSQL ที่เรียกใช้เกณฑ์มาตรฐานบนฮาร์ดแวร์เดียวกัน ดูคำแนะนำอย่างละเอียดเกี่ยวกับเกณฑ์มาตรฐานนี้รวมทั้งวิธีจำลองด้วยตนเองในการสร้างเกณฑ์มาตรฐานด้านประสิทธิภาพของ Amazon Aurora รุ่นที่ใช้งานร่วมกับ PostgreSQL ได้

จะปรับเวิร์กโหลดของฐานข้อมูลให้เหมาะสมกับ Amazon Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้อย่างไร

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

จะปรับเวิร์กโหลดของฐานข้อมูลให้เหมาะสมกับ Amazon Aurora รุ่นที่ใช้งานร่วมกับ PostgreSQL ได้อย่างไร

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

การเรียกเก็บเงิน

Aurora มีค่าใช้จ่ายเท่าไหร่

ดูหน้าราคา Aurora เพื่อดูข้อมูลเกี่ยวกับราคาปัจจุบัน

Aurora เข้าร่วม AWS Free Tier หรือไม่

ขณะนี้ยังไม่มีข้อเสนอของ AWS Free Tier สําหรับ Aurora อย่างไรก็ตาม Aurora จะจัดเก็บข้อมูลของคุณแบบถาวรทั่วทั้ง Availability Zone สามแห่งในรีเจี้ยน และเรียกเก็บค่าบริการสําหรับสําเนาข้อมูลเดียวเท่านั้น คุณจะไม่ถูกเรียกเก็บค่าบริการสำหรับการสำรองข้อมูลสูงสุด 100% ของขนาดคลัสเตอร์ฐานข้อมูลของคุณ คุณจะไม่ถูกเรียกเก็บค่าบริการสําหรับสแนปช็อตในระยะเวลาการเก็บรักษาข้อมูลสํารองที่คุณได้กําหนดค่าไว้สําหรับคลัสเตอร์ฐานข้อมูลของคุณ

Aurora จําลองข้อมูลของฉันทั่วทั้ง Availability Zone สามแห่ง หมายความว่าราคาพื้นที่เก็บข้อมูลจริงของฉันจะอยู่ที่สามหรือหกเท่าของราคาที่แสดงบนหน้าราคาใช่หรือไม่

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

การดำเนินการ I/O ใน Aurora คืออะไร และมีวิธีการคำนวณอย่างไร

การดำเนินการ I/O คือการทำงานของอินพุต/เอาท์พุตที่กลไกฐานข้อมูล Aurora กับชั้นพื้นที่เก็บข้อมูลเสมือนที่ใช้ SSD การดำเนินการอ่านหน้าของฐานข้อมูลทุกครั้งจะนับเป็นหนึ่ง I/O
กลไกฐานข้อมูล Aurora จะออกคำสั่งอ่านกับชั้นพื้นที่เก็บข้อมูลเพื่อดึงข้อมูลหน้าฐานข้อมูลที่ไม่ได้อยู่ในแคชหน่วยความจำ:

  • หากหน่วยความจำหรือแคชสามารถใช้ในการรับส่งข้อมูลการสืบค้นทั้งหมดได้ จะไม่ถูกเรียกเก็บค่าบริการในเรียกข้อมูลจากหน้าข้อมูลใดๆ ในหน่วยความจำ
  • หากการรับส่งข้อมูลการสืบค้นของคุณไม่สามารถให้บริการได้ทั้งหมดจากหน่วยความจำ คุณจะถูกเรียกเก็บเงินสำหรับหน้าข้อมูลใด ๆ ที่จำเป็นต้องดึงข้อมูลจากที่จัดเก็บ
    หน้าฐานข้อมูลแต่ละหน้ามี 16 KB สำหรับ Amazon Aurora รุ่นที่รองรับ MySQL และ 8 KB สำหรับ Aurora รุ่นที่รองรับ PostgreSQL

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

การดำเนินการเขียน I/O จะนับเป็นหน่วย 4 KB ตัวอย่างเช่น ระเบียนบันทึก 1,024 ไบต์จะนับเป็นการดำเนินการเขียนหนึ่ง I/O อย่างไรก็ตาม หากระเบียนบันทึกมีขนาดใหญ่กว่า 4 KB จำเป็นต้องมีการดำเนินการเขียนมากกว่าหนึ่ง I/O เพื่อให้ระเบียนบันทึกคงอยู่

กลไกฐานข้อมูล Aurora อาจจัดกลุ่มการดำเนินการเขียนที่เกิดขึ้นพร้อมกันที่มีระเบียนบันทึกน้อยกว่า 4 KB รวมกันได้เพื่อปรับการใช้งาน I/O ให้เหมาะสม ไม่เหมือนกับโปรแกรมฐานข้อมูลแบบเก่า Aurora จะไม่ไล่หน้าข้อมูลที่นำไปใช้งานไม่ได้ไปยังพื้นที่จัดเก็บเป็นอันขาด

สามารถดูได้ว่าอินสแตนซ์ Aurora ใช้คำขอ I/O ไปเท่าไรแล้ว โดยไปที่ คอนโซลการจัดการของ AWS หากต้องการดูการใช้งาน I/O ให้ไปที่ส่วน Amazon RDS ของคอนโซล ดูที่รายการอินสแตนซ์ เลือกอินสแตนซ์ Aurora จากนั้นดูที่ตัวชี้วัด "VolumeReadIOPs" (การดำเนินการอ่านที่มีการเรียกเก็บค่าบริการ) และ "VolumeWriteIOPs" (การดำเนินการเขียนที่มีการเรียกเก็บค่าบริการ) ในส่วนการติดตามตรวจสอบ

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับราคาของการดําเนินการ I/O โปรดดูหน้าราคา Aurora คุณจะถูกเรียกเก็บค่าบริการสําหรับการดําเนินการอ่านและการเขียน I/O เมื่อคุณกําหนดค่าคลัสเตอร์ฐานข้อมูลของคุณเป็นการกําหนดค่า Aurora Standard คุณจะไม่ถูกเรียกเก็บค่าบริการสําหรับการดําเนินการอ่านและการเขียน I/O เมื่อคุณกําหนดค่าคลัสเตอร์ฐานข้อมูลของคุณเป็น Amazon Aurora I/O-Optimized

Aurora Standard และ Aurora I/O-Optimized คืออะไร

Aurora มอบความยืดหยุ่นในการเพิ่มประสิทธิภาพการใช้จ่ายฐานข้อมูลของคุณโดยเลือกตัวเลือกการกําหนดค่าสองแบบตามความต้องการด้านการประเมินประสิทธิภาพต่อราคาและการคาดการณ์ราคาของคุณ ตัวเลือกการกําหนดค่าสองแบบคือ Aurora Standard และ Aurora I/O-Optimized ตัวเลือกทั้งสองไม่จําเป็นต้องใช้ I/O ล่วงหน้าหรือพื้นที่เก็บข้อมูลที่จัดสรรไว้ และทั้งสองตัวเลือกสามารถปรับขนาดการดําเนินการ I/O เพื่อรองรับแอปพลิเคชันที่มีความต้องการมากที่สุดของคุณ

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

Aurora I/O-Optimized คือการกําหนดค่าคลัสเตอร์ฐานข้อมูลที่มอบการประเมินค่าประสิทธิภาพต่อราคาที่ดีขึ้นสําหรับแอปพลิเคชันที่ใช้ I/O จำนวนมาก เช่น ระบบประมวลผลการชําระเงิน ระบบอีคอมเมิร์ซ และแอปพลิเคชันด้านการเงิน นอกจากนี้ หากค่าใช้จ่าย I/O ของคุณเกิน 25% ของค่าใช้จ่ายฐานข้อมูล Aurora รวม คุณสามารถประหยัดค่าใช้จ่ายสูงสุด 40% สำหรับเวิร์กโหลดที่มีการใช้งาน I/O จำนวนมากด้วย Aurora ที่ปรับ I/O ให้เหมาะสม Aurora I/O-Optimized มอบราคาที่คาดการณ์ได้สําหรับแอปพลิเคชันทั้งหมด เนื่องจากไม่มีค่าใช้จ่ายสําหรับการดําเนินการอ่านและการเขียน I/O ทําให้การกําหนดค่านี้เหมาะสําหรับเวิร์กโหลดที่มีความแปรปรวนของ I/O สูง

ฉันควรใช้ Aurora I/O-Optimized เมื่อใด

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

ฉันจะย้ายคลัสเตอร์ฐานข้อมูลที่มีอยู่เพื่อใช้ Aurora I/O-Optimized ได้อย่างไร

คุณสามารถใช้ประสบการณ์ในคลิกเดียวที่มีอยู่ในคอนโซลการจัดการของ AWS เพื่อเปลี่ยนประเภทพื้นที่เก็บข้อมูลของคลัสเตอร์ฐานข้อมูลที่มีอยู่ของคุณให้เป็น Aurora I/O-Optimized ได้ คุณยังสามารถเรียกดำเนินการ AWS Command Line Interface (AWS CLI) หรือ AWS SDK เพื่อทําการเปลี่ยนแปลงนี้ได้

ฉันสามารถสลับไปมาระหว่างการกําหนดค่า Aurora I/O-Optimized และ Aurora Standard ได้หรือไม่

คุณสามารถสลับคลัสเตอร์ฐานข้อมูลที่มีอยู่ทุก 30 วันเป็น Aurora I/O-Optimized ได้ คุณสามารถสลับกลับไปใช้ Aurora Standard ได้ตลอดเวลา

Aurora I/O-Optimized ทํางานร่วมกับ Reserved Instance ได้หรือไม่

ได้ Aurora I/O-Optimized ทํางานร่วมกับ Reserved Instance ของ Aurora ที่มีอยู่ได้ Aurora จะพิจารณาความแตกต่างของราคาระหว่าง Aurora Standard และ Aurora I/O-Optimized ด้วย Reserved Instance โดยอัตโนมัติ เมื่อใช้ส่วนลด Reserved Instance กับ Aurora I/O-Optimized คุณสามารถประหยัดค่าใช้จ่าย I/O ของคุณได้มากขึ้น

ราคาของการติดตามย้อนหลัง, สแนปช็อต, ส่งออก หรือการสํารองข้อมูลอย่างต่อเนื่องเปลี่ยนแปลงตาม Aurora I/O-Optimized หรือไม่

ไม่มีการเปลี่ยนแปลงราคาของการติดตามย้อนหลัง, สแนปช็อต, ส่งออก หรือการสํารองข้อมูลอย่างต่อเนื่องตาม Aurora I/O-Optimized

ฉันยังต้องชำระเงินสําหรับการดําเนินการ I/O ที่จําเป็นสําหรับการจําลองข้อมูลข้ามรีเจี้ยนด้วยฐานข้อมูลทั่วโลกของ Aurora ที่ใช้ Aurora I/O-Optimized หรือไม่

ใช่ ค่าบริการสําหรับการดําเนินการ I/O ที่จําเป็นในการจำลองข้อมูลข้ามรีเจี้ยนจะยังคงมีผลบังคับใช้ต่อไป Aurora I/O-Optimized ไม่คิดค่าบริการสําหรับการดําเนินการอ่านและการเขียน I/O ซึ่งแตกต่างจากการจําลองข้อมูล

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

ไม่มีค่าใช้จ่ายเพิ่มเติมสำหรับการอ่านประสิทธิภาพสูงของ Amazon Aurora สำหรับ Aurora PostgreSQL นอกเหนือจากราคาของอินสแตนซ์ R6id ที่ใช้ Intel และ R6gd ที่ใช้ Graviton สําหรับข้อมูลเพิ่มเติม โปรดไปที่หน้าราคา Aurora

ฮาร์ดแวร์และการปรับขนาด

ฐานข้อมูล Amazon Aurora มีขีดจำกัดของพื้นที่จัดเก็บต่ำสุดและสูงสุดเท่าใด

พื้นที่จัดเก็บต่ำสุดมีขนาด 10 GB ตามการใช้งานฐานข้อมูล พื้นที่จัดเก็บ Amazon Aurora จะเติบโตโดยอัตโนมัติสูงสุด 128 TB โดยเพิ่มขึ้นทีละ 10 GB โดยไม่มีผลกระทบต่อประสิทธิภาพของฐานข้อมูล โดยไม่จำเป็นต้องจัดเตรียมพื้นที่จัดเก็บไว้ล่วงหน้า

จะปรับขนาดทรัพยากรการประมวลผลที่เชื่อมโยงกับอินสแตนซ์ Amazon Aurora DB ได้อย่างไร

มีสองวิธีในการปรับขนาดทรัพยากรการประมวลผลที่เกี่ยวข้องกับอินสแตนซ์ Amazon Aurora DB – ผ่าน Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ และผ่านการปรับด้วยตนเอง

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

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

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

การสำรองและการกู้คืนข้อมูล

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

การสำรองข้อมูลอัตโนมัติจะถูกเปิดใช้งานตลอดเวลาบนอินสแตนซ์ Amazon Aurora DB การสำรองข้อมูลจะไม่ส่งผลต่อประสิทธิภาพของฐานข้อมูล

จะใช้ Database Snapshot และเก็บไว้นานตามต้องการได้หรือไม่

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

หากฐานข้อมูลล้มเหลว จะกู้คืนข้อมูลอย่างไร

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

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

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

จะแชร์สแน็ปช็อตกับบัญชี AWS อื่นได้หรือไม่

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

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

จะถูกเรียกเก็บเงินค่าสแนปช็อตที่แชร์หรือไม่

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

จะแชร์สแนปช็อตโดยอัตโนมัติได้หรือไม่

เราไม่รองรับการแชร์ฐานข้อมูลสแนปช็อตอัตโนมัติ หากต้องการแชร์สแนปช็อตโดยอัตโนมัติ ต้องสร้างสำเนาสแนปช็อต จากนั้นแชร์สำเนานั้น

สามารถแชร์สแนปช็อตได้กับกี่บัญชี

คุณสามารถแชร์สแนปช็อตด้วยตนเองกับ ID บัญชี AWS ได้ถึง 20 บัญชี หากคุณต้องการแชร์สแนปช็อตกับบัญชีต่างๆ มากกว่า 20 บัญชี คุณสามารถแชร์สแนปช็อตแบบสาธารณะ หรือติดต่อฝ่ายสนับสนุนเพื่อขอให้เพิ่มโควต้าได้

จะแชร์สแนปช็อต Aurora ได้ในภูมิภาคใดบ้าง

แชร์สแนปช็อต Aurora ได้ในทุก AWS Region ที่มีบริการ Aurora

จะแชร์สแนปช็อต Aurora ระหว่างภูมิภาคได้หรือไม่

ไม่ได้ เฉพาะบัญชีที่อยู่ในเขตเดียวกันกับบัญชีที่แชร์สแนปช็อตนั้นเท่านั้นที่เข้าถึงสแนปช็อตที่คุณแชร์ได้

ฉันจะแชร์สแนปช็อต Aurora ที่ถูกเข้ารหัสได้หรือไม่

ได้ คุณสามารถแชร์สแนปช็อต Aurora ที่ถูกเข้ารหัสได้

ความพร้อมใช้งานและการจำลองสูง

Amazon Aurora ปรับปรุงความทนทานต่อความเสียหายของฐานข้อมูลสำหรับความล้มเหลวของดิสก์ได้อย่างไร

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

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

Aurora ช่วยปรับปรุงเวลาในการกู้คืนหลังฐานข้อมูลล้มเหลวได้อย่างไร

ต่างจากฐานข้อมูลอื่นๆ หลังจากฐานข้อมูลล้มเหลว Amazon Aurora ไม่จำเป็นต้องเล่นข้อมูลบันทึกการทำซ้ำจากจุดตรวจสอบฐานข้อมูลล่าสุด (ปกติแล้ว 5 นาที) และยืนยันว่าได้นำการเปลี่ยนแปลงทั้งหมดไปใช้แล้วก่อนที่จะทำให้ฐานข้อมูลพร้อมดำเนินงาน วิธีนี้จะช่วยลดเวลาเริ่มฐานข้อมูลใหม่ให้เหลือน้อยกว่า 60 วินาทีในกรณีส่วนใหญ่ได้

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

Aurora รองรับแบบจำลองประเภทใด

Amazon Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้และ Amazon Aurora รุ่นที่ใช้งานร่วมกับ PostgreSQL ได้รองรับ Amazon Aurora Replicas ซึ่งมีปริมาณพื้นฐานเหมือนกับอินสแตนซ์หลักใน AWS Region เดียวกัน Amazon Aurora Replicas ทั้งหมดจะสามารถดูการอัปเดตที่บัญชีหลักสร้างไว้ได้

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

เราสามารถผสมผสานแบบจำลองสองประเภทนี้ตามความต้องการของแอปพลิเคชันของคุณได้

คุณสมบัติ Amazon Aurora Replicas
MySQL Replicas
จำนวนแบบจำลอง สูงสุด 15 สูงสุด 5
ประเภทการจำลอง อะซิงโครนัส (มิลลิวินาที) อะซิงโครนัส (วินาที)
ผลกระทบด้านประสิทธิภาพต่อหลัก ต่ำ สูง
สถานที่ตั้งของ Replica ในภูมิภาค
ข้ามภูมิภาค
ดำเนินการเป็นเป้าหมายการเปลี่ยนระบบ ใช่ (ไม่มีการสูญเสียข้อมูล) ใช่ (อาจมีข้อมูลสูญเสียหลายนาที)
การเปลี่ยนระบบโดยอัตโนมัติ ใช้ได้ ใช้ไม่ได้
รองรับความล่าช้าในการจำลองตามที่ผู้ใช้กำหนด ใช้ไม่ได้ ใช้ได้
รองรับข้อมูลหรือ Schema อื่นเมื่อเทียบกับหลัก ใช้ไม่ได้ ใช้ได้

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

สามารถใช้แบบจำลองข้ามภูมิภาคด้วย Amazon Aurora ได้หรือไม่

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

สำหรับการอ่านทั่วโลกที่มีเวลาแฝงต่ำและการกู้คืนข้อมูลหลังภัยพิบัติ เราขอแนะนำให้ใช้ Amazon Aurora Global Database
Aurora สนับสนุนการจำลองแบบมีตรรกะแบบเนทีฟในแต่ละกลไกฐานข้อมูล (บินล็อกสำหรับ MySQL และสล็อตการจำลอง PostgreSQL สำหรับ PostgreSQL) ดังนั้นจึงจำลองไปยังฐานข้อมูล Aurora และฐานข้อมูลที่ไม่ใช่ Aurora ได้แม้กระทั่งแบบข้ามภูมิภาค

Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้ยังมีคุณสมบัติจำลองการอ่านข้ามรีเจี้ยนแบบมีตรรกะที่ใช้ง่ายซึ่งรองรับรีเจี้ยนรองของ AWS ถึงห้าแห่งด้วยกัน มันขึ้นอยู่กับการจำลองแบบ binlog ของ MySQL แบบเธรดเดียว ดังนั้นความล่าช้าในการจำลองแบบจะได้รับอิทธิพลจากอัตราการเปลี่ยนแปลง/การใช้และความล่าช้าในการสื่อสารเครือข่ายระหว่างภูมิภาคเฉพาะที่เลือก

ฉันสามารถสร้าง Aurora Read Replicas บนคลัสเตอร์แบบจำลองข้ามภูมิภาคได้หรือไม่

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

จะสามารถเปลี่ยนระบบแอปพลิเคชันจากแบบหลักไปเป็นแบบจำลองข้ามภูมิภาคได้หรือไม่

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

ด้วยฐานข้อมูลทั่วโลกของ Amazon Aurora สามารถเลื่อนภูมิภาครองขึ้นเพื่ออ่าน/เขียนเวิร์กโหลดทั้งหมดได้ภายในเวลาไม่ถึงนาที

สามารถจัดลำดับความสำคัญของแบบจำลองนั้นๆ ให้เป็นเป้าหมายการใช้ระบบสำรองเพื่อกู้คืนข้อมูลแบบจำลองอื่นๆ ได้หรือไม่

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

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

จะแก้ไขชั้นลำดับความสำคัญของอินสแตนซ์หลังสร้างแล้วได้หรือไม่

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

ฉันจะป้องกันไม่ให้แบบจำลองบางตัวเลื่อนระดับเป็นอินสแตนซ์หลักได้หรือไม่

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

จะปรับปรุงความพร้อมใช้งานของฐานข้อมูล Amazon Aurora เดียวได้อย่างไร

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

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

จะเกิดอะไรขึ้นระหว่างการเปลี่ยนระบบและจะเกิดขึ้นนานเท่าใด

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

  • หากคุณมี Aurora Replica ใน AZ เดียวกันหรือต่างกันขณะกำลังเปลี่ยนระบบ Aurora จะพลิก Canonical Name Record (CNAME) สำหรับอินสแตนซ์ DB ของคุณไปยังจุดที่แบบจำลองสมบูรณ์ ซึ่งได้รับการเลื่อนระดับให้เป็นอินสแตนซ์ใหม่แทน โดยทั่วไปแล้วตั้งแต่ต้นจนจบ การใช้ระบบสำรองเพื่อกู้คืนข้อมูลจะใช้เวลาไม่เกิน 30 วินาที หากต้องการความยืดหยุ่นที่ดีขึ้นและการใช้ระบบสำรองเพื่อกู้คืนข้อมูลที่เร็วขึ้น ให้พิจารณาใช้พร็อกซีของ Amazon RDS ซึ่งจะเชื่อมต่อกับอินสแตนซ์ DB ของการใช้ระบบสำรองเพื่อกู้คืนข้อมูลโดยอัตโนมัติในขณะที่ยังคงรักษาการเชื่อมต่อแอปพลิเคชันไว้ พร็อกซีทําให้การใช้ระบบสำรองเพื่อกู้คืนข้อมูลโปร่งใสสําหรับแอปพลิเคชันของคุณและลดเวลาการใช้ระบบสำรองเพื่อกู้คืนข้อมูลสูงสุด 66%
  • หากคุณกำลังเรียกใช้ Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v1 และอินสแตนซ์ DB หรือ AZ แล้วไม่พร้อมใช้งาน Aurora จะสร้างอินสแตนซ์ DB ขึ้นใหม่ใน AZ ที่ต่างกัน Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v2 ทํางานเหมือนกับจัดสรรไว้สําหรับการใช้ระบบสำรองเพื่อกู้คืนข้อมูลและคุณสมบัติความพร้อมใช้งานสูงอื่นๆ สําหรับข้อมูลเพิ่มเติม โปรดดูAurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v2 และความพร้อมใช้งานสูง 
  • หากคุณไม่มี Aurora Replica (เช่น อินสแตนซ์เดียว) และไม่ได้กำลังเรียกใช้ Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ Aurora จะพยายามสร้างอินสแตนซ์ DB ใหม่ใน Availability Zone เดียวกันให้เป็นอินสแตนซ์เดิม การแทนที่อินสแตนซ์เดิมนี้จะดำเนินการโดยพยายามอย่างเต็มที่ซึ่งอาจไม่สำเร็จ ตัวอย่างเช่น ในกรณีที่มีปัญหาที่ส่งผลอย่างกว้างขวางต่อ Availability Zone

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

หากมีฐานข้อมูลหลักและ Amazon Aurora Replica กำลังรับส่งข้อมูลการอ่านและการใช้ระบบสำรองเพื่อกู้คืนข้อมูลขึ้นจะเกิดอะไรขึ้น

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

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

แบบจำลองจะมีความล่าช้ากว่าอินสแตนซ์หลักมากเท่าใด

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

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

สามารถตั้งค่าการจำลองแบบระหว่างฐานข้อมูล Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้กับฐานข้อมูล MySQL ภายนอกได้หรือไม่

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

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

ฐานข้อมูลทั่วโลกของ Amazon Aurora คืออะไร

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

ฉันจะสร้างฐานข้อมูลทั่วโลกของ Amazon Aurora ได้อย่างไร

คุณสามารถสร้างฐานข้อมูลทั่วโลกของ Amazon Aurora ได้ด้วยการคลิกเพียงไม่กี่ครั้งใน Amazon RDS Console หรือใช้ AWS Software Development Kit (SDK) หรือ AWS Command-Line Interface (CLI) โดยคุณจำเป็นต้องจัดเตรียมอินสแตนซ์อย่างน้อยหนึ่งอินสแตนซ์ต่อภูมิภาคในฐานข้อมูลทั่วโลกของ Amazon Aurora ของคุณ

ฐานข้อมูลทั่วโลกของ Amazon Aurora มีภูมิภาครองได้กี่แห่ง

คุณสามารถสร้างภูมิภาครองสำหรับฐานข้อมูลทั่วโลกของ Amazon Aurora ได้สูงสุดห้าแห่ง

ถ้าฉันใช้ฐานข้อมูลทั่วโลกของ Amazon Aurora ฉันยังจะสามารถใช้การจำลองแบบมีตรรกะ (บินล็อก) บนฐานข้อมูลหลักได้หรือไม่

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

Aurora จะเปลี่ยนระบบไปยังภูมิภาครองของฐานข้อมูลทั่วโลกของ Amazon Aurora โดยอัตโนมัติหรือไม่

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

การรักษาความปลอดภัย

ฉันสามารถใช้ Amazon Aurora ใน Amazon Virtual Private Cloud (Amazon VPC) ได้หรือไม่

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

Amazon Aurora เข้ารหัสข้อมูลที่อยู่ระหว่างการโอนย้ายและไม่ได้ใช้งานหรือไม่

ได้ Amazon Aurora จะใช้ SSL (AES-256) เพื่อรักษาความปลอดภัยการเชื่อมต่อระหว่างอินสแตนซ์ฐานข้อมูลและแอปพลิเคชัน Amazon Aurora ช่วยให้สามารถเข้ารหัสฐานข้อมูลได้โดยใช้รหัสที่ตั้งผ่าน AWS Key Management Service (AWS KMS)

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

จะเข้ารหัสฐานข้อมูลที่ไม่ได้เข้ารหัสได้หรือไม่

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

ฉันจะเข้าถึงฐานข้อมูล Amazon Aurora ได้อย่างไร

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

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

ได้ Aurora รุ่นที่เข้ากันได้กับ MySQL และ PostgreSQL นั้นมีคุณสมบัติตรงตาม HIPAA คุณสามารถใช้เพื่อสร้างแอปพลิเคชันที่สอดคล้องกับ HIPAA และจัดเก็บข้อมูลที่เกี่ยวข้องกับการดูแลสุขภาพ รวมถึงข้อมูลสุขภาพที่ได้รับการคุ้มครอง (PHI) ภายใต้ Business Associate Addendum (BAA) กับ AWS ได้ หากคุณได้เข้าสู่ BAA ด้วย AWS อยู่แล้วก็ไม่จำเป็นต้องดำเนินการใดๆ เพิ่มเติมเพื่อเริ่มใช้บริการเหล่านี้ในบริการในบัญชีที่ครอบคลุมโดย BAA ของคุณ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้ AWS เพื่อสร้างแอปพลิเคชันที่ปฏิบัติตามข้อกำหนด โปรดดูที่ผู้ให้บริการด้านการดูแลสุขภาพ

จะเข้าไปดูรายการช่องโหว่และช่องโหว่ที่เปิดเผยสู่สาธารณะแล้ว (CVE) สำหรับช่องโหว่ด้านความมั่นคงปลอดภัยทางไซเบอร์ของ Amazon Aurora รุ่นต่างๆ ได้อย่างไร

คุณสามารถดูรายการ CVE ได้ที่การอัปเดตการรักษาความปลอดภัยของ Amazon Aurora

ฉันจะตรวจจับภัยคุกคามด้านความปลอดภัยที่มีต่อฐานข้อมูล Aurora ของฉันได้อย่างไร

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

แบบไม่ต้องใช้เซิร์ฟเวอร์

Amazon Aurora Serverless คืออะไร

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

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

Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v2 และ v1 ต่างกันอย่างไร

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

นอกจากนี้ ยังปรับขนาดความจุฐานข้อมูลโดยเพิ่มทีละ 0.5 หน่วยความจุ Aurora (ACU) เพื่อให้ความจุฐานข้อมูลตรงกับความต้องการของแอปพลิเคชันมากที่สุด

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

คุณสมบัติของ Aurora ทั้งหมดที่ Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v2 สนับสนุนได้แก่อะไรบ้าง

ฉันสามารถเริ่มใช้ Aurora Serverless v2 กับอินสแตนซ์ที่จัดเตรียมไว้ในคลัสเตอร์ Aurora DB ที่มีอยู่แล้วได้หรือไม่

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

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

สามารถย้ายจาก Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v1 ไปยัง Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v2 ได้หรือไม่

ได้ สามารถย้ายจาก Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v1 ไปยัง Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v2 ได้ โปรดอ่านคู่มือผู้ใช้ Aurora เพื่อเรียนรู้เพิ่มเติม

Amazon Aurora เวอร์ชันใดที่ได้รับการสนับสนุนสำหรับ Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์

จะย้ายคลัสเตอร์ Aurora DB ที่มีอยู่ไปยัง Auroraที่ไม่ต้องใช้เซิร์ฟเวอร์ได้หรือไม่

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

จะเชื่อมต่อกับคลัสเตอร์ DB ของ Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ได้อย่างไร

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

จะตั้งความจุของคลัสเตอร์ Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ อย่างเจาะจงได้อย่างไร

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

เพราะเหตุใดคลัสเตอร์ Aurora ไม่ต้องใช้เซิร์ฟเวอร์ DB ของฉันจึงไม่ปรับขนาดโดยอัตโนมัติ

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

ฉันจะได้รับการเรียกเก็บเงินค่า Aurora ไม่ต้องใช้เซิร์ฟเวอร์ อย่างไร

ใน Aurora Serverless ความจุของฐานข้อมูลจะวัดเป็น ACU คุณจ่ายอัตราคงที่ต่อวินาทีของการใช้งาน ACU ค่าใช้จ่ายในการประมวลผลสำหรับการเรียกใช้เวิร์กโหลดของคุณบน Aurora Serverless จะขึ้นอยู่กับการกำหนดค่าคลัสเตอร์ฐานข้อมูลที่คุณเลือก: Aurora Standard หรือ Aurora I/O-Optimized ไปที่ หน้าราคาของ Aurora เพื่อดูข้อมูลเกี่ยวกับราคาและความพร้อมให้บริการในภูมิภาคต่างๆ

การสืบค้นแบบคู่ขนาน

การสืบค้นแบบคู่ขนานของ Amazon Aurora คืออะไร

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

กรณีการใช้งานเป้าหมายคืออะไร?

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

การสืบค้นแบบคู่ขนานมีประโยชน์อย่างไร

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

การสืบค้นประเภทใดที่ช่วยปรับปรุงการสืบค้นแบบคู่ขนานให้ดีขึ้น

แบบสอบถามส่วนใหญ่เกี่ยวกับชุดข้อมูลขนาดใหญ่ที่ไม่ได้อยู่ในกลุ่มบัฟเฟอร์สามารถคาดหวังให้เกิดประโยชน์ได้ การสืบค้นแบบคู่ขนานเวอร์ชันเริ่มต้นสามารถย่อและขยายออกจากการประมวลผลฟังก์ชัน SQL, equijoins และการคาดการณ์มากกว่า 200 รายการ

มีการปรับปรุงประสิทธิภาพในด้านใดบ้างที่คาดหวังได้

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

มีโอกาสที่ประสิทธิภาพจะช้าลงหรือไม่

ได้ แต่กรณีนั้นเกิดขึ้นได้ยาก

ต้องทำการเปลี่ยนแปลงอะไรเพื่อรับประโยชน์จากการสืบค้นแบบคู่ขนาน

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

ฉันจะเปิดหรือปิดคุณสมบัติการสืบค้นแบบคู่ขนานได้อย่างไร

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

มีค่าบริการเพิ่มเติมใดๆ เกี่ยวกับการใช้การสืบค้นแบบคู่ขนานหรือไม่

ไม่ ระบบจะไม่เรียกเก็บเงินใดๆ นอกเหนือจากค่าบริการที่ชำระอยู่แล้วสำหรับอินสแตนซ์, I/O และพื้นที่จัดเก็บ

เนื่องจากการสืบค้นแบบคู่ขนานจะลด I/O ลง การเปิดใช้งานจะลดค่าบริการ Aurora IO หรือไม่

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

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

เรียนรู้เพิ่มเติมเกี่ยวกับการสืบค้นแบบคู่ขนานในเอกสารประกอบ

การสืบค้นแบบคู่ขนานสามารถใช้ไดักับอินสแตนซ์ทุกประเภทหรือไม่

ไม่ได้ ในขณะนี้ คุณสามารถใช้การสืบค้นแบบคู่ขนานได้กับอินสแตนซ์ที่อยู่ในกลุ่มประเภทอินสแตนซ์ R*

Amazon Aurora เวอร์ชันใดที่รองรับการสืบค้นแบบคู่ขนาน

การสืบค้นแบบคู่ขนานสามารถใช้ได้กับ Amazon Aurora รุ่นที่ใช้งานร่วมกับ MySQL 5.7 and MySQL 8.0 ได้

การสืบค้นแบบคู่ขนานสามารถใช้งานได้กับคุณสมบัติ Aurora ทั้งหมดหรือไม่

การสืบค้นแบบคู่ขนานสามารถใช้งานได้กับ Aurora Serverless v2 และ Backtrack

หากการสืบค้นแบบคู่ขนานเพิ่มความเร็วการในสืบค้นและทำให้สูญเสียประสิทธิภาพได้ยาก ฉันควรเปิดทิ้งไว้ตลอดเวลาหรือไม่

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

การสืบค้นแบบคู่ขนานของ Aurora สามารถใช้แทนที่คลังข้อมูลได้หรือไม่

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

สำหรับคลังข้อมูลบนระบบคลาวด์ขนาดเอกซะไบต์ โปรดศึกษา Amazon Redshift

การอ่านประสิทธิภาพสูง

การอ่านประสิทธิภาพสูงของ Amazon Aurora สําหรับ Aurora PostgreSQL คืออะไร

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

การอ่านประสิทธิภาพสูงของ Amazon Aurora สำหรับ Aurora PostgreSQL สามารถปรับปรุงประสิทธิภาพการสืบค้นได้อย่างไร

อินสแตนซ์การอ่านประสิทธิภาพสูงของ Amazon Aurora ใช้พื้นที่จัดเก็บระดับบล็อก SSD ที่ใช้ NVMe ภายใน (พร้อมใช้งานบนอินสแตนซ์ r6gd ที่ใช้ Graviton และอินสแตนซ์ r6id ที่ใช้ Intel) เพื่อปรับปรุงเวลาแฝงในการสืบค้นของแอปพลิเคชันที่มีชุดข้อมูลที่เกินความจุหน่วยความจำของอินสแตนซ์ฐานข้อมูล การอ่านประสิทธิภาพสูงมีการปรับปรุงประสิทธิภาพ เช่น การแคชแบบเป็นลำดับและอ็อบเจ็กต์ชั่วคราว

การแคชเป็นลำดับมอบเวลาแฝงในการสืบค้นที่ดีขึ้นสูงสุด 8 เท่า และประหยัดต้นทุนสูงสุด 30% สำหรับแอปพลิเคชันที่เน้นการอ่านและมี I/O เข้มข้น เช่น แดชบอร์ดการปฏิบัติงาน การตรวจจับความผิดปกติ และการค้นหาความคล้ายคลึงกันโดยใช้เวกเตอร์ คุณประโยชน์เหล่านี้เกิดขึ้นได้จากการแคชข้อมูลที่ถูกนำออกจากแคชบัฟเฟอร์ฐานข้อมูลแบบใช้หน่วยความจำไปยังที่จัดเก็บในตัวเครื่องโดยอัตโนมัติ เพื่อเพิ่มความเร็วในการเข้าถึงข้อมูลนั้นในภายหลัง การแคชแบบเป็นลำดับจะใช้ได้กับ Amazon Aurora PostgreSQL-Edition ที่มีการกําหนดค่า Aurora I/O-Optimized เท่านั้น

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

ฉันควรใช้การอ่านประสิทธิภาพสูงของ Amazon Aurora สําหรับ Aurora PostgreSQL เมื่อใด

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

อินสแตนซ์ฐานข้อมูลประเภทใดบ้างที่รองรับการอ่านประสิทธิภาพสูงของ Amazon Aurora Optimized Reads สำหรับ Aurora PostgreSQL มีพร้อมให้บริการใน Region ใดบ้าง

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

Amazon Aurora เวอร์ชันกลไกใดบ้างที่รองรับการอ่านประสิทธิภาพสูงของ Aurora สำหรับ Aurora PostgreSQL

การอ่านประสิทธิภาพสูงของ Amazon Aurora ที่พร้อมใช้งานสำหรับ Aurora รุ่นที่เข้ากันได้กับ PostgreSQL บนอินสแตนซ์ R6id และ R6gd เวอร์ชันกลไกที่รองรับคือ 15.4 และสูงกว่า และ 14.9 และสูงกว่าบน Aurora PostgreSQL

ฉันสามารถใช้การอ่านประสิทธิภาพสูงของ Amazon Aurora สำหรับ Aurora PostgreSQL กับ Aurora Serverless v2 ได้หรือไม่

การอ่านประสิทธิภาพสูงของ Amazon Aurora ไม่พร้อมใช้งานบน Aurora Serverless v2 (ASv2)

ฉันสามารถใช้การอ่านประสิทธิภาพสูงของ Amazon Aurora สำหรับ Aurora PostgreSQL กับการกำหนดค่า Aurora Standard และ Aurora I/O-Optimized ได้หรือไม่

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

สำหรับเวิร์กโหลดที่ใช้ I/O จำนวนมากซึ่งมีการอ่านจำนวนมาก อินสแตนซ์ที่เปิดใช้งานการอ่านประสิทธิภาพสูงบน Aurora PostgreSQL ที่ได้รับการกำหนดค่าให้ใช้ Aurora I/O-Optimized แคชข้อมูลโดยอัตโนมัติจากหน่วยความจำบนพื้นที่จัดเก็บในเครื่องที่ใช้ NVMe เพื่อมอบเวลาแฝงในการสืบค้นที่ดีขึ้นสูงสุด 8 เท่าขึ้นไป ประหยัดต้นทุนถึง 30% เมื่อเทียบกับอินสแตนซ์ที่ไม่มี สำหรับแอปพลิเคชันที่มีชุดข้อมูลขนาดใหญ่ที่เกินความจุหน่วยความจำของอินสแตนซ์ฐานข้อมูล

ฉันจะเริ่มต้นใช้งานการอ่านประสิทธิภาพสูงของ Amazon Aurora สำหรับ Aurora PostgreSQL ได้อย่างไร

ลูกค้าสามารถเริ่มต้นใช้งานการอ่านประสิทธิภาพสูงของ Amazon Aurora ได้ผ่านทางคอนโซลการจัดการของ AWS, CLI และ SDK การอ่านประสิทธิภาพสูงจะพร้อมใช้งานบนอินสแตนซ์ R6id และ R6gd ทั้งหมดตามค่าเริ่มต้น หากต้องการใช้ความสามารถนี้ ลูกค้าสามารถแก้ไขคลัสเตอร์ฐานข้อมูล Aurora ที่มีอยู่เพื่อรวมอินสแตนซ์ R6id และ R6gd หรือสร้างคลัสเตอร์ฐานข้อมูลใหม่โดยใช้อินสแตนซ์เหล่านี้ได้ ดูเอกสารประกอบของการอ่านประสิทธิภาพสูงของ Amazon Auroraเพื่อเริ่มต้นใช้งาน

มีจำนวนพื้นที่จัดเก็บภายในตัวเครื่องที่พร้อมใช้งานสำหรับการอ่านประสิทธิภาพสูงของ Amazon Aurora สำหรับ Aurora PostgreSQL อยู่เท่าใด

ประมาณ 90% ของพื้นที่จัดเก็บภายในเครื่องที่มีอยู่บนอินสแตนซ์ R6id และ R6gd พร้อมใช้งานสำหรับการอ่านประสิทธิภาพสูง ส่วน Aurora ขอสงวน 10% ของพื้นที่จัดเก็บ NVMe เพื่อลดผลกระทบของการขยายการเขียน SSD การจัดสรรพื้นที่เก็บข้อมูลที่มีอยู่นั้นขึ้นอยู่กับคุณสมบัติการอ่านประสิทธิภาพสูงที่เปิดใช้งาน

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

เมื่อใช้การอ่านประสิทธิภาพสูงกับคุณสมบัติอ็อบเจ็กต์ชั่วคราวเท่านั้น พื้นที่ว่างในดิสก์ที่จัดเก็บในเครื่องที่มีอยู่ทั้งหมดจะพร้อมใช้งานสำหรับอ็อบเจ็กต์ชั่วคราว ตัวอย่างเช่น เมื่อใช้อินสแตนซ์ r6gd.8xlarge ที่มีทั้งอ็อบเจ็กต์ชั่วคราวและคุณลักษณะการแคชแบบเป็นลำดับ 534 GiB (ความจุหน่วยความจํา 2x) จะถูกสงวนไว้สําหรับอ็อบเจ็กต์ชั่วคราว และ 1054 GiB สําหรับแคชแบบเป็นลำดับ

จะเกิดอะไรขึ้นในกรณีที่พื้นที่เก็บข้อมูลในเครื่องล้มเหลว

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

การอ่านประสิทธิภาพสูงของ Amazon Aurora สำหรับ Aurora PostgreSQL ส่งผลต่อเวลาแฝงของการสืบค้นในกรณีที่ฐานข้อมูลมีการใช้ระบบสำรองเพื่อกู้คืนข้อมูลอย่างไร

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

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

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

AI ช่วยสร้าง

pgvector คืออะไร

pgvector เป็นส่วนขยายโอเพนซอร์สสำหรับ PostgreSQL ที่ Amazon Aurora รุ่นที่ใช้งานร่วมกับ PostgreSQL ได้รองรับ

pgvector เปิดใช้งานความสามารถใดบ้างสำหรับ Aurora PostgreSQL

คุณสามารถใช้ pgvector เพื่อจัดเก็บ ค้นหา จัดทำดัชนี และสืบค้นการฝังนับพันล้านรายการที่สร้างขึ้นจากโมเดลแมชชีนเลิร์นนิง (ML) และปัญญาประดิษฐ์ (AI) ในฐานข้อมูลของคุณ เช่น โมเดลจาก Amazon Bedrock หรือ Amazon SageMaker การฝังเวกเตอร์ คือการแสดงตัวเลขที่แสดงถึงความหมายของเนื้อหา เช่น ข้อความ รูปภาพ และวิดีโอ
 
ด้วยการใช้งาน pgvector คุณจะสามารถสืบค้นการฝังในฐานข้อมูล Aurora PostgreSQL ของคุณเพื่อทำการค้นหาความคล้ายคลึงทางความหมายที่มีประสิทธิภาพของประเภทข้อมูลเหล่านี้ได้ ซึ่งจะแสดงเป็นเวกเตอร์รวมกับข้อมูลแบบตารางอื่น ๆ ใน Aurora วิธีนี้ช่วยให้สามารถใช้ AI ช่วยสร้างและระบบ AI/ML อื่นๆ สำหรับแอปพลิเคชันประเภทใหม่ๆ ได้ เช่น คำแนะนำส่วนบุคคลตามคำอธิบายข้อความหรือรูปภาพที่คล้ายกัน การจับคู่ผู้สมัครตามบันทึกการสัมภาษณ์ แชทบอท และการบริการลูกค้า คำแนะนำการดำเนินการที่ดีที่สุดถัดไปโดยอิงตามการถอดเสียงที่ประสบความสำเร็จหรือเซสชันการแชท กล่องโต้ตอบ และอื่น ๆ 
 
อ่าน บล็อกของเราเกี่ยวกับความสามารถของฐานข้อมูลเวกเตอร์ และเรียนรู้วิธีจัดเก็บการฝังโดยใช้ส่วนขยาย pgvector ในฐานข้อมูล Aurora PostgreSQL สร้างคำถามเชิงโต้ตอบเพื่อตอบแชทบอท และใช้การผสานรวมแบบดั้งเดิมระหว่าง pgvector และ แมชชีนเลิร์นนิงของ Aurora สำหรับการวิเคราะห์ความรู้สึก

pgvector ทำงานร่วมกับแมชชีนเลิร์นนิงของ Aurora ได้หรือไม่

ได้ แมชชีนเลิร์นนิงของ Aurora (ML) มีโมเดล ML เป็นฟังก์ชัน SQL ซึ่งช่วยให้คุณสามารถใช้ SQL มาตรฐานเพื่อเรียกโมเดล ML ส่งข้อมูลไปยังโมเดลเหล่านั้น และส่งคืนการคาดการณ์เป็นผลลัพธ์การสืบค้น pgvector กำหนดให้การฝังเวกเตอร์ถูกจัดเก็บไว้ในฐานข้อมูล ซึ่งจำเป็นต้องเรียกใช้โมเดล ML บนข้อความต้นฉบับหรือข้อมูลรูปภาพเพื่อสร้างการฝัง จากนั้นจึงย้ายการฝังเป็นชุดไปยัง Aurora PostgreSQL

Aurora ML สามารถทำให้กระบวนการนี้กลายเป็นแบบเรียลไทม์ ซึ่งช่วยจะให้มีการอัปเดตการฝังใน Aurora PostgreSQL อยู่เสมอโดยการเรียกใช้ Amazon Bedrock หรือ Amazon SageMaker เป็นระยะ ๆ ซึ่งจะส่งคืนการฝังล่าสุดจากโมเดลของคุณ

การอ่านประสิทธิภาพสูงของ Aurora สำหรับ Aurora PostgreSQL จะช่วยในเรื่องประสิทธิภาพของ pgvector อย่างไร

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

การบูรณาการ ETL แบบไร้รอยต่อ

ฉันควรใช้การบูรณาการ ETL แบบไร้รอยต่อของ Aurora Zero กับ Amazon Redshift เมื่อใด

คุณควรใช้การบูรณาการ ETL แบบไร้รอยต่อของ Amazon Aurora กับ Amazon Redshift เมื่อคุณต้องการเข้าถึงข้อมูลธุรกรรมแบบเรียลไทม์ การบูรณาการนี้ช่วยให้คุณใช้ประโยชน์จาก Amazon RedShift ML ด้วยคำสั่ง SQL ที่ตรงไปตรงมาได้

กลไกและเวอร์ชันใดของ Amazon Aurora ที่รองรับการบูรณาการ ETL แบบไร้รอยต่อ

การบูรณาการ ETL แบบไร้รอยต่อของ Aurora กับ Amazon Redshift พร้อมให้บริการบน Aurora รุ่นที่รองรับ MySQL สำหรับ Aurora MySQL เวอร์ชัน 3.05 (เข้ากันได้กับ MySQL 8.0.32) และสูงกว่าในภูมิภาคสหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอ), สหรัฐอเมริกาฝั่งตะวันออก (เวอร์จิเนียฝั่งเหนือ), สหรัฐอเมริกาฝั่งตะวันตก (ออริกอน), เอเชียแปซิฟิก (สิงคโปร์), เอเชียแปซิฟิก (ซิดนีย์), เอเชียแปซิฟิก (โตเกียว), ยุโรป (แฟรงก์เฟิร์ต), ยุโรป (ไอร์แลนด์) และยุโรป (สตอกโฮล์ม) การบูรณาการ ETL แบบไร้รอยต่อของ Aurora กับ Amazon RedShift มีให้บริการบน Aurora PostgreSQL-Compatible Edition สำหรับ Aurora PostgreSQL 15.4 ในภูมิภาคสหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอ)

การบูรณาการ ETL แบบไร้รอยต่อมีประโยชน์อย่างไรบ้าง

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

การบูรณาการ ETL แบบไร้รอยต่อเข้ากันได้กับ Aurora Serverless v2 หรือไม่

การบูรณาการ ETL แบบไร้รอยต่อของ Aurora กับ Amazon Redshift เข้ากันได้กับ Aurora Serverless v2 เมื่อใช้ทั้ง Aurora Serverless v2 และ Amazon Redshift แบบไม่ต้องใช้เซิร์ฟเวอร์ คุณจะสามารถสร้างการวิเคราะห์ข้อมูลธุรกรรมแบบเกือบเรียลไทม์ได้โดยไม่ต้องจัดการโครงสร้างพื้นฐานใดๆ สําหรับไปป์ไลน์ข้อมูล

ฉันจะเริ่มการบูรณาการ ETL แบบไร้รอยต่อได้อย่างไร

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

การบูรณาการ ETL แบบไร้รอยต่อมีค่าใช้จ่ายเท่าไร

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

สําหรับข้อมูลเพิ่มเติม โปรดไปที่หน้าราคาของ Aurora

Amazon DevOps Guru สำหรับ RDS

Amazon DevOps Guru สำหรับ RDS คืออะไร

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

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

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

ทำไมจึงควรใช้ DevOps Guru สำหรับ RDS

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

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

Amazon DevOps Guru สำหรับ RDS ทำงานอย่างไร

Amazon DevOps Guru สำหรับ RDS ใช้ ML เพื่อวิเคราะห์ข้อมูลทางไกลที่รวบรวมโดยAmazon RDS Performance Insights (PI) DevOps Guru สำหรับ RDS ไม่ได้ใช้ข้อมูลใดๆ ที่จัดเก็บไว้ในฐานข้อมูลในการวิเคราะห์ PI จะตรวจวัดภาระฐานข้อมูล ซึ่งเป็นตัววัดที่กำหนดลักษณะการใช้งานของแอปพลิเคชันในฐานข้อมูลและตัววัดที่เลือกซึ่งสร้างโดยฐานข้อมูล เช่น ตัวแปรสถานะเซิร์ฟเวอร์ใน MySQL และตาราง pg_stat ใน PostgreSQL

จะเริ่มใช้ Amazon DevOps Guru สำหรับ RDS ได้อย่างไร

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

ปัญหาประเภทใดบ้างที่ Amazon DevOps Guru สำหรับ RDS ตรวจพบได้

Amazon DevOps Guru สำหรับ RDS ช่วยระบุปัญหาด้านประสิทธิภาพแบบต่างๆ ที่อาจส่งผลต่อคุณภาพการบริการของแอปพลิเคชัน เช่น การล็อกซ้อนหลายชั้น, การเชื่อมต่อพร้อมกันหลายรายการ, การถดถอยของ SQL, ความขัดแย้งระหว่าง CPU กับ I/O และปัญหาด้านหน่วยความจำ

DevOps Guru สำหรับ RDS แตกต่างจากข้อมูลเชิงลึกด้านประสิทธิภาพของ Amazon RDS อย่างไร

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

Data API

ฉันควรใช้ Data API กับ Aurora แทนไดรเวอร์ฐานข้อมูลเมื่อใด

คุณควรใช้ Data API สําหรับแอปพลิเคชันทันสมัยแบบใหม่ โดยเฉพาะแอปพลิเคชันที่สร้างด้วย AWS Lambda ที่ต้องเข้าถึง Aurora ในโมเดลคําขอ/การตอบกลับ คุณควรใช้ไดรเวอร์ฐานข้อมูลแทน Data API และจัดการการเชื่อมต่อฐานข้อมูลแบบถาวรเมื่อแอปพลิเคชันที่มีอยู่ถูกจับคู่กับไดรเวอร์ฐานข้อมูล เมื่อมีการสืบค้นที่ใช้เวลานานหรือเมื่อนักพัฒนาต้องการใช้ประโยชน์จากคุณสมบัติฐานข้อมูล เช่น ตารางชั่วคราวหรือใช้ตัวแปรเซสชัน

กลไกและเวอร์ชันของ Aurora ใดบ้างที่รองรับ Data API

ความพร้อมใช้งานของ AWS Region ของ Data API และเวอร์ชันฐานข้อมูลสําหรับ Aurora Serverless v2 และอินสแตนซ์ที่จัดเตรียมไว้โดยใช้ Aurora สามารถพบได้ใน เอกสารประกอบ ของเรา ลูกค้าที่ใช้ Data API สําหรับ Aurora Serverless v1 ในปัจจุบัน ขอแนะนําให้ย้ายไปยัง Aurora Serverless v2 เพื่อใช้ประโยชน์จาก Data API ที่ออกแบบใหม่และการปรับขนาด Aurora Serverless v2 ที่ละเอียดยิ่งขึ้น

Data API ให้ประโยชน์อะไรบ้าง

Data API จะช่วยให้คุณลดความซับซ้อนและเร่งการพัฒนาแอปพลิเคชันที่ทันสมัย Data API เป็น API ที่ใช้ HTTP ที่มีปลอดภัยและใช้งานง่าย ซึ่งช่วยลดความจําเป็นในการปรับใช้ไดรเวอร์ฐานข้อมูล จัดการพูลการเชื่อมต่อฝั่งไคลเอ็นต์หรือตั้งค่าเครือข่าย VPC ที่ซับซ้อนระหว่างแอปพลิเคชันและฐานข้อมูล Data API ยังปรับปรุงความสามารถในการปรับขนาดโดยการรวบรวมและแชร์การเชื่อมต่อฐานข้อมูลโดยอัตโนมัติ ซึ่งจะช่วยลดค่าใช้จ่ายในการคํานวณจากแอปพลิเคชันที่เปิดและปิดการเชื่อมต่อบ่อย ๆ 

Data API รองรับ Aurora Global Database หรือ Aurora Serverless v1 หรือไม่

Data API ที่มีอยู่สําหรับ Aurora Serverless v1 จะยังคงเป็นคุณสมบัติของ Aurora Serverless v1 สําหรับทั้ง Aurora รุ่นที่ใช้งานร่วมกับ PostgreSQL ได้และ Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้ Data API สําหรับ Aurora Serverless v2 และอินสแตนซ์ที่จัดเตรียมไว้โดย Aurora นั้น ไม่รองรับ Aurora Serverless v1 Data API สําหรับ Aurora Serverless v2 และอินสแตนซ์ที่จัดเตรียมไว้โดย Aurora นั้น รองรับอินสแตนซ์การเขียนของ Aurora Global Database

ฉันจะรับรองความถูกต้องกับฐานข้อมูลโดยใช้ Data API ได้อย่างไร

ผู้ใช้สามารถเรียกดําเนินการ Data API ได้ก็ต่อเมื่อได้รับอนุญาตให้ทําเช่นนั้นเท่านั้น ผู้ดูแลระบบสามารถให้สิทธิ์แก่ผู้ใช้ในการใช้ Data API ได้โดยแนบนโยบาย AWS Identity and Access Management (IAM) ที่กําหนดสิทธิ์ของพวกเขา คุณยังสามารถแนบนโยบายกับบทบาทได้หากคุณใช้บทบาทใน IAM เมื่อคุณเรียกใช้ Data API คุณสามารถส่งข้อมูลประจําตัวสําหรับคลัสเตอร์ Aurora DB ได้โดยใช้ข้อมูลลับในAWSSecrets Manager 

Data API มีราคาเท่าไหร่

การใช้ Data API กับ Aurora Serverless v1 ยังคงพร้อมใช้งานโดยไม่มีค่าใช้จ่ายเพิ่มเติม Data API สําหรับ Aurora Serverless v2 และอินสแตนซ์ Aurora ที่มีการเตรียมใช้งานไว้แล้วนั้น มีราคาตามปริมาณคําขอ API ตามที่อธิบายไว้ใน หน้าราคา Aurora Data API สําหรับ Aurora Serverless v2 และอินสแตนซ์ที่จัดเตรียมไว้โดย Aurora นั้น ใช้เหตุการณ์ส่วนข้อมูล AWS CloudTrail เพื่อบันทึกข้อมูลกิจกรรมแทนเหตุการณ์การจัดการ เช่นเดียวกับกรณีของ Data API สําหรับ Aurora Serverless v1

คุณสามารถเปิดใช้งานการบันทึกเหตุการณ์ข้อมูลผ่านคอนโซล CloudTrail, CLI หรือ SDK ได้หากต้องการติดตามกิจกรรมนี้ การดําเนินการนี้จะมีค่าใช้จ่ายตามที่กําหนดไว้ใน หน้าราคา CloudTrail นอกจากนี้ การใช้ AWS Secrets Manager จะมีค่าใช้จ่ายตามที่กําหนดไว้ใน หน้าราคา AWS Secrets Manager 

เหตุใด AWS จึงเริ่มใช้เหตุการณ์ส่วนข้อมูลสําหรับ Data API แทนเหตุการณ์การจัดการ CloudTrail

AWS CloudTrail จะบันทึกกิจกรรม AWS API เป็นเหตุการณ์ด้านการจัดการหรือเหตุการณ์ด้านข้อมูล เหตุการณ์การจัดการ CloudTrail (หรือที่เรียกว่า "การดําเนินการส่วนการควบคุม") จะแสดงการดําเนินการจัดการที่ดําเนินการกับทรัพยากรในบัญชี AWS ของคุณ เช่น สร้าง อัปเดต และลบทรัพยากร เหตุการณ์ด้านข้อมูล CloudTrail (หรือที่เรียกว่า "การดําเนินการส่วนข้อมูล") จะแสดงการดําเนินการทรัพยากรที่ดําเนินการบนหรือภายในทรัพยากรในบัญชี AWS ของคุณ

Data API ทำการดําเนินการส่วนข้อมูลเนื่องจากดําเนินการสืบค้นข้อมูลภายในฐานข้อมูล Aurora ของคุณ ดังนั้นเราจะบันทึกกิจกรรม Data API เป็นเหตุการณ์ข้อมูลเนื่องจากเป็นการจัดหมวดหมู่ที่ถูกต้องของเหตุการณ์ ค่าบริการจะเกิดขึ้นสําหรับเหตุการณ์ด้านข้อมูล CloudTrail ก็ต่อเมื่อคุณเปิดใช้งานการบันทึกเหตุการณ์ข้อมูลเท่านั้น

Data API มีแบบ Free Tier หรือไม่

ใช่ Data API Free Tier มีคําขอหนึ่งล้านรายการต่อเดือน ซึ่งรวบรวมทั่วทั้ง AWS Region ทั้งหมดสําหรับการใช้งานในปีแรก หลังจากหนึ่งปี ลูกค้าจะเริ่มชําระเงินสําหรับ Data API ตามที่อธิบายไว้ใน หน้าราคาของ Aurora

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

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

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

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

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

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

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

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

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

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

ตัวอย่างเช่น: คุณมีคลัสเตอร์ Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้เวอร์ชัน 5.7 ที่ทำงานบน r5.2xlarge db.instance สองอินสแตนซ์ ซึ่งเป็นอินสแตนซ์ตัวเขียนหลักและอินสแตนซ์ตัวอ่าน ใน AWS Region us-east-1 อินสแตนซ์ r5.2xlarge db.instance แต่ละตัวได้รับการกำหนดค่าสำหรับพื้นที่จัดเก็บ 40 GiB และมี I/O 25 ล้านรายการต่อเดือน คุณสร้างโคลนของโทโพโลยีอินสแตนซ์ Blue โดยใช้การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ของ Amazon RDS ใช้งานเป็นเวลา 15 วัน (360 ชั่วโมง) และอินสแตนซ์ Green แต่ละรายการมีการอ่าน I/O 3 ล้านครั้งในช่วงเวลานั้น จากนั้น คุณจะลบอินสแตนซ์ Blue ออกหลังจากการสลับเปลี่ยนสำเร็จ อินสแตนซ์ Blue (ตัวเขียนและตัวอ่าน) มีราคาอยู่ที่ 849.2 USD เป็นเวลา 15 วันในอัตราตามความต้องการ 1.179 USD/ชม. (อินสแตนซ์ + พื้นที่เก็บข้อมูล+ I/O) อินสแตนซ์ Green (ตัวเขียนและตัวอ่าน) มีราคา 840.40 USD เป็นเวลา 15 วันที่อัตราตามความต้องการที่ 1.167 USD/ชม. (อินสแตนซ์ + พื้นที่จัดเก็บ + I/O) ค่าใช้จ่ายทั้งหมดของคุณสำหรับการติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ในช่วง 15 วันดังกล่าวคือ 1,689.60 USD ซึ่งคิดเป็นประมาณ 2 เท่าของค่าใช้จ่ายในการเรียกใช้อินสแตนซ์ Blue ในช่วงเวลาดังกล่าว

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

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

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

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

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

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

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

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

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

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

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

ฉันสามารถใช้การติดตั้งใช้งานแบบเปิดตัวระบบใหม่เทียบกับระบบเก่า (Blue/Green) ได้หรือไม่หากมีฐานข้อมูล Blue ในฐานะผู้สมัครรับข้อมูล/ตัวเผยแพร่ข้อความสําหรับแบบจําลองเชิงตรรกะที่จัดการด้วยตนเอง

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

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

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

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

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

ส่วนขยายภาษาที่เชื่อถือได้สำหรับ PostgreSQL

เหตุใดฉันจึงควรใช้ส่วนขยายภาษาที่เชื่อถือได้สำหรับ PostgreSQL

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

อะไรคือความเสี่ยงที่มีมาโดยตลอดของการเรียกใช้ส่วนขยายใน PostgreSQL และ TLE สำหรับ PostgreSQL สามารถช่วยลดความเสี่ยงเหล่านั้นได้อย่างไร

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

TLE สำหรับ PostgreSQL สัมพันธ์/มีการทำงานร่วมกับบริการ AWS อื่นๆ อย่างไร

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

ฉันสามารถเรียกใช้ TLE สำหรับ PostgreSQL ใน PostgreSQL เวอร์ชันใดได้บ้าง

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

ส่วนขยายภาษาที่เชื่อถือได้สำหรับ PostgreSQL มีให้บริการในภูมิภาคใดบ้าง

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

มีค่าใช้จ่ายในการเรียกใช้งาน TLE เท่าไร

TLE สำหรับ PostgreSQL มีพร้อมให้บริการแก่ลูกค้าของ Aurora โดยไม่มีค่าใช้จ่ายเพิ่มเติม

TLE สำหรับ PostgreSQL แตกต่างจากส่วนขยายที่มีอยู่ใน Amazon Aurora และ Amazon RDS ในปัจจุบันอย่างไร

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

ตัวอย่างส่วนขยายที่ฉันสามารถเรียกใช้ด้วย TLE สำหรับ PostgreSQL ได้มีอะไรบ้าง

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

ฉันสามารถใช้ภาษาโปรแกรมในการพัฒนา TLE สำหรับ PostgreSQL ใดได้บ้าง

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

ฉันจะปรับใช้ TLE สำหรับส่วนขยาย PostgreSQL ได้อย่างไร

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

TLE สำหรับส่วนขยาย PostgreSQL สื่อสารกับฐานข้อมูล PostgreSQL ได้อย่างไร

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

ฉันจะเรียนรู้เพิ่มเติมเกี่ยวกับ TLE สำหรับโปรเจกต์โอเพนซอร์ส PostgreSQL ได้ที่ไหน

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

การสนับสนุนเพิ่มเติมของ Amazon RDS

ฉันสามารถใช้การสนับสนุนเพิ่มเติมของ RDS กับเวอร์ชันรองใดได้หรือไม่

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

ฉันจะประมาณค่าบริการของการสนับสนุนเพิ่มเติมของ RDS ได้อย่างไร

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

หากต้องการประมาณค่าใช้จ่าย คุณต้องกำหนดจำนวน vCPU บนอินสแตนซ์และราคาปีตามปฏิทินที่เหมาะสมสำหรับเวอร์ชันของกลไกของคุณ หากเวอร์ชันของคุณอยู่ภายในราคาปีที่ 1-2 และคุณกำลังใช้อินสแตนซ์ที่จัดเตรียมไว้อยู่ คุณจะถูกเรียกเก็บเงิน#vCPUs x ราคาปีที่ 1 และปีที่ 2 ต่อชั่วโมงการใช้งานสำหรับภูมิภาคที่คุณเลือก หากเวอร์ชันของคุณมีราคาปีที่ 3 และคุณกำลังใช้อินสแตนซ์ที่จัดเตรียมไว้ คุณจะถูกเรียกเก็บเงิน #vCPUs x ราคาปีที่ 3 ต่อชั่วโมงการใช้งานสำหรับภูมิภาคที่คุณเลือก

ตัวอย่างเช่น หากคุณใช้งานอินสแตนซ์ Aurora MySQL 2 db.r5.large ในเวอร์จิเนียเหนือในวันที่ 30 ธันวาคม 2024 ซึ่งอยู่ภายในปีแรกของการสนับสนุนเพิ่มเติมของ RDS คุณจะถูกเรียกเก็บเงิน 0.200 USD ต่อชั่วโมง หรือ 2 vCPU x 0.100 USD ต่อ vCPU ต่อชั่วโมง

Amazon Aurora จะเริ่มเรียกเก็บค่าบริการสำหรับการสนับสนุนเพิ่มเติมของ RDS เมื่อใด

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

ตัวอย่างเช่น การสนับสนุนมาตรฐาน Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้รุ่นที่ 2 จะสิ้นสุดในวันที่ 30 พฤศจิกายน 2024 หากคุณใช้งานอินสแตนซ์ Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้รุ่นที่ 2 หลังจากวันที่ 30 พฤศจิกายน 2024 คุณจะถูกเรียกเก็บเงินสำหรับการสนับสนุนเพิ่มเติมของ RDS บนอินสแตนซ์นั้น

ฉันต้องชำระค่าบริการสำหรับการสนับสนุนเพิ่มเติมของ RDS บนสแนปช็อต DB ของฉันหรือไม่

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

ระบบจะหยุดเรียกเก็บค่าบริการสำหรับการสนับสนุนเพิ่มเติมของ RDS ได้เมื่อใด

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

กลไกแต่ละรุ่นมีราคาที่แตกต่างกันออกไปสองแบบ ฉันจะรู้ได้อย่างไรว่าฉันถูกเรียกเก็บเงินแบบใด

ราคาการสนับสนุนเพิ่มเติมของ RDS ที่คุณเรียกเก็บจะขึ้นอยู่กับเวอร์ชันของกลไก, AWS Region และจํานวนปีปฏิทินนับตั้งแต่การสนับสนุนมาตรฐานหมดอายุสําหรับเวอร์ชันนั้น คุณจะถูกเรียกเก็บเงินตามราคาปีที่ 1 และปีที่ 2 ในภูมิภาคที่คุณเลือกต่อ vCPU-ชม. ในช่วงสองปีแรกหลังจากสิ้นสุดการสนับสนุนแบบมาตรฐาน หากมีการเสนอการสนับสนุนเพิ่มเติมของ RDS เป็นปีที่สาม คุณจะถูกเรียกเก็บเงินตามราคาปีที่ 3 ในภูมิภาคที่คุณเลือกต่อ vCPU-ชม. เริ่มตั้งแต่วันแรกของปีที่สาม

ตัวอย่างเช่น Aurora รุ่นที่ใช้งานร่วมกับ PostgreSQL ได้รุ่นที่ 11 จะสิ้นสุดการสนับสนุนแบบมาตรฐานในวันที่ 29 กุมภาพันธ์ 2024 หากคุณใช้งานในสหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอ) คุณจะถูกเรียกเก็บค่าบริการ 0.100 USD ต่อ vCPU-ชม. ระหว่างวันที่ 1 เมษายน 2024 ถึง 31 มีนาคม 2026 ตั้งแต่วันที่ 1 มีนาคม 2026 คุณจะถูกเรียกเก็บค่าบริการ 0.200 USD ต่อ vCPU ต่อชม.

ฉันจะหลีกเลี่ยงการถูกเรียกเก็บค่าบริการสำหรับการสนับสนุนเพิ่มเติมของ RDS ได้อย่างไร

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

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

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

ส่วนลด Reserved Instance ใช้กับการสนับสนุนเพิ่มเติมของ RDS ได้หรือไม่

ไม่ได้ ค่าบริการการสนับสนุนเพิ่มเติมของ RDS นั้นแยกกันกับค่าบริการอินสแตนซ์ ดังนั้นส่วนลด Reserved Instance จึงไม่สามารถใช้ได้กับค่าบริการการสนับสนุนเพิ่มเติมของ RDS

ฉันจะถูกเรียกเก็บค่าบริการสำหรับการสนับสนุนเพิ่มเติมของ RDS หรือไม่ แม้ว่าฉันจะย้ายจาก RDS สำหรับ MySQL 5.7 ไปเป็น Aurora MySQL 2 (อิงจาก MySQL 5.7)

หากคุณย้ายจาก RDS สำหรับ MySQL 5.7 ไปเป็น Aurora MySQL 2 ก่อนวันที่ 29 กุมภาพันธ์ 2024 คุณจะไม่ถูกเรียกเก็บค่าบริการสำหรับการสนับสนุนเพิ่มเติมของ RDS หากคุณย้ายหลังวันที่ 29 กุมภาพันธ์ 2024 และก่อนวันที่ 30 พฤศจิกายน 2024 คุณจะถูกเรียกเก็บค่าบริการสำหรับการสนับสนุนเพิ่มเติมของ RDS ตามจำนวนชั่วโมงที่คุณใช้งาน MySQL 5.7 บน Amazon RDS

หากคุณย้ายหลังวันที่ 30 พฤศจิกายน 2024 หรือใช้ Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้รุ่นที่ 2 หลังวันที่ 30 พฤศจิกายน 2024 คุณจะถูกเรียกเก็บค่าบริการสำหรับการสนับสนุนเพิ่มเติมของ RDS บนฐานข้อมูล Aurora ของคุณด้วย สำหรับรายละเอียดเพิ่มเติม โปรดดูเอกสารประกอบของ Amazon Aurora และ Amazon RDS

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

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

ตัวอย่างเช่น หากคุณกู้คืนสแนปช็อต DB ไปยังอินสแตนซ์ DB ใหม่บน Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้รุ่นที่ 2 หลังจากวันที่ 30 พฤศจิกายน 2024 อินสแตนซ์จะถูกเรียกเก็บค่าบริการตามราคาการสนับสนุนเพิ่มเติมของ RDS ของ Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้รุ่นที่ 2 จนกว่าคุณจะอัปเกรดเป็น Aurora รุ่นที่ใช้งานร่วมกับ MySQL เวอร์ชัน 3 หรือใหม่กว่า หรือลบอินสแตนซ์ออก

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

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

เรียนรู้เพิ่มเติมเกี่ยวกับราคา Amazon Aurora

ไปที่หน้าราคา
พร้อมสร้างหรือยัง
เริ่มต้นใช้งาน Amazon Aurora
มีคำถามเพิ่มเติมหรือไม่
ติดต่อเรา