Kinerja dan penskalaan untuk Aurora Serverless v2

Prosedur dan contoh berikut menunjukkan bagaimana Anda dapat mengatur rentang kapasitas untuk Aurora Serverless v2 cluster 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 terbiasa dengan caranya Aurora Serverless v2 penskalaan bekerja. Mekanisme penskalaan berbeda dari pada Aurora Serverless v1. Untuk detailnya, lihatAurora Serverless v2 penskalaan.

Daftar Isi

• Memilih Aurora Serverless v2 rentang kapasitas untuk cluster Aurora

  • Memilih minimum Aurora Serverless v2 pengaturan kapasitas untuk cluster

  • Memilih maksimum Aurora Serverless v2 pengaturan kapasitas untuk cluster

  • Contoh: Ubah Aurora Serverless v2 rentang kapasitas cluster Aurora MySQL

  • Contoh: Ubah Aurora Serverless v2 rentang kapasitas cluster Aurora PostgreSQL

• Bekerja dengan kelompok parameter untuk Aurora Serverless v2

  • Nilai parameter default

  • Koneksi maksimum untuk Aurora Serverless v2

  • Parameter yang Aurora sesuaikan sebagai Aurora Serverless v2 timbangan naik dan turun

  • Parameter yang dihitung Aurora berdasarkan Aurora Serverless v2 kapasitas maksimum

• Menghindari out-of-memory kesalahan

• CloudWatch Metrik Amazon penting untuk Aurora Serverless v2

  • Bagaimana Aurora Serverless v2 metrik berlaku untuk tagihan Anda AWS

  • Contoh CloudWatch perintah untuk Aurora Serverless v2 metrik

• Pemantauan Aurora Serverless v2 kinerja dengan Performance Insights

• Pemecahan Masalah Aurora Serverless v2 masalah kapasitas

Memilih Aurora Serverless v2 rentang kapasitas untuk cluster Aurora

Dengan Aurora Serverless v2 Instans DB, Anda mengatur rentang kapasitas yang berlaku untuk semua instans DB di cluster DB Anda pada saat yang sama saat Anda menambahkan yang pertama Aurora Serverless v2 Instans DB ke cluster 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. Menerapkan semua perubahan parameter dapat memerlukan reboot masing-masing Aurora Serverless v2 contoh DB.

Topik

• Memilih minimum Aurora Serverless v2 pengaturan kapasitas untuk cluster

• Memilih maksimum Aurora Serverless v2 pengaturan kapasitas untuk cluster

• Contoh: Ubah Aurora Serverless v2 rentang kapasitas cluster Aurora MySQL

• Contoh: Ubah Aurora Serverless v2 rentang kapasitas cluster Aurora PostgreSQL

Memilih minimum Aurora Serverless v2 pengaturan kapasitas untuk cluster

Sangat menggoda untuk selalu memilih 0,5 untuk minimum Aurora Serverless v2 pengaturan kapasitas. 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:

• Tingkat penskalaan untuk sebuah Aurora Serverless v2 Instans DB tergantung pada kapasitas saat ini. Semakin tinggi kapasitas saat ini, semakin cepat instans DB dapat dinaikkan skalanya. Jika Anda memerlukan instans DB menaikkan skalanya dengan cepat ke kapasitas yang sangat tinggi, pertimbangkan untuk mengatur kapasitas minimum ke sebuah nilai sehingga tingkat penskalaannya memenuhi kebutuhan Anda.

• Jika Anda biasanya memodifikasi kelas instans DB dari instans DB Anda untuk mengantisipasi beban kerja yang sangat tinggi atau rendah, Anda dapat menggunakan pengalaman itu untuk membuat perkiraan kasar yang setara Aurora Serverless v2 rentang kapasitas. Untuk menentukan ukuran memori yang akan digunakan pada saat lalu lintas rendah, baca Spesifikasi perangkat keras kelas instans DB untuk Aurora.

  Misalnya, anggaplah Anda menggunakan kelas instans DB db.r6g.xlarge ketika klaster Anda memiliki beban kerja yang rendah. Kelas instans DB tersebut memiliki memori 32 GiB. Dengan demikian, Anda dapat menentukan pengaturan unit kapasitas Aurora minimum (ACU) 16 untuk mengatur Aurora Serverless v2 Instans DB yang dapat menurunkan kapasitas yang kira-kira sama. Itu karena setiap ACU setara dengan sekitar 2 GiB memori. Anda dapat menentukan nilai yang agak lebih rendah agar instans DB menurunkan skalanya lebih jauh jika instans DB db.r6g.xlarge Anda terkadang kurang dimanfaatkan.

• Jika aplikasi Anda beroperasi paling efisien ketika instans DB memiliki sejumlah data dalam cache buffer, pertimbangkan untuk menentukan pengaturan ACU minimum sehingga memorinya cukup besar untuk menampung data yang sering diakses. Jika tidak, beberapa data dikeluarkan dari cache buffer saat Aurora Serverless v2 Instans DB diturunkan ke ukuran memori yang lebih rendah. Kemudian, ketika instans DB menaikkan skalanya kembali, informasi dari data akan dibacakan kembali ke cache buffer dari waktu ke waktu. Jika jumlah I/O untuk memasukkan data kembali ke cache buffer cukup besar, mungkin lebih efektif untuk memilih nilai ACU minimum yang lebih tinggi.

• Jika Aurora Serverless v2 Instans DB berjalan sebagian besar waktu pada kapasitas tertentu, pertimbangkan untuk menentukan pengaturan kapasitas minimum yang lebih rendah dari baseline itu, tetapi tidak terlalu rendah. Aurora Serverless v2 dapat sangat efektif memperkirakan berapa banyak dan seberapa cepat skala harus dinaikkan ketika kapasitas saat ini tidak secara drastis lebih rendah dari kapasitas yang dibutuhkan.

• Jika beban kerja terprovisi Anda memiliki persyaratan memori yang terlalu tinggi untuk kelas instans DB kecil seperti T3 atau T4g, pilih pengaturan ACU minimum yang menyediakan memori yang sebanding dengan instans DB R5 atau R6g.

  Secara khusus, kami merekomendasikan kapasitas minimum berikut untuk digunakan dengan fitur yang ditentukan (rekomendasi ini dapat berubah):

  • Performance Insights - 2 ACUs

  • Database global Aurora — 8 ACUs (hanya berlaku untuk yang utama) Wilayah AWS

• Di Aurora, replikasi terjadi pada lapisan penyimpanan, sehingga kapasitas pembaca tidak secara langsung mempengaruhi replikasi. Namun, untuk Aurora Serverless v2 Instans DB pembaca yang menskalakan secara independen, pastikan bahwa kapasitas minimum cukup untuk menangani beban kerja selama periode intensif penulisan untuk menghindari latensi kueri. Jika instans DB pembaca di tingkatan promosi 2—15 mengalami masalah kinerja, pertimbangkan untuk meningkatkan kapasitas minimum klaster. Untuk detail tentang cara memilih apakah instans DB pembaca akan diskalakan bersama dengan penulis atau terpisah, lihat Memilih tingkat promosi untuk Aurora Serverless v2 pembaca.

• Jika Anda memiliki cluster DB dengan Aurora Serverless v2 Misalnya DB pembaca, pembaca tidak menskalakan bersama dengan instans DB penulis ketika tingkat promosi pembaca tidak 0 atau 1. Dalam hal ini, pengaturan kapasitas minimum yang rendah dapat mengakibatkan lag replikasi yang berlebihan. Hal ini karena pembaca mungkin tidak memiliki kapasitas yang cukup untuk menerapkan perubahan dari penulis ketika basis data sibuk. Kami menyarankan Anda mengatur kapasitas minimum ke nilai yang mewakili jumlah memori dan CPU yang sebanding dengan instans DB penulis.

• Nilai max_connections parameter untuk Aurora Serverless v2Instans 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

  Jika Anda bermaksud menggunakan klaster Aurora PostgreSQL untuk beban kerja koneksi tinggi, pertimbangkan untuk menggunakan pengaturan ACU minimum 1 atau lebih tinggi. Untuk detail tentang caranya Aurora Serverless v2 menangani parameter max_connections konfigurasi, lihatKoneksi maksimum untuk Aurora Serverless v2.

