Mengelola Aurora Serverless v2 Klaster DB - Amazon Aurora

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

Mengelola Aurora Serverless v2 Klaster DB

Dengan Aurora Serverless v2, cluster Anda dapat dipertukarkan dengan cluster yang disediakan. Bagian Aurora Serverless v2 properti berlaku untuk satu atau lebih instance DB dalam cluster DB. Dengan demikian, prosedur untuk membuat klaster, memodifikasi klaster, membuat dan memulihkan snapshot, dan sebagainya, pada dasarnya sama dengan jenis klaster Aurora lainnya. Untuk prosedur umum untuk mengelola klaster Aurora dan instans DB, lihat Mengelola klaster DB Amazon Aurora.

Dalam topik berikut, Anda dapat mempelajari tentang pertimbangan manajemen untuk cluster yang berisi Aurora Serverless v2 Instans DB.

Mengatur Aurora Serverless v2 rentang kapasitas untuk sebuah cluster

Untuk memodifikasi parameter konfigurasi atau pengaturan lain untuk cluster yang berisi Aurora Serverless v2 Instans DB, atau instans DB itu sendiri, mengikuti prosedur umum yang sama seperti untuk cluster yang disediakan. Untuk detailnya, lihat Memodifikasi klaster DB Amazon Aurora.

Pengaturan paling penting yang unik untuk Aurora Serverless v2 adalah rentang kapasitas. Setelah Anda menetapkan nilai unit kapasitas Aurora minimum dan maksimum (ACU) untuk cluster Aurora, Anda tidak perlu secara aktif menyesuaikan kapasitas Aurora Serverless v2 Instans DB di cluster. Aurora akan melakukannya untuk Anda. Pengaturan ini dikelola pada tingkat klaster. Nilai ACU minimum dan maksimum yang sama berlaku untuk masing-masing Aurora Serverless v2 Instans DB di cluster.

Anda dapat mengatur nilai spesifik berikut:

  • Minimum ACUs — Aurora Serverless v2 Instans DB dapat mengurangi kapasitas hingga jumlah ini ACUs.

  • Maksimum ACUs — Aurora Serverless v2 Instans DB dapat meningkatkan kapasitas hingga jumlah ini ACUs.

Versi mesin DB yang lebih baru memungkinkan kapasitas maksimum 256 ACUs, kapasitas minimum 0 ACUs, atau keduanya. Untuk rentang kapasitas untuk berbagai versi mesin DB, lihatAurora Serverless v2 kapasitas.

Untuk kemampuan jeda otomatis dan lanjutkan yang diaktifkan dengan menyetel kapasitas minimum ke 0 ACUs, lihat. Penskalaan ke Nol ACUs dengan jeda otomatis dan lanjutkan Aurora Serverless v2

Untuk informasi lebih lanjut tentang memastikan bahwa Aurora Serverless v2 Cluster DB dapat menskalakan hingga 256 ACUs, lihatUpgrade Anda Aurora Serverless v2 Cluster DB untuk memungkinkan penskalaan hingga 256 ACUs.

catatan

Ketika Anda memodifikasi rentang kapasitas untuk Aurora Serverless v2 Cluster DB, perubahan terjadi segera, terlepas dari apakah Anda memilih untuk menerapkannya segera atau selama jendela pemeliharaan terjadwal berikutnya.

Masuk Aurora Serverless v2, Anda tidak dapat langsung mengatur kapasitas saat ini tanpa memodifikasi rentang kapasitas, karena kapasitas menyesuaikan secara dinamis berdasarkan beban kerja dalam rentang yang ditentukan. Namun, Anda dapat memengaruhi kapasitas secara tidak langsung dengan cara-cara berikut:

  • Sesuaikan kapasitas minimum — Turunkan sementara kapasitas minimum untuk mengurangi kapasitas dasar saat beban kerja ringan.

  • Jeda penskalaan sementara — Untuk memperbaiki kapasitas pada nilai tertentu, atur kapasitas minimum dan maksimum ke tingkat yang sama.

  • Skala proaktif untuk penggunaan yang meledak — Jika Anda mengantisipasi beban kerja yang meledak, tingkatkan kapasitas minimum sebelumnya untuk mempertahankan baseline yang lebih tinggi selama periode aktivitas tinggi.

Untuk mengetahui detail tentang efek rentang kapasitas dan cara memantau dan menyesuaikannya, lihat CloudWatch Metrik Amazon penting untuk Aurora Serverless v2 dan Kinerja dan penskalaan untuk Aurora Serverless v2. Tujuan Anda adalah memastikan bahwa kapasitas maksimum klaster cukup tinggi untuk menangani lonjakan beban kerja, dan kapasitas minimumnya cukup rendah untuk meminimalkan biaya saat klaster tidak sibuk.

Misalnya, berdasarkan pemantauan, Anda menentukan bahwa rentang ACU untuk klaster harus lebih tinggi, lebih rendah, lebih luas, atau lebih sempit. Anda dapat mengatur kapasitas cluster Aurora ke rentang tertentu ACUs dengan, API AWS Management Console AWS CLI, atau Amazon RDS. Rentang kapasitas ini berlaku untuk setiap Aurora Serverless v2 Instans DB di cluster.

Misalnya, cluster Anda memiliki rentang kapasitas 1-16 ACUs dan berisi dua Aurora Serverless v2 Instans DB. Kemudian cluster secara keseluruhan mengkonsumsi antara 2 ACUs (saat idle) dan 32 ACUs (bila digunakan sepenuhnya). Jika Anda mengubah rentang kapasitas dari 8 menjadi 40,5 ACUs, sekarang seluruh cluster mengkonsumsi 16 ACUs saat idle, dan hingga 81 ACUs saat digunakan sepenuhnya.

Aurora secara otomatis menetapkan parameter tertentu untuk Aurora Serverless v2 Instans DB ke nilai yang bergantung pada nilai ACU maksimum dalam rentang kapasitas. Untuk mengetahui daftar parameter tersebut, lihat Koneksi maksimum untuk Aurora Serverless v2. Untuk parameter statis yang bergantung pada jenis perhitungan ini, nilainya dievaluasi lagi saat Anda mem-boot ulang instans DB. Dengan demikian, Anda dapat memperbarui nilai parameter tersebut dengan mem-boot ulang instans DB setelah mengubah rentang kapasitas. Untuk memeriksa apakah Anda perlu mem-boot ulang instans DB Anda untuk menerapkan perubahan parameter tersebut, lihat atribut ParameterApplyStatus instans DB. Nilai pending-reboot menunjukkan bahwa boot ulang akan menerapkan perubahan pada beberapa nilai parameter.

