Cara kerja Aurora Serverless v2 - Amazon Aurora

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Cara kerja Aurora Serverless v2

Gambaran umum berikut menjelaskan cara kerja Aurora Serverless v2.

Gambaran umum Aurora Serverless v2

Amazon Aurora Serverless v2 cocok untuk beban kerja yang paling menuntut dan sangat bervariasi. Misalnya, penggunaan basis data Anda mungkin berat untuk waktu yang singkat, diikuti dengan aktivitas ringan dalam waktu lama atau tidak ada aktivitas sama sekali. Beberapa contohnya adalah situs web retail, game, atau olahraga dengan peristiwa promosi berkala, dan basis data yang menghasilkan laporan jika diperlukan. Contoh lainnya adalah lingkungan pengembangan dan pengujian, serta aplikasi baru yang penggunaannya dapat meningkat dengan cepat. Untuk kasus seperti ini dan banyak kasus lainnya, mengonfigurasi kapasitas dengan benar sebelumnya tidak selalu dapat dilakukan dengan model terprovisi. Hal ini juga dapat mengakibatkan biaya yang lebih tinggi jika Anda menetapkan penyediaan yang berlebih dan memiliki kapasitas yang tidak Anda gunakan.

Sebaliknya, klaster terprovisi Aurora cocok untuk beban kerja yang stabil. Dengan cluster yang disediakan, Anda memilih kelas instans DB yang memiliki jumlah memori, daya CPU, I/O bandwidth, dan sebagainya yang telah ditentukan sebelumnya. Jika beban kerja Anda berubah, Anda secara manual memodifikasi kelas instans penulis dan pembaca Anda. Model terprovisi berfungsi dengan baik saat Anda dapat menyesuaikan kapasitas sebelum pola konsumsi yang diharapkan dan Anda sanggup mengalami pemadaman singkat saat mengubah kelas instans penulis dan pembaca di klaster Anda.

Aurora Serverless v2 dirancang secara menyeluruh untuk mendukung klaster DB nirserver yang dapat diskalakan secara instan. Aurora Serverless v2 direkayasa untuk memberikan tingkat keamanan dan isolasi yang sama seperti penulis dan pembaca terprovisi. Aspek-aspek ini sangat penting dalam lingkungan cloud nirserver multi-penghuni. Mekanisme penskalaan dinamis memiliki overhead yang sangat sedikit sehingga dapat merespons dengan cepat perubahan beban kerja basis data. Mekanisme ini juga cukup kuat untuk memenuhi permintaan memproses permintaan yang meningkat secara drastis.

Dengan menggunakan Aurora Serverless v2, Anda dapat membuat klaster DB Aurora tanpa dibatasi kapasitas basis data tertentu untuk setiap penulis dan pembaca. Anda menentukan rentang kapasitas minimum dan maksimum. Aurora menskalakan setiap penulis atau pembaca Aurora Serverless v2 di klaster dalam rentang kapasitas tersebut. Dengan menggunakan klaster Multi-AZ yang memungkinkan setiap penulis atau pembaca diskalakan secara dinamis, Anda dapat memanfaatkan penskalaan dinamis dan ketersediaan tinggi.

Aurora Serverless v2 menskalakan sumber daya basis data secara otomatis berdasarkan spesifikasi kapasitas minimum dan maksimum Anda. Penskalaan dilakukan dengan cepat karena sebagian besar operasi peristiwa penskalaan mempertahankan penulis atau pembaca di host yang sama. Dalam kasus yang jarang terjadi saat penulis atau pembaca Aurora Serverless v2 dipindahkan dari satu host ke host lainnya, Aurora Serverless v2 akan mengelola koneksinya secara otomatis. Anda tidak perlu mengubah kode aplikasi klien basis data Anda atau string koneksi basis data Anda.

Dengan Aurora Serverless v2, seperti halnya klaster terprovisi, kapasitas penyimpanan dan kapasitas komputasinya terpisah. Ketika kita mengacu pada kapasitas dan penskalaan Aurora Serverless v2, selalu kapasitas komputasinya yang meningkat atau menurun. Dengan demikian, klaster Anda dapat berisi banyak terabyte data bahkan ketika kapasitas CPU dan memori diturunkan skalanya ke tingkat rendah.