• Waktu yang dibutuhkan untuk sebuah Aurora Serverless v2 Instans DB untuk skala dari kapasitas minimum ke kapasitas maksimumnya tergantung pada perbedaan antara nilai ACU minimum dan maksimum. Ketika kapasitas instans DB saat ini besar, Aurora Serverless v2 skala meningkat dalam peningkatan yang lebih besar daripada ketika instans DB dimulai dari kapasitas kecil. Jadi, jika Anda menentukan kapasitas maksimum yang relatif besar dan instans DB menghabiskan sebagian besar waktunya mendekati kapasitas tersebut, pertimbangkan untuk meningkatkan pengaturan ACU minimum. Dengan begitu, instans DB idle dapat menaikkan skalanya kembali ke kapasitas maksimum dengan lebih cepat.

Memilih maksimum Aurora Serverless v2 pengaturan kapasitas untuk cluster

Sangat menggoda untuk selalu memilih beberapa nilai tinggi untuk maksimum Aurora Serverless v2 pengaturan kapasitas. 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:

• Kapasitas maksimum harus minimal setinggi kapasitas minimum. Anda dapat mengatur kapasitas minimum dan maksimum agar identik. Namun, dalam hal ini kapasitas tidak pernah naik atau turun. Dengan demikian, menggunakan nilai yang identik untuk kapasitas minimum dan maksimum tidak tepat untuk situasi di luar pengujian.

• Kapasitas maksimum harus lebih tinggi dari 0,5 ACUs. Anda dapat mengatur kapasitas minimum dan maksimum agar sama dalam banyak kasus. Namun, Anda tidak dapat menentukan 0,5 untuk minimum dan maksimum. Gunakan nilai 1 atau lebih tinggi untuk kapasitas maksimum.

• Jika Anda biasanya memodifikasi kelas instans DB dari instans DB Anda untuk mengantisipasi beban kerja yang sangat tinggi atau rendah, Anda dapat menggunakan pengalaman itu untuk memperkirakan yang setara Aurora Serverless v2 rentang kapasitas. Untuk menentukan ukuran memori yang akan digunakan pada saat lalu lintas tinggi, baca Spesifikasi perangkat keras kelas instans DB untuk Aurora.

  Misalnya, anggaplah Anda menggunakan kelas instans DB db.r6g.4xlarge ketika klaster Anda memiliki beban kerja yang tinggi. Kelas instans DB tersebut memiliki memori 128 GiB. Dengan demikian, Anda dapat menentukan pengaturan ACU maksimum 64 untuk mengatur Aurora Serverless v2 Instans DB yang dapat menskalakan hingga kira-kira kapasitas yang sama. Itu karena setiap ACU setara dengan sekitar 2 GiB memori. Anda dapat menentukan nilai yang agak lebih tinggi agar instans DB menaikkan skalanya lebih jauh jika instans DB db.r6g.4xlarge Anda terkadang tidak memiliki kapasitas yang cukup untuk menangani beban kerja secara efektif.

• Jika Anda memiliki batas anggaran pada penggunaan database Anda, pilih nilai yang tetap dalam batas itu bahkan jika semua Anda Aurora Serverless v2 Instans DB berjalan pada kapasitas maksimum sepanjang waktu. Ingatlah bahwa ketika Anda memiliki n Aurora Serverless v2 Instans DB di cluster Anda, maksimum teoritis Aurora Serverless v2 kapasitas yang dapat dikonsumsi cluster kapan saja adalah n kali pengaturan ACU maksimum untuk cluster. (Jumlah sebenarnya yang dikonsumsi mungkin lebih sedikit, misalnya jika beberapa pembaca diskalakan secara terpisah dari penulis.)

• Jika Anda menggunakan Aurora Serverless v2 instans DB pembaca untuk menurunkan beberapa beban kerja hanya-baca dari instans DB penulis, Anda mungkin dapat memilih pengaturan kapasitas maksimum yang lebih rendah. Anda melakukannya agar setiap instans DB pembaca tidak perlu diskalakan sama tingginya saat klaster hanya berisi satu instans DB.

• Misalkan Anda ingin mencegah penggunaan yang berlebihan karena parameter basis data yang salah dikonfigurasi atau kueri yang tidak efisien dalam aplikasi Anda. Dalam hal ini, Anda dapat menghindari penggunaan berlebihan yang tidak disengaja dengan memilih pengaturan kapasitas maksimum yang lebih rendah dari pengaturan tertinggi absolut yang dapat Anda tetapkan.

