View a markdown version of this page

Penskalaan ke Zero ACU dengan jeda otomatis dan lanjutkan Aurora serverless - Amazon Aurora
Ikhtisar jeda otomatis Prasyarat dan Batasan Menghidupkan dan menonaktifkan jeda otomatis Cara kerja jeda otomatis Auto-pause dan konfigurasi cluster Aurora Memantau jeda otomatis Pemecahan masalah untuk jeda otomatis Desain aplikasi untuk jeda otomatis

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

Penskalaan ke Zero ACU dengan jeda otomatis dan lanjutkan Aurora serverless

Anda dapat menentukan bahwa instans Aurora serverless DB menurunkan skala ke nol ACU dan secara otomatis menjeda, jika mereka tidak memiliki koneksi yang diprakarsai oleh aktivitas pengguna dalam jangka waktu tertentu. Anda melakukannya dengan menentukan nilai ACU minimum nol untuk cluster DB Anda. Anda tidak dikenakan biaya untuk kapasitas instans saat instance dalam status jeda. Mengaktifkan fitur jeda dan melanjutkan otomatis (jeda otomatis) untuk klaster Aurora yang ringan digunakan atau memiliki periode tidak aktif yang lama dapat membantu Anda mengelola biaya untuk armada database Anda.

catatan

Fitur jeda otomatis tersedia untuk Aurora serverless Aurora PostgreSQL dan Aurora MySQL. Anda mungkin perlu memutakhirkan versi mesin basis data Aurora Anda untuk memanfaatkan fitur ini. Untuk versi mesin di mana kapasitas minimum 0 ACU tersedia, lihatKapasitas Aurora serverless.

Ikhtisar Aurora serverless fitur jeda otomatis

Aurora serverlessInstans DB dapat secara otomatis berhenti sejenak setelah periode tanpa koneksi pengguna, dan secara otomatis dilanjutkan ketika permintaan koneksi tiba. pause/resume Fitur Aurora serverless otomatis membantu mengelola biaya untuk sistem yang tidak memiliki tujuan tingkat layanan yang ketat (SLO). Misalnya, Anda dapat mengaktifkan fitur ini untuk cluster yang digunakan untuk pengembangan dan pengujian, atau untuk aplikasi internal di mana jeda singkat dapat diterima saat database dilanjutkan. Jika beban kerja Anda memiliki periode tidak aktif dan dapat mentolerir sedikit keterlambatan dalam menghubungkan saat instans dilanjutkan, pertimbangkan untuk menggunakan jeda otomatis dengan instans Anda untuk mengurangi biaya. Aurora serverless

Anda mengontrol perilaku ini dengan menentukan apakah instans Aurora serverless DB dalam klaster dapat berhenti secara otomatis atau tidak, dan berapa lama setiap instance harus menganggur sebelum dijeda. Untuk mengaktifkan perilaku jeda otomatis untuk semua instans Aurora serverless DB di klaster Aurora, Anda menetapkan nilai kapasitas minimum untuk cluster ke nol ACU.

Manfaat penghematan biaya dari fitur jeda otomatis mirip dengan menggunakan fitur cluster. stop/start Auto-pause for Aurora serverless memiliki manfaat tambahan dari resume yang lebih cepat daripada memulai cluster yang dihentikan, dan mengotomatiskan proses menentukan kapan harus menjeda dan melanjutkan setiap instans DB.

Fitur jeda otomatis juga memberikan perincian tambahan dalam mengendalikan biaya untuk sumber daya komputasi dalam cluster Anda. Anda dapat mengaktifkan beberapa instance pembaca untuk berhenti sementara instance penulis dan pembaca lain di cluster tetap aktif setiap saat. Anda melakukannya dengan menetapkan instance pembaca yang dapat menjeda secara independen dari instance lain sebagai prioritas failover dalam kisaran 2-15.

Instance penulis dan semua instance pembaca dengan prioritas failover 0 dan 1 selalu berhenti sejenak dan melanjutkan pada saat yang bersamaan. Dengan demikian, instance dalam grup ini berhenti sejenak setelah tidak satupun dari mereka memiliki koneksi untuk interval waktu yang ditentukan.

Cluster Aurora DB dapat berisi kombinasi instans DB penulis dan pembaca serta instance yang disediakan dan DB. Aurora serverless Oleh karena itu, untuk menggunakan fitur ini secara efektif, akan sangat membantu untuk memahami aspek-aspek berikut dari mekanisme jeda otomatis:

  • Keadaan ketika instans DB mungkin secara otomatis berhenti.

  • Ketika instance DB dapat dicegah dari jeda. Misalnya, mengaktifkan beberapa fitur Aurora atau melakukan jenis operasi tertentu di cluster dapat mencegah instance berhenti, bahkan tanpa koneksi ke instance tersebut.

  • Konsekuensi untuk pemantauan dan penagihan saat instance dijeda.

  • Tindakan apa yang menyebabkan instans DB melanjutkan pemrosesan.

  • Bagaimana kapasitas instans DB berubah sekitar waktu jeda dan melanjutkan peristiwa.

  • Cara mengontrol interval idle sebelum instance DB berhenti.

  • Cara mengkodekan logika aplikasi untuk menangani periode saat instance DB melanjutkan pemrosesan.

Prasyarat dan Batasan untuk fitur jeda otomatis Aurora serverless

Sebelum menggunakan fitur jeda otomatis, periksa versi mesin mana yang akan digunakan. Juga, periksa apakah jeda otomatis berfungsi dalam kombinasi dengan fitur Aurora lain yang ingin Anda gunakan. Anda tidak dapat mengaktifkan jeda otomatis jika Anda menggunakan versi mesin yang tidak mendukungnya. Untuk fitur yang tidak kompatibel, Anda tidak akan mendapatkan kesalahan jika Anda menggunakannya dalam kombinasi dengan jeda otomatis. Jika klaster menggunakan fitur atau pengaturan yang tidak kompatibel, Aurora serverless instance tidak akan berhenti secara otomatis.

  • Jika Anda menggunakan Aurora PostgreSQL, mesin database harus menjalankan setidaknya versi 16.3, 15.7, 14.12, atau 13.15.

  • Jika Anda menggunakan Aurora MySQL, mesin database harus menjalankan versi 3.08.0 atau lebih tinggi.

  • Untuk daftar lengkap versi mesin dan AWS Wilayah tempat fitur ini tersedia, lihatDaerah yang Didukung dan mesin Aurora DB untuk Aurora serverless.

  • Ketika sebuah Aurora serverless instance dilanjutkan, kapasitasnya mungkin lebih rendah daripada saat instance dijeda.