Alih-alih menyediakan dan mengelola server basis data, Anda menentukan kapasitas basis data. Untuk detail tentang kapasitas Aurora Serverless v2, lihat Kapasitas Aurora Serverless v2. Kapasitas sebenarnya setiap penulis atau pembaca Aurora Serverless v2 bervariasi dari waktu ke waktu, tergantung pada beban kerja Anda. Untuk detail tentang mekanisme tersebut, lihat Penskalaan Aurora Serverless v2.

penting

Dengan Aurora Serverless v1, klaster Anda memiliki satu ukuran kapasitas komputasi yang dapat diskalakan antara nilai kapasitas minimum dan maksimum. Dengan Aurora Serverless v2, klaster Anda dapat berisi pembaca selain penulis. Setiap penulis dan pembaca Aurora Serverless v2 dapat diskalakan antara nilai kapasitas minimum dan maksimum. Dengan demikian, total kapasitas klaster Aurora Serverless v2 Anda tergantung pada rentang kapasitas yang Anda tentukan untuk klaster DB Anda serta jumlah penulis dan pembaca di klaster ini. Pada waktu tertentu, Anda hanya dikenai biaya untuk kapasitas Aurora Serverless v2 yang secara aktif digunakan dalam klaster DB Aurora Anda.

Konfigurasi untuk cluster Aurora DB

Untuk setiap klaster DB Aurora Anda, Anda dapat memilih kombinasi kapasitas Aurora Serverless v2, kapasitas terprovisi, atau keduanya.

Anda dapat mengatur klaster yang berisi kapasitas Aurora Serverless v2 dan kapasitas terprovisi, yang disebut klaster konfigurasi campuran. Misalnya, Anda membutuhkan read/write kapasitas lebih dari yang tersedia untuk seorang Aurora Serverless v2 penulis. Dalam hal ini, Anda dapat mengatur klaster dengan penulis terprovisi yang sangat besar. Dalam hal ini, Anda masih dapat menggunakan Aurora Serverless v2 untuk pembaca. Atau anggaplah beban kerja tulis untuk klaster Anda bervariasi, tetapi beban kerja baca stabil. Dalam hal ini, Anda dapat mengatur klaster Anda dengan sebuah penulis Aurora Serverless v2 dan satu atau beberapa pembaca terprovisi.

Anda juga dapat mengatur klaster DB yang semua kapasitasnya dikelola oleh Aurora Serverless v2. Untuk melakukannya, Anda dapat membuat klaster baru dan menggunakan Aurora Serverless v2 dari awal. Atau Anda dapat mengganti semua kapasitas terprovisi di klaster yang ada dengan Aurora Serverless v2. Misalnya, beberapa jalur peningkatan dari versi mesin yang lebih lama harus dimulai dengan penulis terprovisi lalu diganti dengan penulis Aurora Serverless v2. Untuk prosedur dalam membuat klaster DB baru dengan Aurora Serverless v2 atau untuk mengalihkan klaster DB yang ada ke Aurora Serverless v2, lihat Membuat Aurora Serverless v2 klaster DB. dan Beralih dari klaster yang disediakan ke Aurora Serverless v2.

Jika Anda tidak menggunakan Aurora Serverless v2 sama sekali dalam klaster DB, semua penulis dan pembaca di klaster DB akan memiliki jenis terprovisi. Ini adalah jenis klaster DB terlama dan paling umum yang sudah dikenal oleh sebagian besar pengguna. Bahkan, sebelum Aurora Serverless, tidak ada nama khusus untuk klaster DB Aurora semacam ini. Kapasitas terprovisi bersifat konstan. Biayanya relatif mudah untuk diperkirakan. Namun, Anda harus memprediksi sebelumnya berapa banyak kapasitas yang Anda butuhkan. Dalam beberapa kasus, prediksi Anda mungkin tidak akurat atau kebutuhan kapasitas Anda mungkin berubah. Dalam kasus ini, klaster DB Anda dapat mengalami kekurangan penyediaan (lebih lambat dari yang Anda inginkan) atau kelebihan penyediaan (lebih mahal dari yang Anda inginkan).

Kapasitas Aurora Serverless v2

Unit ukur untuk Aurora Serverless v2 adalah unit kapasitas Aurora (ACU). Kapasitas Aurora Serverless v2 tidak terkait dengan kelas instans DB yang Anda gunakan untuk klaster terprovisi.

