Bagaimana Aurora Serverless v1 cara kerja

penting

AWS telah mengumumkan end-of-life tanggal untuk Aurora 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 .

Setelah itu, Anda dapat mempelajari caranya Aurora Serverless v1 bekerja.

Aurora Serverless v1 arsitektur

Gambar berikut menunjukkan ikhtisar dari Aurora Serverless v1 arsitektur.

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 ditingkatkan skala klaster DB-nya. Berdasarkan pengaturan Anda, Aurora Serverless v1 secara otomatis membuat aturan penskalaan untuk ambang penggunaan CPU, koneksi, dan memori yang tersedia.

Aurora Serverless v1 mengelola kumpulan sumber daya yang hangat Wilayah AWS untuk meminimalkan waktu penskalaan. Saat Aurora Serverless v1 menambahkan sumber daya baru ke klaster Aurora DB, menggunakan router fleet 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 Aurora Serverless v1 Cluster DB dengan mulus menskalakan naik dan turun berdasarkan beban yang dihasilkan oleh aplikasi klien Anda. Di sini, beban adalah pemanfaatan CPU dan jumlah koneksi. Ketika kapasitas dibatasi oleh salah satu dari ini, Aurora Serverless v1 skala. Aurora Serverless v1 juga meningkat ketika mendeteksi masalah kinerja yang dapat diselesaikan dengan melakukannya.

Anda dapat melihat acara penskalaan untuk Aurora Serverless v1 cluster di AWS Management Console. Selama penskalaan otomatis, Aurora Serverless v1 mereset metrik EngineUptime. Nilai nilai metrik reset tidak berarti bahwa penskalaan yang mulus memiliki masalah atau itu Aurora Serverless v1 koneksi terputus. Ini hanyalah titik awal untuk waktu aktif pada kapasitas baru. Untuk mempelajari selengkapnya tentang metrik, lihat Memantau metrik di klaster Amazon Aurora.

Saat Aurora Serverless v1 Cluster DB tidak memiliki koneksi aktif, dapat diturunkan ke kapasitas nol (0 ACUs). Untuk mempelajari selengkapnya, lihat Jeda dan lanjutkan untuk Aurora Serverless v1.

Ketika itu perlu melakukan operasi penskalaan, Aurora Serverless v1 pertama kali mencoba mengidentifikasi titik penskalaan, saat 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 Aurora Serverless v1 Tingkat keberhasilan klaster DB saat menemukan titik penskalaan, kami sarankan Anda menghindari kueri yang berjalan lama dan transaksi yang berjalan lama. Untuk mempelajari lebih lanjut tentang operasi yang memblokir penskalaan dan cara menghindarinya, lihat Praktik terbaik untuk bekerja dengan 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, waktu operasi penskalaan otomatis habis.

Secara default, jika penskalaan otomatis tidak menemukan titik penskalaan sebelum waktu habis, Aurora Serverless v1 menjaga cluster pada kapasitas saat ini. Anda dapat mengubah perilaku default ini saat membuat atau memodifikasi Aurora Serverless v1 Cluster DB 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. Jaga agar opsi ini jelas untuk memiliki Aurora Serverless v1 Kapasitas cluster DB tetap tidak berubah jika waktu operasi penskalaan habis tanpa menemukan titik penskalaan.

Memilih opsi ini menyebabkan Anda Aurora Serverless v1 Cluster DB untuk menegakkan 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 mengirimkan kembali transaksi segera setelah Anda Aurora Serverless v1 klaster DB 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 AWS Management Console saat Anda membuat Aurora Serverless v1 Cluster DB disimpan dalam ScalingConfigurationInfo objek, di SecondsBeforeTimeout dan TimeoutAction properti. 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 yang sudah ada Aurora Serverless v1 DB cluster 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}"

Sebagai contoh, berikut ini menunjukkan query dan respon untuk Aurora Serverless v1 Cluster DB dinamai west-coast-sles di Wilayah AS Barat (California N.).

$ 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 yang ditunjukkan oleh tanggapan, ini Aurora Serverless v1 Cluster DB menggunakan pengaturan default.

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

Jeda dan lanjutkan untuk Aurora Serverless v1

Anda dapat memilih untuk menjeda Aurora Serverless v1 klaster DB setelah jangka waktu tertentu tanpa aktivitas. Anda menentukan jumlah waktu tanpa aktivitas sebelum klaster DB dihentikan sementara. 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 komputasi atau aktivitas memori yang terjadi, dan Anda hanya dikenai biaya untuk penyimpanan. Jika koneksi basis data diminta saat Aurora Serverless v1 klaster DB dijeda, klaster DB secara otomatis melanjutkan dan melayani permintaan koneksi.

Saat klaster DB melanjutkan aktivitas, kapasitasnya sama dengan saat Aurora menjeda klaster. 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.

Menentukan jumlah maksimum koneksi database untuk Aurora Serverless v1

Contoh berikut adalah untuk Aurora Serverless v1 Cluster DB 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 Anda Aurora Serverless v1 Cluster DB menggunakan file 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
   }

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. Skala cluster ke 8-32 ACUs.

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

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 adalah untuk kapasitas minimum cluster, 8 ACUs.

   @@max_connections
   1000

6. Skala cluster semaksimal mungkin, 256-256 ACUs.

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 adalah untuk 256 ACUs.

   @@max_connections
   6000

   catatan

   max_connectionsNilai tidak menskalakan secara linier dengan jumlah. ACUs