Kondisi atau pengaturan tertentu mencegah Aurora serverless instance berhenti secara otomatis. Untuk informasi selengkapnya, lihat Situasi di mana Aurora serverless tidak berhenti otomatis.

Menghidupkan dan menonaktifkan fitur jeda otomatis

Anda dapat mengaktifkan dan menonaktifkan fitur jeda otomatis di tingkat cluster. Untuk melakukannya, Anda menggunakan prosedur yang sama seperti ketika Anda menyesuaikan kapasitas minimum dan maksimum untuk cluster. Fitur jeda otomatis diwakili oleh kapasitas minimum 0 ACU.

Mengaktifkan jeda otomatis untuk Aurora serverless instance di cluster

Ikuti prosedur di Mengatur rentang kapasitas Aurora serverless untuk sebuah klaster. Untuk kapasitas minimum, pilih 0 ACU. Saat Anda memilih kapasitas minimum 0 ACU, Anda juga dapat menentukan lamanya waktu instans menjadi idle sebelum dijeda secara otomatis.

Contoh CLI berikut menunjukkan bagaimana Anda dapat membuat cluster Aurora dengan fitur jeda otomatis diaktifkan dan interval jeda otomatis disetel ke sepuluh menit (600 detik). 

aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \
    --master-username myuser \
    --manage-master-user-password

Contoh CLI berikut menunjukkan bagaimana Anda dapat mengaktifkan fitur jeda otomatis untuk cluster Aurora yang ada. Contoh ini menetapkan interval jeda otomatis menjadi satu jam (3600 detik). 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=80,SecondsUntilAutoPause=3600

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 0,
    "MaxCapacity": 80.0,
    "SecondsUntilAutoPause": 3600
}

Interval batas waktu Aurora serverless jeda otomatis yang dapat dikonfigurasi

Interval batas waktu direpresentasikan dalam ServerlessV2ScalingConfiguration atribut cluster Aurora Anda. Anda dapat menentukan interval ini di Konsol Manajemen AWS saat membuat atau memodifikasi cluster Aurora, jika kapasitas minimum diatur ke nol ACU. Anda dapat menentukannya di AWS CLI dengan menggunakan --serverless-v2-scaling-configuration parameter saat membuat atau memodifikasi cluster Aurora. Anda dapat menentukannya di RDS API dengan menggunakan ServerlessV2ScalingConfiguration parameter saat membuat atau memodifikasi cluster Aurora.

Interval minimum yang dapat Anda atur adalah 300 detik (lima menit). Itu default jika Anda tidak menentukan interval. Interval maksimum yang dapat Anda atur adalah 86.400 detik (satu hari).

Misalkan Anda mematikan fitur jeda otomatis untuk klaster dengan mengubah kapasitas minimum cluster menjadi nilai bukan nol. Dalam hal ini, properti interval dihapus dari ServerlessV2ScalingConfiguration atribut. Tidak adanya properti tersebut memberikan konfirmasi tambahan bahwa fitur jeda otomatis dimatikan untuk cluster tersebut. Jika nanti Anda mengaktifkan kembali jeda otomatis, Anda dapat menentukan interval khusus apa pun lagi pada saat itu.

Melanjutkan instance yang dijeda otomatis Aurora serverless

  • Ketika Anda terhubung ke Aurora serverless instance yang dijeda, secara otomatis melanjutkan dan menerima koneksi.

  • Upaya koneksi yang tidak menyertakan kredensil yang valid masih menyebabkan instans DB dilanjutkan.

  • Jika Anda terhubung melalui titik akhir penulis, Aurora melanjutkan instance DB penulis jika dijeda secara otomatis. Pada saat yang sama, Aurora melanjutkan setiap instance pembaca yang dijeda otomatis yang memiliki prioritas failover 0 atau 1, yang berarti kapasitasnya terkait dengan kapasitas instance penulis.

  • Jika Anda terhubung melalui titik akhir pembaca, Aurora memilih instance pembaca secara acak. Jika instance pembaca itu dijeda, Aurora melanjutkannya. Aurora juga melanjutkan instance penulis terlebih dahulu, karena instance penulis harus selalu aktif jika ada instance pembaca yang aktif. Ketika Aurora melanjutkan contoh penulis itu, itu juga menyebabkan setiap instance pembaca di tingkat promosi failover nol dan satu dilanjutkan.

  • Jika Anda mengirim permintaan ke klaster Anda melalui API Data RDS, Aurora melanjutkan instance penulis jika dijeda. Kemudian Aurora memproses permintaan Data API.

  • Saat Anda mengubah nilai parameter konfigurasi dalam grup parameter cluster DB, Aurora secara otomatis melanjutkan setiap Aurora serverless instance yang dijeda di semua cluster yang menggunakan grup parameter cluster tersebut. Demikian pula, ketika Anda mengubah nilai parameter dalam grup parameter DB, Aurora secara otomatis melanjutkan setiap Aurora serverless instance yang dijeda yang menggunakan grup parameter DB tersebut. Perilaku resume otomatis yang sama berlaku saat Anda memodifikasi klaster untuk menetapkan grup parameter cluster yang berbeda, atau saat Anda memodifikasi instance untuk menetapkan grup parameter DB yang berbeda.

  • Melakukan permintaan backtrack secara otomatis melanjutkan instance Aurora serverless penulis jika dijeda. Aurora memproses permintaan backtrack setelah instance penulis dilanjutkan. Anda dapat mundur ke waktu di mana sebuah Aurora serverless instance dijeda.

  • Mengambil snapshot cluster atau menghapus snapshot tidak menyebabkan Aurora serverless instance apa pun dilanjutkan.

  • Membuat klon Aurora menyebabkan Aurora melanjutkan instance penulis dari cluster yang sedang dikloning.

  • Jika instance yang dijeda menerima sejumlah besar permintaan koneksi sebelum selesai dilanjutkan, beberapa sesi mungkin tidak dapat terhubung. Kami merekomendasikan untuk menerapkan logika coba lagi untuk koneksi ke cluster Aurora yang memiliki Aurora serverless beberapa instance dengan jeda otomatis diaktifkan. Misalnya, Anda dapat mencoba lagi koneksi yang gagal tiga kali.

  • Aurora dapat melakukan beberapa jenis pemeliharaan internal minor tanpa membangunkan instance. Namun, beberapa jenis pemeliharaan yang terjadi selama jendela pemeliharaan cluster memang mengharuskan Aurora untuk melanjutkan instance. Ketika pemeliharaan selesai, instance secara otomatis dijeda lagi jika tidak ada aktivitas lagi setelah interval yang ditentukan.

    catatan

    Aurora tidak secara otomatis melanjutkan instance yang dijeda untuk pekerjaan terjadwal khusus mesin, seperti yang ada di ekstensi PostgreSQL atau penjadwal acara MySQL. pg_cron Untuk memastikan bahwa pekerjaan tersebut berjalan, memulai koneksi secara manual ke instance sebelum waktu yang dijadwalkan. Aurora tidak mengantri pekerjaan apa pun di mana waktu yang dijadwalkan terjadi saat instans DB dijeda. Pekerjaan seperti itu dilewati ketika instance dilanjutkan nanti.

  • Jika cluster Aurora mengalami failover saat Aurora serverless instance dijeda otomatis, Aurora mungkin melanjutkan instance dan kemudian mempromosikan instance itu menjadi penulis. Hal yang sama mungkin terjadi jika satu atau lebih instance DB dihapus dari cluster saat instance dijeda. Dalam hal ini, instance menjadi penulis segera ketika dilanjutkan.

  • Operasi yang mengubah properti klaster juga menyebabkan Aurora serverless instance yang dijeda otomatis dilanjutkan. Misalnya, instance yang dijeda otomatis dilanjutkan untuk operasi seperti berikut ini:

    • Mengubah rentang penskalaan cluster.

    • Memutakhirkan versi mesin cluster.

    • Menjelaskan atau mengunduh file log dari instance yang dijeda. Anda dapat memeriksa data log historis dari instance yang dijeda dengan mengaktifkan unggahan log ke CloudWatch dan menganalisis log. CloudWatch

Mematikan jeda otomatis untuk Aurora serverless instance dalam klaster

Ikuti prosedur di Mengatur rentang kapasitas Aurora serverless untuk sebuah klaster. Untuk kapasitas minimum, pilih nilai 0,5 atau lebih besar. Saat Anda mematikan fitur jeda otomatis, interval untuk instans menjadi idle diatur ulang. Jika Anda mengaktifkan jeda otomatis lagi, Anda menentukan interval batas waktu baru.

Contoh CLI berikut menunjukkan bagaimana Anda dapat mematikan fitur jeda otomatis untuk cluster Aurora yang ada. describe-db-clustersOutput menunjukkan bahwa SecondsUntilAutoPause atribut dihapus ketika kapasitas minimum diatur ke nilai bukan nol. 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 2,
    "MaxCapacity": 80.0
}

Cara kerja Aurora serverless fitur jeda otomatis

Anda dapat menggunakan informasi berikut untuk merencanakan penggunaan fitur jeda otomatis. Memahami keadaan di mana instance berhenti, melanjutkan, atau tetap aktif dapat membantu Anda menyeimbangkan pengorbanan antara ketersediaan, daya tanggap, dan penghematan biaya.

Apa yang terjadi ketika Aurora serverless instance berhenti

Ketika instans Aurora serverless DB berhenti setelah periode tanpa koneksi:

  • Aurora mulai menjeda instance setelah interval yang ditentukan berlalu tanpa koneksi ke instance, terlepas dari berapa banyak ACU yang dimiliki instance pada saat itu.

  • Mekanisme jeda tidak seketika. Sebuah Aurora serverless instance yang akan dijeda otomatis mungkin menunggu sebentar untuk mengejar semua perubahan pada penyimpanan Aurora.

  • Biaya instance untuk contoh itu ditunda. ServerlessV2UsageMetrik memiliki nilai 0 sementara instance dijeda.

  • Nilai status untuk instance tidak berubah. Status masih ditampilkan sebagai “tersedia”.

  • Instance berhenti menulis ke file log database. Ini berhenti mengirim metrik ke CloudWatch, selain mendaftarkan nol persen untuk CPUUtilization danACUUtilization, dan nol untukServerlessDatabaseCapacity.

  • Aurora memancarkan peristiwa ketika instans Aurora serverless DB mulai berhenti, selesai berhenti, dan jika mekanisme jeda terputus atau tidak berhasil. Untuk detail tentang acara ini, lihatPeristiwa instans DB.

Apa yang terjadi ketika instance yang dijeda otomatis dilanjutkan Aurora serverless

Ketika instans Aurora serverless DB dilanjutkan setelah dijeda secara otomatis, kondisi berikut berlaku:

  • Setiap perubahan parameter yang ada dalam pending-reboot perubahan diterapkan saat instance dilanjutkan.

  • Aurora memancarkan peristiwa tingkat instans ketika setiap instans Aurora serverless DB mulai dilanjutkan, selesai dilanjutkan, dan jika instance tidak dapat dilanjutkan karena alasan tertentu. Untuk detail tentang acara ini, lihatPeristiwa instans DB.

  • Setiap koneksi yang diminta dibuat setelah instans DB selesai dilanjutkan. Karena waktu tipikal untuk melanjutkan mungkin sekitar 15 detik, kami sarankan Anda menyesuaikan pengaturan batas waktu klien menjadi lebih dari 15 detik. Misalnya, dalam pengaturan driver JDBC Anda, Anda mungkin menyesuaikan nilai untuk sslResponseTimeout pengaturan connectTimeout dan menjadi lebih dari 15 detik.

catatan

Jika sebuah Aurora serverless instance tetap dijeda lebih dari 24 jam, Aurora dapat menempatkan instance ke dalam tidur yang lebih nyenyak yang membutuhkan waktu lebih lama untuk dilanjutkan. Dalam hal ini, waktu resume bisa 30 detik atau lebih, kira-kira setara dengan melakukan reboot instance. Jika database Anda memiliki periode tidak aktif yang berlangsung lebih dari satu hari, sebaiknya atur batas waktu koneksi menjadi 30 detik atau lebih.

Cara kerja penagihan instans untuk cluster yang dijeda otomatis Aurora serverless

Sementara sebuah Aurora serverless instance dijeda secara otomatis, muatan instance-nya adalah nol. ServerlessV2UsageMetrik adalah nol selama periode itu. AWS masih mengenakan biaya untuk penyimpanan Aurora dan aspek lain dari cluster yang tidak terkait dengan instans DB tertentu.

Situasi di mana Aurora serverless tidak berhenti otomatis

  • Jika nilai kapasitas minimum untuk cluster DB Anda lebih tinggi dari nol ACU, Aurora serverless instance di cluster tidak otomatis berhenti sejenak. Jika Anda memiliki cluster dengan Aurora serverless instance sebelum fitur jeda otomatis tersedia, pengaturan kapasitas minimum terendah adalah 0,5 ACU. Untuk menggunakan fitur jeda otomatis dengan cluster seperti itu, ubah pengaturan kapasitas minimum menjadi nol ACU.

  • Jika ada koneksi yang diprakarsai pengguna yang terbuka untuk sebuah Aurora serverless instance, instance tidak akan berhenti sejenak. Instance juga tidak akan berhenti sementara aktivitas seperti patching dan upgrade sedang berlangsung. Koneksi administratif yang digunakan Aurora untuk pemeriksaan kesehatan tidak dihitung sebagai aktivitas dan tidak mencegah instance berhenti.

  • Dalam klaster Aurora PostgreSQL memiliki replikasi logis yang diaktifkan, atau klaster MySQL Aurora yang mengaktifkan replikasi binlog, instance penulis dan instance pembaca apa pun di tingkat promosi failover nol dan satu tidak berhenti secara otomatis. Aurora melakukan aktivitas minimal yang konstan untuk memeriksa kesehatan koneksi replikasi.

    Untuk cluster dengan replikasi diaktifkan, Anda masih dapat memiliki instance pembaca Aurora di cluster sumber yang berhenti otomatis. Untuk melakukannya, tetapkan prioritas failover mereka ke nilai selain nol atau satu. Dengan begitu, mereka dapat dijeda secara independen dari contoh penulis.

  • Jika klaster Aurora Anda memiliki Proxy RDS terkait, proxy mempertahankan koneksi terbuka ke setiap instans DB di cluster. Dengan demikian, setiap Aurora serverless instance dalam cluster seperti itu tidak akan berhenti secara otomatis.

  • Jika cluster Anda adalah cluster utama dalam database global Aurora, Aurora tidak secara otomatis menjeda instance penulis. Aurora serverless Itu karena tingkat aktivitas yang konstan diperlukan pada instance penulis untuk mengelola cluster lain dalam database global. Karena instance penulis tetap aktif, setiap instance Aurora serverless pembaca dengan prioritas failover nol atau satu juga tidak berhenti otomatis.

  • Aurora serverlessinstance di cluster sekunder dari Aurora Global Database tidak otomatis berhenti sejenak. Jika cluster DB dipromosikan ke cluster mandiri, maka fitur jeda otomatis menjadi efektif jika semua kondisi lainnya terpenuhi.

  • Dalam cluster dengan integrasi nol-ETL terkait ke Redshift, instance penulis dan instance pembaca apa pun di tingkat promosi failover nol dan satu tidak berhenti secara otomatis.

  • Selain aktivitas pada port database utama untuk instance, jika instance Aurora PostgreSQL mengaktifkan fitur Babelfish, koneksi dan aktivitas apa pun di port mencegah instance dijeda otomatis. T-SQL

Cara kerja jeda otomatis dengan fitur cluster stop/start

Anda dapat menghentikan dan memulai cluster Aurora saat fitur jeda otomatis diaktifkan. Tidak masalah jika beberapa contoh dijeda. Saat Anda memulai cluster lagi, setiap Aurora serverless instance yang dijeda akan dilanjutkan secara otomatis.

Sementara klaster Aurora dihentikan, setiap Aurora serverless instance yang dijeda tidak secara otomatis dilanjutkan berdasarkan upaya untuk terhubung. Setelah cluster dimulai lagi, mekanisme biasa untuk menjeda dan melanjutkan instance berlaku. Aurora serverless

Cara kerja pemeliharaan dan peningkatan untuk cluster yang dijeda otomatis Aurora serverless

  • Saat Aurora serverless instance dijeda secara otomatis, jika Anda mencoba memutakhirkan cluster Aurora, Aurora melanjutkan instance dan meningkatkannya.

  • Aurora secara berkala melanjutkan setiap Aurora serverless instance yang dijeda otomatis untuk melakukan pemeliharaan seperti peningkatan versi minor dan perubahan pada properti seperti grup parameter.

  • Setelah sebuah Aurora serverless instance bangun untuk operasi administratif seperti upgrade atau menerapkan pemeliharaan, Aurora menunggu setidaknya 20 menit sebelum menjeda instance itu lagi. Itu untuk memungkinkan operasi latar belakang apa pun selesai. Periode dua puluh menit juga menghindari jeda dan melanjutkan instance beberapa kali jika instance mengalami beberapa operasi administratif berturut-turut.

Cara kerja Aurora serverless jeda otomatis untuk berbagai jenis cluster Aurora

Pertimbangan untuk fitur jeda otomatis bergantung pada berapa banyak instance yang ada di klaster Aurora Anda, tingkatan promosi failover dari instance pembaca, dan apakah semua instance atau kombinasi dan disediakan. Aurora serverless Aurora serverless

