Aurora Serverless v1 arsitektur Penskalaan otomatis Tindakan batas waktu habis Jeda dan lanjutkan Menentukan max_connections Grup parameter Pencatatan log Maintenance Failover Snapshot

Cara kerja Aurora Serverless v1

penting

AWS telah mengumumkan end-of-life tanggal untukAurora Serverless v1: 31 Maret 2025. Semua Aurora Serverless v1 cluster yang tidak dimigrasikan pada 31 Maret 2025 akan dimigrasikan ke Aurora Serverless v2 selama jendela pemeliharaan. Jika pemutakhiran gagal, Amazon Aurora mengonversi kluster v1 Tanpa Server menjadi klaster yang disediakan dengan versi engine yang setara selama jendela pemeliharaan. Jika berlaku, Amazon Aurora akan mendaftarkan klaster yang telah dikonversi di Amazon RDS Extended Support. Untuk informasi selengkapnya, lihat Amazon RDS Extended Support dengan .

Setelahnya, Anda dapat mempelajari cara kerja Aurora Serverless v1.

Topik

Arsitektur Aurora Serverless v1
Penskalaan otomatis untuk Aurora Serverless v1
Tindakan batas waktu habis untuk perubahan kapasitas
Jeda dan lanjutkan untuk Aurora Serverless v1
Mengatur jumlah maksimum koneksi basis data untuk Aurora Serverless v1
Grup parameter untuk Aurora Serverless v1
Pencatatan log untuk Aurora Serverless v1
Aurora Serverless v1 dan pemeliharaan
Aurora Serverless v1 dan failover
Aurora Serverless v1 dan snapshot

Arsitektur Aurora Serverless v1

Gambar berikut menunjukkan gambaran umum arsitektur Aurora Serverless v1.

Alih-alih menyediakan dan mengelola server database, Anda menentukan unit kapasitas Aurora (). ACUs Setiap ACU adalah kombinasi dari sekitar 2 gigabyte (GB) memori, CPU yang sesuai, dan jaringan. Penyimpanan basis data secara otomatis menskalakan dari 10 gibibyte (GiB) hingga 128 tebibyte (TiB), sama seperti penyimpanan dalam klaster DB Aurora standar.

Anda dapat menentukan ACU minimum dan maksimum. Unit kapasitas Aurora minimum adalah ACU terendah yang dapat dicapai saat menurunkan skala klaster DB. Unit kapasitas Aurora maksimum adalah ACU tertinggi yang dapat dicapai saat menaikkan skala klaster DB. Berdasarkan pengaturan Anda, Aurora Serverless v1 secara otomatis membuat aturan penskalaan untuk ambang batas pemanfaatan CPU, koneksi, dan memori yang tersedia.

Aurora Serverless v1mengelola kumpulan sumber daya yang hangat Wilayah AWS untuk meminimalkan waktu penskalaan. Saat Aurora Serverless v1 menambahkan sumber daya baru ke klaster DB Aurora, layanan ini menggunakan armada router untuk mengalihkan koneksi klien aktif ke sumber daya baru. Pada waktu tertentu, Anda hanya dikenakan biaya untuk ACUs yang sedang digunakan secara aktif di cluster Aurora DB Anda.

Penskalaan otomatis untuk Aurora Serverless v1

Kapasitas yang dialokasikan ke klaster DB Aurora Serverless v1 akan dinaikkan dan diturunkan skalakan dengan lancar berdasarkan beban yang dihasilkan oleh aplikasi klien Anda. Di sini, beban adalah pemanfaatan CPU dan jumlah koneksi. Ketika kapasitas dibatasi oleh salah satu dari hal ini, Aurora Serverless v1 menaikkan skala. Aurora Serverless v1 juga menaikkan skala ketika mendeteksi masalah performa yang dapat diatasi dengan penaikan skala.

Anda dapat melihat peristiwa penskalaan untuk Aurora Serverless v1 klaster Anda di. Konsol Manajemen AWS Selama penskalaan otomatis, Aurora Serverless v1 mengatur ulang metrik EngineUptime. Nilai metrik pengaturan ulang ini tidak berarti bahwa penskalaan yang lancar mengalami masalah atau Aurora Serverless v1 memutus koneksi. Ini hanyalah titik awal untuk waktu aktif pada kapasitas baru. Untuk mempelajari selengkapnya tentang metrik, lihat Memantau metrik di klaster Amazon Aurora.

Ketika cluster Aurora Serverless v1 DB Anda tidak memiliki koneksi aktif, itu dapat menurunkan kapasitas nol (0 ACUs). Untuk mempelajari selengkapnya, lihat Jeda dan lanjutkan untuk Aurora Serverless v1.

Jika memang perlu melakukan operasi penskalaan, Aurora Serverless v1 pertama-tama mencoba mengidentifikasi titik penskalaan, waktu ketika tidak ada kueri yang sedang diproses. Aurora Serverless v1 mungkin tidak dapat menemukan titik penskalaan karena alasan berikut:

Kueri yang berjalan lama
Transaksi yang sedang berlangsung
Tabel atau kunci tabel sementara

Untuk meningkatkan tingkat keberhasilan klaster DB Aurora Serverless v1 dalam menemukan titik penskalaan, kami sarankan Anda menghindari kueri dan transaksi yang berjalan lama. Untuk mempelajari selengkapnya tentang operasi yang memblokir penskalaan dan cara menghindarinya, lihat Praktik terbaik untuk menggunakan Aurora Serverless v1.

Secara default, Aurora Serverless v1 mencoba menemukan titik penskalaan selama 5 menit (300 detik). Anda dapat menentukan periode waktu tunggu yang berbeda saat Anda membuat atau memodifikasi klaster. Periode batas waktu bisa antara 60 detik dan 10 menit (600 detik). Jika Aurora Serverless v1 tidak dapat menemukan titik penskalaan dalam periode yang ditentukan, batas waktu operasi penskalaan otomatis habis.

Secara default, jika penskalaan otomatis tidak dapat menemukan titik penskalaan sebelum batas waktu habis, Aurora Serverless v1 akan mempertahankan klaster pada kapasitas saat ini. Anda dapat mengubah perilaku default ini saat Anda membuat atau memodifikasi klaster DB Aurora Serverless v1 dengan memilih opsi Paksa perubahan kapasitas. Untuk informasi selengkapnya, lihat Tindakan batas waktu habis untuk perubahan kapasitas.

Tindakan batas waktu habis untuk perubahan kapasitas

Jika batas waktu penskalaan otomatis habis tanpa menemukan titik penskalaan, Aurora akan secara default mempertahankan kapasitas saat ini. Anda dapat memilih agar Aurora memaksa perubahan dengan memilih opsi Paksa perubahan kapasitas. Opsi ini tersedia di bagian Waktu habis dan tindakan Penskalaan Otomatis pada halaman Buat basis data saat Anda membuat klaster.

Secara default, opsi Paksa perubahan kapasitas tidak dipilih. Jangan pilih opsi ini agar kapasitas klaster DB Aurora Serverless v1 Anda tetap tidak berubah jika waktu operasi penskalaan habis tanpa menemukan titik penskalaan.

Memilih opsi ini akan menyebabkan klaster DB Aurora Serverless v1 Anda menerapkan perubahan kapasitas, bahkan tanpa titik penskalaan. Sebelum memilih opsi ini, ketahui konsekuensinya:

Setiap transaksi dalam proses akan terinterupsi, dan pesan kesalahan berikut akan muncul.

Aurora MySQL versi 2 — ERROR 1105 (HY000): Transaksi terakhir dibatalkan karena Penskalaan Seamless. Silakan coba lagi.

Anda dapat mengirim kembali transaksi segera setelah klaster DB Aurora Serverless v1 Anda tersedia.
Koneksi ke tabel dan kunci sementara terputus.

Kami menyarankan Anda memilih opsi Paksa perubahan kapasitas hanya jika aplikasi Anda dapat dipulihkan dari koneksi yang terputus atau transaksi yang tidak selesai.

Pilihan yang Anda buat Konsol Manajemen AWS saat Anda membuat cluster Aurora Serverless v1 DB disimpan di ScalingConfigurationInfo objek, di TimeoutAction properti SecondsBeforeTimeout dan. Nilai properti TimeoutAction diatur ke salah satu nilai berikut saat Anda membuat klaster:

RollbackCapacityChange – Nilai ini diatur saat Anda memilih opsi Kembalikan perubahan kapasitas. Ini adalah perilaku default.
ForceApplyCapacityChange – Nilai ini diatur saat Anda memilih opsi Paksa perubahan kapasitas.