Anda dapat mengatur rentang kapasitas cluster yang berisi Aurora Serverless v2 Instans DB dengan. AWS Management Console

Saat Anda menggunakan konsol, Anda mengatur rentang kapasitas untuk cluster pada saat Anda menambahkan yang pertama Aurora Serverless v2 Instans DB ke cluster itu. Anda dapat melakukannya saat Anda memilih kelas instans DB Nirserver v2 untuk instans DB penulis saat Anda membuat klaster. Atau Anda mungkin melakukannya ketika Anda memilih kelas instans DB Tanpa Server saat Anda menambahkan Aurora Serverless v2 pembaca instance DB ke cluster. Anda juga dapat melakukannya saat mengonversi instans DB yang sudah ada di klaster ke kelas instans DB Nirserver. Untuk versi lengkap prosedur tersebut, lihat Membuat Aurora Serverless v2 penulis contoh DB, Menambahkan Aurora Serverless v2 pembaca, dan Mengonversi penulis atau pembaca yang disediakan menjadi Aurora Serverless v2.

Apapun rentang kapasitas yang Anda tetapkan di tingkat cluster berlaku untuk semua Aurora Serverless v2 Instans DB di cluster Anda. Gambar berikut menunjukkan sebuah cluster dengan beberapa Aurora Serverless v2 contoh DB pembaca. Masing-masing memiliki rentang kapasitas yang identik 2-64 ACUs.

Cluster dengan banyak Aurora Serverless v2 instans DB pembaca
Untuk memodifikasi rentang kapasitas suatu Aurora Serverless v2 cluster
  1. Buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Basis Data.

  3. Pilih klaster yang berisi Aurora Serverless v2 Instans DB dari daftar. Cluster harus sudah berisi setidaknya satu Aurora Serverless v2 contoh DB. Jika tidak, Aurora tidak menampilkan bagian Rentang kapasitas.

  4. Untuk Tindakan, pilih Modifikasi.

  5. Di bagian Rentang kapasitas, pilih hal berikut:

    1. Masukkan nilai untuk Minimum ACUs. Konsol menampilkan rentang nilai yang diizinkan. Anda dapat memilih kapasitas minimum dari 0 hingga 256 ACUs. Anda dapat memilih kapasitas maksimum dari 1 hingga 256 ACUs. Anda dapat menyesuaikan nilai kapasitas dengan penambahan 0,5 ACU.

    2. Masukkan nilai untuk Maksimum ACUs. Nilai ini harus lebih besar dari atau sama dengan Minimum ACUs. Konsol menampilkan rentang nilai yang diizinkan. Gambar berikut menunjukkan pilihan tersebut.

      Memodifikasi kapasitas cluster DB.
  6. Pilih Lanjutkan. Halaman Ringkasan modifikasi akan muncul.

  7. Pilih Terapkan segera.

    Perubahan kapasitas terjadi segera, terlepas dari apakah Anda memilih untuk menerapkannya segera atau selama periode pemeliharaan terjadwal berikutnya.

  8. Pilih Ubah klaster untuk menerima ringkasan modifikasi tersebut. Anda juga dapat memilih Kembali untuk memodifikasi perubahan atau Batalkan untuk menghapus perubahan Anda.

Untuk mengatur kapasitas cluster tempat Anda ingin menggunakan Aurora Serverless v2 Instans DB menggunakan AWS CLI, jalankan modify-db-cluster AWS CLI perintah. Tentukan opsi --serverless-v2-scaling-configuration. Cluster mungkin sudah berisi satu atau lebih Aurora Serverless v2 Instans DB, atau Anda dapat menambahkan instans DB nanti. Nilai valid untuk bidang MinCapacity dan MaxCapacity mencakup hal berikut:

  • 0, 0.51,1.5,2,,, dan sebagainya, dalam langkah 0,5, hingga maksimum 256. Nilai ACU minimum 0 hanya tersedia untuk versi Aurora yang mendukung fitur jeda otomatis.

Dalam contoh ini, Anda mengatur rentang ACU dari klaster DB Aurora bernama sample-cluster hingga minimum 48.5 dan maksimum 64.

aws rds modify-db-cluster --db-cluster-identifier sample-cluster \ --serverless-v2-scaling-configuration MinCapacity=48.5,MaxCapacity=64

Perubahan kapasitas terjadi segera, terlepas dari apakah Anda memilih untuk menerapkannya segera atau selama periode pemeliharaan terjadwal berikutnya.

Setelah melakukannya, Anda dapat menambahkan Aurora Serverless v2 Instans DB ke cluster dan setiap instans DB baru dapat menskalakan antara 48,5 dan 64. ACUs Rentang kapasitas baru juga berlaku untuk semua Aurora Serverless v2 Instans DB yang sudah ada di cluster. Instans DB menaikkan dan menurunkan skala jika perlu agar berada dalam rentang kapasitas baru.

Untuk contoh tambahan tentang pengaturan rentang kapasitas menggunakan CLI, lihat Memilih Aurora Serverless v2 rentang kapasitas untuk cluster Aurora.

Untuk mengubah konfigurasi penskalaan Aurora Serverless Cluster DB menggunakan AWS CLI, jalankan modify-db-cluster AWS CLI perintah. Tentukan opsi --serverless-v2-scaling-configuration untuk mengonfigurasi kapasitas minimum dan kapasitas maksimum. Nilai kapasitas yang valid mencakup hal berikut:

  • Aurora MySQL:0,,0.5,1, 1.52, dan sebagainya, dengan penambahan 0,5 hingga maksimum. ACUs 256

  • Aurora PostgreSQL:0,,,,0.5, 11.5, dan sebagainya2, dengan penambahan 0,5 hingga maksimum. ACUs 256

  • Nilai ACU minimum 0 hanya tersedia untuk versi Aurora yang mendukung fitur jeda otomatis.

Dalam contoh berikut, Anda memodifikasi konfigurasi penskalaan Aurora Serverless v2 Instans DB bernama sample-instance itu bagian dari cluster bernamasample-cluster.

Untuk Linux, macOS, atau Unix:

aws rds modify-db-cluster --db-cluster-identifier sample-cluster \ --serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64

Untuk Windows:

aws rds modify-db-cluster --db-cluster-identifier sample-cluster ^ --serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64

Anda dapat mengatur kapasitas instans Aurora DB dengan operasi Modify DBCluster API. Tentukan parameter ServerlessV2ScalingConfiguration. Nilai valid untuk bidang MinCapacity dan MaxCapacity mencakup hal berikut:

  • 0, 0.51,1.5,2,,, dan sebagainya, dalam langkah 0,5, hingga maksimum 256. Nilai ACU minimum 0 hanya tersedia untuk versi Aurora yang mendukung fitur jeda otomatis.

Anda dapat memodifikasi konfigurasi penskalaan klaster yang berisi Aurora Serverless v2 Instans DB dengan operasi Modify DBCluster API. Tentukan parameter ServerlessV2ScalingConfiguration untuk mengonfigurasi kapasitas minimum dan kapasitas maksimum. Nilai kapasitas yang valid mencakup hal berikut:

  • Aurora MySQL:0,,0.5,1, 1.52, dan sebagainya, dengan penambahan 0,5 hingga maksimum. ACUs 256

  • Aurora PostgreSQL:0,,,,0.5, 11.5, dan sebagainya2, dengan penambahan 0,5 hingga maksimum. ACUs 256

  • Nilai ACU minimum 0 hanya tersedia untuk versi Aurora yang mendukung fitur jeda otomatis.

Perubahan kapasitas terjadi segera, terlepas dari apakah Anda memilih untuk menerapkannya segera atau selama periode pemeliharaan terjadwal berikutnya.

Upgrade Anda Aurora Serverless v2 Cluster DB untuk memungkinkan penskalaan hingga 256 ACUs

Dalam beberapa kasus, ketika Anda mencoba untuk menskalakan Aurora Serverless v2 DB cluster untuk kapasitas lebih besar dari 128 ACUs, Anda menerima pesan kesalahan. Pesan kesalahan memberi tahu Anda instance mana yang tidak kompatibel dengan rentang penskalaan baru.

Ketidakmampuan untuk skala lebih besar dari 128 ACUs dapat terjadi karena salah satu dari dua alasan:

  • Versi mesin DB yang lebih lama - Tingkatkan versi mesin DB ke versi yang mendukung 256 ACUs. Untuk informasi selengkapnya, lihat Aurora Serverless v2 kapasitas.

  • Platform lama - Tingkatkan platform yang mendasari untuk Anda Aurora Serverless v2 klaster DB. Anda dapat melakukannya dengan salah satu cara berikut:

    • Hentikan dan restart cluster DB. Ini akan mengakhiri platform dasar yang ada dan menyediakan yang baru yang mampu 256 ACUs.

      Namun, menghentikan dan memulai cluster DB menimbulkan beberapa downtime, biasanya beberapa menit. Untuk informasi selengkapnya, lihat Menghentikan dan memulai klaster DB Amazon Aurora.

    • Ganti instance yang lebih lama dan gagal ke salah satu instance baru.

      1. Tambahkan instance DB pembaca. Instans pembaca baru akan berjalan pada perangkat keras yang diperbarui yang mampu 256 ACUs. Untuk informasi selengkapnya, lihat Menambahkan Aurora Serverless v2 pembaca.

      2. Gagal ke salah satu contoh pembaca baru. Untuk informasi selengkapnya, lihat Gagal atas kluster DB Amazon Aurora.

      3. Setelah gagal, Anda dapat menghapus instance lama, termasuk instance penulis sebelumnya.

    • Gunakan penerapan biru/hijau. Untuk informasi selengkapnya, lihat Ikhtisar Penyebaran RDS Biru/Hijau Amazon Aurora.

      1. Buat penyebaran biru/hijau. Untuk informasi selengkapnya, lihat Membuat penyebaran biru/hijau di Amazon RDS Aurora.

      2. Konfirmasikan bahwa Anda dapat mengatur kapasitas maksimum untuk lingkungan pementasan (hijau) ke 256 ACUs.

      3. Beralih ke lingkungan hijau. Untuk informasi selengkapnya, lihat Mengalihkan penerapan biru/hijau di Amazon RDS Aurora.

      4. Hapus cluster DB asli.

      catatan

      Jika Anda mempertahankan kredensi database AWS Secrets Manager, Anda tidak dapat menggunakan penerapan biru/hijau.

      Aurora Global Database tidak mendukung penerapan biru/hijau.

Memeriksa rentang kapasitas untuk Aurora Serverless v2

Prosedur untuk memeriksa rentang kapasitas untuk Anda Aurora Serverless v2 cluster mengharuskan Anda terlebih dahulu mengatur rentang kapasitas. Jika Anda belum melakukannya, ikuti prosedur dalam Mengatur Aurora Serverless v2 rentang kapasitas untuk sebuah cluster.

Apapun rentang kapasitas yang Anda tetapkan di tingkat cluster berlaku untuk semua Aurora Serverless v2 Instans DB di cluster Anda. Gambar berikut menunjukkan sebuah cluster dengan beberapa Aurora Serverless v2 Instans DB. Masing-masing memiliki rentang kapasitas yang identik.

Detail cluster untuk beberapa Aurora Serverless v2 Instans DB.

Anda juga dapat melihat halaman detail untuk setiap Aurora Serverless v2 Instans DB di cluster. Rentang kapasitas instans DB muncul di tab Konfigurasi.

Opsi Tipe instans, bagian dari antarmuka pengguna konfigurasi instans DB

Anda juga dapat melihat rentang kapasitas saat ini untuk klaster pada halaman Ubah untuk klaster. Pada tahap ini, Anda dapat mengubah rentang kapasitas. Untuk semua cara yang dapat Anda gunakan untuk mengatur atau mengubah rentang kapasitas, lihat Mengatur Aurora Serverless v2 rentang kapasitas untuk sebuah cluster.

Memeriksa rentang kapasitas saat ini untuk klaster Aurora

Anda dapat memeriksa rentang kapasitas yang dikonfigurasi Aurora Serverless v2 Instans DB di cluster dengan memeriksa ServerlessV2ScalingConfiguration atribut untuk cluster. AWS CLI Contoh berikut menunjukkan cluster dengan kapasitas minimum 0,5 unit kapasitas Aurora (ACUs) dan kapasitas maksimum 16. ACUs

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-64-acu-cluster \ --query 'DBClusters[*].[ServerlessV2ScalingConfiguration]' [ [ { "MinCapacity": 0.5, "MaxCapacity": 16.0 } ] ]

