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.

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

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.

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:

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, lihatKapasitas Aurora Serverless v2.

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

Untuk informasi selengkapnya tentang memastikan bahwa cluster Aurora Serverless v2 DB Anda dapat menskalakan hingga 256 ACUs, lihatMemutakhirkan cluster Aurora Serverless v2 DB Anda untuk memungkinkan penskalaan ke 256 ACUs.

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:

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

Misalnya, berdasarkan pemantauan, Anda menentukan bahwa rentang ACU untuk klaster harus lebih tinggi, lebih rendah, lebih luas, atau lebih sempit. Anda dapat mengatur kapasitas cluster Aurora ke rentang tertentu ACUs dengan, API AWS Management Console AWS CLI, atau Amazon RDS. Rentang kapasitas ini berlaku untuk setiap 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. 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.

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:

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.

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.

Anda juga dapat melihat halaman detail untuk instans DB Aurora Serverless v2 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 v2 untuk sebuah klaster.

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. 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.

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.

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

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.

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

Mengonversi penulis atau pembaca 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. Klaster harus memenuhi persyaratan dalam Persyaratan dan batasan untuk Aurora Serverless v2. 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 yang disediakan ke Aurora Serverless v2.

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.

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

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.

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.

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. 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.

Jika Anda mengonversi instans DB penulis untuk klaster Anda dari Aurora Serverless v2 menjadi terprovisi, Anda dapat mengikuti prosedur dalam Beralih dari klaster yang disediakan ke Aurora Serverless v2, 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.

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.

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

Untuk instans DB terprovisi, pilihan tingkat 0–15 hanya menentukan urutan yang digunakan Aurora dalam memilih instans DB pembaca mana yang akan dipromosikan menjadi penulis selama operasi failover. Untuk 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.

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

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

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

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

Untuk Linux, macOS, atau Unix:

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

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

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

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.

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.

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. 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.

Dalam AWS Management Console, 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).

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 AWS Management Console, periksa grafik CloudWatch metrik Amazon pada tab Monitoring untuk instans DB. Untuk informasi tentang metrik yang perlu dilihat dan cara menafsirkannya, lihat CloudWatch Metrik Amazon penting untuk Aurora Serverless v2.

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.

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

Untuk Aurora PostgreSQL, Anda dapat mengaktifkan log berikut pada instans DB Aurora Serverless v2 Anda.

Logging dengan Amazon CloudWatch

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

Anda dapat menggunakan Amazon CloudWatch untuk menganalisis data log, membuat alarm, dan melihat metrik. Secara default, log kesalahan untuk Aurora Serverless v2 diaktifkan dan 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 AWS Management Console 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.

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.

Melihat Aurora Serverless v2 log di Amazon CloudWatch

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

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

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.

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.

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

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 namainstance.log, dan log lama diberi nama menggunakan polainstance.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 AWS Management Console atau dengan menggunakan AWS CLI atau RDSP API. Saat ini, Anda tidak dapat mengunggah log ini ke CloudWatch.

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

instance.logIni 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:

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: