Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Performa dan penskalaan untuk Aurora Serverless v2

Prosedur dan contoh berikut menunjukkan bagaimana Anda dapat mengatur rentang kapasitas untuk klaster Aurora Serverless v2 dan instans DB terkait. Anda juga dapat menggunakan prosedur berikut untuk memantau seberapa sibuk instans DB Anda. Kemudian, Anda dapat menggunakan temuan Anda untuk menentukan apakah Anda perlu menambah atau mengurangi rentang kapasitas.

Sebelum Anda menggunakan prosedur ini, pastikan Anda memahami cara kerja penskalaan Aurora Serverless v2. Mekanisme penskalaannya berbeda dari Aurora Serverless v1. Untuk detailnya, lihat Aurora Serverless v2 penskalaan.

Memilih rentang kapasitas Aurora Serverless v2 untuk klaster Aurora

Dengan instans DB Aurora Serverless v2, Anda mengatur rentang kapasitas yang berlaku untuk semua instans DB di klaster DB Anda pada saat yang sama saat Anda menambahkan instans DB Aurora Serverless v2 pertama ke klaster DB. Untuk prosedur dalam melakukannya, lihat Mengatur Aurora Serverless v2 rentang kapasitas untuk sebuah cluster.

Anda juga dapat mengubah rentang kapasitas untuk klaster yang ada. Bagian berikut membahas secara lebih mendetail tentang cara memilih nilai minimum dan maksimum yang sesuai dan apa yang terjadi ketika Anda membuat perubahan pada rentang kapasitas. Misalnya, mengubah rentang kapasitas dapat memodifikasi nilai default dari beberapa parameter konfigurasi. Untuk menerapkan semua perubahan parameter, setiap instans DB Aurora Serverless v2 mungkin harus di-boot ulang.

Memilih pengaturan kapasitas Aurora Serverless v2 minimum untuk klaster

Pengguna cenderung selalu memilih 0,5 untuk pengaturan kapasitas Aurora Serverless v2 minimum. Nilai itu memungkinkan instans DB untuk menurunkan kapasitas terkecil saat benar-benar menganggur, sambil tetap aktif. Anda juga dapat mengaktifkan perilaku jeda otomatis dengan menentukan kapasitas minimum 0 ACUs, seperti yang dijelaskan dalam. Penskalaan ke Nol ACUs dengan jeda otomatis dan lanjutkan Aurora Serverless v2 Namun, tergantung pada bagaimana Anda menggunakan cluster itu dan pengaturan lain yang Anda konfigurasikan, kapasitas minimum yang berbeda mungkin yang paling efektif. Pertimbangkan faktor-faktor berikut saat memilih pengaturan kapasitas minimum:

Memilih pengaturan kapasitas Aurora Serverless v2 maksimum untuk klaster

Pengguna cenderung selalu memilih nilai tinggi tertentu untuk pengaturan kapasitas Aurora Serverless v2 maksimum. Kapasitas maksimum yang besar memungkinkan instans DB menaikkan skala secara maksimal saat menjalankan beban kerja intensif. Nilai rendah menghindari kemungkinan biaya tak terduga. Bergantung pada cara Anda menggunakan klaster tersebut dan pengaturan lain yang Anda konfigurasikan, nilai yang paling efektif mungkin lebih tinggi atau lebih rendah dari yang Anda kira. Pertimbangkan faktor-faktor berikut saat memilih pengaturan kapasitas maksimum:

Contoh: Ubah rentang kapasitas Aurora Serverless v2 klaster untuk Aurora MySQL

AWS CLI Contoh berikut menunjukkan cara memperbarui rentang ACU untuk instans Aurora Serverless v2 DB di cluster Aurora MySQL yang ada. Awalnya, rentang kapasitas untuk cluster adalah 8-32 ACUs.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}

Instans DB menganggur dan diperkecil menjadi 8. ACUs Pengaturan terkait kapasitas berikut berlaku untuk instans DB pada saat ini. Untuk merepresentasikan ukuran pool buffer dalam unit yang mudah dibaca, kita membaginya dengan 2 pangkat 30, sehingga menghasilkan pengukuran dalam gibibyte (GiB). Itu karena pengukuran terkait memori untuk Aurora menggunakan unit berdasarkan pangkat 2, bukan pangkat 10.

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                9294577664 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|   8.65625 |
+-----------+
1 row in set (0.00 sec)