Ketika fitur jeda otomatis diaktifkan, Anda dapat mengatur cluster Aurora Anda untuk keseimbangan yang tepat dari ketersediaan tinggi, respons cepat, dan skalabilitas yang sesuai dengan kasus penggunaan Anda. Anda melakukannya dengan memilih kombinasi instance, Aurora serverless instance yang disediakan, dan tingkatan promosi failover untuk instans DB di cluster Anda.

Jenis konfigurasi berikut menunjukkan pengorbanan yang berbeda antara ketersediaan tinggi dan pengoptimalan biaya untuk klaster Anda:

  • Untuk sistem pengembangan dan pengujian, Anda dapat mengatur cluster DB AZ tunggal dengan instans Aurora serverless DB. Instance tunggal melayani semua permintaan baca dan tulis. Ketika cluster tidak digunakan untuk interval waktu yang signifikan, instans DB berhenti. Pada saat itu, biaya komputasi DB untuk cluster Anda juga dijeda.

  • Untuk sistem yang menjalankan aplikasi di mana ketersediaan tinggi adalah prioritas, tetapi cluster masih memiliki periode di mana ia sepenuhnya menganggur, Anda dapat mengatur cluster multi-AZ di mana instance DB penulis dan pembaca berada. Aurora serverless Atur instance pembaca ke prioritas failover nol atau satu, sehingga instance penulis dan pembaca berhenti sejenak dan melanjutkan pada saat yang bersamaan. Sekarang Anda mendapatkan manfaat dari failover cepat saat cluster aktif. Ketika cluster tetap menganggur lebih lama dari ambang jeda otomatis, biaya instans DB untuk kedua instance dijeda. Ketika cluster melanjutkan pemrosesan, sesi database pertama membutuhkan waktu singkat untuk terhubung.

  • Misalkan klaster Anda terus-menerus aktif dengan jumlah aktivitas minimal, dan memerlukan respons cepat untuk koneksi apa pun. Dalam hal ini, Anda dapat membuat cluster dengan lebih dari satu instance Aurora serverless pembaca, dan memisahkan kapasitas beberapa instance pembaca dari penulis. Tentukan prioritas failover nol atau satu untuk instance penulis dan satu instance pembaca. Tentukan prioritas yang lebih besar dari satu untuk instance pembaca lainnya. Dengan begitu, contoh pembaca di tingkat prioritas yang lebih tinggi dapat berhenti otomatis, bahkan ketika penulis dan salah satu pembaca tetap aktif.

    Dalam hal ini, Anda dapat menggunakan beberapa teknik lain untuk memastikan bahwa klaster tetap tersedia secara terus menerus sambil tetap menurunkan ke kapasitas rendah selama periode idle:

    • Anda dapat menggunakan instance yang disediakan untuk penulis dan pembaca prioritas 0 atau 1. Dengan begitu, dua instance DB tidak pernah berhenti otomatis dan selalu tersedia untuk melayani lalu lintas database dan untuk melakukan failover.

    • Anda dapat menyiapkan titik akhir kustom yang menyertakan Aurora serverless instance di tingkat prioritas yang lebih tinggi, tetapi bukan penulis atau pembaca tingkat promosi 0 atau 1. Dengan begitu, Anda dapat mengarahkan sesi hanya-baca yang tidak sensitif terhadap latensi kepada pembaca yang mungkin dijeda secara otomatis. Anda dapat menghindari penggunaan titik akhir pembaca untuk permintaan tersebut, karena Aurora mungkin mengarahkan koneksi titik akhir pembaca ke instance pembaca yang selalu terjaga, atau ke salah satu instance yang dijeda otomatis. Menggunakan titik akhir kustom memungkinkan Anda mengarahkan koneksi ke berbagai grup instans berdasarkan preferensi Anda untuk respons cepat atau kapasitas penskalaan ekstra.

Cara kerja Aurora serverless jeda otomatis untuk instance penulis di cluster DB

Ketika cluster Aurora DB hanya berisi satu instans DB, mekanisme untuk menjeda otomatis dan melanjutkan instance DB sangat mudah. Itu hanya tergantung pada aktivitas pada contoh penulis. Anda mungkin memiliki konfigurasi seperti itu untuk cluster yang digunakan untuk pengembangan dan pengujian, atau untuk menjalankan aplikasi di mana ketersediaan tinggi tidak penting. Perhatikan bahwa dalam cluster instance tunggal, Aurora mengarahkan koneksi melalui titik akhir pembaca ke instance DB penulis. Jadi, untuk cluster DB instance tunggal, mencoba terhubung ke titik akhir pembaca menyebabkan instance DB penulis yang dijeda otomatis dilanjutkan.

Faktor-faktor tambahan berikut berlaku untuk klaster Aurora dengan beberapa instans DB:

  • Dalam cluster Aurora DB, instans DB penulis biasanya sering diakses. Oleh karena itu, Anda mungkin menemukan bahwa instans DB penulis tetap aktif bahkan ketika satu atau lebih instance DB pembaca berhenti secara otomatis.

  • Aktivitas tertentu pada instans DB pembaca mengharuskan instans DB penulis tersedia. Oleh karena itu, instance DB penulis tidak dapat dijeda sampai semua instance pembaca juga dijeda. Melanjutkan instance pembaca apa pun secara otomatis melanjutkan instance penulis, bahkan jika aplikasi Anda tidak mengakses instance penulis secara langsung.

  • Aurora serverlessinstance pembaca di tingkat promosi failover nol dan satu skala untuk menjaga kapasitasnya tetap sinkron dengan instance penulis. Jadi, ketika instance Aurora serverless penulis dilanjutkan, begitu juga instance Aurora serverless pembaca yang berada di tingkatan promosi nol atau satu.

Cara kerja Aurora serverless jeda otomatis untuk cluster multi-AZ

Dalam cluster Aurora DB yang berisi penulis dan satu atau lebih instance DB pembaca, beberapa instance Aurora serverless DB mungkin dijeda sementara instance DB lainnya aktif. Instance penulis dan setiap instance pembaca dengan prioritas failover 0 dan 1 selalu berhenti sejenak dan melanjutkan semuanya pada saat yang bersamaan. Instance pembaca dengan prioritas selain 0 atau 1 dapat menjeda dan melanjutkan secara independen dari instance lainnya.