Anda bisa mendapatkan nilai properti ini pada cluster Aurora Serverless v1 DB yang ada dengan menggunakan describe-db-clusters AWS CLI perintah, seperti yang ditunjukkan berikut.

Untuk Linux, macOS, atau Unix:


aws rds describe-db-clusters --region region \
  --db-cluster-identifier your-cluster-name \
  --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

Untuk Windows:


aws rds describe-db-clusters --region region ^
  --db-cluster-identifier your-cluster-name ^
  --query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"

Misalnya, berikut ini adalah kueri dan respons untuk klaster DB Aurora Serverless v1 bernama west-coast-sles di Wilayah AS Barat (California Utara).


$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles 
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

[
    {
        "ScalingConfigurationInfo": {
            "MinCapacity": 1,
            "MaxCapacity": 64,
            "AutoPause": false,
            "SecondsBeforeTimeout": 300,
            "SecondsUntilAutoPause": 300,
            "TimeoutAction": "RollbackCapacityChange"
        }
    }
]

Seperti ditunjukkan oleh responsnya, klaster DB Aurora Serverless v1 ini menggunakan pengaturan default.

Untuk informasi selengkapnya, lihat Membuat Aurora Serverless v1 klaster DB.. Setelah membuat Aurora Serverless v1, Anda juga dapat mengubah tindakan batas waktu habis dan pengaturan kapasitas lainnya kapan saja. Untuk mempelajari caranya, lihat Memodifikasi klaster DB Aurora Serverless v1.

Jeda dan lanjutkan untuk Aurora Serverless v1

Anda dapat memilih untuk menjeda klaster DB Aurora Serverless v1 setelah jumlah waktu tertentu tanpa aktivitas. Anda menentukan jumlah waktu tanpa aktivitas sebelum klaster DB dijeda. Saat Anda memilih opsi ini, waktu tanpa aktivitas default adalah lima menit, tetapi Anda dapat mengubah nilai ini. Ini adalah pengaturan opsional.

Ketika klaster DB dijeda, tidak ada aktivitas komputasi atau memori yang terjadi, dan Anda hanya dikenai biaya untuk penyimpanan. Jika koneksi basis data diminta saat klaster DB Aurora Serverless v1 dijeda, klaster DB secara otomatis beroperasi kembali dan melayani permintaan koneksi.

Saat klaster DB melanjutkan aktivitas, kapasitasnya sama dengan saat Aurora menjeda klaster tersebut. Jumlah ACUs tergantung pada seberapa banyak Aurora menskalakan cluster ke atas atau ke bawah sebelum menjedanya.

catatan

Jika klaster DB dijeda selama lebih dari tujuh hari, klaster DB ini mungkin akan dicadangkan dengan snapshot. Dalam kasus ini, Aurora memulihkan klaster DB dari snapshot ketika ada permintaan untuk terhubung ke klaster DB tersebut.

Mengatur jumlah maksimum koneksi basis data untuk Aurora Serverless v1

Contoh berikut ditujukan untuk klaster DB Aurora Serverless v1 yang kompatibel dengan MySQL 5.7. Anda dapat menggunakan klien MySQL atau editor kueri, jika aksesnya telah Anda konfigurasi. Untuk informasi selengkapnya, lihat Menjalankan kueri di editor kueri.

Untuk menemukan jumlah maksimum koneksi basis data

Temukan rentang kapasitas untuk klaster DB Aurora Serverless v1 Anda menggunakan AWS CLI.


aws rds describe-db-clusters \
    --db-cluster-identifier my-serverless-57-cluster \
    --query 'DBClusters[*].ScalingConfigurationInfo|[0]'

Hasilnya menunjukkan bahwa rentang kapasitasnya adalah 1-4 ACUs.


