Setelah membuat kluster serverless, konfigurasikan kebijakan penskalaan resource untuk mengontrol cara kluster melakukan scale-up dan scale-down. Gunakan kebijakan lifecycle untuk menyediakan resource sebelum periode puncak yang dapat diprediksi—seperti promosi atau lonjakan lalu lintas—dan lakukan penskalaan kembali selama jam sepi guna melepas resource idle.
Batasan
Fitur-fitur berikut tidak didukung pada kluster serverless:
Manually scaling up or down storage capacity (Enterprise Edition)
Manually scaling down storage capacity (Standard Edition)
Global Database Network (GDN) didukung, tetapi dengan batasan berikut:
Automatic start and stop tidak dapat diaktifkan pada semua kluster serverless dalam GDN.
Setiap kluster serverless dalam GDN harus memiliki setidaknya satu node read-only jika kluster menjalankan:
PolarDB for MySQL 8.0.1 dengan versi revisi 8.0.1.1.42 atau lebih baru
PolarDB for MySQL 8.0.2 dengan versi revisi 8.0.2.2.23 atau lebih baru
Operasi berikut didukung: menambah atau menghapus node read-only, meningkatkan atau menurunkan spesifikasi kluster PolarDB secara manual, melakukan Peningkatan sementara pada kluster, dan melakukan penskalaan otomatis untuk kluster yang tidak mendukung arsitektur tanpa server.
Fitur In-Memory Column Index (IMCI) didukung untuk kluster serverless yang memiliki setidaknya satu node read-only. Sebelum menambahkan node penyimpanan kolom read-only, atur Minimum Read-only Nodes menjadi 1.
Catatan penggunaan
Jumlah maksimum koneksi ke kluster serverless adalah 100.000, dan IOPS maksimum adalah 84.000.
PolarDB Capacity Unit (PCU) adalah unit penagihan dan penskalaan untuk kluster serverless. Satu PCU setara dengan sekitar 1 core CPU dan 2 GB memori. Jumlah PCU tiap node diskalakan secara dinamis dalam rentang yang dikonfigurasi, dengan granularitas minimum 0,5 PCU.
Cara kerja penskalaan
PolarDB memantau utilisasi CPU, penggunaan memori, dan metrik kernel lainnya dari node primary dan node read-only. Scale-up dan scale-out dipicu ketika ambang batas terlampaui; scale-down terjadi ketika utilisasi turun di bawah ambang batas selama periode berkelanjutan.
Pemicu scale-up dan scale-out
Scale-up (skalabilitas vertikal pada node tunggal) dipicu selama siklus pemantauan ketika salah satu kondisi berikut terpenuhi:
Utilisasi CPU sebuah node melebihi ambang batas scale-up (default: 80%, atau nilai kustom).
Penggunaan memori sebuah node melebihi 90%.
Spesifikasi node read-only kurang dari separuh spesifikasi node primary. Misalnya, jika node read-only berada di 4 PCU dan node primary di 10 PCU, maka node read-only akan diskalakan naik hingga minimal 5 PCU.
Scale-out (menambahkan node read-only) dipicu ketika node read-only telah diskalakan naik ke spesifikasi maksimumnya namun utilisasi CPU masih melebihi ambang batas scale-up.
Pemicu scale-down
Scale-down dipicu ketika utilisasi CPU turun di bawah ambang batas scale-down (default: 50%, atau nilai kustom) dan penggunaan memori turun di bawah 80%.
Metrik yang memicu penskalaan bervariasi berdasarkan konfigurasi parameter kluster dan pengaturan serverless. Anda dapat menyesuaikan ambang batas penskalaan CPU; ambang batas untuk metrik lain bersifat tetap.
Ketika workload melonjak tiba-tiba, node diskalakan naik secara bertahap alih-alih langsung melompat ke spesifikasi target dalam satu langkah. Ukuran langkah minimum adalah 0,5 PCU; langkah-langkah berikutnya meningkat berdasarkan jumlah PCU saat ini untuk mengejar permintaan.
Atur aturan notifikasi di Performance Monitoring di Konsol PolarDB untuk menerima notifikasi saat scale-down dipicu. Untuk detailnya, lihat Create an alert rule.
Konfigurasi parameter serverless
Masuk ke PolarDB console.
Di panel navigasi sebelah kiri, klik Clusters.
Di pojok kiri atas, pilih wilayah.
Klik ID kluster untuk membuka halaman Basic Information.
Di bagian Database Nodes, klik Serverless Configuration.
Konfigurasi parameter saat ini
Pada kotak dialog Configure Serverless-related Parameters, klik Edit di sebelah kanan Current Parameters.
Rentang resource node
| Parameter | Deskripsi | Nilai valid |
|---|---|---|
| Minimum Resources for Single Node | PCU minimum per node. Setiap node diskalakan turun hingga batas ini saat idle. | 0,25–32 PCU |
| Maximum Resources for Single Node | PCU maksimum per node. Setiap node tidak boleh melebihi batas ini dalam kondisi workload apa pun. | 1–32 PCU |
Memilih nilai PCU minimum Anda
Nilai minimum yang lebih rendah mengurangi biaya idle tetapi dapat memperlambat proses scale-up ketika workload melonjak tiba-tiba, karena PolarDB menskalakan naik secara proporsional dari jumlah PCU saat ini. Pertimbangkan nilai minimum yang lebih tinggi jika:
Workload Anda melonjak secara tak terduga dan latensi rendah pada awal lonjakan sangat penting.
Aplikasi Anda mendapat manfaat dari cache buffer yang hangat, yang memerlukan cukup memori setiap saat.
Jika Anda melakukan migrasi dari instans dengan spesifikasi tetap, gunakan rasio memori sebagai referensi: satu PCU setara dengan sekitar 2 GB memori. Misalnya, jika instans sebelumnya memiliki memori 8 GB, mulailah dengan minimum 4 PCU.
Memilih nilai PCU maksimum Anda
Nilai maksimum yang lebih tinggi memungkinkan kluster menangani workload yang lebih besar tetapi meningkatkan batas biaya. Pertimbangkan hal berikut:
Tinjau puncak historis utilisasi CPU dan memori untuk memperkirakan batas atas.
Jika lonjakan secara konsisten mencapai maksimum saat ini, tingkatkan nilainya.
Pantau penggunaan setelah penerapan menggunakan Performance Monitoring dan sesuaikan berdasarkan puncak yang teramati.
Jika Minimum Resources for Single Node adalah 2 PCU dan Maximum Resources for Single Node adalah 16 PCU, maka node secara default berada di 2 PCU (2 core CPU, 4 GB memori) dan dapat diskalakan naik hingga 16 PCU (16 core CPU, 32 GB memori) saat beban meningkat.
Rentang node read-only
| Parameter | Deskripsi | Nilai valid |
|---|---|---|
| Minimum Read-Only Nodes | Jumlah minimum node read-only yang dipertahankan setiap saat. | 0–15 |
| Maximum Read-only Nodes | Jumlah maksimum node read-only yang dapat ditambahkan melalui scale-out. | 0–15 |
| Read-only Column Store Nodes | Jumlah maksimum node penyimpanan kolom read-only yang dapat ditambahkan (untuk IMCI). | 0–15 |
Jumlah node read-only diskalakan secara otomatis dalam rentang yang dikonfigurasi. Untuk kondisi pemicunya, lihat Scale-up and scale-out triggers.
Atur Minimum Read-Only Nodes menjadi 1 untuk menjaga ketersediaan tinggi.
Sebelum menambahkan node penyimpanan kolom read-only, atur Minimum Read-Only Nodes menjadi minimal 1. Untuk informasi lebih lanjut, lihat IMCIs.
No-activity suspension
Jika diaktifkan, kluster secara otomatis ditangguhkan jika tidak ada koneksi layanan dalam periode deteksi. Biaya penyimpanan tetap berlaku selama penangguhan; kluster akan segera dimulai ulang ketika ada koneksi masuk.
Automatic start and stop tidak dapat diaktifkan secara bersamaan pada semua kluster serverless dalam GDN. Jika kluster Anda termasuk dalam GDN, pastikan batasan ini sebelum mengaktifkan no-activity suspension.
| Parameter | Deskripsi | Nilai valid |
|---|---|---|
| Enable No-activity Suspension | Secara otomatis menangguhkan kluster setelah periode tidak aktif yang dikonfigurasi. | Enabled / Disabled |
| Detection Period for No-activity Suspension | Durasi tidak aktif sebelum kluster ditangguhkan. | Kelipatan 5 menit, dari 5 menit hingga 24 jam |
Pengaturan lanjutan
| Parameter | Deskripsi | Nilai valid |
|---|---|---|
| Scan Interval | Dalam mode Sensitive, kluster mendeteksi dan merespons perubahan workload lebih cepat, sehingga mengurangi jendela observasi dan periode eksekusi. Gunakan mode Sensitive untuk workload dengan fluktuasi beban instan seperti lonjakan CPU. Mode Sensitive memicu penskalaan lebih sering. | Standard / Sensitive |
| Maximum CPU Resources for Elastic Upgrade | Ambang batas utilisasi CPU yang memicu scale-up. | 40%–100% |
| Minimum CPU Resources for Elastic Upgrade | Ambang batas utilisasi CPU yang memicu scale-down. | 10%–70% |
Ambang batas CPU maksimum harus sama dengan atau lebih tinggi daripada ambang batas CPU minimum, dan selisih antara keduanya harus minimal 30 PCU.
Atur kebijakan lifecycle
Buat kebijakan lifecycle untuk secara otomatis menyesuaikan parameter serverless pada waktu tertentu—harian, mingguan, atau bulanan. Hal ini memungkinkan Anda menyediakan resource sebelum periode puncak dan melakukan penskalaan kembali setelahnya tanpa intervensi manual.
Menghapus kebijakan berulang tidak membatalkan tugas yang sedang berjalan di bawah kebijakan tersebut. Hanya tugas yang belum dimulai yang dihapus.
Jika Anda menonaktifkan fitur serverless, semua kebijakan berulang dan tugas terjadwal akan dihapus.
Buat kebijakan lifecycle
Pada kotak dialog Configure Serverless-related Parameters, klik + Add Lifecycle Policy.
Atur parameter berikut:
| Parameter | Deskripsi | Nilai valid |
|---|---|---|
| Maximum Resources for Single Node | PCU maksimum selama periode aktif kebijakan. | 1–32 |
| Minimum Resources for Single Node | PCU minimum selama periode aktif kebijakan. Harus kurang dari atau sama dengan Maximum Resources for Single Node. | 1–32 |
| Maximum Read-only Nodes | Node read-only maksimum selama periode aktif. | 0–15 |
| Minimum Read-Only Nodes | Node read-only minimum selama periode aktif. Harus kurang dari atau sama dengan Maximum Read-only Nodes. | 0–15 |
| Read-only Column Store Nodes | Node penyimpanan kolom read-only maksimum selama periode aktif. | 0–15 |
| Start/End Time | Periode validitas kebijakan berulang. | — |
| Policy Scheduling | Frekuensi kebijakan dijalankan. Opsi: Month, Weekly, atau Daily. Untuk Month, tentukan arah penghitungan (Positive dari hari pertama atau Last dari hari terakhir) dan hari-hari (dipisahkan koma, misalnya, 1,3,5). Untuk Weekly, tentukan hari dalam minggu dan waktu. Untuk Daily, tentukan waktu. | — |
Setelah kebijakan lifecycle berlaku, parameter yang disesuaikan tetap berlaku—tidak secara otomatis dikembalikan ketika periode kebijakan berakhir. Buat kebijakan lifecycle terpisah untuk mengembalikan parameter pada waktu yang diinginkan. Lihat contoh di bawah untuk detailnya.
Lihat tugas terjadwal
Setelah membuat kebijakan berulang, tugas terjadwal dibuat secara otomatis. Lihat menggunakan salah satu metode berikut:
Di halaman Basic Information kluster, periksa bagian Pending Scheduled and Failed Tasks.
Di Konsol PolarDB, buka Task Management > Scheduled Tasks.
Contoh
Untuk melakukan scale-up 5 PCU pada pukul 09.30 dan scale-down 1 PCU pada pukul 22.00 setiap hari kerja (Senin hingga Jumat) dari 1 Agustus hingga 30 September, buat dua kebijakan lifecycle seperti yang ditunjukkan di bawah.
 |  |
|---|