• Jika lonjakan karena aktivitas pengguna sebenarnya jarang tetapi dapat terjadi, Anda dapat mempertimbangkan situasi tersebut saat memilih pengaturan kapasitas maksimum. Jika prioritasnya adalah agar aplikasi tetap berjalan dengan performa dan skalabilitas penuh, Anda dapat menentukan pengaturan kapasitas maksimum yang lebih tinggi daripada yang Anda amati dalam penggunaan normal. Jika Anda tidak memiliki masalah dengan aplikasi yang berjalan dengan throughput yang berkurang selama lonjakan aktivitas yang sangat ekstrem, Anda dapat memilih pengaturan kapasitas maksimum yang sedikit lebih rendah. Pastikan Anda memilih pengaturan yang masih memiliki cukup memori dan sumber daya CPU untuk menjaga aplikasi tetap berjalan.

• Jika Anda mengaktifkan pengaturan di klaster Anda yang meningkatkan penggunaan memori untuk setiap instans DB, pertimbangkan memori tersebut saat memutuskan nilai ACU maksimum. Pengaturan tersebut mencakup pengaturan untuk Wawasan Performa, kueri paralel Aurora MySQL, skema performa Aurora MySQL, dan replikasi log biner Aurora MySQL. Pastikan bahwa nilai ACU maksimum memungkinkan Aurora Serverless v2 Instans DB cukup ditingkatkan untuk menangani beban kerja saat fitur tersebut digunakan. Untuk informasi tentang pemecahan masalah yang disebabkan oleh kombinasi pengaturan ACU maksimum rendah dan fitur Aurora yang memerlukan overhead memori, lihat Menghindari out-of-memory kesalahan.

Contoh: Ubah Aurora Serverless v2 rentang kapasitas cluster Aurora MySQL

AWS CLI Contoh berikut menunjukkan cara memperbarui rentang ACU untuk Aurora Serverless v2 Instans 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.

catatan

Jika Anda mengatur parameter max_connections secara langsung dalam grup parameter DB kustom, boot ulang tidak diperlukan.

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 Aurora Serverless v2 rentang kapasitas cluster Aurora PostgreSQL

Contoh CLI berikut menunjukkan cara memperbarui rentang ACU untuk Aurora Serverless v2 Instans DB di cluster Aurora PostgreSQL yang ada.

1. Rentang kapasitas untuk klaster dimulai pada 0,5–1 ACU.

2. Ubah rentang kapasitas menjadi 8-32 ACUs.

3. Ubah rentang kapasitas menjadi 12,5-80 ACUs.

4. Ubah rentang kapasitas menjadi 0,5-128 ACUs.

5. Kembalikan kapasitas ke rentang awal 0,5–1 ACU.

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.

catatan

Jika Anda mengatur parameter max_connections secara langsung dalam grup parameter DB kustom, boot ulang tidak diperlukan.

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. Hal ini karena max_connections memiliki nilai maksimum 5000 untuk Aurora Serverless v2 Cluster DB 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 Aurora Serverless v2 Instans 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)

Bekerja dengan kelompok parameter untuk Aurora Serverless v2

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

Fitur grup parameter bekerja secara umum sama antara cluster yang disediakan dan cluster yang berisi Aurora Serverless v2 Contoh DB:

• Nilai parameter default untuk semua instans DB di klaster ditentukan oleh grup parameter klaster.

• Anda dapat mengganti beberapa parameter untuk instans DB tertentu dengan menentukan grup parameter DB kustom untuk instans DB tersebut. Anda dapat melakukannya selama debugging atau penyesuaian performa untuk instans DB tertentu. Misalnya, Anda memiliki cluster yang berisi beberapa Aurora Serverless v2 Instans DB dan beberapa instans DB yang disediakan. Dalam kasus ini, Anda dapat menentukan beberapa parameter berbeda untuk instans DB terprovisi dengan menggunakan grup parameter DB kustom.

• Untuk Aurora Serverless v2, Anda dapat menggunakan semua parameter yang memiliki nilai provisioned dalam SupportedEngineModes atribut di grup parameter. Masuk Aurora Serverless v1, Anda hanya dapat menggunakan subset parameter yang ada serverless di SupportedEngineModes atribut.

Topik

• Nilai parameter default

• Koneksi maksimum untuk Aurora Serverless v2

• Parameter yang Aurora sesuaikan sebagai Aurora Serverless v2 timbangan naik dan turun

