Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mengelola cluster Aurora serverless DB
Dengan Aurora serverless, klaster Anda dapat dipertukarkan dengan klaster terprovisi. Aurora serverlessProperti 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 DB.
**Topics**
+ [Mengatur rentang kapasitas Aurora serverless untuk sebuah klaster](#aurora-serverless-v2-setting-acus)
+ [Memeriksa rentang kapasitas untuk Aurora serverless](#aurora-serverless-v2-checking-capacity)
+ [Memeriksa versi platform untuk Aurora serverless cluster yang ada](#aurora-serverless-v2-checking-platform-version)
+ [Menambahkan pembaca Aurora serverless](#aurora-serverless-v2-adding-reader)
+ [Mengonversi penulis atau pembaca terprovisi menjadi Aurora serverless](#aurora-serverless-v2-converting-from-provisioned)
+ [Mengonversi penulis atau pembaca Aurora serverless menjadi terprovisi](#aurora-serverless-v2-converting-to-provisioned)
+ [Menjeda instans Aurora serverless DB](#pause-when-inactive)
+ [Memilih tingkat promosi untuk pembaca Aurora serverless](#aurora-serverless-v2-choosing-promotion-tier)
+ [Menggunakan TLS/SSL dengan Aurora serverless](#aurora-serverless-v2.tls)
+ [Melihat penulis dan pembaca Aurora serverless](#aurora-serverless-v2.viewing)
+ [Pencatatan log untuk Aurora serverless](#aurora-serverless-v2.logging)
## Mengatur rentang kapasitas Aurora serverless untuk sebuah klaster
Untuk memodifikasi parameter konfigurasi atau pengaturan lain untuk klaster yang berisi instans DB Aurora serverless, 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 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 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 dalam klaster.
Anda dapat mengatur nilai spesifik berikut:
+ **ACU Minimum** – Instans DB Aurora serverless dapat mengurangi kapasitas hingga mencapai jumlah ACU ini.
+ **ACU Maksimum** – instans DB Aurora serverless dapat menambah kapasitas hingga mencapai jumlah ACU ini.
Rentang kapasitas yang tersedia untuk Aurora serverless adalah fungsi dari versi mesin DB dan versi platform. Versi mesin DB yang lebih baru memungkinkan kapasitas maksimum 256 ACU, kapasitas minimum 0 ACU, atau keduanya. Untuk rentang kapasitas untuk berbagai versi mesin DB, lihat[Kapasitas Aurora serverless](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 ACU, lihat. [Penskalaan ke Zero ACU dengan jeda otomatis dan lanjutkan Aurora serverless](aurora-serverless-v2-auto-pause.md)
Untuk informasi selengkapnya tentang memastikan bahwa cluster Aurora serverless DB Anda dapat menskalakan hingga 256 ACU, lihat. [Memutakhirkan cluster Aurora serverless DB Anda untuk memungkinkan penskalaan ke 256 ACU](#setting-256-acus)
**catatan**
Ketika Anda memodifikasi rentang kapasitas untuk klaster DB Aurora serverless, perubahannya akan terjadi dengan segera, terlepas dari apakah Anda memilih untuk menerapkannya langsung atau selama periode pemeliharaan terjadwal berikutnya.
DiAurora serverless, 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](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring) dan [Performa dan penskalaan untuk Aurora serverless](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 ACU tertentu dengan, API Konsol Manajemen AWS, atau Amazon RDS. AWS CLI Rentang kapasitas ini berlaku untuk setiap instans DB Aurora serverless di klaster.
Misalnya, anggaplah klaster Anda memiliki rentang kapasitas 1–16 ACU dan berisi dua instans DB Aurora serverless. Kemudian, klaster ini secara keseluruhan menggunakan antara 2 ACU (saat idle) dan 32 ACU (saat dimanfaatkan sepenuhnya). Jika Anda mengubah rentang kapasitas dari 8 menjadi 40,5 ACU, sekarang seluruh cluster mengkonsumsi 16 ACU saat idle, dan hingga 81 ACU saat digunakan sepenuhnya.
Aurora secara otomatis menetapkan parameter tertentu untuk instans DB Aurora serverless ke nilai yang didasarkan pada nilai ACU maksimum dalam rentang kapasitas. Untuk mengetahui daftar parameter tersebut, lihat [Koneksi maksimum untuk Aurora serverless](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 dengan Konsol Manajemen AWS.
Saat Anda menggunakan konsol, Anda mengatur rentang kapasitas untuk klaster saat Anda menambahkan instans DB Aurora serverless 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 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 instance DB Aurora serverless penulis](aurora-serverless-v2.create.md#aurora-serverless-v2-adding-writer), [Menambahkan pembaca Aurora serverless](#aurora-serverless-v2-adding-reader), dan [Mengonversi penulis atau pembaca terprovisi menjadi Aurora serverless](#aurora-serverless-v2-converting-from-provisioned).
Rentang kapasitas apa pun yang Anda tetapkan di tingkat klaster berlaku untuk semua instans DB Aurora serverless di klaster Anda. Gambar berikut menunjukkan klaster dengan beberapa instans DB pembaca Aurora serverless. Masing-masing memiliki rentang kapasitas yang identik, yaitu 2–64 ACU.
**Untuk memodifikasi rentang kapasitas klaster Aurora serverless**
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 Anda dari daftar. Klaster ini harus sudah berisi setidaknya satu instans DB Aurora serverless. 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 **ACU Minimum**. Konsol menampilkan rentang nilai yang diizinkan. Anda dapat memilih kapasitas minimum dari 0 hingga 256 ACU. Anda dapat memilih kapasitas maksimum dari 1 hingga 256 ACU. 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 **ACU Maksimum**. Nilai ini harus lebih besar atau sama dengan **ACU Minimum**. Konsol menampilkan rentang nilai yang diizinkan. Gambar berikut menunjukkan pilihan tersebut.
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 DB menggunakan AWS CLI, jalankan perintah [AWS CLI modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Tentukan opsi `--serverless-v2-scaling-configuration`. Klaster ini mungkin sudah berisi satu atau beberapa instans DB Aurora serverless, 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 instans DB Aurora serverless ke klaster dan setiap instans DB baru dapat diskalakan antara 48,5 dan 64 ACU. Rentang kapasitas baru juga berlaku untuk semua instans DB Aurora serverless 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 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 perintah [AWS CLI modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). 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`, dan sebagainya`2`, dengan penambahan 0,5 ACU hingga maksimum. `256`
+ Aurora PostgreSQL:`0`,,,,, `0.5``1`, dan sebagainya `1.5``2`, dengan penambahan 0,5 ACU hingga maksimum. `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 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 DB Aurora dengan operasi API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). 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 mengubah konfigurasi penskalaan klaster yang berisi instans DB Aurora serverless dengan operasi API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). 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`, dan sebagainya`2`, dengan penambahan 0,5 ACU hingga maksimum. `256`
+ Aurora PostgreSQL:`0`,,,,, `0.5``1`, dan sebagainya `1.5``2`, dengan penambahan 0,5 ACU 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.
Perubahan kapasitas terjadi segera, terlepas dari apakah Anda memilih untuk menerapkannya segera atau selama periode pemeliharaan terjadwal berikutnya.
### Memutakhirkan cluster Aurora serverless DB Anda untuk memungkinkan penskalaan ke 256 ACU
Dalam beberapa kasus, ketika Anda mencoba menskalakan cluster Aurora serverless DB Anda ke kapasitas yang lebih besar dari 128 ACU, 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 menskalakan lebih besar dari 128 ACU dapat terjadi karena salah satu dari dua alasan:
+ Versi mesin DB yang lebih lama - Tingkatkan versi mesin DB ke versi yang mendukung 256 ACU. Untuk informasi selengkapnya, lihat [Kapasitas Aurora serverless](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 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 ACU.
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.
**Penting:** Setelah Anda meningkatkan ke versi platform yang lebih baru, Anda tidak dapat menurunkan versi ke versi sebelumnya.
## Memeriksa rentang kapasitas untuk Aurora serverless
Prosedur untuk memeriksa rentang kapasitas untuk klaster Aurora serverless Anda mengharuskan Anda menetapkan rentang kapasitas terlebih dahulu. Jika Anda belum melakukannya, ikuti prosedur dalam [Mengatur rentang kapasitas Aurora serverless 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 di klaster Anda. Gambar berikut menunjukkan klaster dengan beberapa instans DB Aurora serverless. Masing-masing memiliki rentang kapasitas yang identik.
Anda juga dapat melihat halaman detail untuk instans DB Aurora serverless apa pun di klaster. Rentang kapasitas instans DB muncul di tab **Konfigurasi**.
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 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 di klaster dengan memeriksa atribut `ServerlessV2ScalingConfiguration` untuk klaster. Contoh AWS CLI berikut menunjukkan klaster dengan kapasitas minimum 0,5 unit kapasitas Aurora (ACU) dan kapasitas maksimum 16 ACU.
```
$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-64-acu-cluster \
--query 'DBClusters[*].[ServerlessV2ScalingConfiguration]'
[
[
{
"MinCapacity": 0.5,
"MaxCapacity": 16.0
}
]
]
```
## Memeriksa versi platform untuk Aurora serverless cluster yang ada
### Konsol
Versi platform ditampilkan di bagian Konfigurasi Instans instance.
### AWS CLI
Anda dapat menggunakan `describe-db-clusters` perintah untuk memeriksa versi platform untuk klaster yang ada.
**Example**
```
1. aws rds describe-db-clusters \
2. --db-cluster-identifier {{mydbcluster}}
```
### Memeriksa versi platform default
#### AWS CLI
Anda dapat menggunakan `describe-serverless-v2-platform-versions` perintah untuk memeriksa detail versi platform atau untuk memeriksa versi platform default yang akan Anda dapatkan ketika Anda membuat cluster baru.
**Example**
```
1. $ aws rds describe-serverless-v2-platform-versions
2. {
3. "ServerlessV2PlatformVersions": [
4. {
5. "Engine": "aurora-postgresql",
6. "ServerlessV2PlatformVersion": "3",
7. "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2"
8. "ServerlessV2FeatureSupport": {
9. "MinCapacity": 0
10. "MaxCapacity": 256
11. },
12. "Status": "available",
13. "IsDefault": True
14. },
15. ...
16. ]
17. }
18.
19. # describing the default platform version for an engine
20. $ aws rds describe-serverless-v2-platform-versions --engine aurora-postgresql --default-only
21. {
22. "ServerlessV2PlatformVersions": [
23. {
24. "Engine": "aurora-postgresql",
25. "ServerlessV2PlatformVersion": "3",
26. "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2"
27. "ServerlessV2FeatureSupport": {
28. "MinCapacity": 0
29. "MaxCapacity": 256
30. },
31. "Status": "available",
32. "IsDefault": True
33. }
34. ]
35. }
```
### Memeriksa peningkatan versi platform yang tertunda
Anda dapat menggunakan `describe-pending-maintenance-actions` perintah untuk memeriksa apakah ada upgrade versi platform yang tertunda untuk cluster Aurora serverless DB Anda.
Untuk memeriksa upgrade yang tertunda pada klaster tertentu, gunakan `--resource-identifier` parameter untuk menentukan Amazon Resource Name (ARN) cluster DB Anda:
**Example**
```
1. aws rds describe-pending-maintenance-actions \
2. --resource-identifier arn:aws:rds:{{us-east-1}}:{{123456789012}}
3. :cluster:{{my-serverless-cluster}}
```
#### Menjadwalkan peningkatan versi platform
Setelah Anda mengidentifikasi peningkatan versi platform yang tertunda, Anda dapat menggunakan `apply-pending-maintenance-action` perintah untuk menjadwalkan kapan pemutakhiran terjadi.
Untuk menjadwalkan upgrade versi platform, tentukan parameter berikut:
+ `--resource-identifier`— ARN dari cluster DB Anda Aurora serverless
+ `--apply-action`— Gunakan `serverless-platform-version-update` untuk menentukan upgrade versi platform
+ `--opt-in-type`— Pilih kapan harus menerapkan peningkatan:
+ `immediate`— Terapkan upgrade segera
+ `next-maintenance`— Terapkan upgrade selama jadwal Anda berikutnya
## Menambahkan pembaca Aurora serverless
Untuk menambahkan instans DB pembaca Aurora serverless 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 pertama di klaster, Anda juga perlu memilih rentang kapasitas. Pengaturan ini berlaku untuk instans DB pembaca ini dan instans DB Aurora serverless lainnya yang ditambahkan ke klaster. Setiap instans DB Aurora serverless dapat diskalakan antara nilai ACU minimum dan maksimum.
Jika ada Aurora serverless 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.
Jika Anda sudah menambahkan instans DB Aurora serverless apa pun ke klaster, rentang kapasitas saat ini akan ditampilkan saat menambahkan instans DB pembaca Aurora serverless lain. Gambar berikut menunjukkan kontrol hanya baca tersebut.
Jika Anda ingin mengubah rentang kapasitas klaster, ikuti prosedur dalam [Mengatur rentang kapasitas Aurora serverless 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 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](#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](#aurora-serverless-v2-checking-capacity).
## Mengonversi penulis atau pembaca terprovisi menjadi Aurora serverless
Anda dapat mengonversi instans DB terprovisi untuk menggunakan Aurora serverless. 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](aurora-serverless-v2.requirements.md). Misalnya, instans DB Aurora serverless mengharuskan klaster menjalankan versi mesin minimum tertentu.
Misalkan Anda mengonversi klaster terprovisi yang sedang berjalan untuk memanfaatkan Aurora serverless. Dalam hal ini, Anda dapat meminimalkan waktu henti dengan mengonversi instans DB menjadi Aurora serverless sebagai langkah pertama dalam proses switchover. Untuk prosedur lengkapnya, lihat [Mengonversi penulis atau pembaca terprovisi menjadi Aurora serverless](#aurora-serverless-v2-converting-from-provisioned).
Jika instans DB yang Anda konversi adalah instans DB Aurora serverless 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 yang ditambahkan ke klaster. Gambar berikut menunjukkan halaman tempat Anda menentukan unit kapasitas Aurora (ACU) minimum dan maksimum.
Untuk detail tentang pentingnya rentang kapasitas, lihat [Kapasitas Aurora serverless](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, Anda akan melihat rentang kapasitas yang ada selama operasi **Ubah**. Gambar berikut menunjukkan contoh panel informasi tersebut.
Jika Anda ingin mengubah rentang kapasitas untuk klaster setelah Anda menambahkan instans DB Aurora serverless lainnya, ikuti prosedurnya dalam [Mengatur rentang kapasitas Aurora serverless untuk sebuah klaster](#aurora-serverless-v2-setting-acus).
## Mengonversi penulis atau pembaca Aurora serverless menjadi terprovisi
Anda dapat mengonversi instans DB Aurora serverless 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 DB Aurora serverless menjadi terprovisi jika memerlukan kapasitas yang lebih besar daripada yang tersedia dengan unit kapasitas Aurora (ACU) maksimum dari instans DB Aurora serverless. 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 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. Untuk melihat kelas instans DB mana yang dapat Anda gunakan saat mengonversi instans DB Aurora serverless 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 menjadi terprovisi, Anda dapat mengikuti prosedur dalam [Mengonversi penulis atau pembaca terprovisi menjadi Aurora serverless](#aurora-serverless-v2-converting-from-provisioned), tetapi secara terbalik. Alihkan salah satu instans DB pembaca di klaster dari Aurora serverless 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 dihapus dari klaster. Jika Anda ingin mengubah rentang kapasitas, Anda dapat memodifikasi klaster, seperti yang dijelaskan dalam [Mengatur rentang kapasitas Aurora serverless untuk sebuah klaster](#aurora-serverless-v2-setting-acus).
## Menjeda instans Aurora serverless DB
Anda dapat mengonfigurasi cluster Aurora untuk secara otomatis menjeda dan melanjutkan instans DB mereka. Aurora serverless Untuk informasi selengkapnya, lihat [Penskalaan ke Zero ACU dengan jeda otomatis dan lanjutkan Aurora serverless](aurora-serverless-v2-auto-pause.md).
## Memilih tingkat promosi untuk pembaca Aurora serverless
Untuk klaster yang berisi beberapa instans DB Aurora serverless atau gabungan instans terprovisi dan instans DB Aurora serverless, perhatikan pengaturan tingkat promosi untuk setiap instans DB Aurora serverless. Pengaturan ini mengontrol lebih banyak perilaku untuk instans DB Aurora serverless 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, 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 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 yang setara. Aurora menggunakan perkiraan tersebut sebagai kapasitas minimum untuk instans DB pembaca Aurora serverless.
Instans DB pembaca Aurora serverless 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](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.scaling).
## Menggunakan TLS/SSL dengan Aurora serverless
Aurora serverlessdapat menggunakan protokol Transport Layer Security/Secure Sockets Layer (TLS/SSL) untuk mengenkripsi komunikasi antara klien dan instans Aurora serverless DB Anda. 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 serverlessmendukung 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 |
| --- | --- | --- |
| Connect tanpa menggunakan TLS/SSL. | DISABLED | disable |
| Coba koneksi menggunakan TLS/SSL terlebih dahulu, tetapi kembali ke non-SSL jika perlu. | PREFERRED | prefer (default) |
| Menegakkan menggunakan TLS/SSL. | REQUIRED | require |
| Menegakkan TLS/SSL dan memverifikasi otoritas sertifikat (CA). | VERIFY\_CA | verify-ca |
| Menegakkan TLS/SSL, memverifikasi CA, dan memverifikasi nama host CA. | VERIFY\_IDENTITY | verify-full |
Aurora serverless menggunakan sertifikat wildcard. Jika Anda menentukan opsi “verifikasi CA” atau “verifikasi nama host CA dan CA” saat menggunakan TLS/SSL, unduh dulu [toko kepercayaan CA 1 root Amazon dari Amazon Trust](https://www.amazontrust.com/repository/AmazonRootCA1.pem) Services. Setelah melakukannya, Anda dapat mengidentifikasi PEM-formatted file 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
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 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 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
Anda dapat melihat detail instans DB Aurora serverless 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, seluruh instans DB terprovisi, atau beberapa dari masing-masing.
Setelah membuat satu atau beberapa instans DB Aurora serverless, Anda dapat melihat instans DB mana yang memiliki jenis **Nirserver** dan mana yang memiliki jenis **Instans**. Anda juga dapat melihat unit kapasitas Aurora (ACU) minimum dan maksimum yang dapat digunakan instans DB Aurora serverless. Setiap ACU merupakan kombinasi dari kapasitas pemrosesan (CPU) dan memori (RAM). Rentang kapasitas ini berlaku untuk setiap instans DB Aurora serverless di klaster. Untuk prosedur untuk memeriksa rentang kapasitas klaster atau instans DB Aurora serverless apa pun di klaster, lihat [Memeriksa rentang kapasitas untuk Aurora serverless](#aurora-serverless-v2-checking-capacity).
Dalam Konsol Manajemen AWS, instans Aurora serverless 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 **Nirserver v2 (4–64 ACU)** atau **Nirserver v2 (1–40 ACU)**.
Anda dapat menemukan informasi yang sama pada tab **Konfigurasi** untuk setiap instans DB Aurora serverless di konsol. Misalnya, Anda mungkin melihat bagian **Tipe instans** seperti berikut ini. Di sini, nilai **Tipe instans** adalah **Nirserver v2**, nilai **Kapasitas minimum** adalah **2 ACU (4 GiB)**, dan nilai **Kapasitas maksimum** adalah **64 ACU (128 GiB)**.
Anda dapat memantau kapasitas setiap instans DB Aurora serverless dari waktu ke waktu. Dengan begitu, Anda dapat memeriksa ACU minimum, maksimum, dan rata-rata yang 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](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).
## Pencatatan log untuk Aurora serverless
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 DB Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
Untuk Aurora PostgreSQL, Anda dapat mengaktifkan log berikut pada instans DB Aurora serverless 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 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 jeda dan melanjutkan aktivitas](#autopause-logging-instance-log)
### Logging dengan Amazon CloudWatch
Setelah Anda menggunakan prosedur [Pencatatan log untuk Aurora serverless](#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 diaktifkan dan secara otomatis diunggah ke CloudWatch. Anda juga dapat mengunggah log lain dari instans Aurora serverless 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 log mana yang akan diunggah CloudWatch. Untuk informasi selengkapnya, lihat [Menggunakan Audit Lanjutan dengan klaster DB Amazon Aurora MySQL](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 Anda, agar tersedia untuk dipilih saat membuat basis data pada konsol.
**catatan**
Untuk Aurora serverless, Anda dapat membuat klaster DB dan grup parameter DB.
### Melihat Aurora serverless 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 Anda**
1. Buka CloudWatch konsol di [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Pilih Anda AWS Region.
1. Pilih **Grup log**.
1. Pilih log klaster DB Aurora serverless Anda dari daftar. Pola penamaan log adalah sebagai berikut.
```
/aws/rds/cluster/{{cluster-name}}/{{log_type}}
```
**catatan**
Untuk klaster DB Aurora serverless yang kompatibel dengan Aurora MySQL, log kesalahan menyertakan peristiwa penskalaan pool buffer meskipun tidak ada kesalahan.
### Kapasitas pemantauan dengan Amazon CloudWatch
DenganAurora serverless, Anda dapat menggunakannya CloudWatch untuk memantau kapasitas dan pemanfaatan semua instans Aurora serverless DB di cluster Anda. Anda dapat melihat metrik tingkat instans untuk memeriksa kapasitas setiap instans DB Aurora serverless 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, lihat [CloudWatch Metrik Amazon penting untuk Aurora serverless](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).
**Untuk memantau kapasitas klaster DB Aurora serverless 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: `ServerlessDatabaseCapacity`, `ACUUtilization`, `CPUUtilization`, dan `FreeableMemory`.
Kami menyarankan Anda menyiapkan CloudWatch dasbor untuk memantau kapasitas cluster Aurora serverless 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 jeda dan melanjutkan aktivitas
Aurora menulis file log terpisah untuk instans Aurora serverless 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 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 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 instance yang dijeda otomatis Aurora serverless](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 instance 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 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 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 ACU, itu tidak menghentikan sementara instance. Ini diharapkan menjadi kejadian yang sangat langka.