Setiap ACU adalah kombinasi dari sekitar 2 gibibyte (GiB) memori, CPU yang sesuai, dan jaringan. Anda menentukan rentang kapasitas basis data menggunakan unit ukur ini. Metrik ACUUtilization dan ServerlessDatabaseCapacity membantu Anda menentukan berapa banyak kapasitas yang sebenarnya digunakan basis data Anda dan di mana kapasitas tersebut berada dalam rentang yang ditentukan.

Setiap penulis atau pembaca DB Aurora Serverless v2 memiliki kapasitas setiap saat. Kapasitas direpresentasikan sebagai angka floating-point yang mewakili. ACUs Kapasitas ini meningkat atau menurun setiap kali penulis atau pembaca diskalakan. Nilai ini diukur setiap detik. Untuk setiap klaster DB tempat Anda ingin menggunakan Aurora Serverless v2, Anda menentukan rentang kapasitas: nilai kapasitas minimum dan maksimum untuk menskalakan setiap penulis atau pembaca Aurora Serverless v2. Rentang kapasitasnya sama untuk setiap penulis atau pembaca Aurora Serverless v2 dalam klaster DB. Setiap penulis atau pembaca Aurora Serverless v2 memiliki kapasitasnya sendiri, yang berada pada titik tertentu dalam rentang tersebut.

Tabel berikut menunjukkan rentang Aurora Serverless v2 kapasitas dan dukungan versi engine untuk Aurora MySQL dan Aurora PostgreSQL.

Rentang kapasitas (ACUs) Versi yang didukung Aurora MySQL Aurora PostgreSQL versi yang didukung
0,5—128 3.02.0 dan lebih tinggi 13.6 dan lebih tinggi, 14.3 dan lebih tinggi, 15.2 dan lebih tinggi, 16.1 dan lebih tinggi
0,5—256 3.06.0 dan lebih tinggi 13.13 dan lebih tinggi, 14.10 dan lebih tinggi, 15.5 dan lebih tinggi, 16.1 dan lebih tinggi
0—256 3.08.0 dan lebih tinggi 13.15 dan lebih tinggi, 14.12 dan lebih tinggi, 15.7 dan lebih tinggi, 16.3 dan lebih tinggi

Tabel berikut menunjukkan versi Aurora Serverless v2 platform dengan rentang ACU dan karakteristik kinerjanya.

Aurora Serverless v2versi platform Rentang ACU Performa
1 0—128 Kinerja dasar
2 0—256 Kinerja dasar
3 0—256 Hingga 30% peningkatan kinerja dibandingkan dengan platform versi 2
catatan

Rentang penskalaan yang tersedia untuk cluster tertentu ditentukan oleh versi mesin dan versi platform. Dimungkinkan untuk memiliki versi mesin yang lebih mumpuni yang berjalan pada versi platform yang kurang mampu dan sebaliknya. Rentang penskalaan ditentukan oleh mesin atau versi platform berkemampuan terendah.

Anda dapat menentukan versi platform apa yang dijalankan klaster Anda di bagian Konfigurasi Instans AWS Management Console atau melalui API dengan melihat file ServerlessV2PlatformVersion untuk file DBCluster.

Aurora Serverless v2Kapasitas terkecil yang dapat Anda tentukan adalah 0 ACUs, untuk Aurora Serverless v2 versi yang mendukung fitur jeda otomatis. Anda dapat menentukan angka yang lebih tinggi jika kapasitasnya kurang dari atau sama dengan nilai kapasitas maksimum. Mengatur kapasitas minimum ke angka kecil akan memungkinkan klaster DB yang berbeban ringan mengonsumsi sumber daya komputasi minimal. Pada saat yang sama, klaster tersebut tetap siap untuk menerima koneksi dengan segera dan menaikkan skalanya ketika menjadi sibuk.

Kami merekomendasikan pengaturan kapasitas minimum ke sebuah nilai yang memungkinkan setiap penulis atau pembaca DB mempertahankan rangkaian aplikasi yang beroperasi di pool buffer. Dengan begitu, konten pool buffer tidak dibuang selama periode idle. Untuk semua pertimbangan saat memilih nilai kapasitas minimum, lihat Memilih pengaturan kapasitas Aurora Serverless v2 minimum untuk klaster. Untuk semua pertimbangan saat memilih nilai kapasitas maksimum, lihat Memilih pengaturan kapasitas Aurora Serverless v2 maksimum untuk klaster.