• Parameter yang dihitung Aurora berdasarkan Aurora Serverless v2 kapasitas maksimum

Nilai parameter default

Perbedaan penting antara instans DB yang disediakan dan Aurora Serverless v2 Instans DB adalah bahwa Aurora mengganti nilai parameter khusus 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 lebih lanjut tentang caranya Aurora Serverless v2 Instans DB menafsirkan parameter dari kelompok parameter Aurora, lihat. Parameter konfigurasi untuk klaster Aurora Untuk parameter spesifik yang Aurora Serverless v2 mengesampingkan, melihat Parameter yang Aurora sesuaikan sebagai Aurora Serverless v2 timbangan naik dan turun dan. Parameter yang dihitung Aurora berdasarkan Aurora Serverless v2 kapasitas maksimum

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 --db-parameter-group-family dan -db-parameter-group-name opsi untuk versi mesin yang kompatibel dengan Aurora Serverless v2.

Mesin dan versi basis data	Kelompok grup parameter	Nama grup parameter default
Aurora MySQL versi 3	aurora-mysql8.0	default.aurora-mysql8.0
Aurora PostgreSQL versi 13.x	aurora-postgresql13	default.aurora-postgresql13
Aurora PostgreSQL versi 14.x	aurora-postgresql14	default.aurora-postgresql14
Aurora PostgreSQL versi 15.x	aurora-postgresql15	default.aurora-postgresql15
Aurora PostgreSQL versi 16.x	aurora-postgresql16	default.aurora-postgresql16

Contoh berikut mendapatkan daftar parameter dari grup klaster DB default untuk Aurora MySQL versi 3 dan Aurora PostgreSQL 13. Itu adalah versi Aurora MySQL dan Aurora PostgreSQL yang Anda gunakan 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, Aurora Serverless v2 Instans DB menahan max_connections parameter konstan sehingga koneksi tidak terputus saat instans DB turun. 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 Aurora My DB SQL dan Koneksi maksimum ke instans Aurora SQL Postgre DB.

Saat Aurora Serverless v2 mengevaluasi rumus, menggunakan ukuran memori berdasarkan unit kapasitas Aurora maksimum ACUs () untuk instance DB, bukan nilai ACU saat ini. Jika Anda mengubah nilai default, sebaiknya gunakan variasi rumus alih-alih menentukan nilai konstan. Dengan cara itu, Aurora Serverless v2 dapat menggunakan pengaturan yang sesuai berdasarkan kapasitas maksimum.

Ketika Anda mengubah kapasitas maksimum Aurora Serverless v2 Cluster DB, Anda harus me-reboot Aurora Serverless v2 Instans DB untuk memperbarui max_connections nilai. Ini karena max_connections merupakan parameter statis untuk Aurora Serverless v2.

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

Maksimum ACUs	Koneksi maksimum default pada Aurora MySQL	Koneksi maksimum default pada Aurora PostgreSQL
1	90	189
4	135	823
8	1.000	1,669
16	2.000	3,360
32	3.000	5.000
64	4.000	5.000
128	5.000	5.000
192	6.000	5.000
256	6.000	5.000

catatan

max_connectionsNilai untuk Aurora Serverless v2Instans 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

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

Parameter yang Aurora sesuaikan sebagai Aurora Serverless v2 timbangan naik dan turun

Selama penskalaan otomatis, Aurora Serverless v2 harus dapat mengubah parameter untuk setiap instans DB agar bekerja paling baik 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:

• innodb_buffer_pool_size

• innodb_purge_threads

• table_definition_cache

• table_open_cache

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:

• shared_buffers

Untuk semua parameter selain yang tercantum di sini, Aurora Serverless v2 Instans DB bekerja sama dengan instans DB yang disediakan. 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 Aurora Serverless v2 kapasitas maksimum

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

• autovacuum_max_workers

• autovacuum_vacuum_cost_limit

• autovacuum_work_mem

• effective_cache_size

• maintenance_work_mem

Menghindari out-of-memory kesalahan

Jika salah satu dari Anda Aurora Serverless v2 Instans DB secara konsisten mencapai batas kapasitas maksimumnya, Aurora 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:

• Tingkatkan batas bawah kapasitas untuk Aurora Serverless v2 Instans DB dengan mengubah nilai unit kapasitas Aurora minimum (ACU) untuk cluster. Tindakan ini menghindari masalah saat basis data idle menurunkan skalanya ke kapasitas dengan memori lebih sedikit daripada yang dibutuhkan untuk fitur yang diaktifkan di klaster Anda. Setelah mengubah pengaturan ACU untuk cluster, reboot Aurora Serverless v2 contoh DB. Tindakan ini mengevaluasi apakah Aurora dapat mereset status kembali ke available.

• Tingkatkan batas atas kapasitas untuk Aurora Serverless v2 Instans DB dengan mengubah nilai ACU maksimum untuk cluster. Tindakan ini menghindari masalah saat basis data yang sibuk tidak dapat menaikkan skalanya ke kapasitas dengan memori yang cukup untuk fitur yang diaktifkan di klaster Anda dan beban kerja basis data. Setelah mengubah pengaturan ACU untuk cluster, reboot Aurora Serverless v2 contoh DB. Tindakan ini mengevaluasi apakah Aurora dapat mereset status kembali ke available.

• Nonaktifkan pengaturan konfigurasi yang memerlukan overhead memori. Misalnya, Anda memiliki fitur seperti AWS Identity and Access Management (IAM), Performance Insights, atau replikasi log biner Aurora MySQL yang diaktifkan tetapi tidak menggunakannya. Jika demikian, Anda dapat menonaktifkannya. Atau Anda dapat menambah nilai kapasitas minimum dan maksimum untuk klaster untuk memperhitungkan memori yang digunakan oleh fitur-fitur tersebut. Untuk panduan tentang memilih pengaturan kapasitas minimum dan maksimum, lihat Memilih Aurora Serverless v2 rentang kapasitas untuk cluster Aurora.

• Kurangi beban kerja pada instans DB. Misalnya, Anda dapat menambahkan instans DB pembaca ke klaster untuk menyebarkan beban dari kueri hanya baca ke lebih banyak instans DB.

• Sesuaikan kode SQL yang digunakan oleh aplikasi Anda untuk menggunakan lebih sedikit sumber daya. Misalnya, Anda dapat memeriksa rencana kueri Anda, memeriksa log kueri yang lambat, atau menyesuaikan indeks pada tabel Anda. Anda juga dapat melakukan jenis penyesuaian SQL standar lainnya.

CloudWatch Metrik Amazon penting untuk Aurora Serverless v2

Untuk memulai dengan Amazon CloudWatch untuk Anda Aurora Serverless v2 Contoh DB, 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 Aurora Serverless v2 Instans DB 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 cara Anda Aurora Serverless v2 Instans DB sedang naik dan turun. Semua metrik ini dihitung setiap detik. Dengan begitu, Anda dapat memantau status Anda saat ini Aurora Serverless v2 Contoh DB. Anda dapat mengatur alarm untuk memberi tahu Anda jika ada Aurora Serverless v2 Instans DB 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.

• ServerlessDatabaseCapacity. Sebagai metrik tingkat instance, ia melaporkan jumlah yang ACUs diwakili oleh kapasitas instans DB saat ini. Sebagai metrik tingkat cluster, ini mewakili rata-rata ServerlessDatabaseCapacity nilai semua Aurora Serverless v2 Instans DB di cluster. Metrik ini hanya metrik tingkat cluster di Aurora Serverless v1. Di Aurora Serverless v2, ini tersedia di tingkat instans DB dan di tingkat cluster.

• ACUUtilization. Metrik ini baru di Aurora Serverless v2. Nilai ini direpresentasikan sebagai persentase. Metrik ini dihitung sebagai nilai metrik ServerlessDatabaseCapacity dibagi dengan nilai ACU maksimum klaster DB. Pertimbangkan pedoman berikut untuk menafsirkan metrik ini dan mengambil tindakan:

  • Jika metrik ini mendekati nilai 100.0, instans DB telah dinaikkan skalanya setinggi mungkin. Pertimbangkan untuk meningkatkan pengaturan ACU maksimum untuk klaster. Dengan begitu, instans DB penulis dan pembaca dapat diskalakan ke kapasitas yang lebih tinggi.

  • Misalkan beban kerja hanya baca menyebabkan instans DB pembaca mendekati ACUUtilization sebesar 100.0, sedangkan instans DB penulis tidak mendekati kapasitas maksimumnya. Dalam hal ini, pertimbangkan untuk menambahkan instans DB pembaca lainnya ke klaster. Dengan begitu, Anda dapat menyebarkan bagian hanya baca dari beban kerja yang tersebar di lebih banyak instans DB, sehingga mengurangi beban pada setiap instans DB pembaca.

  • Misalkan Anda menjalankan aplikasi produksi, sehingga performa dan skalabilitas adalah pertimbangan utamanya. Dalam hal ini, Anda dapat mengatur nilai ACU maksimum untuk klaster ke angka yang tinggi. Tujuan Anda adalah agar metrik ACUUtilization selalu berada di bawah 100.0. Dengan nilai ACU maksimum yang tinggi, Anda dapat yakin bahwa ada cukup ruang jika ada lonjakan tak terduga dalam aktivitas basis data. Anda hanya dikenai biaya untuk kapasitas basis data yang benar-benar dikonsumsi.

