Cara kerja Aurora Serverless v1

Setelahnya, Anda dapat mempelajari cara kerja Aurora Serverless v1.

Arsitektur Aurora Serverless v1

Gambar berikut menunjukkan gambaran umum arsitektur Aurora Serverless v1.

Alih-alih menyediakan dan mengelola server basis data, Anda menentukan unit kapasitas Aurora (ACU). 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 v1 mengelola kumpulan sumber daya aktif di 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 dikenai biaya untuk ACU yang secara aktif digunakan dalam klaster DB Aurora 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 klaster Aurora Serverless v1 Anda di AWS Management Console. 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.

Jika tidak memiliki koneksi aktif, klaster DB Aurora Serverless v1 Anda dapat menurunkan skalanya ke kapasitas nol (0 ACU). 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 Seamless Scaling. 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 di AWS Management Console saat membuat klaster DB Aurora Serverless v1 akan disimpan di objek ScalingConfigurationInfo, pada properti SecondsBeforeTimeout dan TimeoutAction. 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-clustersAWS CLIperintah, 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 klaster DB Aurora Serverless v1. 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 ACU akan bergantung pada seberapa banyak Aurora menaikkan atau menurunkan skala klaster 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

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

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

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

3. Skalakan klaster menjadi 8–32 ACU.

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

4. Konfirmasikan rentang kapasitas.

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

5. Temukan jumlah maksimum koneksi.

   select @@max_connections;

   Hasil yang ditampilkan ditujukan untuk kapasitas minimum klaster, 8 ACU.

   @@max_connections
   1000

6. Skalakan klaster ke nilai maksimum yang mungkin, 256–256 ACU.

7. Konfirmasikan rentang kapasitas.

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

8. Temukan jumlah maksimum koneksi.

   select @@max_connections;

   Hasil yang ditampilkan ditujukan untuk 256 ACU.

   @@max_connections
   6000

   catatan

   Nilaimax_connections tidak diskalakan secara linier dengan jumlah ACU.

9. Skalakan klaster kembali ke 1–4 ACU.

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

   Kali ini, nilai max_connections ditujukan untuk 4 ACU.

   @@max_connections
   270

10. Biarkan klaster diturunkan skalanya menjadi 2 ACU.

    @@max_connections
    180

    Jika Anda telah mengonfigurasi klaster untuk dijeda setelah jumlah waktu idle tertentu, klaster akan diturunkan skalanya menjadi 0 ACU. 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 klaster DB Aurora terprovisi, klaster DB Aurora Serverless v1 memiliki satu instans DB baca/tulis tunggal yang dikonfigurasi hanya dengan grup parameter klaster DB—instans tersebut 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 file. 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 akses AWS dan kunci akses rahasia AWS, serta mengatur Wilayah AWS sebelum menggunakan perintah AWS CLI. Dengan menyediakan Wilayah untuk konfigurasi CLI, Anda tidak perlu memasukkan parameter --region saat menjalankan perintah. Untuk mempelajari selengkapnya tentang mengonfigurasi AWS CLI, lihat Dasar-dasar konfigurasi dalam Panduan Pengguna AWS Command Line Interface.

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

1. Masuk ke AWS Management Console lalu buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

2. Pilih Grup parameter.

3. Pilih Buat grup parameter untuk membuka panel detail Grup parameter.

4. 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 klaster DB Aurora Serverless v1 Anda dimulai menggunakan grup parameter klaster DB kustom, Anda dapat mengubah nilai untuk parameter dinamis menggunakan AWS Management Console 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.

Jika Anda mengubah nilai parameter pada klaster DB aktif, Aurora Serverless v1 akan memulai penskalaan ke dalam yang konstans 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.

Logging 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 ke. 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 logging 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.

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

1. Buka CloudWatch konsol di https://console.aws.amazon.com/cloudwatch/.

2. Pilih Wilayah AWS Anda.

3. Pilih Grup log.

4. 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 klaster DB Aurora Serverless v1, seperti menerapkan fitur terbaru, perbaikan, dan pembaruan keamanan, dilakukan secara otomatis untuk Anda. Aurora Serverless v1 memiliki periode pemeliharaan yang dapat Anda lihat di AWS Management Console pada bagian Pemeliharaan & pencadangan untuk klaster DB Aurora Serverless v1 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.

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 upgrade versi mayor terjadwal. Upgrade versi minor dan patch diterapkan segera selama penskalaan. Penskalaan terjadi sesuai dengan pengaturan Anda untukTimeoutAction:

• ForceApplyCapacityChange— Perubahan 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 bergantung pada permintaan dan ketersediaan kapasitas di AZ lain dalam Wilayah AWS yang ditentukan.

Karena Aurora memisahkan kapasitas komputasi dan penyimpanan, volume penyimpanan untuk klaster tersebar di beberapa AZ. 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 Menyalin snapshot klaster DB. Untuk mempelajari selengkapnya tentang enkripsi dan Amazon Aurora, lihat Mengenkripsi klaster DB Amazon Aurora