Selanjutnya, kita mengubah rentang kapasitas untuk klaster. Setelah perintah modify-db-cluster selesai, rentang ACU untuk klaster adalah 12,5–80.

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}

Mengubah rentang kapasitas menyebabkan perubahan pada nilai default dari beberapa parameter konfigurasi. Aurora dapat segera menerapkan beberapa nilai default baru tersebut. Namun, beberapa perubahan parameter hanya berlaku setelah boot ulang. Status pending-reboot menunjukkan bahwa boot ulang diperlukan untuk menerapkan beberapa perubahan parameter.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}

Pada titik ini, cluster menganggur dan instans serverless-v2-instance-1 DB mengkonsumsi ACUs 12,5. Parameterinnodb_buffer_pool_size sudah disesuaikan berdasarkan kapasitas instans DB saat ini. Parameter max_connections masih mencerminkan nilai dari kapasitas maksimum sebelumnya. Jika nilai tersebut direset, instans DB harus di-boot ulang.

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               15572402176 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+---------------+
| gibibytes     |
+---------------+
| 14.5029296875 |
+---------------+
1 row in set (0.00 sec)

Sekarang kita mem-boot ulang instans DB dan menunggu hingga instans tersebut tersedia lagi.

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

Status pending-reboot dihapus. Nilai in-sync mengonfirmasi bahwa Aurora telah menerapkan semua perubahan parameter yang tertunda.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}

Parameter innodb_buffer_pool_size telah meningkat ke ukuran akhir untuk instans DB idle. Parameter max_connections telah meningkat untuk mencerminkan nilai yang berasal dari nilai ACU maksimum. Rumus yang digunakan Aurora untuk max_connections menyebabkan peningkatan 1.000 ketika ukuran memori berlipat ganda.

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               16139681792 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|  15.03125 |
+-----------+
1 row in set (0.00 sec)

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              4000 |
+-------------------+
1 row in set (0.00 sec)

Kami mengatur rentang kapasitas menjadi 0,5-128 ACUs, dan me-reboot instans DB. Sekarang instans DB idle memiliki ukuran cache buffer yang kurang dari 1 GiB, jadi kita mengukurnya dalam mebibyte (MiB). Nilai max_connections 5000 berasal dari ukuran memori pada pengaturan kapasitas maksimum.

mysql> select @@innodb_buffer_pool_size / pow(2,20) as mebibytes, @@max_connections;
+-----------+-------------------+
| mebibytes | @@max_connections |
+-----------+-------------------+
|       672 |              5000 |
+-----------+-------------------+
1 row in set (0.00 sec)

Contoh: Ubah rentang kapasitas Aurora Serverless v2 untuk klaster Aurora PostgreSQL

Contoh CLI berikut menunjukkan cara memperbarui rentang ACU untuk instans DB Aurora Serverless v2 di klaster Aurora PostgreSQL yang sudah ada.

Gambar berikut menunjukkan perubahan kapasitas di Amazon CloudWatch.

Instans DB menganggur dan diperkecil menjadi 0,5. ACUs Pengaturan terkait kapasitas berikut berlaku untuk instans DB pada saat ini.

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

Selanjutnya, kita mengubah rentang kapasitas untuk klaster. Setelah perintah modify-db-cluster selesai, rentang ACU untuk klaster adalah 8.0–32.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}

Mengubah rentang kapasitas menyebabkan perubahan pada nilai default dari beberapa parameter konfigurasi. Aurora dapat segera menerapkan beberapa nilai default baru tersebut. Namun, beberapa perubahan parameter hanya berlaku setelah boot ulang. Status pending-reboot menunjukkan bahwa Anda harus melakukan boot ulang untuk menerapkan beberapa perubahan parameter.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}

Pada titik ini, cluster menganggur dan instance serverless-v2-instance-1 DB mengkonsumsi 8.0 ACUs. Parametershared_buffers sudah disesuaikan berdasarkan kapasitas instans DB saat ini. Parameter max_connections masih mencerminkan nilai dari kapasitas maksimum sebelumnya. Jika nilai tersebut direset, instans DB harus di-boot ulang.

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)

Kita mem-boot ulang instans DB dan menunggu hingga instans tersebut tersedia lagi.

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