• CPUUtilization. Metrik ini ditafsirkan secara berbeda di Aurora Serverless v2 dibandingkan dengan instans DB yang disediakan. Untuk Aurora Serverless v2, nilai ini adalah persentase yang dihitung sebagai jumlah CPU yang saat ini digunakan dibagi dengan kapasitas CPU yang tersedia di bawah nilai ACU maksimum cluster DB. Aurora memonitor nilai ini secara otomatis dan meningkatkan skala Anda Aurora Serverless v2 Instans DB ketika instans DB secara konsisten menggunakan proporsi kapasitas CPU-nya yang tinggi.

  Jika metrik ini mendekati nilai 100.0, instans DB telah mencapai kapasitas CPU maksimumnya. Pertimbangkan untuk meningkatkan pengaturan ACU maksimum untuk klaster. Jika metrik ini mendekati nilai 100.0 pada instans DB pembaca, pertimbangkan untuk menambahkan instans DB pembaca lain ke klaster. Dengan begitu, Anda dapat menyebarkan bagian hanya baca dari beban kerja yang tersebar di lebih banyak instans DB, sehingga mengurangi beban pada setiap instans DB pembaca.

• FreeableMemory. Nilai ini mewakili jumlah memori yang tidak terpakai yang tersedia ketika Aurora Serverless v2 Instans DB diskalakan ke kapasitas maksimumnya. Untuk setiap ACU yang kapasitasnya saat ini di bawah kapasitas maksimum, nilai ini meningkat sekitar 2 GiB. Dengan demikian, metrik ini tidak mendekati nol sampai instans DB dinaikkan skalanya setinggi mungkin.

  Jika metrik ini mendekati nilai 0, instans DB telah dinaikkan skalanya setinggi mungkin dan mendekati batas memori yang tersedia. Pertimbangkan untuk meningkatkan pengaturan ACU maksimum untuk klaster. Jika metrik ini mendekati nilai 0 pada instans DB pembaca, pertimbangkan untuk menambahkan instans DB pembaca lain ke klaster. Dengan begitu, bagian hanya baca dari beban kerja dapat disebarkan ke lebih banyak instans DB, sehingga mengurangi penggunaan memori pada setiap instans DB pembaca.

• TempStorageIops. Jumlah IOPS yang dilakukan pada penyimpanan lokal yang dilampirkan ke instans DB. Ini termasuk IOPS untuk baca dan tulis. Metrik ini merepresentasikan hitungan dan diukur sekali per detik. Ini adalah metrik baru untuk Aurora Serverless v2. Untuk detailnya, lihatMetrik tingkat instans untuk Amazon Aurora.

• TempStorageThroughput. Jumlah data yang ditransfer ke dan dari penyimpanan lokal yang terkait dengan instans DB. Metrik ini merepresentasikan byte dan diukur sekali per detik. Ini adalah metrik baru untuk Aurora Serverless v2. Untuk detailnya, lihatMetrik tingkat instans untuk Amazon Aurora.

Biasanya, sebagian besar penskalaan untuk Aurora Serverless v2 Instans DB 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:

• NetworkReceiveThroughput

• NetworkThroughput

• NetworkTransmitThroughput

• StorageNetworkReceiveThroughput

• StorageNetworkThroughput

• StorageNetworkTransmitThroughput

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

• Menerbitkan log Aurora PostgreSQL ke Amazon Logs CloudWatch

• Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch

Bagaimana Aurora Serverless v2 metrik berlaku untuk tagihan Anda AWS