9. Skala cluster kembali ke 1-4 ACUs.

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

   Kali ini, max_connections nilainya adalah untuk 4 ACUs.

   @@max_connections
   270

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

Kelompok parameter untuk Aurora Serverless v1

Saat Anda membuat Aurora Serverless v1 Cluster DB, Anda memilih mesin Aurora DB tertentu dan grup parameter cluster DB terkait. Tidak seperti cluster Aurora DB yang disediakan, sebuah Aurora Serverless v1 Cluster DB memiliki satu instance DB baca/tulis 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 cluster bekerja paling baik untuk peningkatan atau penurunan kapasitas. Dengan demikian, dengan Aurora Serverless v1 Cluster DB, beberapa perubahan yang mungkin Anda buat pada parameter untuk jenis mesin DB tertentu mungkin tidak berlaku.

Misalnya, berbasis Aurora PostgreSQL Aurora Serverless v1 Cluster DB tidak dapat digunakan apg_plan_mgmt.capture_plan_baselines dan parameter lain yang mungkin digunakan pada klaster Aurora PostgreSQL DB yang disediakan 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 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 Aurora Serverless v1 Cluster DB 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 dan kemudian 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 engine DB yang ingin Anda gunakan untuk berkas Aurora Serverless v1 klaster DB. 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 bekerja dengan Aurora Serverless v1 klaster DB 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 cluster DB kustom Anda saat Anda membuat yang baru Aurora Serverless v1 klaster DB. Anda juga dapat memodifikasi yang sudah ada Aurora Serverless v1 Cluster DB untuk menggunakan grup parameter cluster DB kustom Anda. Setelah Anda Aurora Serverless v1 Cluster DB mulai menggunakan grup parameter cluster DB kustom Anda, Anda dapat mengubah nilai untuk parameter dinamis menggunakan salah satu 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.

Saat Anda mengubah nilai parameter pada cluster DB aktif, Aurora Serverless v1 memulai skala mulus untuk menerapkan perubahan parameter. Jika Aurora Serverless v1 Cluster DB dalam keadaan jeda, ia melanjutkan dan mulai menskalakan sehingga dapat membuat 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 memiliki Aurora Serverless v1 Cluster DB mengunggah log khusus mesin database Aurora ke. CloudWatch Untuk melakukannya, aktifkan parameter konfigurasi di grup parameter klaster DB kustom Anda. Klaster Aurora Serverless v1 Cluster DB 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. Ketika diaktifkan, mereka secara otomatis diunggah dari Aurora Serverless v1 Cluster DB 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. Ketika diaktifkan, mereka secara otomatis diunggah dari Aurora Serverless v1 Cluster DB 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 Anda Aurora Serverless v1 Cluster DB, Anda dapat melihat log masuk CloudWatch.

Melihat Aurora Serverless v1 log dengan Amazon CloudWatch

Aurora Serverless v1 secara 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 Anda Aurora Serverless v1 Klaster DB

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

2. Pilih Anda Wilayah AWS.

3. Pilih Grup log.

4. Pilih Anda Aurora Serverless v1 Log cluster DB dari daftar. Untuk log kesalahan, pola penamaannya adalah sebagai berikut.

   /aws/rds/cluster/cluster-name/error

Misalnya, dalam tangkapan layar berikut Anda dapat menemukan daftar untuk log yang diterbitkan untuk PostgreSQL Aurora Aurora Serverless v1 Cluster DB bernamawestern-sles. Anda juga dapat menemukan beberapa daftar untuk Aurora MySQL Aurora Serverless v1 Kluster DB,west-coast-sles. Pilih log yang Anda minati untuk mulai mengkaji kontennya.

Aurora Serverless v1 dan pemeliharaan

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

Anda dapat mengatur jendela pemeliharaan saat Anda membuat Aurora Serverless v1 DB cluster, dan Anda dapat memodifikasi jendela 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.

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

Di akhir setiap hari itu yang Aurora Serverless v1 tidak dapat menemukan titik penskalaan, itu menciptakan peristiwa cluster. Peristiwa ini memberi tahu Anda tentang pemeliharaan yang tertunda dan kebutuhan penskalaan untuk melakukan pemeliharaan. Pemberitahuan termasuk tanggal kapan Aurora Serverless v1 dapat memaksa klaster DB untuk menskalakan.

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

Aurora Serverless v1 dan failover

Jika instans DB untuk Aurora Serverless v1 Cluster DB menjadi tidak tersedia atau Availability Zone (AZ) gagal, Aurora membuat ulang instans DB di AZ yang berbeda. Namun, Aurora Serverless v1 cluster bukanlah cluster 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 cluster Aurora dengan provisioned atau Aurora Serverless v2 contoh. Bagian Aurora Serverless v1 waktu 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 Aurora Serverless v1 klaster selalu dienkripsi. Anda dapat memilih kunci enkripsi, tetapi tidak dapat menonaktifkan enkripsi. Untuk menyalin atau berbagi snapshot Aurora Serverless v1 cluster, enkripsi snapshot menggunakan milik Anda sendiri. AWS KMS key Untuk informasi selengkapnya, lihat Penyalinan snapshot cluster DB. Untuk mempelajari selengkapnya tentang enkripsi dan Amazon Aurora, lihat Mengenkripsi klaster DB Amazon Aurora