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

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

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

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

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

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

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

สามารถดูภูมิภาคที่พร้อมใช้งานสำหรับ Amazon Aurora ได้ที่นี่

หากต้องการย้ายไปมาระหว่าง MySQL และ Amazon Aurora มีหลายทางให้เลือก

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

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

หากต้องการย้ายข้อมูลไปมาระหว่าง PostgreSQL และ Amazon Aurora มีหลายทางให้เลือก

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

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

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

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

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

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

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

หน้าฐานข้อมูลแต่ละหน้าคือ Aurora รุ่นที่ใช้งานร่วมกับ MySQL ได้ขนาด 16 KB และ Aurora รุ่นที่ใช้งานร่วมกับ PostgreSQL ได้ขนาด 8 KB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Amazon 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Amazon Aurora Multi-Master เป็นคุณลักษณะ Aurora MySQL-Compatible Edition ใหม่ที่เพิ่มความสามารถในการปรับขนาดออกประสิทธิภาพการเขียนใน Availability Zone ที่หลากหลาย ทำให้แอปพลิเคชันสามารถกำหนดปริมาณงานในการอ่าน/เขียนไปยังหลายอินสแตนซ์ในคลัสเตอร์ฐานข้อมูลและทำงานด้วยความพร้อมใช้งานที่สูงขึ้น

ขณะนี้ Amazon Aurora Multi-Master พร้อมใช้งานได้โดยทั่วไปแล้ว สามารถอ่านเอกสารประกอบของ Amazon Aurora เพื่อเรียนรู้เพิ่มเติมได้ สามารถสร้างคลัสเตอร์ Aurora Multi-Master ได้ด้วยการคลิกเพียงไม่กี่ครั้งใน Amazon RDS Console หรือดาวน์โหลด AWS SDK หรือ CLI ล่าสุด

ได้ อินสแตนซ์ Amazon Aurora DB ทั้งหมดต้องสร้างใน VPC Amazon VPC ช่วยให้คุณสามารถกำหนดโครงสร้างเครือข่ายเสมือนที่มีความคล้ายกับเครือข่ายแบบเดิมที่คุณอาจใช้งานได้ในศูนย์ข้อมูลของคุณเอง ซึ่งจะช่วยให้คุณสามารถควบคุมได้ว่าใครบ้างที่สามารถเข้าถึงฐานข้อมูล 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 ผ่านพอร์ตฐานข้อมูลที่ป้อนไว้ขณะสร้างฐานข้อมูล ซึ่งจะช่วยเพิ่มระดับความปลอดภัยให้ข้อมูลของคุณ โปรดดูคำแนะนำทีละขั้นตอนเกี่ยวกับการเชื่อมต่อกับฐานข้อมูล Amazon Aurora ได้ในคู่มือการเชื่อมต่อ Amazon Aurora

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

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

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

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

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

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

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

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

ได้ สามารถเริ่มใช้ 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 เพื่อเรียนรู้เพิ่มเติม

สามารถดูข้อมูลความเข้ากันได้ของ Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v1 ได้ที่นี่ สามารถดูข้อมูลความเข้ากันได้ของ Aurora ที่ไม่ต้องใช้เซิร์ฟเวอร์ v2 ได้ที่นี่

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

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

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

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

ใน Aurora ไม่ต้องใช้เซิร์ฟเวอร์ ความจุของฐานข้อมูลจะวัดเป็น Aurora Capacity Unit (ACU) คุณจ่ายอัตราคงที่ต่อวินาทีของการใช้งาน ACU ราคาของสตอเรจและ I/O จะเท่ากันสำหรับการกำหนดค่าแบบเตรียมใช้งานและแบบไร้เซิร์ฟเวอร์ ไปที่หน้าราคาของ Aurora เพื่อดูข้อมูลล่าสุดเกี่ยวกับราคาและความพร้อมใช้งานภูมิภาคของ AWS (AWS Region)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 โดยทันที และแจ้งข้อมูลการวินิจฉัย รายละเอียดขอบเขตปัญหา และคำแนะนำการแก้ไขปัญหาอัจฉริยะ เพื่อช่วยให้ลูกค้าสามารถแก้ไขปัญหาคอขวดด้านประสิทธิภาพและปัญหาด้านการทำงานที่เกี่ยวข้องกับฐานข้อมูลได้อย่างรวดเร็ว

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

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

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

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

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

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