Sekarang setelah instans DB di-boot ulang, status pending-reboot dihapus. Nilai in-sync mengonfirmasi bahwa Aurora telah menerapkan semua perubahan parameter yang tertunda.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}

Setelah boot ulang, max_connections menunjukkan nilai dari kapasitas maksimum baru.

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)

Selanjutnya, kami mengubah rentang kapasitas untuk cluster menjadi 12, 5-80 ACUs.

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}

Pada titik ini, cluster menganggur dan instans serverless-v2-instance-1 DB mengkonsumsi ACUs 12,5. Parametershared_buffers sudah disesuaikan berdasarkan kapasitas instans DB saat ini. Nilai max_connections masih 5000.

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

Kita mem-boot ulang lagi, tetapi nilai parameternya tetap sama. Ini karena max_connections memiliki nilai maksimum 5000 untuk klaster DB Aurora Serverless v2 yang menjalankan Aurora PostgreSQL.

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

Sekarang kami mengatur kisaran kapasitas dari 0,5 hingga 128 ACUs. Skala cluster DB turun ke 10 ACUs, lalu ke 2. Kita mem-boot ulang instans DB.

postgres=> show max_connections;
 max_connections
-----------------
 2000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

max_connectionsNilai untuk instans Aurora Serverless v2 DB didasarkan pada ukuran memori yang berasal dari maksimum ACUs. Namun, ketika Anda menentukan kapasitas minimum 0 atau 0,5 ACUs pada instans DB yang kompatibel dengan PostgreSQL, nilai maksimum dibatasi pada 2.000. max_connections

Sekarang kita mengembalikan kapasitas ke rentang awal 0,5–1 ACU dan mem-boot ulang instans DB. Parameter max_connections telah kembali ke nilai aslinya.

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

Menggunakan grup parameter untuk Aurora Serverless v2

Saat Anda membuat klaster DB Aurora Serverless v2, Anda memilih mesin Aurora DB tertentu dan grup parameter klaster DB terkait. Jika Anda tidak memahami cara Aurora menggunakan grup parameter untuk menerapkan pengaturan konfigurasi secara konsisten di seluruh klaster, lihat . Semua prosedur tersebut untuk membuat, memodifikasi, menerapkan, dan tindakan lain untuk grup parameter akan berlaku untuk Aurora Serverless v2.

Fitur grup parameter beroperasi sama antara klaster terprovisi dan klaster yang berisi instans DB Aurora Serverless v2:

Nilai parameter default

Perbedaan penting antara instans DB terprovisi dan instans DB Aurora Serverless v2 adalah bahwa Aurora mengganti nilai parameter kustom apa pun untuk parameter tertentu yang terkait dengan kapasitas instans DB. Nilai parameter kustom masih berlaku untuk instans DB terprovisi di klaster Anda. Untuk detail selengkapnya tentang bagaimana instans DB Aurora Serverless v2 menafsirkan parameter dari grup parameter Aurora, lihat Parameter konfigurasi untuk klaster Aurora. Untuk parameter spesifik yang diganti oleh Aurora Serverless v2, lihat Parameter yang disesuaikan Aurora saat Aurora Serverless v2 menaikkan dan menurunkan skalanya dan Parameter yang dihitung Aurora berdasarkan kapasitas maksimum Aurora Serverless v2.

Anda bisa mendapatkan daftar nilai default untuk grup parameter default untuk berbagai mesin Aurora DB dengan menggunakan perintah describe-db-cluster-parametersCLI dan menanyakan file. Wilayah AWS Berikut ini adalah nilai-nilai yang dapat Anda gunakan untuk opsi --db-parameter-group-family dan -db-parameter-group-name untuk versi mesin yang kompatibel dengan Aurora Serverless v2.

Contoh berikut mendapatkan daftar parameter dari grup klaster DB default untuk Aurora MySQL versi 3 dan Aurora PostgreSQL 13. Ini adalah versi Aurora MySQL dan Aurora PostgreSQL yang Anda gunakan dengan Aurora Serverless v2.

Untuk Linux, macOS, atau Unix:

aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-mysql8.0 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text

aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-postgresql13 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text

Untuk Windows:

aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-mysql8.0 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text

aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-postgresql13 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text

Koneksi maksimum untuk Aurora Serverless v2

