Mengelola performa dan penskalaan untuk klaster DB Aurora - Amazon Aurora
Penskalaan penyimpananPenskalaan instansPenskalaan bacaMengelola koneksiMengelola rencana eksekusi kueri

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

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:

Penskalaan penyimpanan

Penyimpanan Aurora secara otomatis diskalakan dengan data dalam volume klaster Anda. Seiring pertumbuhan data Anda, penyimpanan volume klaster Anda dapat diperluas hingga maksimum 128 tebibyte (TiB) atau 64 TiB. Ukuran maksimum ini bergantung pada versi mesin DB. 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 Saya SQL

    • Versi 3 (kompatibel dengan My SQL 8.0): semua versi yang didukung

    • Versi 2 (kompatibel dengan My SQL 5.7): 2.11 dan lebih tinggi
    Aurora Postgre SQL Versi yang Didukung
    Aurora Serverless v2 Versi yang Didukung
    Aurora Serverless v1 Versi yang Didukung

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

  • Fitur ini sedang digunakan secara bertahap ke AWS Wilayah di mana Aurora tersedia. Tergantung Wilayah tempat klaster Anda berada, fitur ini mungkin belum tersedia.

Pengubahan ukuran dinamis berlaku untuk operasi yang secara fisik menghapus atau mengubah ukuran ruang tabel dalam volume klaster. Dengan demikian, ini berlaku untuk SQL pernyataan sepertiDROP TABLE,DROP DATABASE,TRUNCATE TABLE, danALTER TABLE ... DROP PARTITION. Hal ini tidak berlaku untuk penghapusan baris menggunakan pernyataan DELETE. Jika Anda menghapus sejumlah besar baris dari tabel, Anda dapat menjalankan SQL OPTIMIZE TABLE pernyataan Aurora My atau menggunakan SQL pg_repack ekstensi Aurora Postgre sesudahnya untuk mengatur ulang tabel dan mengubah ukuran volume cluster secara dinamis.

Untuk Aurora MySQL, pertimbangan berikut berlaku:

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

    Jika fitur dinonaktifkan secara eksplisit pada suatu fitur tertentu Wilayah AWS, 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 ke 1 innodb_file_per_table untuk cluster Aurora My SQL DB untuk memanfaatkan sepenuhnya 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 kluster dengan memantau VolumeBytesUsed metrik 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 SQL pernyataan yang relevan selesai.

Contoh pertama mengembalikan output dalam JSON format default. Titik data dihasilkan dalam urutan arbitrer, tidak diurutkan berdasarkan stempel waktu. Anda dapat mengimpor JSON data ini ke alat charting untuk melakukan penyortiran 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. -kParameter sort perintah mengurutkan output berdasarkan bidang ketiga, yang merupakan stempel waktu dalam format Universal Coordinated Time ()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 My SQL versi 2.09 atau lebih tinggi, atau Aurora PostgreSQL, ukuran bebas yang dilaporkan VolumeBytesUsed meningkat 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 dengan cluster yang menjalankan Aurora My SQL versi 2.09 atau lebih tinggi, atau Aurora PostgreSQL, ukuran bebas yang dilaporkan oleh mencerminkan batas ukuran 128-TiB. AuroraVolumeBytesLeftTotal

$ 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"
127 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.

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 Saya SQL

Lihat Koneksi maksimum ke instans Aurora My DB SQL

Amazon Aurora Postgre SQL

Lihat Koneksi maksimum ke instans Aurora SQL Postgre DB
Tip

Jika aplikasi Anda sering membuka dan menutup koneksi, atau membiarkan sejumlah besar koneksi berumur panjang tetap terbuka, kami sarankan Anda menggunakan Amazon RDS Proxy. RDSProxy adalah proxy database yang dikelola sepenuhnya dan sangat tersedia yang menggunakan penyatuan koneksi untuk berbagi koneksi database dengan aman dan efisien. Untuk mempelajari lebih lanjut tentang RDS Proxy, lihatMenggunakan Amazon RDS Proxy untuk Aurora.

Mengelola rencana eksekusi kueri

Jika Anda menggunakan manajemen rencana kueri untuk Aurora PostgreSQL, Anda mendapatkan kendali atas rencana mana yang dijalankan pengoptimal. Untuk informasi selengkapnya, lihat Mengelola rencana eksekusi kueri untuk Aurora Postgre SQL.