Bergantung pada bagaimana Anda mengkonfigurasi pembaca dalam penyebaran multi-AZ, kapasitas mereka dapat dikaitkan dengan kapasitas penulis atau secara mandiri. Untuk detail tentang cara melakukannya, lihat Penskalaan Aurora Serverless v2.

Pemantauan Aurora Serverless v2 berkaitan dengan pengukuran nilai kapasitas untuk penulis dan pembaca di klaster DB Anda dari waktu ke waktu. Jika basis data Anda tidak menurunkan skalanya ke kapasitas minimum, Anda dapat mengambil tindakan seperti menyesuaikan kapasitas minimum dan mengoptimalkan aplikasi basis data Anda. Jika basis data Anda secara konsisten mencapai kapasitas maksimumnya, Anda dapat mengambil tindakan seperti meningkatkan kapasitas maksimum. Anda juga dapat mengoptimalkan aplikasi basis data Anda dan menyebarkan beban kueri ke lebih banyak pembaca.

Biaya untuk kapasitas Aurora Serverless v2 diukur dalam hal ACU-jam. Untuk informasi tentang cara penghitungan biaya Aurora Serverless v2, lihat halaman Harga Aurora.

Misalkan jumlah total penulis dan pembaca di cluster Anda adalahn. Dalam hal ini, cluster mengkonsumsi kira-kira n x minimum ACUs ketika Anda tidak menjalankan operasi database apa pun. Aurora sendiri mungkin menjalankan operasi pemantauan atau pemeliharaan yang menyebabkan sejumlah kecil beban. Klaster tersebut mengonsumsi tidak lebih dari n x maximum ACUs ketika basis data berjalan pada kapasitas penuh.

Untuk detail selengkapnya tentang memilih nilai ACU minimum dan maksimum yang sesuai, lihat Memilih rentang kapasitas Aurora Serverless v2 untuk klaster Aurora. Nilai ACU minimum dan maksimum yang Anda tentukan juga memengaruhi cara kerja beberapa parameter konfigurasi Aurora untuk Aurora Serverless v2. Untuk detail tentang interaksi antara rentang kapasitas dan parameter konfigurasi, lihat Menggunakan grup parameter untuk Aurora Serverless v2.

Penskalaan Aurora Serverless v2

Untuk setiap penulis atau pembaca Aurora Serverless v2, Aurora terus melacak pemanfaatan sumber daya seperti CPU, memori, dan jaringan. Pengukuran ini secara kolektif disebut beban. Beban mencakup operasi basis data yang dilakukan oleh aplikasi Anda. Hal ini juga mencakup pemrosesan latar belakang untuk server basis data dan tugas administratif Aurora. Ketika kapasitas dibatasi oleh salah satu dari hal ini, Aurora Serverless v2 akan menaikkan skalanya. Aurora Serverless v2 juga menaikkan skalanya ketika mendeteksi masalah performa yang dapat diselesaikan dengan penaikan skala. Anda dapat memantau pemanfaatan sumber daya dan pengaruhnya terhadap penskalaan Aurora Serverless v2 dengan menggunakan prosedur dalam CloudWatch Metrik Amazon penting untuk Aurora Serverless v2 dan Memantau performa Aurora Serverless v2 dengan Wawasan Performa.

Beban dapat bervariasi di seluruh penulis dan pembaca di klaster DB Anda. Penulis menangani semua laporan bahasa definisi data (DDL), seperti CREATE TABLE, ALTER TABLE, dan DROP TABLE. Penulis juga menangani semua laporan bahasa manipulasi data (DML), seperti INSERT dan UPDATE. Pembaca dapat memproses pernyataan hanya baca, seperti kueri SELECT.

Penskalaan adalah operasi yang meningkatkan atau menurunkan kapasitas Aurora Serverless v2 untuk basis data Anda. DenganAurora Serverless v2, setiap penulis dan pembaca memiliki nilai kapasitasnya sendiri saat ini, diukur dalam ACUs. Aurora Serverless v2skala penulis atau pembaca hingga kapasitas yang lebih tinggi ketika kapasitas saat ini terlalu rendah untuk menangani beban. Operasi ini menurunkan skala penulis atau pembaca ke kapasitas yang lebih rendah ketika kapasitas saat ini lebih tinggi dari yang dibutuhkan.

