Penskalaan penyimpanan Penskalaan instans Penskalaan baca Mengelola koneksi Mengelola rencana eksekusi kueri

Mengelola performa dan penskalaan untuk klaster DB Aurora

Anda dapat menggunakan opsi berikut untuk mengelola performa dan penskalaan untuk klaster DB dan instans DB Aurora:

Topik

Penskalaan penyimpanan
Penskalaan instans
Penskalaan baca
Mengelola koneksi
Mengelola rencana eksekusi kueri

Penskalaan penyimpanan

Penyimpanan Aurora secara otomatis diskalakan dengan data dalam volume klaster Anda. Seiring pertumbuhan data Anda, penyimpanan volume cluster Anda bertambah tergantung pada versi mesin DB. Untuk informasi tentang ukuran volume cluster Aurora maksimum untuk setiap versi mesin, lihat. Batas ukuran Amazon Aurora Untuk mempelajari data yang termasuk dalam volume klaster, lihat Penyimpanan Amazon Aurora. Untuk detail tentang ukuran maksimum untuk versi tertentu, lihat Batas ukuran Amazon Aurora.

Ukuran volume klaster Anda dievaluasi setiap jam untuk menentukan biaya penyimpanan Anda. Untuk informasi harga, lihat halaman Harga Aurora.

Meskipun volume klaster Aurora dapat menaikkan skala ukurannya menjadi banyak tebibyte, Anda hanya dikenai biaya untuk ruang yang Anda gunakan dalam volume. Mekanisme untuk menentukan ruang penyimpanan yang ditagih bergantung pada versi klaster Aurora Anda.

Ketika data Aurora dihapus dari volume klaster, keseluruhan ruang yang ditagih berkurang sebesar jumlah yang sebanding. Perilaku pengubahan ukuran dinamis ini terjadi saat ruang tabel dasar dihapus atau disusun ulang agar membutuhkan lebih sedikit ruang. Dengan demikian, Anda dapat mengurangi biaya penyimpanan dengan menghapus tabel dan basis data yang tidak lagi Anda butuhkan. Pengubahan ukuran dinamis berlaku untuk versi Aurora tertentu. Berikut adalah versi Aurora yang memungkinkan volume klaster berubah ukurannya secara dinamis saat Anda menghapus data:

Mesin basis data	Versi dengan pengubahan ukuran dinamis
Aurora MySQL	Versi 3 (kompatibel dengan MySQL 8.0): semua versi didukung Versi 2 (kompatibel dengan MySQL 5.7): 2.11 dan lebih tinggi
Aurora PostgreSQL	Versi yang Didukung
Aurora Serverless v2	Versi yang Didukung
Aurora Serverless v1	Tidak tersedia

Dalam versi Aurora yang lebih rendah daripada yang ada di daftar sebelumnya, volume cluster dapat menggunakan kembali ruang yang dibebaskan saat Anda menghapus data, tetapi volume itu sendiri tidak pernah berkurang ukurannya.

Pengubahan ukuran dinamis berlaku untuk operasi yang secara fisik menghapus atau mengubah ukuran ruang tabel dalam volume klaster. Dengan demikian, hal ini berlaku untuk pernyataan SQL seperti DROP TABLE, DROP DATABASE, TRUNCATE TABLE, dan ALTER TABLE ... DROP PARTITION. Hal ini tidak berlaku untuk penghapusan baris menggunakan pernyataan DELETE. Jika Anda menghapus sejumlah besar baris dari tabel, Anda dapat menjalankan pernyataan OPTIMIZE TABLE Aurora MySQL atau menggunakan ekstensi pg_repack Aurora PostgreSQL setelahnya untuk menyusun ulang tabel dan mengubah ukuran volume klaster secara dinamis.

Untuk Aurora MySQL, pertimbangan berikut berlaku:

Setelah Anda memutakhirkan cluster DB Anda ke versi mesin DB yang mendukung pengubahan ukuran dinamis, dan ketika fitur diaktifkan secara spesifik AWS Region, ruang apa pun yang kemudian dibebaskan oleh pernyataan SQL tertentu, sepertiDROP TABLE, dapat direklamasi kembali.

Jika fitur dinonaktifkan secara eksplisit pada suatu fitur tertentu AWS Region, ruang mungkin hanya dapat digunakan kembali—dan tidak dapat direklamasi—bahkan pada versi yang mendukung pengubahan ukuran dinamis.

Fitur ini diaktifkan untuk versi mesin DB tertentu (1.23.0—1.23.4, 2.09.0—2.09.3, dan 2.10.0) antara November 2020 dan Maret 2022, dan diaktifkan secara default pada versi berikutnya.
Sebuah tabel disimpan secara internal dalam satu atau lebih fragmen yang berdekatan dengan berbagai ukuran. Saat menjalankan TRUNCATE TABLE operasi, ruang yang sesuai dengan fragmen pertama dapat digunakan kembali dan tidak dapat direklamasi. Fragmen lainnya dapat direklamasi. Selama DROP TABLE operasi, ruang yang sesuai dengan seluruh tablespace dapat direklamasi kembali.
innodb_file_per_tableParameter mempengaruhi bagaimana penyimpanan tabel diatur. Jika tabelnya adalah bagian dari ruang tabel sistem, menghapus tabel tidak akan mengurangi ukuran ruang tabel sistem. Jadi, pastikan untuk mengatur innodb_file_per_table ke 1 untuk klaster DB Aurora MySQL agar mengambil keuntungan penuh dari pengubahan ukuran dinamis.
Di versi 2.11 dan yang lebih tinggi, ruang meja sementara InnoDB dijatuhkan dan dibuat ulang saat restart. Hal ini akan melepaskan ruang yang ditempati oleh ruang tabel sementara ke sistem, lalu volume klaster akan diubah ukurannya. Untuk memanfaatkan sepenuhnya fitur pengubahan ukuran dinamis, kami sarankan Anda meningkatkan cluster DB Anda ke versi 2.11 atau lebih tinggi.

catatan

Fitur pengubahan ukuran dinamis tidak segera merebut kembali ruang saat tabel di ruang tabel dijatuhkan, tetapi secara bertahap dengan kecepatan sekitar 10 TB per hari. Spasi di tablespace sistem tidak direklamasi, karena tablespace sistem tidak pernah dihapus. Ruang kosong yang tidak diklaim ulang di ruang tabel akan digunakan kembali saat operasi membutuhkan ruang di ruang tabel tersebut. Fitur pengubahan ukuran dinamis dapat mengklaim kembali ruang penyimpanan hanya ketika klasternya dalam keadaan tersedia.

Anda dapat memeriksa berapa banyak ruang penyimpanan yang digunakan klaster dengan memantau metrik VolumeBytesUsed pada CloudWatch. Untuk informasi selengkapnya tentang penagihan penyimpanan, lihat Cara penyimpanan data Aurora ditagih.

Di dalam AWS Management Console, Anda dapat melihat gambar ini dalam bagan dengan melihat Monitoring tab pada halaman detail untuk cluster.

Dengan AWS CLI, Anda dapat menjalankan perintah yang mirip dengan contoh Linux berikut. Ganti contoh ini dengan nilai Anda sendiri untuk waktu mulai dan berakhir serta nama klaster.


aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '6 hours ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" \
  --statistics Average Maximum Minimum \
  --dimensions Name=DBClusterIdentifier,Value=my_cluster_identifier

Perintah tersebut menghasilkan output seperti yang berikut ini.


{
    "Label": "VolumeBytesUsed",
    "Datapoints": [
        {
            "Timestamp": "2020-08-04T21:25:00+00:00",
            "Average": 182871982080.0,
            "Minimum": 182871982080.0,
            "Maximum": 182871982080.0,
            "Unit": "Bytes"
        }
    ]
}

Contoh berikut menunjukkan bagaimana Anda dapat melacak penggunaan penyimpanan untuk cluster Aurora dari waktu ke waktu menggunakan AWS CLI perintah pada sistem Linux. Parameter --start-time dan --end-time menentukan interval waktu keseluruhan sebagai satu hari. Parameter --period meminta pengukuran pada interval satu jam. Tidak masuk akal untuk memilih nilai --period yang kecil karena metrik dikumpulkan dalam interval dan tidak terus-menerus. Selain itu, operasi penyimpanan Aurora terkadang berlanjut selama beberapa waktu di latar belakang setelah pernyataan SQL yang relevan selesai.

Contoh pertama menghasilkan output dalam format default JSON. Titik data dihasilkan dalam urutan arbitrer, tidak diurutkan berdasarkan stempel waktu. Anda dapat mengimpor data JSON ini ke alat bagan untuk melakukan pengurutan dan visualisasi.


$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id
{
    "Label": "VolumeBytesUsed",
    "Datapoints": [
        {
            "Timestamp": "2020-08-04T19:40:00+00:00",
            "Maximum": 182872522752.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-05T00:40:00+00:00",
            "Maximum": 198573719552.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-05T05:40:00+00:00",
            "Maximum": 206827454464.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-04T17:40:00+00:00",
            "Maximum": 182872522752.0,
            "Unit": "Bytes"
        },
... output omitted ...

Contoh ini menghasilkan data yang sama seperti sebelumnya. Parameter --output merepresentasikan data dalam format teks biasa yang ringkas. Perintah aws cloudwatch mengirimkan output ke perintah sort. Parameter -k dari perintah sort mengurutkan output berdasarkan bidang ketiga, yang merupakan stempel waktu dalam format Waktu Universal Terkoordinasi (UTC).


$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id \
  --output text | sort -k 3
VolumeBytesUsed
DATAPOINTS  182872522752.0  2020-08-04T17:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T18:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T19:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T20:41:00+00:00 Bytes
DATAPOINTS  187667791872.0  2020-08-04T21:41:00+00:00 Bytes
DATAPOINTS  190981029888.0  2020-08-04T22:41:00+00:00 Bytes
DATAPOINTS  195587244032.0  2020-08-04T23:41:00+00:00 Bytes
DATAPOINTS  201048915968.0  2020-08-05T00:41:00+00:00 Bytes
DATAPOINTS  205368492032.0  2020-08-05T01:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T02:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T03:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T04:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T05:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T06:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T07:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T08:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T09:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T10:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T11:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T12:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T13:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T14:41:00+00:00 Bytes
DATAPOINTS  206833664000.0  2020-08-05T15:41:00+00:00 Bytes
DATAPOINTS  206833664000.0  2020-08-05T16:41:00+00:00 Bytes

Output yang diurutkan menunjukkan berapa banyak penyimpanan yang digunakan pada awal dan akhir periode pemantauan. Anda juga dapat menemukan titik selama periode tersebut saat Aurora mengalokasikan lebih banyak penyimpanan untuk klaster. Contoh berikut menggunakan perintah Linux untuk memformat ulang nilai VolumeBytesUsed awal dan akhir sebagai gigabyte (GB) dan gibibyte (GiB). Gigabyte merepresentasikan unit yang diukur dalam pangkat 10 dan umumnya digunakan dalam pembahasan penyimpanan untuk hard drive rotasional. Gibibyte merepresentasikan unit yang diukur dalam pangkat 2. Pengukuran dan batas penyimpanan Aurora biasanya dinyatakan dalam unit pangkat 2, seperti gibibyte dan tebibyte.


$ GiB=$((1024*1024*1024))
$ GB=$((1000*1000*1000))
$ echo "Start: $((182872522752/$GiB)) GiB, End: $((206833664000/$GiB)) GiB"
Start: 170 GiB, End: 192 GiB
$ echo "Start: $((182872522752/$GB)) GB, End: $((206833664000/$GB)) GB"
Start: 182 GB, End: 206 GB

Metrik VolumeBytesUsed memberi tahu Anda berapa banyak penyimpanan dalam klaster tersebut yang menimbulkan biaya. Jadi, jika memungkinkan sebaiknya minimalkan angka ini. Namun, metrik ini tidak mencakup beberapa penyimpanan yang digunakan Aurora secara internal di klaster dan tidak dikenai biaya. Jika klaster Anda mendekati batas penyimpanan dan mungkin kehabisan ruang, sebaiknya pantau metrik AuroraVolumeBytesLeftTotal dan coba maksimalkan angka tersebut. Contoh berikut menjalankan perhitungan yang sama seperti yang sebelumnya, tetapi untuk AuroraVolumeBytesLeftTotal, bukan VolumeBytesUsed.


$ aws cloudwatch get-metric-statistics --metric-name "AuroraVolumeBytesLeftTotal" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_old_cluster_id \
  --output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS      140530528288768.0       2023-02-23T19:25:00+00:00       Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((69797067915264 / $TB)) TB remaining for this cluster"
69 TB remaining for this cluster
$ echo "$((69797067915264 / $TiB)) TiB remaining for this cluster"
63 TiB remaining for this cluster

Untuk klaster yang menjalankan Aurora MySQL versi 2.09 atau yang lebih tinggi, atau Aurora PostgreSQL, ukuran kosong yang dilaporkan meningkat sebesar VolumeBytesUsed saat data ditambahkan dan berkurang saat data dihapus. Contoh berikut menunjukkan cara melakukannya. Laporan ini menunjukkan ukuran penyimpanan maksimum dan minimum untuk klaster dengan interval 15 menit saat tabel dengan data sementara dibuat dan dihapus. Laporan ini mencantumkan nilai maksimum sebelum nilai minimum. Jadi, untuk memahami bagaimana penggunaan penyimpanan berubah dalam interval 15 menit, tafsirkan angkanya dari kanan ke kiri.


$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
  --namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id
  --output text | sort -k 4
VolumeBytesUsed
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T20:49:00+00:00	Bytes
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T21:19:00+00:00	Bytes
DATAPOINTS	22022176768.0 14545305600.0	2020-08-05T21:49:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:19:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:49:00+00:00	Bytes
DATAPOINTS	22022176768.0 15614263296.0	2020-08-05T23:19:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-05T23:49:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-06T00:19:00+00:00	Bytes

Contoh berikut menunjukkan bagaimana untuk cluster yang menjalankan versi kompatibel Aurora MySQL atau Aurora PostgreSQL, ukuran bebas yang dilaporkan oleh mencerminkan batas ukuran 256-Tib. AuroraVolumeBytesLeftTotal Untuk informasi selengkapnya tentang versi yang kompatibel, lihatBatas ukuran Amazon Aurora.


$ aws cloudwatch get-metric-statistics --region us-east-1 --metric-name "AuroraVolumeBytesLeftTotal" \
  --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBClusterIdentifier,Value=pq-57 \
  --output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS	140515818864640.0	2020-08-05T20:56:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-05T21:26:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-05T21:56:00+00:00	Count
DATAPOINTS	140514866757632.0	2020-08-05T22:26:00+00:00	Count
DATAPOINTS	140511020580864.0	2020-08-05T22:56:00+00:00	Count
DATAPOINTS	140503168843776.0	2020-08-05T23:26:00+00:00	Count
DATAPOINTS	140503168843776.0	2020-08-05T23:56:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-06T00:26:00+00:00	Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((140515818864640 / $TB)) TB remaining for this cluster"
140 TB remaining for this cluster
$ echo "$((140515818864640 / $TiB)) TiB remaining for this cluster"
256 TiB remaining for this cluster

Penskalaan instans

Anda dapat menskalakan klaster DB Aurora sesuai kebutuhan dengan memodifikasi kelas instans DB untuk setiap instans DB dalam klaster DB ini. Aurora mendukung beberapa kelas instans DB yang dioptimalkan untuk Aurora, bergantung pada kompatibilitas mesin basis data.

Mesin basis data	Penskalaan instans
Amazon Aurora MySQL	Lihat Penskalaan instans DB Aurora MySQL
Amazon Aurora PostgreSQL	Lihat Penskalaan instans DB Aurora PostgreSQL

Penskalaan baca

Anda dapat melakukan penskalaan baca untuk klaster DB Aurora dengan membuat hingga 15 Replika Aurora dalam klaster DB. Setiap Replika Aurora menghasilkan data yang sama dari volume klaster dengan sedikit lag replika—biasanya kurang dari 100 milidetik setelah instans primer menulis pembaruan. Saat lalu lintas baca meningkat, Anda dapat membuat Replika Aurora tambahan dan terhubung langsung ke replika ini untuk mendistribusikan beban baca untuk klaster DB Anda. Replika Aurora tidak harus berasal dari kelas instans DB yang sama dengan instans primer.

Untuk informasi tentang menambahkan Replika Aurora ke klaster DB, lihat Menambahkan Replika Aurora ke klaster DB.

Mengelola koneksi

Jumlah maksimum koneksi yang diizinkan untuk instans DB Aurora ditentukan oleh parameter max_connections dalam grup parameter tingkat instans untuk instans DB. Nilai default parameter tersebut bervariasi bergantung pada kelas instans DB yang digunakan untuk instans DB dan kompatibilitas mesin basis data.

Mesin basis data	Nilai default max_connections
Amazon Aurora MySQL	Lihat Koneksi maksimum ke instans DB Aurora MySQL
Amazon Aurora PostgreSQL	Lihat Koneksi maksimum ke instans DB Aurora PostgreSQL

Tip

Jika aplikasi Anda sering membuka dan menutup koneksi, atau membiarkan sejumlah besar koneksi yang lama aktif tetap terbuka, kami menyarankan agar Anda menggunakan Proksi Amazon RDS. Proksi RDS adalah proksi basis data yang sepenuhnya terkelola dengan ketersediaan tinggi yang menggunakan pooling koneksi untuk berbagi koneksi basis data dengan aman dan efisien. Untuk mempelajari tentang RDS, lihat Proksi Amazon RDS untuk Aurora.

Mengelola rencana eksekusi kueri

Jika Anda menggunakan manajemen rencana kueri untuk Aurora PostgreSQL, Anda dapat mengontrol rencana mana yang dijalankan pengoptimisasi. Untuk informasi selengkapnya, lihat Mengelola rencana eksekusi kueri untuk Aurora PostgreSQL.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

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

Konvensi Dokumen

Menghapus kebijakan penskalaan otomatis

Mengkloning volume untuk klaster DB Aurora