Saat Anda menggunakan fitur ini untuk cluster dengan beberapa instance pembaca, Anda dapat mengelola biaya tanpa mengorbankan ketersediaan tinggi. Contoh penulis dan satu atau dua instance pembaca lainnya dapat tetap aktif setiap saat, sementara instance pembaca tambahan dapat berhenti ketika mereka tidak diperlukan untuk menangani lalu lintas baca volume tinggi.

Apakah instance pembaca dapat berhenti secara otomatis tergantung pada apakah kapasitasnya dapat diskalakan secara independen, atau apakah kapasitasnya terkait dengan instans DB penulis. Properti penskalaan itu bergantung pada prioritas failover dari instance DB pembaca. Ketika prioritas pembaca adalah nol atau satu, kapasitas pembaca melacak kapasitas instance DB penulis. Oleh karena itu, untuk memungkinkan instans DB pembaca berhenti secara otomatis dalam rentang situasi terluas, tetapkan prioritasnya ke nilai yang lebih tinggi dari satu.

Waktu untuk melanjutkan instance pembaca mungkin sedikit lebih lama daripada melanjutkan instance penulis. Untuk respons tercepat jika instance mungkin dijeda, sambungkan ke titik akhir cluster.

Cara kerja Aurora serverless jeda otomatis untuk cluster dengan instance yang disediakan

Instans DB apa pun yang disediakan di cluster Aurora DB Anda tidak akan berhenti secara otomatis. Hanya instance Aurora serverless DB, dengan kelas db.serverless instance, yang dapat menggunakan fitur jeda otomatis.

Ketika klaster Aurora Anda berisi instans DB yang disediakan, instans Aurora serverless penulis apa pun tidak berhenti secara otomatis. Itu karena persyaratan bahwa instance penulis tetap tersedia saat setiap instance pembaca aktif. Fakta bahwa Aurora serverless penulis tetap aktif juga berarti bahwa setiap instance Aurora serverless pembaca dengan prioritas failover 0 dan 1 tidak akan berhenti otomatis di cluster hibrida yang berisi instance yang disediakan.

Memantau klaster Aurora yang menggunakan jeda otomatis

Untuk memantau Aurora, Anda harus sudah terbiasa dengan prosedur pemantauan Memantau Amazon Aurora dengan Amazon CloudWatch dan CloudWatch metrik yang tercantum di dalamnya. Referensi metrik untuk Amazon Aurora Ketahuilah bahwa ada beberapa pertimbangan khusus saat Anda memantau klaster Aurora yang menggunakan fitur jeda otomatis:

  • Mungkin ada periode waktu ketika Aurora serverless instance tidak merekam data log dan sebagian besar metrik karena instance dijeda. Satu-satunya metrik yang dikirim ke CloudWatch saat instance dijeda adalah nol persen untuk CPUUtilization danACUUtilization, dan nol untuk. ServerlessDatabaseCapacity

  • Anda dapat memeriksa apakah Aurora serverless instance berhenti lebih atau kurang dari yang Anda harapkan. Untuk melakukannya, periksa seberapa sering ServerlessDatabaseCapacity metrik berubah dari nilai bukan nol menjadi nol, dan berapa lama metrik tetap nol. Jika instans tidak berhenti selama yang Anda harapkan, Anda tidak menghemat biaya sebanyak yang Anda bisa. Jika instans berhenti sejenak dan dilanjutkan lebih sering daripada yang Anda inginkan, klaster Anda mungkin memiliki latensi yang tidak perlu saat menanggapi permintaan koneksi. Untuk informasi tentang faktor-faktor yang mempengaruhi apakah dan seberapa sering Aurora serverless instance dapat berhenti, lihat Prasyarat dan Batasan untuk fitur jeda otomatis Aurora serverlessSituasi di mana Aurora serverless tidak berhenti otomatis, dan. Pemecahan masalah untuk jeda otomatis Aurora serverless

  • Anda juga dapat memeriksa file log yang mencatat jeda otomatis dan melanjutkan operasi untuk sebuah Aurora serverless instance. Jika instance tidak berhenti sejenak setelah interval batas waktu kedaluwarsa, file log ini juga menyertakan alasan mengapa jeda otomatis tidak terjadi. Untuk informasi selengkapnya, lihat Memantau Aurora serverless jeda dan melanjutkan aktivitas.

Memeriksa apakah sebuah Aurora serverless instance dijeda

Untuk menentukan apakah sebuah Aurora serverless instance berada dalam keadaan jeda, Anda dapat mengamati ACUUtilization metrik untuk instance tersebut. Metrik itu memiliki nilai nol sementara instance dijeda.

Sementara sebuah Aurora serverless instance dijeda, nilai statusnya masih terdaftar sebagai Tersedia. Hal yang sama berlaku saat Aurora serverless instance yang dijeda sedang dalam proses melanjutkan. Itu karena Anda dapat berhasil terhubung ke instance seperti itu, bahkan jika koneksi mengalami sedikit penundaan.

Setiap metrik yang terkait dengan ketersediaan instance Aurora mempertimbangkan periode saat instance dijeda sebagai waktu instans tersedia.

Acara untuk operasi jeda otomatis dan lanjutkan otomatis

Aurora memancarkan Aurora serverless kejadian saat jeda otomatis dan operasi lanjutkan otomatis dimulai, selesai, atau dibatalkan. Peristiwa yang terkait dengan fitur jeda otomatis telah RDS-EVENT-0370 selesai. RDS-EVENT-0374 Untuk detail tentang acara ini, lihatPeristiwa instans DB.

Cara kerja jeda otomatis dengan Performance Insights dan Enhanced Monitoring

Sementara Aurora serverless instance dijeda, Aurora tidak mengumpulkan informasi pemantauan untuk instance tersebut baik melalui Performance Insights atau Enhanced Monitoring. Ketika instance dilanjutkan, mungkin ada penundaan singkat sebelum Aurora melanjutkan pengumpulan informasi pemantauan tersebut.