Tidak seperti Aurora Serverless v1, yang diskalakan dengan menggandakan kapasitas setiap kali klaster DB mencapai ambang batas, Aurora Serverless v2 dapat meningkatkan kapasitas secara bertahap. Ketika permintaan beban kerja Anda mulai mencapai kapasitas database saat ini dari seorang penulis atau pembaca, Aurora Serverless v2 meningkatkan jumlah ACUs untuk penulis atau pembaca itu. Aurora Serverless v2skala kapasitas dalam peningkatan yang diperlukan untuk memberikan kinerja terbaik untuk sumber daya yang dikonsumsi. Penskalaan terjadi secara bertahap sekecil 0,5. ACUs Semakin besar kapasitas saat ini, semakin besar inkremen penskalaan dan akibatnya semakin cepat penskalaan dapat terjadi.

Karena Aurora Serverless v2 penskalaan sangat sering, granular, dan tidak mengganggu, itu tidak menyebabkan peristiwa diskrit seperti itu AWS Management Console . Aurora Serverless v1 Sebagai gantinya, Anda dapat mengukur CloudWatch metrik Amazon seperti ServerlessDatabaseCapacity dan ACUUtilization dan melacak nilai minimum, maksimum, dan rata-ratanya dari waktu ke waktu. Untuk mempelajari selengkapnya tentang metrik Aurora, lihat Memantau metrik di klaster Amazon Aurora. Untuk tips tentang pemantauan Aurora Serverless v2, lihat CloudWatch Metrik Amazon penting untuk Aurora Serverless v2.

Anda dapat memilih untuk membuat pembaca diskalakan pada saat yang sama dengan penulis terkait, atau secara independen dari penulis. Anda dapat melakukannya dengan menentukan tingkat promosi untuk pembaca tersebut.

  • Pembaca di tingkat promosi 0 dan 1 akan diskalakan pada saat yang sama dengan penulis. Perilaku penskalaan tersebut membuat pembaca di tingkat prioritas 0 dan 1 cocok untuk mendukung ketersediaan. Hal ini karena pembaca tersebut selalu diatur ukurannya sesuai dengan kapasitas yang tepat untuk mengambil alih beban kerja dari penulis jika terjadi failover.

  • Pembaca di tingkat promosi 2–15 akan diskalakan secara independen dari penulis. Setiap pembaca tetap berada dalam nilai ACU minimum dan maksimum yang Anda tentukan untuk klaster Anda. Ketika pembaca diskalakan secara independen dari DB penulis terkait, pembaca tersebut bisa menjadi idle dan menurunkan skalanya sementara penulis terus memproses volume transaksi yang tinggi. Pembaca tersebut masih tersedia sebagai target failover jika tidak ada pembaca lain yang tersedia di tingkat promosi yang lebih rendah. Namun, jika dipromosikan menjadi penulis, pembaca tersebut mungkin perlu dinaikkan skalanya untuk menangani beban kerja penuh dari penulis.

Untuk detail tentang tingkat promosi, lihat Memilih tingkat promosi untuk pembaca Aurora Serverless v2.

Gagasan tentang titik penskalaan dan periode batas waktu terkait dari Aurora Serverless v1 tidak berlaku di Aurora Serverless v2. Penskalaan Aurora Serverless v2 dapat terjadi saat koneksi basis data terbuka, saat transaksi SQL sedang dalam proses, saat tabel dikunci, dan saat tabel sementara sedang digunakan. Aurora Serverless v2 tidak menunggu titik tenang untuk memulai penskalaan. Penskalaan tidak mengganggu operasi basis data apa pun yang sedang berlangsung.

Jika beban kerja Anda membutuhkan lebih banyak kapasitas baca daripada yang tersedia dengan satu penulis dan satu pembaca, Anda dapat menambahkan beberapa pembaca Aurora Serverless v2 ke klaster. Setiap pembaca Aurora Serverless v2 dapat diskalakan dalam rentang nilai kapasitas minimum dan maksimum yang Anda tentukan untuk klaster DB Anda. Anda dapat menggunakan titik akhir pembaca klaster untuk mengarahkan sesi hanya baca ke pembaca dan mengurangi beban pada penulis.