Menambahkan Aurora Serverless v2 pembaca

Untuk menambahkan Aurora Serverless v2 pembaca instans DB ke cluster Anda, Anda mengikuti prosedur umum yang sama seperti diMenambahkan Replika Aurora ke klaster DB. Pilih kelas instans Nirserver v2 untuk instans DB baru.

Jika instans DB pembaca adalah yang pertama Aurora Serverless v2 Instans DB di cluster, Anda juga memilih rentang kapasitas. Pengaturan ini berlaku untuk instans DB pembaca ini dan lainnya Aurora Serverless v2 Instans DB yang Anda tambahkan ke cluster. Masing-masing Aurora Serverless v2 Instans DB dapat menskalakan antara nilai ACU minimum dan maksimum.

Jika ada yang lain Aurora Serverless v2 contoh sudah ada di cluster, dialog Add reader menunjukkan rentang kapasitas saat ini untuk cluster. Dalam hal ini, Anda tidak dapat mengubah kapasitas. Gambar berikut menunjukkan laporan kapasitas cluster saat ini.

Antarmuka pengguna konfigurasi instans untuk Aurora Serverless v2.

Jika Anda sudah menambahkan Aurora Serverless v2 Instans DB ke cluster, menambahkan yang lain Aurora Serverless v2 instans DB pembaca menunjukkan rentang kapasitas saat ini. Gambar berikut menunjukkan kontrol hanya baca tersebut.

Pengaturan kapasitas untuk Aurora Serverless v2 ditampilkan di Tambahkan antarmuka pembaca.

Jika Anda ingin mengubah rentang kapasitas klaster, ikuti prosedur dalam Mengatur Aurora Serverless v2 rentang kapasitas untuk sebuah cluster.

Untuk cluster yang berisi lebih dari satu instans DB pembaca, prioritas failover masing-masing Aurora Serverless v2 instans DB pembaca memainkan peran penting dalam bagaimana instans DB itu naik dan turun. Anda tidak dapat menentukan prioritas saat membuat klaster pada awalnya. Ingat properti ini saat Anda menambahkan pembaca kedua atau instans DB yang lebih baru ke klaster Anda. Untuk informasi selengkapnya, lihat Memilih tingkat promosi untuk Aurora Serverless v2 pembaca.

Untuk cara lain agar Anda dapat melihat rentang kapasitas saat ini untuk sebuah klaster, lihat Memeriksa rentang kapasitas untuk Aurora Serverless v2.

Mengonversi penulis atau pembaca yang disediakan menjadi Aurora Serverless v2

Anda dapat mengonversi instans DB yang disediakan untuk digunakan Aurora Serverless v2. Untuk melakukannya, Anda mengikuti prosedur diMemodifikasi instans DB dalam klaster DB. Klaster harus memenuhi persyaratan dalam Persyaratan dan batasan untuk Aurora Serverless v2. Misalnya, Aurora Serverless v2 Instans DB mengharuskan cluster menjalankan versi mesin minimum tertentu.

Misalkan Anda mengonversi cluster yang disediakan yang sedang berjalan untuk memanfaatkan Aurora Serverless v2. Dalam hal ini, Anda dapat meminimalkan waktu henti dengan mengonversi instans DB ke Aurora Serverless v2 sebagai langkah pertama dalam proses peralihan. Untuk prosedur lengkapnya, lihat Beralih dari klaster yang disediakan ke Aurora Serverless v2.

Jika instans DB yang Anda konversi adalah yang pertama Aurora Serverless v2 Instans DB di cluster, Anda memilih rentang kapasitas untuk cluster sebagai bagian dari operasi Modify. Rentang kapasitas ini berlaku untuk masing-masing Aurora Serverless v2 Instans DB yang Anda tambahkan ke cluster. Gambar berikut menunjukkan halaman tempat Anda menentukan unit kapasitas Aurora minimum dan maksimum ()ACUs.

Antarmuka pengguna konfigurasi instans

Untuk detail tentang pentingnya rentang kapasitas, lihat Aurora Serverless v2 kapasitas.

Jika cluster sudah berisi satu atau lebih Aurora Serverless v2 Instans DB, Anda melihat rentang kapasitas yang ada selama operasi Modify. Gambar berikut menunjukkan contoh panel informasi tersebut.

Panel informasi rentang kapasitas

Jika Anda ingin mengubah rentang kapasitas untuk cluster setelah Anda menambahkan lebih banyak Aurora Serverless v2 Instans DB, ikuti prosedur diMengatur Aurora Serverless v2 rentang kapasitas untuk sebuah cluster.

Mengonversi Aurora Serverless v2 penulis atau pembaca untuk disediakan

Anda dapat mengonversi Aurora Serverless v2 Instans DB ke instance DB yang disediakan. Untuk melakukannya, ikuti prosedur dalam Memodifikasi instans DB dalam klaster DB. Pilih kelas instans DB selain Nirserver.

Anda dapat mengonversi Aurora Serverless v2 Instans DB untuk disediakan jika membutuhkan kapasitas yang lebih besar daripada yang tersedia dengan unit kapasitas Aurora maksimum () dari ACUs Aurora Serverless v2 contoh DB. Misalnya, kelas instans db.r5 dan db.r6g DB terbesar memiliki kapasitas memori yang lebih besar daripada Aurora Serverless v2 Instans DB dapat menskalakan ke.

Tip

Beberapa kelas instans DB yang lebih lama seperti db.r3 dan db.t2 tidak tersedia untuk versi Aurora yang Anda gunakan Aurora Serverless v2. Untuk melihat kelas instans DB mana yang dapat Anda gunakan saat mengonversi Aurora Serverless v2 Instans DB ke yang disediakan, lihat. Mesin DB yang didukung untuk kelas instans DB

Jika Anda mengonversi instance DB penulis cluster Anda dari Aurora Serverless v2 untuk disediakan, Anda dapat mengikuti prosedur Beralih dari klaster yang disediakan ke Aurora Serverless v2 tetapi secara terbalik. Ganti salah satu instance DB pembaca di cluster dari Aurora Serverless v2 untuk disediakan. Kemudian lakukan failover untuk membuat instans DB terprovisi tersebut menjadi penulis.