Bagaimana fitur Aurora serverless jeda otomatis berinteraksi dengan metrik Aurora

Sementara sebuah Aurora serverless instance dijeda, itu tidak memancarkan sebagian besar CloudWatch metrik atau menulis informasi apa pun ke log database-nya. Satu-satunya metrik yang dikirim ke CloudWatch saat instance dijeda adalah nol persen untuk CPUUtilization danACUUtilization, dan nol untuk. ServerlessDatabaseCapacity

CloudWatch Kapan statistik komputasi terkait dengan ketersediaan instance atau cluster dan uptime, Aurora serverless instance dianggap tersedia selama waktu dijeda.

Saat Anda memulai tindakan AWS CLI atau RDS API untuk mendeskripsikan atau mengunduh log untuk instance yang dijeda, Aurora serverless instance akan dilanjutkan secara otomatis untuk membuat informasi log tersedia.

Contoh CloudWatch metrik

AWS CLI Contoh berikut menunjukkan bagaimana Anda dapat mengamati kapasitas instance yang berubah dari waktu ke waktu. Selama periode waktu, instance otomatis berhenti dan kemudian dilanjutkan. Sementara itu dijeda, ServerlessDatabaseCapacity metrik melaporkan nilai nol. Untuk menentukan apakah instance dijeda pada titik mana pun selama periode waktu, kami memeriksa apakah kapasitas minimum selama periode waktu itu adalah nol.

Contoh Linux berikut merupakan Aurora serverless contoh yang telah secara otomatis dijeda selama beberapa waktu. Kami mengambil sampel ServerlessDatabaseCapacity setiap menit, selama tiga menit. Nilai ACU minimum 0,0 menegaskan bahwa instance dijeda di beberapa titik selama setiap menit. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:11:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:12:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None

Selanjutnya, kami mencoba membuat koneksi ke instance yang dijeda. Aurora serverless Dalam contoh ini, kami sengaja menggunakan kata sandi yang salah sehingga upaya koneksi tidak berhasil. Meskipun gagal, upaya koneksi menyebabkan Aurora melanjutkan instance yang dijeda. 


$ mysql -h my_cluster_endpoint.rds.amazonaws.com -u admin -pwrong-password

ERROR 1045 (28000): Access denied for user 'admin'@'ip_address' (using password: YES)

Contoh Linux berikut menunjukkan bahwa instance yang dijeda dilanjutkan, tetap menganggur selama kurang lebih lima menit, dan kemudian kembali ke keadaan jeda. Instans dilanjutkan pada kapasitas 2,0 ACU. Kemudian ditingkatkan sedikit, misalnya untuk melakukan beberapa pembersihan internal. Karena tidak menerima upaya koneksi pengguna dalam periode batas waktu lima menit, ia beralih dari 4.0 ACU langsung ke status jeda. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
DATAPOINTS	2.0	2024-08-02T22:14:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:15:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:16:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:17:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:18:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:19:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:20:00+00:00	None

Jika laporan dimaksudkan untuk menunjukkan seberapa cepat instance ditingkatkan untuk menangani beban kerja, kami mungkin menentukan Maximum statistik alih-alih. Minimum Untuk perencanaan kapasitas dan estimasi biaya, kami dapat menentukan periode waktu yang lebih lama dan menggunakan Average statistik. Dengan begitu, kita dapat menentukan nilai kapasitas tipikal selama periode aktivitas tinggi, aktivitas rendah, dan keadaan jeda. Untuk memeriksa perilaku selama waktu yang tepat di sekitar jeda dan melanjutkan, kami dapat menentukan periode satu detik dan memeriksa interval waktu yang lebih pendek. Nilai stempel waktu dalam output, seperti2024-08-02T22:13:00+00:00, menunjukkan format untuk menentukan parameter yang tepat untuk opsi --start-time dan--end-time.

Pemecahan masalah untuk jeda otomatis Aurora serverless