Apakah Aurora Serverless v2 melakukan penskalaan atau tidak, dan seberapa cepat penskalaan terjadi begitu dimulai, juga akan tergantung pada pengaturan ACU minimum dan maksimum untuk klaster. Selain itu, hal tersebut bergantung pada apakah pembaca dikonfigurasi untuk diskalakan bersama dengan penulis atau secara independen. Untuk detail tentang faktor-faktor yang memengaruhi penskalaan Aurora Serverless v2, lihat Performa dan penskalaan untuk Aurora Serverless v2.

Penskalaan ke Nol

Dalam versi Aurora MySQL dan Aurora PostgreSQL baru-baru ini, penulis dan pembaca dapat menurunkan skala hingga nol. Aurora Serverless v2 ACUs Kami menyebut kemampuan ini sebagai jeda dan lanjutkan otomatis, atau jeda otomatis. Anda dapat memilih apakah akan mengizinkan perilaku ini dengan menentukan nilai nol atau bukan nol untuk kapasitas minimum. Anda juga dapat memilih berapa lama untuk menunggu sebelum sebuah Aurora Serverless v2 instance berhenti. Untuk informasi tentang versi mana yang memiliki kemampuan ini, lihatKapasitas Aurora Serverless v2. Untuk informasi tentang cara menggunakannya secara efektif, lihatPenskalaan ke Nol ACUs dengan jeda otomatis dan lanjutkan Aurora Serverless v2.

Dalam versi Aurora MySQL dan Aurora PostgreSQL yang lebih lama, penulis dan pembaca yang tidak Aurora Serverless v2 aktif dapat menurunkan ke nilai ACU minimum yang Anda tentukan untuk cluster, tetapi tidak sampai nol. ACUs Dalam hal ini, nol ACUs tidak tersedia sebagai pilihan saat Anda mengatur rentang kapasitas. Perilaku tersebut berbeda dari Aurora Serverless v1, yang dapat dijeda setelah periode idle, tetapi kemudian membutuhkan waktu untuk dilanjutkan ketika Anda membuka koneksi baru.

Ketika cluster DB Anda dengan Aurora Serverless v2 kapasitas tidak diperlukan untuk beberapa waktu, Anda juga dapat menghentikan dan memulai seluruh cluster, sama seperti dengan cluster DB yang disediakan. Teknik ini paling tepat untuk pengembangan dan pengujian sistem, di mana mereka mungkin tidak diperlukan selama berjam-jam pada suatu waktu, dan kecepatan melanjutkan cluster tidak penting. Fitur stop/start cluster tersedia untuk semua Aurora Serverless v2 versi. Untuk informasi selengkapnya tentang fitur tersebut, lihatMenghentikan dan memulai klaster DB Amazon Aurora.

Aurora Serverless v2 dan ketersediaan tinggi

Cara untuk menetapkan ketersediaan tinggi untuk klaster DB Aurora adalah dengan menjadikannya sebagai klaster DB Multi-AZ. Klaster DB Aurora Multi-AZ memiliki kapasitas komputasi yang tersedia setiap saat di lebih dari satu Zona Ketersediaan (AZ). Konfigurasi tersebut membuat basis data Anda tetap aktif dan berjalan bahkan jika terjadi pemadaman yang signifikan. Aurora melakukan failover otomatis jika terjadi masalah yang memengaruhi penulis atau bahkan seluruh AZ. Dengan Aurora Serverless v2, Anda dapat memilih kapasitas komputasi siaga yang akan dinaikkan dan diturunkan skalanya bersama dengan kapasitas penulis. Dengan begitu, kapasitas komputasi di AZ kedua siap mengambil alih beban kerja saat ini kapan saja. Pada saat yang sama, kapasitas komputasi di semua AZs dapat menurunkan skala ketika database menganggur. Untuk detail tentang cara kerja Aurora Wilayah AWS dan Availability Zones, lihat. Ketersediaan yang tinggi untuk instans DB Aurora

Kemampuan Multi-AZ Aurora Serverless v2 menggunakan pembaca selain penulis. Dukungan untuk pembaca baru tersedia di Aurora Serverless v2 dibandingkan dengan Aurora Serverless v1. Anda dapat menambahkan hingga 15 Aurora Serverless v2 pembaca yang tersebar di 3 AZs ke cluster Aurora DB.