Untuk Aurora MySQL dan Aurora PostgreSQL, instans DB Aurora Serverless v2 menjaga parameter max_connections tetap konstan sehingga koneksi tidak terputus saat instans DB diturunkan skalanya. Nilai default untuk parameter ini berasal dari rumus berdasarkan ukuran memori instans DB. Untuk detail tentang rumus dan nilai default untuk kelas instans DB terprovisi, lihat Koneksi maksimum ke instans DB Aurora MySQL dan Koneksi maksimum ke instans DB Aurora PostgreSQL.

Ketika Aurora Serverless v2 mengevaluasi rumus, ia menggunakan ukuran memori berdasarkan unit kapasitas Aurora maksimum ACUs () untuk instans DB, bukan nilai ACU saat ini. Jika Anda mengubah nilai default, sebaiknya gunakan variasi rumus alih-alih menentukan nilai konstan. Dengan begitu, Aurora Serverless v2 bisa menggunakan pengaturan yang sesuai berdasarkan kapasitas maksimum.

Saat Anda mengubah kapasitas maksimum klaster DB Aurora Serverless v2, Anda harus mem-boot ulang instans DB Aurora Serverless v2 untuk memperbarui nilai max_connections. Ini karena max_connections merupakan parameter statis untuk Aurora Serverless v2.

Tabel berikut menunjukkan nilai default untuk max_connections bagi Aurora Serverless v2 berdasarkan nilai ACU maksimum.

Untuk contoh spesifik yang menunjukkan perubahan max_connections dengan nilai ACU maksimum, lihat Contoh: Ubah rentang kapasitas Aurora Serverless v2 klaster untuk Aurora MySQL dan Contoh: Ubah rentang kapasitas Aurora Serverless v2 untuk klaster Aurora PostgreSQL.

Parameter yang disesuaikan Aurora saat Aurora Serverless v2 menaikkan dan menurunkan skalanya

Selama penskalaan otomatis, Aurora Serverless v2 harus dapat mengubah parameter agar setiap instans DB beroperasi dengan paling efektif untuk peningkatan atau penurunan kapasitas. Dengan demikian, Anda tidak dapat mengganti beberapa parameter yang terkait dengan kapasitas. Untuk beberapa parameter yang dapat Anda ganti, hindari melakukan hard-coding nilai tetap. Pertimbangan berikut berlaku untuk pengaturan ini yang terkait dengan kapasitas.

Untuk Aurora MySQL, Aurora Serverless v2 mengubah ukuran beberapa parameter secara dinamis selama penskalaan. Untuk parameter berikut, Aurora Serverless v2 tidak menggunakan nilai parameter kustom apa pun yang Anda tentukan:

Untuk Aurora PostgreSQL, Aurora Serverless v2 mengubah ukuran parameter berikut secara dinamis selama penskalaan. Untuk parameter berikut, Aurora Serverless v2 tidak menggunakan nilai parameter kustom apa pun yang Anda tentukan:

Untuk semua parameter selain yang tercantum di sini, instans Aurora Serverless v2 DB beroperasi sama dengan instans DB terprovisi. Nilai parameter default diwarisi dari grup parameter klaster. Anda dapat memodifikasi nilai default untuk seluruh klaster dengan menggunakan grup parameter klaster kustom. Atau Anda dapat memodifikasi nilai default untuk instans DB tertentu dengan menggunakan grup parameter DB kustom. Parameter dinamis akan segera diperbarui. Perubahan parameter statis hanya berlaku setelah Anda mem-boot ulang instans DB.

Parameter yang dihitung Aurora berdasarkan kapasitas maksimum Aurora Serverless v2

Untuk parameter berikut, Aurora PostgreSQL menggunakan nilai default yang berasal dari ukuran memori berdasarkan pengaturan ACU maksimum, sama seperti dengan max_connections:

Menghindari out-of-memory kesalahan

Jika salah satu instans DB Aurora Serverless v2 Anda secara konsisten mencapai batas kapasitas maksimumnya, Aurora akan menunjukkan kondisi ini dengan mengatur instans DB ke status incompatible-parameters. Saat instans DB memiliki status incompatible-parameters, beberapa operasi akan diblokir. Misalnya, Anda tidak dapat meningkatkan versi mesin.