Jika Anda menemukan bahwa Aurora serverless instance tidak berhenti sesering yang Anda harapkan, periksa kemungkinan penyebab berikut:

  • Konfirmasikan bahwa versi Aurora yang Anda jalankan mendukung kapasitas minimum nol ACU. Untuk rentang kapasitas versi Aurora yang berbeda, lihat. Kapasitas Aurora serverless

  • Konfirmasikan bahwa nilai kapasitas minimum untuk cluster diatur ke nol ACU.

  • Konfirmasikan bahwa instance yang dimaksud sebenarnya menggunakan kelas Aurora serverless instancedb.serverless, bukan salah satu kelas instance yang disediakan.

  • Konfirmasikan bahwa klaster tidak menggunakan fitur atau pengaturan yang tidak kompatibel dariPrasyarat dan Batasan untuk fitur jeda otomatis Aurora serverless.

  • Periksa file log yang ditampilkan saat Aurora serverless instance dijeda, dilanjutkan, atau Aurora tidak dapat menjeda atau melanjutkan instance karena alasan tertentu. Untuk informasi selengkapnya, lihat Memantau Aurora serverless jeda dan melanjutkan aktivitas.

  • Periksa apakah ada klien atau aplikasi yang menjaga koneksi tetap terbuka untuk jangka waktu yang lama. Sebaliknya, periksa apakah ada aplikasi yang menggunakan RDS Data API atau fungsi Lambda mengirim permintaan yang sering sehingga instance tidak pernah menganggur cukup lama untuk dijeda. Anda dapat memeriksa CloudWatch metrik seperti ConnectionAttempts danDatabaseConnections. Untuk informasi selengkapnya, lihat Instance-level metrik untuk Amazon Aurora.

  • Jika instance pembaca jarang berhenti, periksa prioritas failovernya. Jika pembaca digunakan untuk penskalaan baca dan bukan sebagai siaga jika terjadi failover, atur ke prioritas dalam kisaran 2-15.

  • Jika contoh penulis jarang berhenti sejenak, periksa penggunaan instance pembaca Anda. Penulis hanya dapat berhenti sejenak jika seluruh cluster menganggur. Itu karena koneksi ke instance pembaca mana pun menyebabkan penulis melanjutkan.

  • Jika aplikasi Anda menerima batas waktu selama permintaan koneksi saat Aurora serverless instance dilanjutkan, pertimbangkan untuk memperpanjang interval batas waktu yang digunakan oleh kode aplikasi Anda atau kerangka database yang mendasarinya. Batas waktu koneksi yang lebih lama mengurangi kemungkinan koneksi gagal saat Aurora serverless instance dilanjutkan. Namun, batas waktu yang lebih lama juga dapat membuat aplikasi Anda lebih lambat untuk mendeteksi masalah ketersediaan di klaster Anda.

    Sebaliknya, pertimbangkan untuk memperpanjang interval jeda otomatis sehingga aplikasi tidak sering menemukan instance yang dijeda.

    Jika tidak ada keseimbangan logis antara perilaku jeda otomatis dan respons klaster untuk aplikasi Anda, klaster tersebut mungkin bukan kandidat yang baik untuk menggunakan fitur jeda otomatis.

  • Jika Anda memperkirakan berapa lama Aurora serverless instans Anda akan dijeda, ketahuilah bahwa ada faktor-faktor yang membuatnya tidak praktis untuk membuat prediksi yang tepat.

    • Instans mungkin dilanjutkan secara berkala untuk melakukan pemeliharaan, peningkatan versi minor, atau menerapkan perubahan pada grup parameter.

    • Untuk cluster multi-AZ, ada situasi di mana melanjutkan satu instance menyebabkan instance lain dilanjutkan juga. Melanjutkan setiap pembaca selalu menyebabkan penulis melanjutkan. Melanjutkan penulis selalu menyebabkan pembaca dengan prioritas failover 0 dan 1 untuk melanjutkan.

    Kami merekomendasikan untuk mengukur waktu jeda aktual selama beberapa hari, dengan beban kerja yang realistis. Kemudian gunakan pengukuran tersebut untuk menetapkan garis dasar berapa proporsi waktu yang dapat Anda harapkan dari sebuah instance untuk dijeda.

  • Anda mungkin menemukan bahwa operasi internal seperti MySQL purge, MySQL event scheduler, PostgreSQL autovacuum, atau PostgreSQL jobs yang dijadwalkan melalui ekstensi tidak berjalan atau tidak selesai. pg_cron Instance tidak secara otomatis melanjutkan untuk melakukan operasi seperti itu yang tidak melibatkan koneksi pengguna ke database. Jika operasi internal tersebut sedang berlangsung ketika batas waktu jeda otomatis berakhir, tugas pemeliharaan seperti pembersihan MySQL dan autovacuum PostgreSQL dibatalkan. Pekerjaan terjadwal dari penjadwal acara MySQL atau ekstensi pg_cron PostgreSQL juga dibatalkan jika sedang berlangsung saat Aurora memulai operasi jeda.

    Jika Anda perlu memastikan bahwa instans secara berkala terjaga untuk melakukan operasi terjadwal, Anda dapat memulai koneksi untuk melanjutkan instance sebelum waktu mulai pekerjaan. Anda juga dapat meningkatkan interval batas waktu jeda otomatis sehingga operasi seperti autovacuum dapat berjalan lebih lama setelah aktivitas pengguna selesai. Anda juga dapat menggunakan mekanisme seperti fungsi Lambda untuk melakukan operasi database sesuai jadwal, dengan cara yang secara otomatis melanjutkan instance jika perlu.

Pertimbangan desain aplikasi untuk fitur jeda Aurora serverless otomatis

Ketika instans Aurora serverless DB dilanjutkan setelah dijeda secara otomatis, itu dimulai dengan kapasitas yang relatif kecil dan meningkat dari sana. Kapasitas awal ini berlaku bahkan jika instans DB memiliki kapasitas yang lebih tinggi segera sebelum dijeda secara otomatis.

Gunakan fitur ini dengan aplikasi yang dapat mentolerir interval sekitar 15 detik saat membuat koneksi. Itu menjelaskan kasus tipikal di mana sebuah Aurora serverless instance dilanjutkan karena satu atau sejumlah kecil koneksi masuk. Jika instance dijeda selama lebih dari 24 jam, waktu untuk melanjutkan mungkin lebih lama.

Jika Anda menggunakan Aurora serverless kombinasi dengan fitur stop/start cluster Aurora, waktu dimulainya kembali untuk Aurora serverless instance yang dijeda otomatis biasanya jauh lebih pendek daripada waktu untuk memulai cluster yang dihentikan.

Saat mengkodekan logika koneksi dalam aplikasi Anda, coba lagi koneksi jika upaya pertama mengembalikan kesalahan yang memiliki penyebab sementara. (Jika kesalahan disebabkan oleh kegagalan otentikasi, perbaiki kredensialnya sebelum mencoba lagi.) Kesalahan yang terjadi segera setelah dilanjutkan mungkin merupakan batas waktu, atau beberapa kesalahan yang terkait dengan batas basis data. Mencoba lagi dapat menangani masalah dalam kasus yang lebih jarang di mana Aurora serverless instance dilanjutkan karena banyaknya permintaan koneksi simultan. Dalam hal ini, beberapa koneksi mungkin membutuhkan waktu lebih lama dari biasanya untuk diproses, atau mungkin melebihi batas koneksi simultan pada upaya pertama.

Selama pengembangan aplikasi dan debugging, jangan biarkan sesi klien atau alat pemrograman dengan koneksi terbuka ke database. Aurora tidak akan menjeda instance jika ada koneksi yang dimulai pengguna yang terbuka, terlepas dari apakah koneksi tidak menjalankan pernyataan atau transaksi SQL apa pun. Ketika satu Aurora serverless instance di cluster Aurora tidak dapat berhenti sejenak, instance lain di cluster mungkin juga dicegah untuk berhenti. Untuk informasi selengkapnya, lihat Situasi di mana Aurora serverless tidak berhenti otomatis.

Aurora memancarkan peristiwa ketika instans Aurora serverless DB mulai dilanjutkan, selesai dilanjutkan, dan jika instance tidak dapat dilanjutkan karena alasan tertentu. Untuk detail tentang acara ini, lihatPeristiwa instans DB.