Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mengelola cluster Aurora Serverless v2 DB
Dengan Aurora Serverless v2, klaster Anda dapat dipertukarkan dengan klaster terprovisi. Aurora Serverless v2Properti 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](CHAP_Aurora.md).
Dalam topik berikut, Anda dapat mempelajari tentang pertimbangan manajemen untuk cluster yang berisi instans Aurora Serverless v2 DB.
**Topics**
+ [Mengatur rentang kapasitas Aurora Serverless v2 untuk sebuah klaster](#aurora-serverless-v2-setting-acus)
+ [Memeriksa rentang kapasitas untuk Aurora Serverless v2](#aurora-serverless-v2-checking-capacity)
+ [Menambahkan pembaca Aurora Serverless v2](#aurora-serverless-v2-adding-reader)
+ [Mengonversi penulis atau pembaca terprovisi menjadi Aurora Serverless v2](#aurora-serverless-v2-converting-from-provisioned)
+ [Mengonversi penulis atau pembaca Aurora Serverless v2 menjadi terprovisi](#aurora-serverless-v2-converting-to-provisioned)
+ [Menjeda instans Aurora Serverless v2 DB](#pause-when-inactive)
+ [Memilih tingkat promosi untuk pembaca Aurora Serverless v2](#aurora-serverless-v2-choosing-promotion-tier)
+ [Menggunakan TLS/SSL dengan Aurora Serverless v2](#aurora-serverless-v2.tls)
+ [Melihat penulis dan pembaca Aurora Serverless v2](#aurora-serverless-v2.viewing)
+ [Pencatatan log untuk Aurora Serverless v2](#aurora-serverless-v2.logging)
## Mengatur rentang kapasitas Aurora Serverless v2 untuk sebuah klaster
Untuk memodifikasi parameter konfigurasi atau pengaturan lain untuk klaster yang berisi instans DB Aurora Serverless v2, atau instans DB itu sendiri, ikuti prosedur umum yang sama seperti untuk klaster terprovisi. Untuk detailnya, lihat [Memodifikasi klaster DB Amazon Aurora](Aurora.Modifying.md).
Pengaturan terpenting yang unik untuk Aurora Serverless v2 adalah rentang kapasitas. Setelah Anda menetapkan nilai unit kapasitas Aurora (ACU) minimum dan maksimum untuk klaster Aurora, Anda tidak perlu secara aktif menyesuaikan kapasitas instans DB Aurora Serverless v2 di klaster. Aurora akan melakukannya untuk Anda. Pengaturan ini dikelola pada tingkat klaster. Nilai ACU minimum dan maksimum yang sama berlaku untuk setiap instans DB Aurora Serverless v2 dalam klaster.
Anda dapat mengatur nilai spesifik berikut:
+ **Minimum ACUs** — Instans Aurora Serverless v2 DB dapat mengurangi kapasitas hingga jumlah ini ACUs.
+ **Maksimum ACUs** — Instans Aurora Serverless v2 DB dapat meningkatkan kapasitas hingga jumlah ini ACUs.
Rentang kapasitas yang tersedia untuk Aurora Serverless v2 adalah fungsi dari versi mesin DB dan versi platform. 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, lihat[Kapasitas Aurora Serverless v2](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
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](aurora-serverless-v2-auto-pause.md)
Untuk informasi selengkapnya tentang memastikan bahwa cluster Aurora Serverless v2 DB Anda dapat menskalakan hingga 256 ACUs, lihat[Memutakhirkan cluster Aurora Serverless v2 DB Anda untuk memungkinkan penskalaan ke 256 ACUs](#setting-256-acus).
**catatan**
Ketika Anda memodifikasi rentang kapasitas untuk klaster DB Aurora Serverless v2, perubahannya akan terjadi dengan segera, terlepas dari apakah Anda memilih untuk menerapkannya langsung atau selama periode pemeliharaan terjadwal berikutnya.
DiAurora 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](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring) dan [Performa dan penskalaan untuk Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md). 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 Konsol Manajemen AWS AWS CLI, atau Amazon RDS. Rentang kapasitas ini berlaku untuk setiap instans DB Aurora Serverless v2 di klaster.
Misalnya, kluster Anda memiliki rentang kapasitas 1—16 ACUs dan berisi dua instans Aurora Serverless v2 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 instans DB Aurora Serverless v2 ke nilai yang didasarkan pada nilai ACU maksimum dalam rentang kapasitas. Untuk mengetahui daftar parameter tersebut, lihat [Koneksi maksimum untuk Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections). 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.
### Konsol
Anda dapat mengatur rentang kapasitas klaster yang berisi instans DB Aurora Serverless v2 dengan Konsol Manajemen AWS.
Saat Anda menggunakan konsol, Anda mengatur rentang kapasitas untuk klaster saat Anda menambahkan instans DB Aurora Serverless v2 pertama ke klaster tersebut. Anda dapat melakukannya saat Anda memilih kelas instans DB **Nirserver v2** untuk instans DB penulis saat Anda membuat klaster. Anda dapat melakukannya saat Anda memilih kelas instans DB **Nirserver** saat Anda menambahkan instans DB pembaca Aurora Serverless v2 ke klaster. 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](aurora-serverless-v2.create.md#aurora-serverless-v2-adding-writer), [Menambahkan pembaca Aurora Serverless v2](#aurora-serverless-v2-adding-reader), dan [Mengonversi penulis atau pembaca terprovisi menjadi Aurora Serverless v2](#aurora-serverless-v2-converting-from-provisioned).
Rentang kapasitas apa pun yang Anda tetapkan di tingkat klaster berlaku untuk semua instans DB Aurora Serverless v2 di klaster Anda. Gambar berikut menunjukkan klaster dengan beberapa instans DB pembaca Aurora Serverless v2. Masing-masing memiliki rentang kapasitas yang identik 2-64 ACUs.
![\[Klaster dengan beberapa instans DB pembaca Aurora Serverless v2\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_identical_all_instances_in_tree_view.png)
**Untuk memodifikasi rentang kapasitas klaster Aurora Serverless v2**
1. Buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Basis data**.
1. Pilih klaster yang berisi instans DB Aurora Serverless v2 Anda dari daftar. Klaster ini harus sudah berisi setidaknya satu instans DB Aurora Serverless v2. Jika tidak, Aurora tidak menampilkan bagian **Rentang kapasitas**.
1. Untuk **Tindakan**, pilih **Modifikasi**.
1. 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. Rentang kapasitas yang tersedia tergantung pada versi mesin DB Anda dan versi platform.
1. 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.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/sv2_capacity_settings_256_acus.png)
1. Pilih **Lanjutkan**. Halaman **Ringkasan modifikasi** akan muncul.
1. Pilih **Terapkan segera**.
Perubahan kapasitas terjadi segera, terlepas dari apakah Anda memilih untuk menerapkannya segera atau selama periode pemeliharaan terjadwal berikutnya.
1. Pilih **Ubah klaster** untuk menerima ringkasan modifikasi tersebut. Anda juga dapat memilih **Kembali** untuk memodifikasi perubahan atau **Batalkan** untuk menghapus perubahan Anda.
### AWS CLI
Untuk mengatur kapasitas cluster tempat Anda ingin menggunakan instance Aurora Serverless v2 DB menggunakan AWS CLI, jalankan [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI perintah. Tentukan opsi `--serverless-v2-scaling-configuration`. Klaster ini mungkin sudah berisi satu atau beberapa instans DB Aurora Serverless v2, atau Anda dapat menambahkan instans DB nanti. Nilai valid untuk bidang `MinCapacity` dan `MaxCapacity` mencakup hal berikut:
+ `0`, `0.5``1`,`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.
Kapasitas maksimum yang tersedia tergantung pada versi mesin DB Anda dan versi platform.
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 instance Aurora Serverless v2 DB ke cluster dan setiap instans DB baru dapat menskalakan antara 48,5 dan 64. ACUs Rentang kapasitas baru juga berlaku untuk semua instans DB Aurora Serverless v2 yang sudah ada di klaster. 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 rentang kapasitas Aurora Serverless v2 untuk klaster Aurora](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster).
Untuk memodifikasi konfigurasi penskalaan cluster Aurora Serverless DB menggunakan AWS CLI, jalankan [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 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.5``2`, dan sebagainya, dengan penambahan 0,5 hingga maksimum. ACUs `256`
+ Aurora PostgreSQL:`0`,,,,`0.5`, `1``1.5`, dan sebagainya`2`, 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 instans DB Aurora Serverless v2 bernama `sample-instance` yang merupakan bagian dari klaster bernama `sample-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
```
### API RDS
Anda dapat mengatur kapasitas instans Aurora DB dengan operasi [Modify DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API. Tentukan parameter `ServerlessV2ScalingConfiguration`. Nilai valid untuk bidang `MinCapacity` dan `MaxCapacity` mencakup hal berikut:
+ `0`, `0.5``1`,`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 instans Aurora Serverless v2 DB dengan operasi [Modify DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) 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.5``2`, dan sebagainya, dengan penambahan 0,5 hingga maksimum. ACUs `256`
+ Aurora PostgreSQL:`0`,,,,`0.5`, `1``1.5`, dan sebagainya`2`, dengan penambahan 0,5 hingga maksimum. ACUs `256`
+ Nilai ACU minimum 0 hanya tersedia untuk versi Aurora yang mendukung fitur jeda otomatis.
Kapasitas maksimum yang tersedia tergantung pada versi mesin DB Anda dan versi platform.
Perubahan kapasitas terjadi segera, terlepas dari apakah Anda memilih untuk menerapkannya segera atau selama periode pemeliharaan terjadwal berikutnya.
### Memutakhirkan cluster Aurora Serverless v2 DB Anda untuk memungkinkan penskalaan ke 256 ACUs
Dalam beberapa kasus, ketika Anda mencoba untuk skala cluster Aurora Serverless v2 DB Anda ke kapasitas yang lebih besar dari 128 ACUs, Anda menerima pesan kesalahan. Pesan kesalahan memberi tahu Anda instance mana yang tidak kompatibel dengan rentang penskalaan baru. Ini menyoroti hubungan penting antara rentang kapasitas Anda, versi mesin DB, dan versi platform.
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 [Kapasitas Aurora Serverless v2](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
+ Versi platform yang lebih lama - Tingkatkan platform untuk cluster Aurora Serverless v2 DB Anda. Anda dapat melakukannya dengan salah satu cara berikut:
+ Hentikan dan restart cluster DB. Ketika cluster restart, itu akan berada pada versi platform terbaru yang mampu yang mungkin mampu mencapai maksimum ACU yang lebih tinggi.
Namun, menghentikan dan memulai cluster DB menimbulkan beberapa downtime, biasanya beberapa menit. Untuk informasi selengkapnya, lihat [Menghentikan dan memulai klaster DB Amazon Aurora](aurora-cluster-stop-start.md).
+ Gunakan blue/green penerapan. Untuk informasi selengkapnya, lihat [Ikhtisar Amazon Blue/Green Aurora](blue-green-deployments-overview.md).
1. Buat blue/green penyebaran. Untuk informasi selengkapnya, lihat [Membuat blue/green penyebaran di ](blue-green-deployments-creating.md).
1. Konfirmasikan bahwa Anda dapat mengatur kapasitas maksimum untuk lingkungan pementasan (hijau) ke 256 ACUs.
1. Beralih ke lingkungan hijau. Untuk informasi selengkapnya, lihat [Mengalihkan blue/green penerapan di ](blue-green-deployments-switching.md).
1. Hapus cluster DB asli.
**catatan**
Jika Anda mempertahankan kredensi database AWS Secrets Manager, Anda tidak dapat menggunakan blue/green penerapan.
Aurora Global Database tidak mendukung blue/green penerapan.
## Memeriksa rentang kapasitas untuk Aurora Serverless v2
Prosedur untuk memeriksa rentang kapasitas untuk klaster Aurora Serverless v2 Anda mengharuskan Anda menetapkan rentang kapasitas terlebih dahulu. Jika Anda belum melakukannya, ikuti prosedur dalam [Mengatur rentang kapasitas Aurora Serverless v2 untuk sebuah klaster](#aurora-serverless-v2-setting-acus).
Rentang kapasitas apa pun yang Anda tetapkan di tingkat klaster berlaku untuk semua instans DB Aurora Serverless v2 di klaster Anda. Gambar berikut menunjukkan klaster dengan beberapa instans DB Aurora Serverless v2. Masing-masing memiliki rentang kapasitas yang identik.
![\[Detail cluster untuk beberapa instans Aurora Serverless v2 DB.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_identical_all_instances_in_tree_view.png)
Anda juga dapat melihat halaman detail untuk instans DB Aurora Serverless v2 apa pun di klaster. Rentang kapasitas instans DB muncul di tab **Konfigurasi**.
![\[Opsi Tipe instans, bagian dari antarmuka pengguna konfigurasi instans DB\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_shown_for_serverless_instance.png)
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 rentang kapasitas Aurora Serverless v2 untuk sebuah klaster](#aurora-serverless-v2-setting-acus).
### Memeriksa rentang kapasitas saat ini untuk klaster Aurora
Anda dapat memeriksa rentang kapasitas yang dikonfigurasi untuk instans DB Aurora Serverless v2 di klaster dengan memeriksa atribut `ServerlessV2ScalingConfiguration` untuk klaster. 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 pembaca Aurora Serverless v2
Untuk menambahkan instans DB pembaca Aurora Serverless v2 ke klaster Anda, Anda mengikuti prosedur umum yang sama seperti dalam [Menambahkan Replika Aurora ke klaster DB](aurora-replicas-adding.md). Pilih kelas instans **Nirserver v2** untuk instans DB baru.
Jika instans DB pembaca adalah instans DB Aurora Serverless v2 pertama di klaster, Anda juga perlu memilih rentang kapasitas. Pengaturan ini berlaku untuk instans DB pembaca ini dan instans DB Aurora Serverless v2 lainnya yang ditambahkan ke klaster. Setiap instans DB Aurora Serverless v2 dapat diskalakan antara nilai ACU minimum dan maksimum.
Jika ada Aurora Serverless v2 instance lain yang 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 untukAurora Serverless v2.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_settable_for_add_reader_modify_instance.png)
Jika Anda sudah menambahkan instans DB Aurora Serverless v2 apa pun ke klaster, rentang kapasitas saat ini akan ditampilkan saat menambahkan instans DB pembaca Aurora Serverless v2 lain. Gambar berikut menunjukkan kontrol hanya baca tersebut.
![\[Pengaturan kapasitas untuk Aurora Serverless v2 ditampilkan di antarmuka Add reader.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_fixed_for_add_reader_modify_instance.png)
Jika Anda ingin mengubah rentang kapasitas klaster, ikuti prosedur dalam [Mengatur rentang kapasitas Aurora Serverless v2 untuk sebuah klaster](#aurora-serverless-v2-setting-acus).
Untuk klaster yang berisi lebih dari satu instans DB pembaca, prioritas failover dari setiap instans DB pembaca Aurora Serverless v2 memainkan peran penting dalam cara instans DB tersebut menaikkan dan menurunkan skalanya. 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 pembaca Aurora Serverless v2](#aurora-serverless-v2-choosing-promotion-tier).
Untuk cara lain agar Anda dapat melihat rentang kapasitas saat ini untuk sebuah klaster, lihat [Memeriksa rentang kapasitas untuk Aurora Serverless v2](#aurora-serverless-v2-checking-capacity).
## Mengonversi penulis atau pembaca terprovisi menjadi Aurora Serverless v2
Anda dapat mengonversi instans DB terprovisi untuk menggunakan Aurora Serverless v2. Untuk melakukannya, ikuti prosedur dalam [Memodifikasi instans DB dalam klaster DB](Aurora.Modifying.md#Aurora.Modifying.Instance). Klaster harus memenuhi persyaratan dalam [Persyaratan dan batasan untuk Aurora Serverless v2](aurora-serverless-v2.requirements.md). Misalnya, instans DB Aurora Serverless v2 mengharuskan klaster menjalankan versi mesin minimum tertentu.
Misalkan Anda mengonversi klaster terprovisi yang sedang berjalan untuk memanfaatkan Aurora Serverless v2. Dalam hal ini, Anda dapat meminimalkan waktu henti dengan mengonversi instans DB menjadi Aurora Serverless v2 sebagai langkah pertama dalam proses switchover. Untuk prosedur lengkapnya, lihat [Beralih dari klaster terprovisi ke Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.switch-from-provisioned).
Jika instans DB yang Anda konversi adalah instans DB Aurora Serverless v2 pertama di klaster, Anda perlu memilih rentang kapasitas untuk klaster sebagai bagian dari operasi **Ubah**. Rentang kapasitas ini berlaku untuk setiap instans DB Aurora Serverless v2 yang ditambahkan ke klaster. Gambar berikut menunjukkan halaman tempat Anda menentukan unit kapasitas Aurora minimum dan maksimum ()ACUs.
![\[Antarmuka pengguna konfigurasi instans\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_settable_for_add_reader_modify_instance.png)
Untuk detail tentang pentingnya rentang kapasitas, lihat [Kapasitas Aurora Serverless v2](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
Jika klaster sudah berisi satu atau beberapa instans DB Aurora Serverless v2, Anda akan melihat rentang kapasitas yang ada selama operasi **Ubah**. Gambar berikut menunjukkan contoh panel informasi tersebut.
![\[Panel informasi rentang kapasitas\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_fixed_for_add_reader_modify_instance.png)
Jika Anda ingin mengubah rentang kapasitas untuk klaster setelah Anda menambahkan instans DB Aurora Serverless v2 lainnya, ikuti prosedurnya dalam [Mengatur rentang kapasitas Aurora Serverless v2 untuk sebuah klaster](#aurora-serverless-v2-setting-acus).
## Mengonversi penulis atau pembaca Aurora Serverless v2 menjadi terprovisi
Anda dapat mengonversi instans DB Aurora Serverless v2 menjadi instans DB terprovisi. Untuk melakukannya, ikuti prosedur dalam [Memodifikasi instans DB dalam klaster DB](Aurora.Modifying.md#Aurora.Modifying.Instance). Pilih kelas instans DB selain **Nirserver**.
Anda dapat mengonversi instans Aurora Serverless v2 DB ke provisioned jika membutuhkan kapasitas yang lebih besar daripada yang tersedia dengan unit kapasitas Aurora maksimum (ACUs) dari instans DB. Aurora Serverless v2 Misalnya, kelas instans DB db.r5 dan db.r6g terbesar memiliki kapasitas memori yang lebih besar daripada yang dapat dicapai oleh instans DB Aurora Serverless v2 yang diskalakan.
**Tip**
Beberapa kelas instans DB yang lebih lama seperti db.r3 dan db.t2 tidak tersedia untuk versi Aurora yang Anda gunakan dengan Aurora Serverless v2. Untuk melihat kelas instans DB mana yang dapat Anda gunakan saat mengonversi instans DB Aurora Serverless v2 menjadi instans terprovisi, lihat [Mesin DB yang didukung untuk kelas instans DB](Concepts.DBInstanceClass.SupportAurora.md).
Jika Anda mengonversi instans DB penulis untuk klaster Anda dari Aurora Serverless v2 menjadi terprovisi, Anda dapat mengikuti prosedur dalam [Beralih dari klaster terprovisi ke Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.switch-from-provisioned), tetapi secara terbalik. Alihkan salah satu instans DB pembaca di klaster dari Aurora Serverless v2 menjadi terprovisi. Kemudian lakukan failover untuk membuat instans DB terprovisi tersebut menjadi penulis.
Rentang kapasitas apa pun yang sebelumnya Anda tentukan untuk klaster akan tetap ada, bahkan jika semua instans DB Aurora Serverless v2 dihapus dari klaster. Jika Anda ingin mengubah rentang kapasitas, Anda dapat memodifikasi klaster, seperti yang dijelaskan dalam [Mengatur rentang kapasitas Aurora Serverless v2 untuk sebuah klaster](#aurora-serverless-v2-setting-acus).
## Menjeda instans Aurora Serverless v2 DB
Anda dapat mengonfigurasi cluster Aurora untuk secara otomatis menjeda dan melanjutkan instans DB mereka. Aurora Serverless v2 Untuk informasi selengkapnya, lihat [Penskalaan ke Nol ACUs dengan jeda otomatis dan lanjutkan Aurora Serverless v2](aurora-serverless-v2-auto-pause.md).
## Memilih tingkat promosi untuk pembaca Aurora Serverless v2
Untuk klaster yang berisi beberapa instans DB Aurora Serverless v2 atau gabungan instans terprovisi dan instans DB Aurora Serverless v2, perhatikan pengaturan tingkat promosi untuk setiap instans DB Aurora Serverless v2. Pengaturan ini mengontrol lebih banyak perilaku untuk instans DB Aurora Serverless v2 dibandingkan dengan instans DB terprovisi.
Dalam Konsol Manajemen AWS, 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 instans DB pembaca Aurora Serverless v2, nomor tingkat juga menentukan apakah instans DB menaikkan skalanya agar sesuai dengan kapasitas instans DB penulis atau diskalakan secara independen berdasarkan beban kerjanya sendiri. Instans DB pembaca Aurora Serverless v2 di tingkat 0 atau 1 dipertahankan 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 terprovisi, Aurora memperkirakan kapasitas Aurora Serverless v2 yang setara. Aurora menggunakan perkiraan tersebut sebagai kapasitas minimum untuk instans DB pembaca Aurora Serverless v2.
Instans DB pembaca Aurora Serverless v2 di tingkat 2–15 tidak memiliki batasan 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 [Penskalaan Aurora Serverless v2](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.scaling).
## Menggunakan TLS/SSL dengan Aurora Serverless v2
Aurora Serverless v2dapat menggunakan protokol Transport Layer Security/Secure Sockets Layer (TLS/SSL) untuk mengenkripsi komunikasi antara klien dan instans DB Anda. Aurora Serverless v2 Ini mendukung TLS/SSL versi 1.0, 1.1, dan 1.2. Untuk informasi umum tentang penggunaan TLS/SSL dengan Aurora, lihat. [Koneksi TLS ke cluster DB MySQL Aurora](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)
Untuk mempelajari selengkapnya tentang menghubungkan ke basis data Aurora MySQL dengan klien MySQL, lihat [Menghubungkan ke instans DB yang menjalankan mesin basis data MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html).
Aurora Serverless v2mendukung semua TLS/SSL mode yang tersedia untuk klien MySQL `mysql` () dan klien PostgreSQL `psql` (), termasuk yang tercantum dalam tabel berikut.
| Deskripsi TLS/SSL mode | mysql | psql |
| --- | --- | --- |
| Hubungkan tanpa menggunakan TLS/SSL. | DISABLED | disable |
| Coba koneksi menggunakan TLS/SSL terlebih dahulu, tetapi kembali ke non-SSL jika perlu. | PREFERRED | prefer (default) |
| Memberlakukan penggunaan TLS/SSL. | REQUIRED | require |
| Menegakkan TLS/SSL dan memverifikasi otoritas sertifikat (CA). | VERIFY\$1CA | verify-ca |
| Memberlakukan TLS/SSL, memverifikasi CA, dan memverifikasi nama host CA. | VERIFY\$1IDENTITY | 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](https://www.amazontrust.com/repository/AmazonRootCA1.pem) 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html).
Untuk informasi selengkapnya tentang menghubungkan ke klaster DB Aurora secara umum, lihat [Menghubungkan ke klaster DB Amazon Aurora](Aurora.Connecting.md).
### Cipher suite yang didukung untuk koneksi ke klaster DB Aurora Serverless v2
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 TLS/SSL koneksi klien ke database 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.
Klaster DB Aurora Serverless v2 yang didasarkan pada Aurora MySQL mendukung cipher suite yang sama dengan klaster DB terprovisi Aurora MySQL. Untuk informasi tentang cipher suite ini, lihat [Mengonfigurasi cipher suite untuk koneksi ke klaster DB Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.ConfiguringCipherSuites).
Klaster DB Aurora Serverless v2 yang didasarkan pada Aurora PostgreSQL mendukung cipher suite yang sama dengan klaster DB terprovisi Aurora PostgreSQL. Untuk informasi tentang cipher suite ini, lihat [Mengonfigurasi cipher suite untuk koneksi ke klaster DB Aurora PostgreSQL](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL.ConfiguringCipherSuites).
## Melihat penulis dan pembaca Aurora Serverless v2
Anda dapat melihat detail instans DB Aurora Serverless v2 dengan cara yang sama seperti yang Anda lakukan untuk instans DB terprovisi. Untuk melakukannya, ikuti prosedur umum dari [Melihat klaster DB Amazon Aurora](accessing-monitoring.md#Aurora.Viewing). Sebuah klaster mungkin berisi seluruh instans DB Aurora Serverless v2, seluruh instans DB terprovisi, atau beberapa dari masing-masing.
Setelah membuat satu atau beberapa instans DB Aurora Serverless v2, Anda dapat melihat instans DB mana yang memiliki jenis **Nirserver** dan mana yang memiliki jenis **Instans**. Anda juga dapat melihat unit kapasitas Aurora minimum dan maksimum (ACUs) yang dapat digunakan instans Aurora Serverless v2 DB. Setiap ACU merupakan kombinasi dari kapasitas pemrosesan (CPU) dan memori (RAM). Rentang kapasitas ini berlaku untuk setiap instans DB Aurora Serverless v2 di klaster. Untuk prosedur untuk memeriksa rentang kapasitas klaster atau instans DB Aurora Serverless v2 apa pun di klaster, lihat [Memeriksa rentang kapasitas untuk Aurora Serverless v2](#aurora-serverless-v2-checking-capacity).
Dalam Konsol Manajemen AWS, instance Aurora Serverless v2 DB ditandai di bawah kolom **Ukuran** di halaman **Database**. Instans DB terprovisi menunjukkan nama kelas instans DB seperti r6g.xlarge. Instans DB Aurora Serverless menunjukkan **Nirserver** 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 setiap instans DB Aurora Serverless v2 di konsol. Misalnya, Anda mungkin melihat bagian **Tipe instans** seperti berikut ini. Di sini, nilai **tipe Instance** adalah **Tanpa Server 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\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_shown_for_serverless_instance.png)
Anda dapat memantau kapasitas setiap instans DB Aurora Serverless v2 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 Konsol Manajemen AWS, 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](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).
## Pencatatan log 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](AuroraMySQL.Auditing.md).
Untuk Aurora PostgreSQL, Anda dapat mengaktifkan log berikut pada instans DB Aurora Serverless v2 Anda.
| 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`. |
**Topics**
+ [Logging dengan Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging)
+ [Melihat Aurora Serverless v2 log di Amazon CloudWatch](#aurora-serverless-v2.logging.monitoring)
+ [Kapasitas pemantauan dengan Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging.monitoring)
+ [Memantau Aurora Serverless v2 jeda dan melanjutkan aktivitas](#autopause-logging-instance-log)
### Logging dengan Amazon CloudWatch
Setelah Anda menggunakan prosedur [Pencatatan log untuk Aurora Serverless v2](#aurora-serverless-v2.logging) 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 secara otomatis diunggah ke CloudWatch. Anda juga dapat mengunggah log lain dari instans Aurora Serverless v2 DB ke CloudWatch.
Kemudian Anda memilih log mana yang akan diunggah CloudWatch, dengan menggunakan pengaturan **ekspor Log** di Konsol Manajemen AWS atau `--enable-cloudwatch-logs-exports` opsi di AWS CLI.
Anda dapat memilih Aurora Serverless v2 log mana yang akan diunggah CloudWatch. Untuk informasi selengkapnya, lihat [Menggunakan Audit Lanjutan dengan klaster Amazon Aurora My DB SQL](AuroraMySQL.Auditing.md).
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 sarankan Anda membuat grup parameter klaster DB kustom Anda sebelum membuat klaster DB Aurora Serverless v2 Anda, agar tersedia untuk dipilih saat membuat basis data pada konsol.
**catatan**
Untuk Aurora Serverless v2, Anda dapat membuat klaster DB dan grup parameter DB. Ini kontras dengan Aurora Serverless v1, yang hanya memungkinkan Anda membuat grup parameter klaster DB.
### Melihat Aurora Serverless v2 log di Amazon CloudWatch
Setelah Anda menggunakan prosedur dalam [Logging dengan Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging) 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](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor) [Menerbitkan log Aurora PostgreSQL ke Amazon Logs CloudWatch](AuroraPostgreSQL.CloudWatch.md)
**Untuk melihat log untuk klaster DB Aurora Serverless v2 Anda**
1. Buka CloudWatch konsol di [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Pilih Anda Wilayah AWS.
1. Pilih **Grup log**.
1. Pilih log klaster DB Aurora Serverless v2 Anda dari daftar. Pola penamaan log adalah sebagai berikut.
```
/aws/rds/cluster/cluster-name/log_type
```
**catatan**
Untuk klaster DB Aurora Serverless v2 yang kompatibel dengan Aurora MySQL, log kesalahan menyertakan peristiwa penskalaan pool buffer meskipun tidak ada kesalahan.
### Kapasitas pemantauan dengan Amazon CloudWatch
DenganAurora Serverless v2, Anda dapat menggunakannya CloudWatch untuk memantau kapasitas dan pemanfaatan semua instans Aurora Serverless v2 DB di cluster Anda. Anda dapat melihat metrik tingkat instans untuk memeriksa kapasitas setiap instans DB Aurora Serverless v2 saat menaikkan dan menurunkan skalanya. 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 untuk Aurora Serverless v2, lihat [CloudWatch Metrik Amazon penting untuk Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).
**Untuk memantau kapasitas klaster DB Aurora Serverless v2 Anda**
1. Buka CloudWatch konsol di [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Pilih **Metrik**. Semua metrik yang tersedia muncul sebagai kartu di konsol, yang dikelompokkan berdasarkan nama layanan.
1. Pilih **RDS**.
1. (Opsional) Gunakan kotak **Pencarian** untuk menemukan metrik yang sangat penting untuk Aurora Serverless v2: `ServerlessDatabaseCapacity`, `ACUUtilization`, `CPUUtilization`, dan `FreeableMemory`.
Kami menyarankan Anda menyiapkan CloudWatch dasbor untuk memantau kapasitas cluster Aurora Serverless v2 DB Anda menggunakan metrik terkait kapasitas. Untuk mempelajari caranya, lihat [Membangun dasbor dengan CloudWatch](https://docs.aws.amazon.com/autoscaling/application/userguide/monitoring-cloudwatch.html).
Untuk mempelajari lebih lanjut tentang menggunakan Amazon CloudWatch dengan Amazon Aurora, lihat. [Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch](AuroraMySQL.Integrating.CloudWatch.md)
### Memantau Aurora Serverless v2 jeda dan melanjutkan aktivitas
Aurora menulis file log terpisah untuk instans Aurora Serverless v2 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 nama`instance.log`, dan log lama diberi nama menggunakan pola`instance.YYYY-MM-DD.N.log`.
Log ini diaktifkan secara default untuk instans Aurora Serverless v2 DB dengan jeda otomatis diaktifkan. Anda dapat melihat isi log ini di Konsol Manajemen AWS 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](USER_Events.Messages.md#USER_Events.Messages.instance) 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.log`Ini memberikan detail yang lebih terperinci tentang alasan mengapa sebuah Aurora Serverless v2 instance 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](aurora-serverless-v2-auto-pause.md#auto-pause-waking)
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 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 sebuah Aurora Serverless v2 instance mungkin melebihi interval batas waktu jeda otomatis, tetapi dicegah agar tidak berhenti:
+ **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.