Biasanya, instans DB Anda masuk ke status ini ketika sering restart karena out-of-memory kesalahan. Aurora mencatat sebuah peristiwa ketika jenis pengaktifan ulang ini terjadi. Anda dapat melihat peristiwa ini dengan mengikuti prosedur dalam Melihat RDS acara Amazon. Penggunaan memori yang luar biasa tinggi dapat terjadi karena overhead yang timbul saat mengaktifkan pengaturan seperti Wawasan Performa dan autentikasi IAM. Hal ini juga bisa berasal dari beban kerja yang berat pada instans DB Anda atau pengelolaan metadata yang terkait dengan sejumlah besar objek skema.

Jika tekanan memori menjadi lebih rendah sehingga instans DB sangat sering tidak mencapai kapasitas maksimumnya, Aurora akan secara otomatis mengubah status instans DB kembali ke available.

Untuk pulih dari kondisi ini, Anda dapat mengambil beberapa atau semua tindakan berikut:

CloudWatch Metrik Amazon penting untuk Aurora Serverless v2

Untuk memulai Amazon CloudWatch untuk instans Aurora Serverless v2 DB Anda, lihatMelihat Aurora Serverless v2 log di Amazon CloudWatch. Untuk mempelajari lebih lanjut tentang cara memantau klaster Aurora DB, lihat CloudWatch. Memantau peristiwa log di Amazon CloudWatch

Anda dapat melihat instans Aurora Serverless v2 DB Anda CloudWatch untuk memantau kapasitas yang dikonsumsi oleh setiap instans DB dengan ServerlessDatabaseCapacity metrik. Anda juga dapat memantau semua CloudWatch metrik Aurora standar, seperti dan. DatabaseConnections Queries Untuk daftar lengkap CloudWatch metrik yang dapat Anda pantau untuk Aurora, lihat. CloudWatch Metrik Amazon untuk Amazon Aurora Metrik dibagi menjadi metrik tingkat klaster dan tingkat instans, di Metrik tingkat klaster untuk Amazon Aurora dan Metrik tingkat instans untuk Amazon Aurora.

Metrik CloudWatch tingkat instans berikut ini penting untuk dipantau agar Anda memahami bagaimana instans Aurora Serverless v2 DB Anda meningkat dan turun. Semua metrik ini dihitung setiap detik. Dengan begitu, Anda dapat memantau status instans DB Aurora Serverless v2 Anda saat ini. Anda dapat mengatur alarm untuk memberi tahu Anda jika ada instans DB Aurora Serverless v2 yang mendekati ambang batas untuk metrik yang terkait dengan kapasitas. Anda dapat menentukan apakah pengaturan kapasitas minimum dan maksimum sudah sesuai, atau apakah Anda perlu menyesuaikannya. Anda dapat menentukan di mana upaya Anda harus difokuskan untuk mengoptimalkan efisiensi basis data Anda.

Biasanya, sebagian besar penskalaan untuk instans DB Aurora Serverless v2 disebabkan oleh penggunaan memori dan aktivitas CPU. Metrik TempStorageIops dan TempStorageThroughput metrik dapat membantu Anda mendiagnosis kasus yang jarang terjadi saat aktivitas jaringan untuk transfer antara instans DB dan perangkat penyimpanan lokal menimbulkan peningkatan kapasitas yang tidak terduga. Untuk memantau aktivitas jaringan lainnya, Anda dapat menggunakan metrik yang ada ini:

Anda dapat meminta Aurora menerbitkan beberapa atau semua log database ke Amazon CloudWatch Logs. Untuk petunjuk, lihat yang berikut ini tergantung pada mesin database Anda:

Bagaimana Aurora Serverless v2 metrik berlaku untuk tagihan Anda AWS

Aurora Serverless v2Biaya pada AWS tagihan Anda dihitung berdasarkan ServerlessDatabaseCapacity metrik yang sama yang dapat Anda pantau. Mekanisme penagihan dapat berbeda dari CloudWatch rata-rata yang dihitung untuk metrik ini jika Anda menggunakan Aurora Serverless v2 kapasitas hanya sebagian dari satu jam. Ini juga dapat berbeda jika masalah sistem membuat CloudWatch metrik tidak tersedia untuk periode singkat. Dengan demikian, Anda mungkin melihat nilai ACU-jam yang sedikit berbeda pada tagihan Anda daripada jika Anda menghitung sendiri angkanya dari nilai rata-rata ServerlessDatabaseCapacity.