Rentang kapasitas apa pun yang sebelumnya Anda tentukan untuk klaster tetap ada, meskipun semuanya Aurora Serverless v2 Instans DB dihapus dari cluster. Jika Anda ingin mengubah rentang kapasitas, Anda dapat memodifikasi klaster, seperti yang dijelaskan dalam Mengatur Aurora Serverless v2 rentang kapasitas untuk sebuah cluster.

Menjeda Aurora Serverless v2 Instans DB

Anda dapat mengonfigurasi klaster Aurora untuk menjeda dan melanjutkannya secara otomatis Aurora Serverless v2 Instans DB. Untuk informasi selengkapnya, lihat Penskalaan ke Nol ACUs dengan jeda otomatis dan lanjutkan Aurora Serverless v2.

Memilih tingkat promosi untuk Aurora Serverless v2 pembaca

Untuk cluster yang berisi beberapa Aurora Serverless v2 Instans DB atau campuran yang disediakan dan Aurora Serverless v2 Instans DB, perhatikan pengaturan tingkat promosi untuk masing-masing Aurora Serverless v2 contoh DB. Pengaturan ini mengontrol lebih banyak perilaku untuk Aurora Serverless v2 Instans DB daripada untuk instans DB yang disediakan.

Dalam AWS Management Console, Anda menentukan pengaturan ini menggunakan pilihan prioritas Failover di bawah Konfigurasi tambahan untuk Buat database, Modify instance, dan Add reader pages. Anda melihat properti ini untuk instans DB yang ada di kolom Tingkat prioritas opsional pada halaman Basis data. Anda juga dapat melihat properti ini di halaman detail untuk klaster DB atau instans DB.

Untuk instans DB terprovisi, pilihan tingkat 0–15 hanya menentukan urutan yang digunakan Aurora dalam memilih instans DB pembaca mana yang akan dipromosikan menjadi penulis selama operasi failover. Untuk Aurora Serverless v2 Instance DB pembaca, nomor tier juga menentukan apakah instans DB menskalakan agar sesuai dengan kapasitas instans DB penulis atau skala secara independen berdasarkan beban kerjanya sendiri. Aurora Serverless v2 Instans DB pembaca di tingkat 0 atau 1 disimpan pada kapasitas minimum setidaknya setinggi instans DB penulis. Dengan begitu, instans DB pembaca tersebut akan siap mengambil alih dari instans DB penulis jika terjadi failover. Jika instans DB penulis adalah instans DB yang disediakan, Aurora memperkirakan yang setara Aurora Serverless v2 kapasitas. Ini menggunakan perkiraan itu sebagai kapasitas minimum untuk Aurora Serverless v2 pembaca contoh DB.

Aurora Serverless v2 instans DB pembaca di tingkatan 2-15 tidak memiliki kendala yang sama pada kapasitas minimumnya. Saat idle, instans DB ini dapat diturunkan skalanya ke nilai unit kapasitas Aurora (ACU) minimum yang ditentukan dalam rentang kapasitas klaster.

AWS CLI Contoh Linux berikut menunjukkan cara memeriksa tingkatan promosi dari semua instans DB di cluster Anda. Bidang akhir menyertakan nilai True untuk instans DB penulis dan False untuk semua instans DB pembaca.

$ aws rds describe-db-clusters --db-cluster-identifier promotion-tier-demo \ --query 'DBClusters[*].DBClusterMembers[*].[PromotionTier,DBInstanceIdentifier,IsClusterWriter]' \ --output text 1 instance-192 True 1 tier-01-4840 False 10 tier-10-7425 False 15 tier-15-6694 False

AWS CLI Contoh Linux berikut menunjukkan cara mengubah tingkat promosi instans DB tertentu di cluster Anda. Perintah ini pertama-tama memodifikasi instans DB dengan tingkat promosi baru. Kemudian perintah ini akan menunggu instans DB tersedia lagi dan mengonfirmasi tingkat promosi baru untuk instans DB.

$ aws rds modify-db-instance --db-instance-identifier instance-192 --promotion-tier 0 $ aws rds wait db-instance-available --db-instance-identifier instance-192 $ aws rds describe-db-instances --db-instance-identifier instance-192 \ --query '*[].[PromotionTier]' --output text 0

Untuk panduan selengkapnya tentang menentukan tingkat promosi untuk kasus penggunaan yang berbeda-beda, lihat Aurora Serverless v2 penskalaan.

Menggunakan TLS/SSL dengan Aurora Serverless v2

Aurora Serverless v2 dapat menggunakan protokol Transport LayerSecurity/Secure Sockets Layer (TLS/SSL) untuk mengenkripsi komunikasi antara klien dan Aurora Serverless v2 Instans DB. Ini mendukung TLS/SSL versions 1.0, 1.1, and 1.2. For general information about using TLS/SSL dengan Aurora, lihat. Koneksi TLS ke cluster DB MySQL Aurora

Untuk mempelajari selengkapnya tentang menghubungkan ke basis data Aurora MySQL dengan klien MySQL, lihat Menghubungkan ke instans DB yang menjalankan mesin basis data MySQL.

Aurora Serverless v2 mendukung semua mode TLS/SSL yang tersedia untuk klien MySQL (mysql) dan klien PostgreSQL (), termasuk yang tercantum dalam tabel berikut. psql

Deskripsi mode TLS/SSL mysql psql

Hubungkan tanpa menggunakan TLS/SSL.

DISABLED

disable

Mencoba koneksi menggunakan TLS/SSL terlebih dahulu, tetapi kembali ke non-SSL jika diperlukan.

PREFERRED

prefer (default)

Memberlakukan penggunaan TLS/SSL.

REQUIRED

require

Memberlakukan TLS/SSL dan memverifikasi otorisasi sertifikat (CA).

VERIFY_CA

verify-ca

Memberlakukan TLS/SSL, memverifikasi CA, dan memverifikasi nama host CA.

VERIFY_IDENTITY

verify-full

Aurora Serverless v2 menggunakan sertifikat wildcard. Jika Anda menentukan opsi "memverifikasi CA" atau "memverifikasi CA dan nama host CA" saat menggunakan TLS/SSL, pertama-tama unduh trust store Amazon root CA 1 dari Amazon Trust Services. Setelah melakukannya, Anda dapat mengidentifikasi file berformat PEM ini dalam perintah klien Anda. Untuk melakukannya menggunakan PostgreSQL, lakukan hal berikut.