Untuk aplikasi bisnis penting yang harus tetap tersedia bahkan jika terjadi masalah yang memengaruhi seluruh klaster Anda atau seluruh AWS Wilayah, Anda dapat menyiapkan basis data global Aurora. Anda dapat menggunakan kapasitas Aurora Serverless v2 di klaster sekunder agar siap mengambil alih selama pemulihan bencana. Klaster tersebut juga dapat menurunkan skalanya ketika basis data tidak sibuk. Untuk detail tentang basis data global Aurora, lihat Menggunakan Database Global Amazon Aurora.

Aurora Serverless v2 berfungsi seperti klaster terprovisi untuk failover dan fitur ketersediaan tinggi lainnya. Untuk informasi selengkapnya, lihat Ketersediaan yang tinggi untuk Amazon Aurora.

Misalkan Anda ingin memastikan ketersediaan maksimum untuk klaster Aurora Serverless v2 Anda. Anda dapat membuat pembaca selain penulis. Jika Anda menetapkan pembaca ke tingkat promosi 0 atau 1, penskalaan apa pun yang terjadi pada penulis juga terjadi pada pembaca. Dengan begitu, pembaca dengan kapasitas yang sama selalu siap mengambil alih untuk penulis jika terjadi failover.

Misalkan Anda ingin menjalankan laporan triwulanan untuk bisnis Anda seiring klaster Anda terus memproses transaksi. Jika Anda menambahkan pembaca Aurora Serverless v2 ke klaster dan menetapkannya ke tingkat promosi dari 2 hingga 15, Anda dapat terhubung langsung ke pembaca tersebut untuk menjalankan laporan. Bergantung pada berapa banyak memori dan CPU yang diperlukan kueri pelaporan, pembaca dapat menaikkan skala untuk mengakomodasi beban kerja. Pembaca ini kemudian dapat kembali diturunkan skalanya ketika laporannya sudah selesai.

Aurora Serverless v2 dan penyimpanan

Penyimpanan untuk setiap cluster Aurora DB terdiri dari enam salinan dari semua data Anda, tersebar di tiga. AZs Replikasi data default ini berlaku terlepas dari apakah klaster DB Anda mencakup pembaca selain penulis. Dengan begitu, data Anda aman, bahkan dari masalah yang memengaruhi kapasitas komputasi klaster.

Penyimpanan Aurora Serverless v2 memiliki karakteristik keandalan dan durabilitas yang sama seperti yang dijelaskan dalam Penyimpanan Amazon Aurora. Hal ini karena penyimpanan untuk klaster DB Aurora beroperasi dengan cara yang sama, baik kapasitas komputasinya menggunakan Aurora Serverless v2 maupun terprovisi.

Parameter konfigurasi untuk klaster Aurora

Anda dapat menyesuaikan semua parameter konfigurasi klaster dan basis data yang sama untuk klaster dengan kapasitas Aurora Serverless v2 seperti untuk klaster DB terprovisi. Namun, beberapa parameter terkait kapasitas ditangani secara berbeda untuk Aurora Serverless v2. Dalam klaster konfigurasi campuran, nilai parameter yang Anda tentukan untuk parameter terkait kapasitas tersebut masih berlaku untuk penulis dan pembaca terprovisi.

Hampir semua parameter beroperasi dengan cara yang sama untuk penulis Aurora Serverless v2 dan pembaca seperti untuk klaster terprovisi. Hal ini tidak termasuk beberapa parameter yang disesuaikan oleh Aurora secara otomatis selama penskalaan, dan beberapa parameter yang disimpan oleh Aurora pada nilai tetap yang bergantung pada pengaturan kapasitas maksimum.

Misalnya, jumlah memori yang dicadangkan untuk cache buffer meningkat saat penulis atau pembaca dinaikkan skalanya, dan berkurang saat penulis atau pembaca diturunkan skalanya. Dengan begitu, memori dapat dilepaskan ketika basis data Anda tidak sibuk. Sebaliknya, Aurora secara otomatis menetapkan jumlah maksimum koneksi ke nilai yang sesuai berdasarkan pengaturan kapasitas maksimum. Dengan begitu, koneksi aktif tidak terputus jika beban berkurang dan Aurora Serverless v2 menurunkan skalanya. Untuk informasi tentang cara Aurora Serverless v2 menangani parameter tertentu, lihat Menggunakan grup parameter untuk Aurora Serverless v2.