Bagian Aurora Serverless v2 biaya 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 dengan Aurora Serverless v2. Dalam setiap kasus, ganti Value= string untuk --dimensions parameter dengan pengenal Anda sendiri Aurora Serverless v2 contoh DB.

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

Pemantauan Aurora Serverless v2 kinerja dengan Performance Insights

Anda dapat menggunakan Performance Insights untuk memantau kinerja Aurora Serverless v2 Contoh DB. Untuk prosedur Wawasan Performa, lihat Memantau beban DB dengan Performance Insights di Amazon Aurora.

Penghitung Performance Insights baru berikut ini berlaku untuk Aurora Serverless v2 Contoh DB:

• os.general.serverlessDatabaseCapacity- Kapasitas saat ini dari instans DB di ACUs. Nilai sesuai dengan ServerlessDatabaseCapacity CloudWatch metrik untuk instance DB.

• os.general.acuUtilization – Persentase kapasitas saat ini dari kapasitas maksimum yang dikonfigurasi. Nilai sesuai dengan ACUUtilization CloudWatch metrik untuk instance DB.

• os.general.maxConfiguredAcu— Kapasitas maksimum yang Anda konfigurasikan untuk ini Aurora Serverless v2 contoh DB. Ini diukur dalam ACUs.

• os.general.minConfiguredAcu— Kapasitas minimum yang Anda konfigurasikan untuk ini Aurora Serverless v2 contoh DB. Hal ini diukur dalam ACUs

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

Ketika vCPU nilai ditampilkan untuk sebuah Aurora Serverless v2 Instans DB di Performance Insights, nilai tersebut mewakili perkiraan berdasarkan nilai ACU untuk instans DB. 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.

Pemecahan Masalah Aurora Serverless v2 masalah kapasitas

Dalam beberapa kasus, Aurora Serverless v2 tidak mengurangi kapasitas minimum, bahkan tanpa beban pada database. Hal ini dapat terjadi karena alasan berikut:

• Fitur tertentu dapat meningkatkan penggunaan sumber daya dan mencegah basis data diturunkan skalanya ke kapasitas minimum. Fitur-fitur ini mencakup hal-hal berikut:

  • Basis data global Aurora

  • Mengekspor CloudWatch Log

  • Mengaktifkan pg_audit pada klaster DB yang kompatibel dengan Aurora PostgreSQL

  • Pemantauan yang Ditingkatkan

  • Wawasan Performa

  Untuk informasi selengkapnya, lihat Memilih minimum Aurora Serverless v2 pengaturan kapasitas untuk cluster.

• Jika instance pembaca tidak mengurangi ke minimum dan tetap pada kapasitas yang sama atau lebih tinggi dari instance penulis, maka periksa tingkat prioritas instance pembaca. Aurora Serverless v2 Instans DB pembaca di tingkat 0 atau 1 disimpan pada kapasitas minimum setidaknya setinggi instans DB penulis. Ubah tingkat prioritas pembaca menjadi 2 atau lebih tinggi agar dinaikkan dan diturunkan skalanya secara independen dari penulis. Untuk informasi selengkapnya, lihat Memilih tingkat promosi untuk Aurora Serverless v2 pembaca.

• Tetapkan parameter basis data apa pun yang memengaruhi ukuran memori bersama ke nilai default-nya. Mengatur nilai yang lebih tinggi dari nilai default akan meningkatkan kebutuhan memori bersama dan mencegah basis data menurunkan skalanya ke kapasitas minimum. Contohnya adalah max_connections dan max_locks_per_transaction.

  catatan

  Memperbarui parameter memori bersama memerlukan pengaktifan ulang basis data agar perubahan diterapkan.

• Beban kerja basis data yang berat dapat meningkatkan penggunaan sumber daya.

• Volume basis data yang besar dapat meningkatkan penggunaan sumber daya.

  Amazon Aurora menggunakan memori dan sumber daya CPU untuk manajemen klaster DB. Aurora membutuhkan lebih banyak CPU dan memori untuk mengelola klaster DB dengan volume basis data yang lebih besar. Jika kapasitas minimum klaster Anda kurang dari minimum yang diperlukan untuk pengelolaan klaster, klaster Anda tidak akan menurunkan kapasitas minimum.

• Proses latar belakang, seperti purging, juga dapat meningkatkan penggunaan sumber daya.

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.