Untuk Linux, macOS, atau Unix:

psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'

Untuk mempelajari selengkapnya tentang mengoperasikan basis data Aurora PostgreSQL menggunakan klien Postgres, lihat Menghubungkan ke instans DB yang menjalankan mesin basis data PostgreSQL.

Untuk informasi selengkapnya tentang menghubungkan ke klaster DB Aurora secara umum, lihat Menghubungkan ke klaster DB Amazon Aurora.

Suite cipher yang didukung untuk koneksi ke Aurora Serverless v2 Klaster DB

Dengan menggunakan cipher suite yang dapat dikonfigurasi, Anda dapat memiliki kontrol lebih besar atas keamanan koneksi basis data Anda. Anda dapat menentukan daftar cipher suite yang ingin Anda izinkan untuk mengamankan koneksi TLS/SSL klien ke basis data Anda. Dengan cipher suite yang dapat dikonfigurasi, Anda dapat mengontrol enkripsi koneksi yang diterima server basis data Anda. Tindakan ini mencegah penggunaan cipher yang tidak aman atau yang sudah dihentikan.

Aurora Serverless v2 Cluster DB yang didasarkan pada Aurora MySQL mendukung suite cipher yang sama dengan cluster DB yang disediakan Aurora MySQL. Untuk informasi tentang cipher suite ini, lihat Mengonfigurasi cipher suite untuk koneksi ke klaster DB Aurora MySQL.

Aurora Serverless v2 Cluster DB yang didasarkan pada Aurora PostgreSQL mendukung suite cipher yang sama dengan cluster DB yang disediakan Aurora PostgreSQL. Untuk informasi tentang cipher suite ini, lihat Mengkonfigurasi cipher suite untuk koneksi ke cluster Aurora Postgre DB SQL.

Melihat Aurora Serverless v2 penulis dan pembaca

Anda dapat melihat detail Aurora Serverless v2 Instans DB dengan cara yang sama seperti yang Anda lakukan untuk instance DB yang disediakan. Untuk melakukannya, ikuti prosedur umum dari Melihat klaster DB Amazon Aurora. Sebuah klaster mungkin berisi semua Aurora Serverless v2 Instans DB, semua instans DB yang disediakan, atau beberapa dari masing-masing.

Setelah Anda membuat satu atau lebih Aurora Serverless v2 Instans DB, Anda dapat melihat instance DB mana yang bertipe Tanpa Server dan tipe Instance. Anda juga dapat melihat unit kapasitas Aurora minimum dan maksimum (ACUs) yang Aurora Serverless v2 Instans DB dapat digunakan. Setiap ACU merupakan kombinasi dari kapasitas pemrosesan (CPU) dan memori (RAM). Rentang kapasitas ini berlaku untuk masing-masing Aurora Serverless v2 Instans DB di cluster. Untuk prosedur untuk memeriksa rentang kapasitas cluster atau apapun Aurora Serverless v2 Instans DB di cluster, lihatMemeriksa rentang kapasitas untuk Aurora Serverless v2.

Di AWS Management Console, Aurora Serverless v2 Instans DB ditandai di bawah kolom Ukuran di halaman Database. Instans DB terprovisi menunjukkan nama kelas instans DB seperti r6g.xlarge. Bagian Aurora Serverless Instans DB menunjukkan Tanpa Server untuk kelas instans DB, bersama dengan kapasitas minimum dan maksimum instans DB. Misalnya, Anda mungkin melihat Tanpa Server v2 (4—64 ACUs) atau Tanpa Server v2 (1-40). ACUs

Anda dapat menemukan informasi yang sama pada tab Konfigurasi untuk masing-masing Aurora Serverless v2 Instans DB di konsol. Misalnya, Anda mungkin melihat bagian Tipe instans seperti berikut ini. Di sini, nilai tipe Instance adalah Serverless v2, nilai kapasitas Minimum adalah 2 ACUs (4 GiB), dan nilai kapasitas maksimum adalah ACUs 64 (128 GiB).

Opsi Tipe instans, bagian dari antarmuka pengguna konfigurasi instans DB

Anda dapat memantau kapasitas masing-masing Aurora Serverless v2 Instans DB dari waktu ke waktu. Dengan begitu, Anda dapat memeriksa minimum, maksimum, dan rata-rata yang ACUs dikonsumsi oleh setiap instans DB. Anda juga dapat memeriksa seberapa dekat instans DB dengan kapasitas minimum atau maksimumnya. Untuk melihat detail tersebut di AWS Management Console, periksa grafik CloudWatch metrik Amazon pada tab Monitoring untuk instans DB. Untuk informasi tentang metrik yang perlu dilihat dan cara menafsirkannya, lihat CloudWatch Metrik Amazon penting untuk Aurora Serverless v2.

Penebangan untuk Aurora Serverless v2

Untuk mengaktifkan pencatatan log basis data, Anda menentukan log yang akan diaktifkan menggunakan parameter konfigurasi di grup parameter kustom Anda.

Untuk Aurora MySQL, Anda dapat mengaktifkan log berikut.

Aurora MySQL Deskripsi

general_log

Membuat log umum. Atur ke 1 untuk mengaktifkan. Default-nya adalah nonaktif (0).

log_queries_not_using_indexes

Mencatat setiap kueri ke log kueri lambat yang tidak menggunakan indeks. Default-nya adalah nonaktif (0). Atur ke 1 untuk mengaktifkan log ini.

long_query_time

Mencegah kueri yang berjalan cepat agar tidak dicatat dalam log kueri lambat. Dapat diatur ke angka float antara 0 dan 31536000. Default-nya adalah 0 (tidak aktif).

server_audit_events

Daftar peristiwa untuk dicatat dalam log. Nilai yang didukung adalah CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML, dan TABLE.

server_audit_logging

Atur ke 1 untuk mengaktifkan pencatatan log audit server. Jika Anda mengaktifkan ini, Anda dapat menentukan peristiwa audit yang akan dikirim CloudWatch dengan mencantumkannya di server_audit_events parameter.

slow_query_log

Membuat log kueri lambat. Atur ke 1 untuk mengaktifkan log kueri lambat. Default-nya adalah nonaktif (0).