Contoh CloudWatch perintah untuk Aurora Serverless v2 metrik

AWS CLI Contoh berikut menunjukkan bagaimana Anda dapat memantau CloudWatch metrik terpenting yang terkait Aurora Serverless v2 dengannya. Dalam setiap kasus, ganti string Value= untuk parameter --dimensions dengan pengidentifikasi instans DB Aurora Serverless v2 Anda sendiri.

Contoh Linux berikut menampilkan nilai kapasitas minimum, maksimum, dan rata-rata untuk instans DB, yang diukur setiap 10 menit selama satu jam. Perintah date Linux menentukan waktu mulai dan akhir secara relatif terhadap tanggal dan waktu saat ini. Fungsi sort_by dalam parameter --query mengurutkan hasil secara kronologis berdasarkan bidang Timestamp.

aws cloudwatch get-metric-statistics --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Contoh Linux berikut menunjukkan pemantauan kapasitas setiap instans DB dalam sebuah klaster. Hal ini mengukur pemanfaatan kapasitas minimum, maksimum, dan rata-rata dari setiap instans DB. Pengukuran dilakukan sekali setiap jam selama periode tiga jam. Contoh-contoh ini menggunakan ACUUtilization metrik yang mewakili persentase dari batas atas ACUs, alih-alih ServerlessDatabaseCapacity mewakili jumlah tetap ACUs. Dengan begitu, Anda tidak perlu mengetahui angka sebenarnya untuk nilai ACU minimum dan maksimum dalam rentang kapasitas. Anda dapat melihat persentase mulai dari 0 hingga 100.

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_writer_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_reader_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Contoh Linux berikut melakukan pengukuran yang sama seperti yang sebelumnya. Dalam hal ini, pengukuran ditujukan untuk metrik CPUUtilization. Pengukuran dilakukan setiap 10 menit selama periode 1 jam. Angka-angka tersebut merepresentasikan persentase CPU yang tersedia yang digunakan, berdasarkan sumber daya CPU yang tersedia untuk pengaturan kapasitas maksimum untuk instans DB.

aws cloudwatch get-metric-statistics --metric-name "CPUUtilization" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Contoh Linux berikut melakukan pengukuran yang sama seperti yang sebelumnya. Dalam hal ini, pengukuran ditujukan untuk metrik FreeableMemory. Pengukuran dilakukan setiap 10 menit selama periode 1 jam.

aws cloudwatch get-metric-statistics --metric-name "FreeableMemory" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Memantau performa Aurora Serverless v2 dengan Wawasan Performa

Anda dapat menggunakan Wawasan Performa untuk memantau performa instans DB Aurora Serverless v2. Untuk prosedur Wawasan Performa, lihat Memantau muatan DB dengan Wawasan Performa di Amazon Aurora.

Penghitung Wawasan Performa baru berikut ini berlaku untuk instans DB Aurora Serverless v2:

Untuk daftar lengkap penghitung Wawasan Performa, lihat Metrik penghitung Wawasan Performa.

Ketika nilai vCPU ditampilkan untuk instans DB Aurora Serverless v2 di Wawasan Performa, nilai tersebut merepresentasikan perkiraan berdasarkan nilai ACU untuk instans DB ini. Pada interval default satu menit, nilai vCPU fraksional apa pun dibulatkan ke bilangan bulat terdekat. Untuk interval yang lebih lama, nilai vCPU yang ditampilkan adalah rata-rata nilai vCPU bilangan bulat untuk setiap menit.

Memecahkan masalah kapasitas Aurora Serverless v2

Dalam beberapa kasus, Aurora Serverless v2 tidak diturunkan skalanya ke kapasitas minimum, bahkan tanpa beban pada basis data. Hal ini dapat terjadi karena alasan berikut:

Jika basis data masih tidak menurunkan skalanya ke kapasitas minimum yang dikonfigurasi, hentikan dan aktifkan ulang basis data untuk mengklaim kembali fragmen memori yang mungkin telah terakumulasi dari waktu ke waktu. Menghentikan dan memulai basis data akan menghasilkan waktu henti, jadi sebaiknya lakukan ini seperlunya.