{
    "MinCapacity": 1,
    "AutoPause": true,
    "MaxCapacity": 4,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

Jalankan kueri SQL berikut untuk menemukan jumlah maksimum koneksi.
```
select @@max_connections;
```
Hasil yang ditampilkan ditujukan untuk kapasitas minimum klaster, 1 ACU.
```
@@max_connections
90
```
Skala cluster ke 8-32 ACUs.

Untuk informasi selengkapnya tentang penskalaan, lihat Memodifikasi klaster DB Aurora Serverless v1.

Konfirmasikan rentang kapasitas.


{
    "MinCapacity": 8,
    "AutoPause": true,
    "MaxCapacity": 32,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

Temukan jumlah maksimum koneksi.
```
select @@max_connections;
```
Hasil yang ditampilkan adalah untuk kapasitas minimum cluster, 8 ACUs.
```
@@max_connections
1000
```
Skala cluster semaksimal mungkin, 256-256 ACUs.

Konfirmasikan rentang kapasitas.


{
    "MinCapacity": 256,
    "AutoPause": true,
    "MaxCapacity": 256,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

Temukan jumlah maksimum koneksi.
```
select @@max_connections;
```
Hasil yang ditampilkan adalah untuk 256 ACUs.
```
@@max_connections
6000
```
catatan
max_connectionsNilai tidak berskala linier dengan jumlah. ACUs

Skala cluster kembali ke 1-4 ACUs.


{
    "MinCapacity": 1,
    "AutoPause": true,
    "MaxCapacity": 4,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

Kali ini, max_connections nilainya untuk 4 ACUs.


@@max_connections
270

Biarkan skala cluster turun menjadi 2 ACUs.
```
@@max_connections
180
```
Jika Anda telah mengonfigurasi klaster untuk berhenti sejenak setelah waktu idle tertentu, klaster akan turun menjadi 0. ACUs Namun, max_connections tidak akan turun di bawah nilai untuk 1 ACU.
```
@@max_connections
90
```

Grup parameter untuk Aurora Serverless v1

Saat Anda membuat klaster DB Aurora Serverless v1, Anda memilih mesin Aurora DB tertentu dan grup parameter klaster DB terkait. Tidak seperti cluster Aurora DB yang disediakan, cluster Aurora Serverless v1 DB memiliki instans read/write DB tunggal yang dikonfigurasi dengan grup parameter cluster DB saja—tidak memiliki grup parameter DB terpisah. Selama penskalaan otomatis, Aurora Serverless v1 harus dapat mengubah parameter agar klaster beroperasi dengan paling efektif untuk peningkatan atau penurunan kapasitas. Jadi, dengan klaster DB Aurora Serverless v1, beberapa perubahan yang dapat Anda terapkan pada parameter untuk jenis mesin DB tertentu mungkin tidak berlaku.

Misalnya, klaster DB Aurora Serverless v1 berbasis Aurora PostgreSQL tidak dapat menggunakan apg_plan_mgmt.capture_plan_baselines dan parameter lain yang mungkin digunakan pada \klaster DB Aurora PostgreSQL terprovisi untuk manajemen rencana kueri.

Anda bisa mendapatkan daftar nilai default untuk grup parameter default untuk berbagai mesin Aurora DB dengan menggunakan perintah describe-engine-default-cluster-parameter CLI dan menanyakan. Wilayah AWS Berikut ini adalah nilai yang dapat Anda gunakan untuk opsi --db-parameter-group-family.

Aurora MySQL versi 2	`aurora-mysql5.7`
Aurora PostgreSQL versi 11	`aurora-postgresql11`
Aurora PostgreSQL versi 13	`aurora-postgresql13`

Kami menyarankan Anda mengonfigurasi AWS CLI dengan ID kunci AWS akses dan kunci akses AWS rahasia, dan Anda mengatur Wilayah AWS sebelum menggunakan AWS CLI perintah. Dengan menyediakan Wilayah untuk konfigurasi CLI, Anda tidak perlu memasukkan parameter --region saat menjalankan perintah. Untuk mempelajari lebih lanjut tentang mengonfigurasi AWS CLI, lihat Dasar-dasar konfigurasi di Panduan AWS Command Line Interface Pengguna.

Contoh berikut mendapatkan daftar parameter dari grup klaster DB default untuk Aurora MySQL versi 2.

Untuk Linux, macOS, atau Unix:


aws rds describe-engine-default-cluster-parameters \
  --db-parameter-group-family aurora-mysql5.7 --query \
  'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \
  --output text

Untuk Windows:


aws rds describe-engine-default-cluster-parameters ^
   --db-parameter-group-family aurora-mysql5.7 --query ^
   "EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^
   --output text

Memodifikasi nilai parameter untuk Aurora Serverless v1

Seperti yang dijelaskan dalam , Anda tidak dapat langsung mengubah nilai dalam grup parameter default, terlepas dari jenisnya (grup parameter klaster DB, grup parameter DB). Sebagai gantinya, Anda membuat grup parameter kustom berdasarkan grup parameter klaster DB default untuk mesin Aurora DB Anda dan mengubah pengaturan yang diperlukan pada grup parameter tersebut. Misalnya, Anda mungkin ingin mengubah beberapa pengaturan untuk cluster Aurora Serverless v1 DB Anda untuk mencatat kueri atau mengunggah log khusus mesin DB ke Amazon CloudWatch.

Untuk membuat grup parameter klaster DB kustom

Masuk ke Konsol Manajemen AWS dan kemudian buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.
Pilih Grup parameter.
Pilih Buat grup parameter untuk membuka panel detail Grup parameter.
Pilih grup klaster DB default yang sesuai untuk mesin DB yang ingin Anda gunakan untuk klaster DB Aurora Serverless v1. Pastikan Anda memilih opsi berikut:
1. Untuk Rangkaian grup parameter, pilih rangkaian grup parameter yang sesuai untuk mesin DB pilihan Anda. Pastikan bahwa pilihan Anda memiliki awalan aurora- dalam namanya.
2. Untuk Jenis, pilih Grup Parameter Klaster DB.
3. Untuk Nama grup dan Deskripsi, masukkan nama yang bermakna untuk Anda atau orang lain yang mungkin perlu menangani klaster DB Aurora Serverless v1 Anda dan parameternya.
4. Pilih Buat.

Grup parameter klaster DB kustom Anda ditambahkan ke daftar grup parameter yang tersedia di Wilayah AWS Anda. Anda dapat menggunakan grup parameter klaster DB kustom Anda saat membuat klaster DB Aurora Serverless v1 baru. Anda juga dapat memodifikasi klaster DB Aurora Serverless v1 yang ada untuk menggunakan grup parameter klaster DB kustom Anda. Setelah cluster Aurora Serverless v1 DB Anda mulai menggunakan grup parameter cluster DB kustom Anda, Anda dapat mengubah nilai untuk parameter dinamis menggunakan salah satu Konsol Manajemen AWS atau AWS CLI.

Anda juga dapat menggunakan konsol untuk melihat side-by-side perbandingan nilai dalam grup parameter cluster DB kustom Anda dibandingkan dengan grup parameter cluster DB default, seperti yang ditunjukkan pada gambar berikut.

Log diterbitkan ke CloudWatch Log untuk Aurora MySQL dan Aurora PostgreSQL DB cluster Aurora Serverless v1

Jika Anda mengubah nilai parameter pada klaster DB aktif, Aurora Serverless v1 akan memulai penskalaan secara lancar untuk menerapkan perubahan parameter. Jika klaster DB Aurora Serverless v1 Anda dalam keadaan "dijeda", klaster DB ini akan dilanjutkan dan memulai penskalaan agar dapat menerapkan perubahan. Operasi penskalaan untuk perubahan grup parameter selalu memaksa perubahan kapasitas, jadi ketahui bahwa memodifikasi parameter dapat mengakibatkan koneksi terputus jika titik penskalaan tidak dapat ditemukan selama periode penskalaan.

Pencatatan log untuk Aurora Serverless v1

Secara default, log kesalahan untuk Aurora Serverless v1 diaktifkan dan diunggah secara otomatis ke Amazon CloudWatch. Anda juga dapat meminta cluster Aurora Serverless v1 DB Anda mengunggah log khusus mesin database Aurora. CloudWatch Untuk melakukannya, aktifkan parameter konfigurasi di grup parameter klaster DB kustom Anda. Cluster Aurora Serverless v1 DB Anda kemudian mengunggah semua log yang tersedia ke Amazon CloudWatch. Pada titik ini, Anda dapat menggunakan CloudWatch untuk menganalisis data log, membuat alarm, dan melihat metrik.

Untuk Aurora MySQL, tabel berikut menunjukkan log yang dapat Anda aktifkan. Saat diaktifkan, mereka secara otomatis diunggah dari cluster Aurora Serverless v1 DB Anda ke Amazon CloudWatch.

Log Aurora MySQL	Deskripsi
`general_log`	Membuat log umum. Atur ke 1 untuk mengaktifkan. Default-nya adalah nonaktif (0).
`log_queries_not_using_indexes`	Mencatat setiap kueri ke log kueri lambat yang tidak menggunakan indeks. Default-nya adalah nonaktif (0). Atur ke 1 untuk mengaktifkan log ini.
`long_query_time`	Mencegah kueri yang berjalan cepat agar tidak dicatat dalam log kueri lambat. Dapat diatur ke angka float antara 0 dan 31536000. Default-nya adalah 0 (tidak aktif).
`server_audit_events`	Daftar peristiwa untuk dicatat dalam log. Nilai yang didukung adalah `CONNECT`, `QUERY`, `QUERY_DCL`, `QUERY_DDL`, `QUERY_DML`, dan `TABLE`.
`server_audit_logging`	Atur ke 1 untuk mengaktifkan pencatatan log audit server. Jika Anda mengaktifkan ini, Anda dapat menentukan peristiwa audit yang akan dikirim CloudWatch dengan mencantumkannya di `server_audit_events` parameter.
`slow_query_log`	Membuat log kueri lambat. Atur ke 1 untuk mengaktifkan log kueri lambat. Default-nya adalah nonaktif (0).

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

Untuk Aurora PostgreSQL, tabel berikut menunjukkan log yang dapat Anda aktifkan. Saat diaktifkan, mereka secara otomatis diunggah dari cluster Aurora Serverless v1 DB Anda ke Amazon CloudWatch bersama dengan log kesalahan biasa.

Log Aurora PostgreSQL	Deskripsi
`log_connections`	Diaktifkan secara default dan tidak dapat diubah. Log ini mencatat log detail untuk semua koneksi klien baru.
`log_disconnections`	Diaktifkan secara default dan tidak dapat diubah. Mencatat log semua pemutusan koneksi klien.
`log_hostname`	Dimatikan secara default dan tidak dapat diubah. Nama host tidak dicatat.
`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`.

Setelah Anda mengaktifkan log untuk Aurora MySQL atau Aurora PostgreSQL untuk cluster DB Anda, Anda dapat melihat log masuk. Aurora Serverless v1 CloudWatch

Melihat Aurora Serverless v1 log dengan Amazon CloudWatch

Aurora Serverless v1secara otomatis mengunggah (“menerbitkan”) ke Amazon CloudWatch semua log yang diaktifkan di grup parameter cluster DB kustom Anda. Anda tidak perlu memilih atau menentukan jenis log. Mengunggah log dimulai segera setelah Anda mengaktifkan parameter konfigurasi log. Jika Anda menonaktifkan parameter log nanti, pengunggahan lainnya akan berhenti. Namun, semua log yang telah diterbitkan CloudWatch tetap ada sampai Anda menghapusnya.

Untuk informasi lebih lanjut tentang penggunaan CloudWatch dengan log Aurora MySQL, lihat. Memantau peristiwa log di Amazon CloudWatch

Untuk informasi lebih lanjut tentang CloudWatch dan Aurora PostgreSQL, lihat. Menerbitkan log Aurora PostgreSQL ke Amazon Logs CloudWatch

Untuk melihat log untuk klaster DB Aurora Serverless v1 Anda

Buka CloudWatch konsol di https://console.aws.amazon.com/cloudwatch/.
Pilih Anda Wilayah AWS.
Pilih Grup log.
Pilih log klaster DB Aurora Serverless v1 Anda dari daftar. Untuk log kesalahan, pola penamaannya adalah sebagai berikut.
```
/aws/rds/cluster/cluster-name/error
```

Misalnya, pada tangkapan layar berikut Anda dapat menemukan daftar untuk log yang diterbitkan untuk klaster DB Aurora Serverless v1 Aurora PostgreSQL bernama western-sles. Anda juga dapat menemukan beberapa entri untuk klaster DB Aurora Serverless v1 Aurora MySQL, west-coast-sles. Pilih log yang Anda minati untuk mulai mengkaji kontennya.

Aurora Serverless v1 dan pemeliharaan

Pemeliharaan untuk cluster Aurora Serverless v1 DB, seperti menerapkan fitur terbaru, perbaikan, dan pembaruan keamanan, dilakukan secara otomatis untuk Anda. Aurora Serverless v1memiliki jendela pemeliharaan yang dapat Anda lihat Konsol Manajemen AWS di Pemeliharaan & cadangan untuk cluster Aurora Serverless v1 DB Anda. Anda dapat menemukan tanggal dan waktu pemeliharaan yang mungkin dilakukan dan jika ada pemeliharaan yang tertunda untuk cluster Aurora Serverless v1 DB Anda, seperti yang ditunjukkan pada gambar berikut.

Jadwal pemeliharaan untuk contoh klaster DB Aurora Serverless v1, tanpa pemeliharaan yang tertunda

Anda dapat mengatur periode pemeliharaan ketika Anda membuat klaster DB Aurora Serverless v1, dan Anda dapat memodifikasi periode ini nanti. Untuk informasi selengkapnya, lihat Menyesuaikan periode pemeliharaan klaster DB yang dinginkan.

Jendela pemeliharaan digunakan untuk peningkatan versi mayor terjadwal. Upgrade versi minor dan patch diterapkan segera selama penskalaan. Penskalaan terjadi sesuai dengan pengaturan Anda untukTimeoutAction:

ForceApplyCapacityChangePerubahan diterapkan segera.
RollbackCapacityChange— Aurora secara paksa memperbarui cluster setelah 3 hari dari upaya patch pertama.

Seperti halnya perubahan apa pun yang dipaksakan tanpa titik penskalaan yang tepat, hal ini dapat mengganggu beban kerja Anda.

Jika memungkinkan, Aurora Serverless v1 melakukan pemeliharaan dengan cara yang tidak mengganggu. Jika pemeliharaan diperlukan, klaster DB Aurora Serverless v1 Anda menskalakan kapasitasnya untuk menangani operasi yang diperlukan. Sebelum menskalakan, Aurora Serverless v1 mencari titik penskalaan. Itu dilakukan hingga tiga hari jika perlu.

Pada akhirnya jika Aurora Serverless v1 tidak dapat menemukan titik penskalaan, layanan tersebut akan membuat peristiwa klaster. Peristiwa ini memberi tahu Anda tentang pemeliharaan yang tertunda dan kebutuhan penskalaan untuk melakukan pemeliharaan. Notifikasi ini mencakup tanggal kapan Aurora Serverless v1 dapat memaksa klaster DB untuk diskalakan.

Untuk informasi selengkapnya, lihat Tindakan batas waktu habis untuk perubahan kapasitas.

Aurora Serverless v1 dan failover

Jika instans DB untuk klaster DB Aurora Serverless v1 menjadi tidak tersedia atau Zona Ketersediaan (AZ) tempat klaster DB ini berada mengalami kegagalan, Aurora akan membuat ulang instans DB di AZ yang berbeda. Namun, klaster Aurora Serverless v1 bukan klaster Multi-AZ. Hal ini karena klaster tersebut terdiri dari satu instans DB dalam satu AZ. Dengan demikian, mekanisme failover ini membutuhkan waktu lebih lama daripada untuk klaster Aurora dengan instans terprovisi atau instans Aurora Serverless v2. Waktu Aurora Serverless v1 failover tidak ditentukan karena tergantung pada permintaan dan ketersediaan kapasitas di tempat lain AZs dalam yang diberikan. Wilayah AWS

Karena Aurora memisahkan kapasitas komputasi dan penyimpanan, volume penyimpanan untuk cluster tersebar di beberapa. AZs Data Anda tetap tersedia meskipun pemadaman memengaruhi instans DB atau AZ terkait.

Aurora Serverless v1 dan snapshot

Volume klaster untuk klaster Aurora Serverless v1 selalu dienkripsi. Anda dapat memilih kunci enkripsi, tetapi tidak dapat menonaktifkan enkripsi. Untuk menyalin atau membagikan snapshot klaster Aurora Serverless v1, enkripsi snapshot menggunakan AWS KMS key Anda sendiri. Untuk informasi selengkapnya, lihat Penyalinan snapshot cluster DB. Untuk mempelajari selengkapnya tentang enkripsi dan Amazon Aurora, lihat Mengenkripsi klaster DB Amazon Aurora

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Menggunakan Aurora Serverless v1

Membuat Aurora Serverless v1 klaster DB