Untuk informasi selengkapnya, lihat Menggunakan Audit Lanjutan dengan klaster Amazon Aurora My DB SQL.

Untuk Aurora PostgreSQL, Anda dapat mengaktifkan log berikut di Aurora Serverless v2 Instans DB.

Aurora PostgreSQL Deskripsi

log_connections

Mencatat log setiap koneksi yang berhasil.

log_disconnections

Mencatat log terkait akhir sebuah sesi, termasuk durasinya.

log_lock_waits

Default-nya adalah 0 (nonaktif). Atur ke 1 untuk mencatat log peristiwa tunggu kunci.

log_min_duration_statement

Durasi minimum (dalam milidetik) untuk menjalankan pernyataan sebelum dicatat lognya.

log_min_messages

Mengatur tingkat pesan yang dicatat lognya. Nilai yang didukung adalah debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. Untuk mencatat data performa ke log postgres, tetapkan nilainya ke debug1.

log_temp_files

Mencatat log penggunaan file sementara yang melampaui kilobyte (kB) yang ditentukan.

log_statement

Mengontrol pernyataan SQL tertentu yang dicatat lognya. Nilai yang didukung adalah none, ddl, mod, dan all. Default-nya adalah none.

Logging dengan Amazon CloudWatch

Setelah Anda menggunakan prosedur Penebangan untuk Aurora Serverless v2 untuk memilih log database mana yang akan diaktifkan, Anda dapat memilih log mana yang akan diunggah (“publikasikan”) ke Amazon CloudWatch.

Anda dapat menggunakan Amazon CloudWatch untuk menganalisis data log, membuat alarm, dan melihat metrik. Secara default, log kesalahan untuk Aurora Serverless v2 diaktifkan dan diunggah secara otomatis ke CloudWatch. Anda juga dapat mengunggah log lain dari Aurora Serverless v2 Instans DB ke CloudWatch.

Kemudian Anda memilih log mana yang akan diunggah CloudWatch, dengan menggunakan pengaturan ekspor Log di AWS Management Console atau --enable-cloudwatch-logs-exports opsi di AWS CLI.

Anda dapat memilih yang mana dari Anda Aurora Serverless v2 log untuk diunggah ke CloudWatch. Untuk informasi selengkapnya, lihat Menggunakan Audit Lanjutan dengan klaster Amazon Aurora My DB SQL.

Sama seperti jenis apa pun dari klaster DB Aurora, Anda tidak dapat memodifikasi grup parameter klaster DB default. Sebagai gantinya, buat grup parameter klaster DB Anda sendiri berdasarkan parameter default untuk klaster DB dan jenis mesin Anda. Kami menyarankan Anda membuat grup parameter cluster DB kustom Anda sebelum membuat Aurora Serverless v2 Cluster DB, sehingga tersedia untuk dipilih saat Anda membuat database di konsol.

catatan

Untuk Aurora Serverless v2, Anda dapat membuat cluster DB dan grup parameter DB. Ini kontras dengan Aurora Serverless v1, di mana Anda hanya dapat membuat grup parameter cluster DB.

Melihat Aurora Serverless v2 log di Amazon CloudWatch

Setelah Anda menggunakan prosedur dalam Logging dengan Amazon CloudWatch untuk memilih log basis data mana yang akan diaktifkan, Anda dapat melihat konten log.

Untuk informasi lebih lanjut tentang penggunaan CloudWatch dengan log Aurora MySQL dan Aurora PostgreSQL, lihat dan. Memantau peristiwa log di Amazon CloudWatch Menerbitkan log Aurora Postgre ke Amazon Logs SQL CloudWatch

Untuk melihat log untuk Aurora Serverless v2 Klaster DB
  1. Buka CloudWatch konsol di https://console.aws.amazon.com/cloudwatch/.

  2. Pilih Anda Wilayah AWS.

  3. Pilih Grup log.

  4. Pilih Anda Aurora Serverless v2 Log cluster DB dari daftar. Pola penamaan log adalah sebagai berikut.

    /aws/rds/cluster/cluster-name/log_type
catatan

Untuk Aurora MySQL — Kompatibel Aurora Serverless v2 Cluster DB, log kesalahan menyertakan peristiwa penskalaan kumpulan buffer bahkan ketika tidak ada kesalahan.

Kapasitas pemantauan dengan Amazon CloudWatch

Dengan Aurora Serverless v2, Anda dapat menggunakan CloudWatch untuk memantau kapasitas dan pemanfaatan semua Aurora Serverless v2 Instans DB di cluster Anda. Anda dapat melihat metrik tingkat instans untuk memeriksa kapasitas masing-masing Aurora Serverless v2 Instans DB saat skala naik dan turun. Anda juga dapat membandingkan metrik terkait kapasitas dengan metrik lain untuk melihat bagaimana perubahan beban kerja memengaruhi konsumsi sumber daya. Misalnya, Anda dapat membandingkan ServerlessDatabaseCapacity dengan DatabaseUsedMemory, DatabaseConnections, dan DMLThroughput untuk menilai bagaimana klaster DB Anda merespons selama operasi. Untuk detail tentang metrik terkait kapasitas yang berlaku Aurora Serverless v2, lihat CloudWatch Metrik Amazon penting untuk Aurora Serverless v2.

Untuk memantau Aurora Serverless v2 Kapasitas cluster DB
  1. Buka CloudWatch konsol di https://console.aws.amazon.com/cloudwatch/.

  2. Pilih Metrik. Semua metrik yang tersedia muncul sebagai kartu di konsol, yang dikelompokkan berdasarkan nama layanan.

  3. Pilih RDS.

  4. (Opsional) Gunakan kotak Pencarian untuk menemukan metrik yang sangat penting Aurora Serverless v2:ServerlessDatabaseCapacity,ACUUtilization,CPUUtilization, danFreeableMemory.

Kami menyarankan Anda mengatur CloudWatch dasbor untuk memantau Aurora Serverless v2 Kapasitas cluster DB menggunakan metrik terkait kapasitas. Untuk mempelajari caranya, lihat Membangun dasbor dengan CloudWatch.

Untuk mempelajari lebih lanjut tentang menggunakan Amazon CloudWatch dengan Amazon Aurora, lihat. Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch

Pemantauan Aurora Serverless v2 jeda dan lanjutkan aktivitas

Aurora menulis file log terpisah untuk Aurora Serverless v2 Instans DB dengan jeda otomatis diaktifkan. Aurora menulis ke log untuk setiap interval 10 menit bahwa instance tidak dijeda. Aurora mempertahankan hingga tujuh batang kayu ini, diputar setiap hari. File log saat ini diberi namainstance.log, dan log lama diberi nama menggunakan polainstance.YYYY-MM-DD.N.log.

Log ini diaktifkan secara default untuk Aurora Serverless v2 Instans DB dengan jeda otomatis diaktifkan. Anda dapat melihat isi log ini di AWS Management Console atau dengan menggunakan AWS CLI atau RDSP API. Saat ini, Anda tidak dapat mengunggah log ini ke CloudWatch.

Peristiwa yang tercantum dalam Peristiwa instans DB memberikan ikhtisar tingkat tinggi tentang aktivitas jeda dan melanjutkan, seperti berikut ini:

  • Ketika instance mulai berhenti, dan ketika selesai berhenti.

  • Ketika instance mulai dilanjutkan, dan ketika selesai dilanjutkan.

  • Kasus di mana instance mencoba untuk berhenti sejenak, tetapi beberapa kondisi mencegahnya berhenti.

instance.logIni memberikan detail yang lebih terperinci tentang alasan mengapa Aurora Serverless v2 misalnya mungkin atau mungkin tidak dapat berhenti sejenak.

Log mungkin menunjukkan bahwa instance dilanjutkan karena alasan yang berbeda:

  • aktivitas pengguna: Permintaan koneksi database. Ini bisa dari sesi klien interaktif, panggilan API Data RDS, atau permintaan untuk mengunduh log dari instance.

  • Aktivitas latar belakang: Kategori luas yang mencakup semua alasan mengapa Aurora melanjutkan sebuah instance. Misalnya, ketika permintaan koneksi ke instance pembaca menyebabkan instance penulis dilanjutkan, log untuk pembaca menunjukkan aktivitas pengguna, sedangkan log untuk penulis mengklasifikasikan permintaan resume itu sebagai aktivitas latar belakang. Untuk alasan mengapa Aurora mungkin melanjutkan instance selain permintaan koneksi pengguna, lihat. Melanjutkan jeda otomatis Aurora Serverless v2 instans

Ketika Aurora tidak mengetahui kondisi apa pun yang akan mencegah instance berhenti ketika interval jeda otomatis berakhir, ia secara berkala menulis pesan informasi ke log. Untuk cluster dengan hanya satu instans DB, log berisi pesan ini:

[INFO] No auto-pause blockers registered since time

Untuk cluster dengan beberapa instance DB, pesannya sedikit berbeda. Itu karena seorang penulis mungkin tidak dapat berhenti sejenak karena aktivitas pada salah satu contoh pembaca. Jika aktivitas pada pembaca selesai sebelum interval jeda otomatis berakhir pada penulis, penulis dapat berhenti pada waktu yang diharapkan.

[INFO] No auto-pause blockers registered since time. Database might be required to maintain compute capacity for high availability.

Jika operasi jeda dimulai, tetapi permintaan koneksi database baru tiba sebelum instance selesai dijeda, log berisi pesan ini:

[INFO] Unable to pause database due to a new database activity

Jika Aurora mengetahui kondisi apa pun yang pasti mencegah instance berhenti, log berisi pesan ini yang mencantumkan semua kondisi tersebut:

[INFO] Auto-pause blockers registered since time: list_of_conditions

Dengan begitu, Aurora tidak mencegah Anda mengaktifkan replikasi, integrasi nol-ETL, Aurora Global Database, dan sebagainya dalam kombinasi dengan fitur jeda otomatis. Log memberi tahu Anda kapan penggunaan fitur tersebut dapat mencegah jeda otomatis diterapkan.

Berikut ini adalah alasan mengapa Aurora Serverless v2 instance mungkin melebihi interval batas waktu jeda otomatis, tetapi dicegah agar tidak menjeda:

  • aktivitas database sebelum batas waktu jeda otomatis: Instans DB menerima permintaan koneksi sebelum interval batas waktu berakhir.

  • anggota database global: Jika cluster DB adalah bagian dari database global Aurora, Aurora Serverless v2 instance di cluster tidak berhenti sejenak. Sebuah cluster dapat berubah dari cluster mandiri ke cluster database global. Dengan demikian, contoh yang sebelumnya dijeda otomatis mungkin berhenti berhenti, dan melaporkan alasan ini di log. Setelah cluster menjadi anggota database global, itu tidak akan kembali ke cluster mandiri sampai Anda secara eksplisit melepaskannya. Cluster primer masih dianggap sebagai bagian dari database global bahkan jika Anda melepaskan semua cluster sekunder.

  • kemampuan replikasi dikonfigurasi: Instans DB penulis memiliki replikasi khusus mesin yang diaktifkan, baik replikasi binlog untuk MySQL atau replikasi logis untuk PostgreSQL. Kondisi ini juga dapat disebabkan oleh penggunaan fitur Aurora lain yang memerlukan pengaktifan replikasi, seperti integrasi nol-ETL atau Database Activity Streams (DAS).

  • kelambatan pencadangan berkelanjutan: Jika sistem penyimpanan Aurora belum selesai menerapkan perubahan penyimpanan hingga titik waktu saat ini, instance penulis tidak berhenti sampai menyusul. Kondisi ini hanya mempengaruhi contoh penulis, dan diharapkan relatif singkat.

  • layanan atau tindakan pemeliharaan pelanggan: Jika operasi pemeliharaan dimulai, instans DB tidak akan berhenti lagi sampai operasi itu selesai. Kondisi ini mencakup berbagai macam operasi yang mungkin dimulai oleh Anda atau oleh Aurora, seperti upgrade, kloning, mengubah pengaturan konfigurasi, upgrade, men-download file log, dan sebagainya. Peristiwa ini juga terjadi ketika Anda meminta untuk menghapus instance, dan Aurora secara singkat melanjutkan instance sebagai bagian dari mekanisme penghapusan.

  • Masalah komunikasi sementara: Jika Aurora tidak dapat menentukan apakah konfigurasi penskalaan saat ini memiliki pengaturan kapasitas minimum nol ACUs, itu tidak menghentikan sementara instance. Ini diharapkan menjadi kejadian yang sangat langka.