Azure Database for MySQL – Tingkatan layanan Server Fleksibel
BERLAKU UNTUK:
Azure Database for MySQL - Server Fleksibel
Anda dapat membuat instans server fleksibel Azure Database for MySQL di salah satu dari tiga tingkat layanan yang berbeda: Burstable, General Purpose, dan Business Critical. Tingkat layanan dibedakan oleh SKU mesin virtual dasar yang digunakan, yaitu seri B, seri D, dan seri E. Pilihan tingkat komputasi dan ukuran menentukan memori dan vCore yang tersedia di server. Teknologi penyimpanan yang sama digunakan di semua tingkat layanan. Semua sumber daya disediakan di tingkat instans server fleksibel Azure Database for MySQL. Server dapat memiliki satu atau banyak database.
| Sumber Daya / Tingkat | Mudah meledak | Tujuan Umum | Kritis Bisnis |
|---|---|---|---|
| Seri VM | Seri B | SeriDadsv5 seri Ddsv4 | Seri Eadsv5 seri*/Edsv4/Edsv5 |
| vCore | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Memori per vCore | Variabel | 4 GiB | 8 GiB ** |
| Ukuran penyimpanan | 20 GiB hingga 16 TiB | 20 GiB hingga 16 TiB | 20 GiB hingga 16 TiB |
| Periode retensi cadangan database | 1 hingga 35 hari | 1 hingga 35 hari | 1 hingga 35 hari |
** Dengan pengecualian masing-masing 64.80, dan 96 vCore, yang memiliki memori 504 GiB, 504 GiB, dan 672 GiB.
* Komputasi Ev5 memberikan performa terbaik di antara seri VM lainnya dalam hal QPS dan latensi. Pelajari selengkapnya tentang performa dan ketersediaan wilayah komputasi Ev5 dari sini.
Untuk memilih tingkat komputasi, gunakan tabel berikut ini sebagai titik awal.
| Tingkat komputasi | Beban kerja target |
|---|---|
| Mudah meledak | Tingkat terbaik untuk beban kerja yang tidak memerlukan CPU penuh terus menerus. |
| Tujuan Umum | Sebagian besar beban kerja bisnis yang memerlukan komputasi dan memori seimbang dengan throughput I/O yang dapat diskalakan. Contohnya termasuk server untuk menghosting aplikasi web dan seluler serta aplikasi perusahaan lainnya. |
| Kritis Bisnis | Beban kerja database dengan performa tinggi yang memerlukan performa dalam memori untuk pemrosesan transaksi yang lebih cepat dan konkurensi yang lebih tinggi. Ini dapat mencakup server untuk pemrosesan data real-time, dan aplikasi transaksional atau analitik dengan performa tinggi. |
Setelah Anda membuat server, tingkat komputasi, ukuran komputasi, dan ukuran penyimpanan dapat berubah. Penskalaan komputasi memerlukan mulai ulang dan memakan waktu antara 60-120 detik, sementara penskalaan penyimpanan tidak memerlukan mulai ulang. Anda juga dapat menyesuaikan periode retensi cadangan secara independen untuk ditingkatkan atau diturunkan. Untuk informasi selengkapnya, lihat bagian Mengukur sumber daya.
Tingkat layanan, ukuran, dan jenis server
Sumber daya komputasi dapat dipilih berdasarkan tingkat dan ukuran. Hal ini menentukan vCore dan ukuran memori. vCore mewakili CPU logis dari perangkat keras yang mendasarinya.
Spesifikasi terperinci dari jenis server yang tersedia adalah sebagai berikut untuk Burstable:
| Ukuran komputasi | vCore | Ukuran Memori Fisik (GiB) | Ukuran Memori Total (GiB) | IOPS Maksimum yang Didukung | Koneksi Maksimal | GiB Penyimpanan Sementara (SSD) |
|---|---|---|---|---|---|---|
| Standard_B1s | 1 | 1 | 1.1 | 320 | 171 | 0 |
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17.6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35,2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52.8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5000 | 13653 | 0 |
Spesifikasi terperinci dari jenis server yang tersedia adalah sebagai berikut untuk Tujuan Umum:
| Ukuran komputasi | vCore | Ukuran Memori Fisik (GiB) | Ukuran Memori Total (GiB) | IOPS Maksimum yang Didukung | Koneksi Maksimal | GiB Penyimpanan Sementara (SSD) |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
Spesifikasi terperinci dari jenis server yang tersedia adalah sebagai berikut untuk Business Critical:
| Ukuran komputasi | vCore | Ukuran Memori Fisik (GiB) | Ukuran Memori Total (GiB) | IOPS Maksimum yang Didukung | Koneksi Maksimal | GiB Penyimpanan Sementara (SSD) |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E80ids_v4 | 80 | 504 | 693 | 72000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Manajemen memori di server fleksibel Azure Database for MySQL
Di MySQL, memori memainkan peran penting di berbagai operasi, termasuk pemrosesan dan penembolokan kueri. Server fleksibel Azure Database for MySQL mengoptimalkan alokasi memori untuk proses server MySQL (mysqld), memastikan server menerima sumber daya memori yang memadai untuk pemrosesan kueri, penembolokan, manajemen koneksi klien, dan penanganan utas yang efisien. Pelajari selengkapnya tentang cara MySQL menggunakan memori.
Ukuran Memori Fisik (GB)
Ukuran memori Fisik (GB) dalam tabel di bawah ini mewakili memori akses acak (RAM) yang tersedia dalam gigabyte (GB) di server fleksibel Azure Database for MySQL Anda.
Ukuran Memori Total (GB)
Server fleksibel Azure Database for MySQL menyediakan Ukuran Memori Total (GB). Ini mewakili total memori yang tersedia untuk server Anda, yang merupakan kombinasi memori fisik dan jumlah komponen SSD penyimpanan sementara yang ditetapkan. Tampilan terpadu ini dirancang untuk menyederhanakan manajemen sumber daya, memungkinkan Anda untuk fokus pada total memori yang tersedia untuk proses Azure MySQL Server (mysqld) Anda saja. Metrik Memory Percent (memory_percent) mewakili persentase memori yang ditempati oleh proses server Azure MySQL (mysqld). Metrik ini dihitung dari Ukuran Memori Total (GB). Misalnya, ketika metrik Memory Percent menampilkan nilai 60, itu berarti bahwa proses Azure MySQL Server Anda menggunakan 60% dari Total ukuran memori (GB) yang tersedia di server fleksibel Azure Database for MySQL Anda.
Server MySQL (mysqld)
Proses server Azure MySQL, mysqld, berfungsi sebagai mesin inti untuk operasi database. Setelah startup, ini menginisialisasi total komponen seperti kumpulan buffer InnoDB dan cache utas, menggunakan memori berdasarkan konfigurasi dan tuntutan beban kerja. Misalnya, kumpulan buffer InnoDB menyimpan data dan indeks yang sering diakses untuk meningkatkan kecepatan eksekusi kueri, sementara cache utas mengelola utas koneksi klien. Pelajari selengkapnya.
Mesin Penyimpanan InnoDB
Sebagai mesin penyimpanan default MySQL, InnoDB menggunakan memori untuk penembolokan data yang sering diakses dan mengelola struktur internal seperti kumpulan buffer innodb dan buffer log. Kumpulan buffer InnoDB menyimpan data tabel dan indeks dalam memori untuk meminimalkan I/O disk, meningkatkan performa. Parameter Ukuran Kumpulan Buffer InnoDB dihitung berdasarkan ukuran memori fisik (GB) yang tersedia di server. Pelajari selengkapnya tentang ukuran Kumpulan Buffer InnoDB yang tersedia di server fleksibel Azure Database for MySQL.
Utas
Koneksi klien dikelola melalui utas khusus yang ditangani oleh manajer koneksi. Alur ini menangani autentikasi, eksekusi kueri, dan pengambilan hasil untuk interaksi klien. Pelajari selengkapnya.
Untuk mendapatkan detail selengkapnya tentang seri komputasi yang tersedia, lihat dokumentasi Azure VM untuk Burstable (seri B), seri Ddsv4 seriGeneral Purpose Dadsv5, dan Seri Eadsv5 Business Critical Edsv4/seri Edsv5./
Batasan performa instans seri yang dapat meledak
Catatan
Untuk tingkat komputasi Burstable (seri B) jika VM dimulai/dihentikan atau dimulai ulang, kredit mungkin hilang. Untuk informasi selengkapnya, lihat Tanya Jawab Umum Burstable (Seri-B).
Tingkat komputasi yang dapat meledak dirancang untuk memberikan solusi hemat biaya untuk beban kerja yang tidak memerlukan CPU penuh berkelanjutan terus menerus. Tingkat ini sangat ideal untuk beban kerja nonproduksi, seperti lingkungan pengembangan, penahapan, atau pengujian. Fitur unik dari tingkat komputasi yang dapat meledak adalah kemampuannya untuk "meledak", yaitu, untuk menggunakan lebih dari performa CPU dasarnya menggunakan hingga 100% vCPU ketika beban kerja membutuhkannya. Hal ini dimungkinkan oleh model kredit CPU, yang memungkinkan instans seri B untuk mengakumulasi "kredit CPU" selama periode penggunaan CPU rendah. Kredit ini kemudian dapat dihabiskan selama periode penggunaan CPU tinggi, memungkinkan instans meledak di atas performa CPU dasarnya.
Namun, penting untuk dicatat bahwa setelah instans burstable menghabiskan kredit CPU-nya, instans tersebut beroperasi pada performa CPU dasarnya. Misalnya, performa CPU dasar Standard_B1ms adalah 20% yaitu, 0,2 Vcore. Jika server tingkat Burstable menjalankan beban kerja yang membutuhkan lebih banyak performa CPU daripada tingkat dasar, dan telah menghabiskan kredit CPU-nya, server mungkin mengalami keterbatasan performa dan akhirnya dapat memengaruhi berbagai operasi sistem seperti Stop/Start/Restart untuk server Anda.
Catatan
Untuk server di tingkat komputasi Burstable (seri B), seperti Standard_B1s/Standard_B1ms/Standard_B2s, ukuran memori host yang relatif lebih kecil, dapat menyebabkan crash (kehabisan memori) di bawah beban kerja berkelanjutan, bahkan jika metrik memory_percent belum mencapai 100%.
Karena pembatasan ini, server mungkin mengalami masalah konektivitas dan operasi sistem mungkin terpengaruh. Dalam situasi seperti itu, tindakan yang direkomendasikan adalah menjeda beban kerja di server untuk mengakumulasi kredit sesuai dengan model perbankan kredit seri B, atau untuk mempertimbangkan untuk menskalakan server ke tingkat yang lebih tinggi seperti tingkat Tujuan Umum atau Bisnis Kritis .
Oleh karena itu, sementara tingkat komputasi Burstable menawarkan keuntungan biaya dan fleksibilitas yang signifikan untuk jenis beban kerja tertentu, tidak disarankan untuk beban kerja produksi yang membutuhkan performa CPU yang konsisten. Tingkat Burstable tidak mendukung fungsionalitas pembuatan Replika Baca dan fitur Ketersediaan tinggi. Untuk beban kerja dan fitur tersebut, tingkat komputasi lainnya, seperti Tujuan Umum atau Kritis Bisnis lebih tepat.
Untuk informasi selengkapnya tentang model kredit CPU seri B Azure, lihat instans seri B yang dapat meledak dan model kredit CPU seri B.
Memantau kredit CPU di tingkat yang dapat meledak
Memantau saldo kredit CPU Anda sangat penting untuk mempertahankan performa optimal di tingkat komputasi burstable. Server Fleksibel Azure Database for MySQL menyediakan dua metrik utama yang terkait dengan kredit CPU. Ambang ideal untuk memicu pemberitahuan tergantung pada beban kerja dan persyaratan performa spesifik Anda.
Kredit CPU yang Digunakan: Metrik ini menunjukkan jumlah kredit CPU yang digunakan oleh instans Anda. Memantau metrik ini dapat membantu Anda memahami pola penggunaan CPU instans Anda dan mengelola performanya secara efektif.
Sisa Kredit CPU: Metrik ini menunjukkan jumlah kredit CPU yang tersisa untuk instans Anda. Mengawasi metrik ini dapat membantu Anda mencegah instans Anda menurunkan performa karena kredit CPU-nya habis. Jika metrik Sisa Kredit CPU turun di bawah tingkat tertentu (misalnya, kurang dari 30% dari total kredit yang tersedia), ini akan menunjukkan bahwa instans berisiko kelelahan kredit CPU-nya jika beban CPU saat ini berlanjut.
Untuk informasi selengkapnya, tentang cara menyiapkan pemberitahuan pada metrik, lihat panduan ini.
Penyimpanan
Penyimpanan yang Anda sediakan adalah jumlah kapasitas penyimpanan yang tersedia untuk server fleksibel Anda. Penyimpanan digunakan untuk file database, file sementara, log transaksi, dan log server MySQL. Dalam semua tingkat layanan, penyimpanan minimum yang didukung adalah 20 GiB dan maksimum adalah 16 TiB. Penyimpanan diskalakan dalam kenaikan 1-GiB dan dapat ditingkatkan skalanya setelah server dibuat.
Catatan
Penyimpanan hanya dapat ditingkatkan, tidak diturunkan.
Anda dapat memantau konsumsi penyimpanan di portal Azure (dengan Azure Monitor) menggunakan batas penyimpanan, persentase penyimpanan, dan metrik penyimpanan yang digunakan. Lihat artikel pemantauan untuk mempelajari metrik.
Mencapai batas penyimpanan
Ketika penyimpanan yang dikonsumsi di server hampir mencapai batas yang tersedia, server dimasukkan ke mode baca-saja untuk melindungi setiap tulisan yang hilang di server. Server dengan penyimpanan yang tersedia kurang dari atau sama dengan 100 GiB ditandai baca-saja jika penyimpanan gratis kurang dari 5% dari ukuran penyimpanan yang tersedia. Server dengan lebih dari penyimpanan 100 GiB yang tersedia ditandai baca hanya ketika penyimpanan gratis kurang dari 5 GiB.
Misalnya, jika Anda telah menyediakan penyimpanan 110 GiB, dan pemanfaatan aktual lebih dari 105 GiB, server tersebut ditandai baca-saja. Atau, jika Anda telah menyediakan penyimpanan 5 GiB, server tersebut ditandai baca-saja ketika penyimpanan gratis mencapai kurang dari 256 MB.
Meskipun layanan mencoba membuat server baca-saja, semua permintaan transaksi tulis baru diblokir dan transaksi aktif yang ada terus dijalankan. Ketika server diatur ke baca-saja, semua operasi dan transaksi tulis berikutnya akan gagal. Membaca kueri terus bekerja tanpa gangguan.
Untuk mengeluarkan server dari mode baca-saja, Anda harus meningkatkan penyimpanan yang tersedia di server. Anda bisa menggunakan portal Microsoft Azure atau Azure CLI. Setelah ditingkatkan, server siap untuk menerima transaksi tulis lagi.
Kami menyarankan agar Anda menyiapkan pemberitahuan untuk memberi tahu Anda saat penyimpanan server Anda mendekati ambang batas sehingga Anda dapat menghindari masuk ke status baca-saja. Untuk informasi selengkapnya, lihat dokumentasi tentang dokumentasi pemberitahuan cara menyiapkan pemberitahuan.
Penyimpanan bertambah secara otomatis
Pertumbuhan otomatis penyimpanan mencegah server Anda kehabisan penyimpanan dan menjadi baca-saja. Jika pertumbuhan otomatis penyimpanan diaktifkan, penyimpanan secara otomatis tumbuh tanpa memengaruhi beban kerja. Autogrow penyimpanan diaktifkan secara default untuk semua pembuatan server baru. Untuk server dengan penyimpanan yang tersedia kurang dari 100 GB, ukuran penyimpanan yang tersedia ditingkatkan sebesar 5 GB ketika penyimpanan kosongnya di bawah 10% dari penyimpanan yang tersedia. Untuk server dengan lebih dari 100 GB penyimpanan yang tersedia, ukuran penyimpanan yang tersedia ditingkatkan sebesar 5% ketika ruang penyimpanan kosongnya di bawah 10 GB dari ukuran penyimpanan yang tersedia. Batas penyimpanan maksimum seperti yang ditentukan di atas berlaku. Refresh instans server untuk melihat penyimpanan yang diperbarui yang disediakan di bawah Pengaturan pada halaman Komputasi + Penyimpanan.
Misalnya, jika Anda telah menyediakan penyimpanan 1.000 GB, dan pemanfaatan aktual melebihi 990 GB, ukuran penyimpanan server ditingkatkan menjadi 1.050 GB. Atau, jika Anda telah menyediakan penyimpanan sebesar 20 GB, ukuran penyimpanan ditingkatkan menjadi 25 GB jika penyimpanan gratis kurang dari 2 GB.
Ingat bahwa penyimpanan setelah ditingkatkan secara otomatis, tidak dapat diturunkan skalanya.
Catatan
Autogrow penyimpanan diaktifkan secara default untuk server yang dikonfigurasi Ketersediaan Tinggi dan tidak dapat dinonaktifkan.
IOPS
Server fleksibel Azure Database for MySQL mendukung IOPS yang telah disediakan sebelumnya dan IOPS skala otomatis. Pelajari selengkapnya. IOPS minimum adalah 360 di semua ukuran komputasi dan IOPS maksimum ditentukan oleh ukuran komputasi yang dipilih. Untuk mempelajari selengkapnya tentang IOPS maksimum per ukuran komputasi, lihat tabel.
Penting
**IOPS minimum adalah 360 di semua ukuran komputasi
**IOPS maksimum ditentukan oleh ukuran komputasi yang dipilih.
Anda dapat memantau konsumsi I/O Anda di portal Azure (dengan Azure Monitor) menggunakan metrik IO persen. Jika Anda membutuhkan lebih banyak IOPS daripada IOPS maks berdasarkan komputasi, maka Anda perlu menskalakan komputasi server Anda.
IOPS yang telah disediakan sebelumnya
Server fleksibel Azure Database for MySQL menawarkan IOPS yang telah disediakan sebelumnya, memungkinkan Anda mengalokasikan sejumlah IOPS tertentu ke instans server fleksibel Azure Database for MySQL Anda. Pengaturan ini memastikan performa yang konsisten dan dapat diprediksi untuk beban kerja Anda. Dengan IOPS yang telah disediakan sebelumnya, Anda dapat menentukan batas IOPS tertentu untuk volume penyimpanan Anda, menjamin kemampuan untuk menangani beberapa permintaan per detik. Ini menghasilkan tingkat performa yang andal dan terjaga. IOPS yang telah disediakan sebelumnya memungkinkan Anda untuk menyediakan IOPS tambahan di atas batas IOPS. Dengan menggunakan fitur ini, Anda dapat menambah atau mengurangi jumlah IOPS yang tersedia berdasarkan persyaratan beban kerja Anda kapan saja.
IOPS skala otomatis
Landasan server fleksibel Azure Database for MySQL adalah kemampuannya untuk mencapai performa terbaik untuk beban kerja tingkat 1, yang dapat ditingkatkan dengan memungkinkan server secara otomatis menskalakan performa (IO) server databasenya dengan mulus tergantung pada kebutuhan beban kerja. Ini adalah fitur keikutsertaan yang memungkinkan pengguna untuk menskalakan IOPS sesuai permintaan tanpa harus melakukan pra-provisi sejumlah IO per detik. Dengan mengaktifkan fitur Autoscale IOPS, Anda sekarang dapat menikmati manajemen IO gratis yang khawatir di server fleksibel Azure Database for MySQL karena server menskalakan IOP naik atau turun secara otomatis tergantung pada kebutuhan beban kerja.
Dengan IOPS Autoscale, Anda hanya membayar untuk IO yang digunakan server dan tidak perlu lagi menyediakan dan membayar sumber daya yang tidak sepenuhnya mereka gunakan, menghemat waktu dan uang. Selain itu, aplikasi Tier-1 yang sangat penting dapat mencapai performa yang konsisten dengan membuat IO tambahan tersedia untuk beban kerja kapan saja. IOPS skala otomatis menghilangkan administrasi yang diperlukan untuk memberikan performa terbaik dengan biaya paling sedikit untuk pelanggan server fleksibel Azure Database for MySQL.
Penskalaan Dinamis: IOPS Skala Otomatis secara dinamis menyesuaikan batas IOPS server database Anda berdasarkan permintaan aktual beban kerja Anda. Ini memastikan performa optimal tanpa intervensi atau konfigurasi manual.
Menangani Lonjakan Beban Kerja: IOPS Skala Otomatis memungkinkan database Anda menangani lonjakan atau fluktuasi beban kerja dengan lancar tanpa mengorbankan performa aplikasi Anda. Fitur ini memastikan respons yang konsisten bahkan selama periode penggunaan puncak.
Penghematan Biaya: Tidak seperti IOPS yang telah disediakan sebelumnya di mana batas IOPS tetap ditentukan dan dibayar terlepas dari penggunaan, IOPS Skala Otomatis memungkinkan Anda membayar hanya untuk jumlah operasi I/O yang Anda konsumsi.
Cadangan
Layanan ini secara otomatis mengambil cadangan server Anda. Anda dapat memilih periode retensi dari kisaran 1 hingga 35 hari. Pelajari selengkapnya tentang cadangan di artikel konsep pencadangan dan pemulihan.
Menskalakan sumber daya
Setelah membuat server, Anda dapat mengubah tingkat komputasi, ukuran komputasi secara independen (vCore dan memori), dan jumlah penyimpanan, dan periode retensi cadangan. Ukuran komputasi dapat diskalakan meningkat atau menurun. Periode retensi cadangan dapat ditingkatkan atau diturunkan dari 1 hingga 35 hari. Ukuran penyimpanan hanya dapat ditingkatkan. Penskalaan sumber daya dapat dilakukan melalui portal atau Azure CLI.
Catatan
Ukuran penyimpanan hanya dapat ditingkatkan. Anda tidak dapat kembali ke ukuran penyimpanan yang lebih kecil setelah kenaikan.
Ketika Anda mengubah tingkat komputasi atau ukuran komputasi, server dimulai ulang agar jenis server baru berlaku. Selama momen ketika sistem beralih ke server baru, tidak ada koneksi baru yang dapat dibuat, dan semua transaksi yang tidak terikat dibatalkan. Jendela ini bervariasi, tetapi dalam banyak kasus, berkisar antara 60-120 detik.
Menskalakan penyimpanan dan mengubah periode retensi cadangan adalah operasi online dan tidak memerlukan mulai ulang server.
Harga
Untuk informasi harga terbaru, lihat halaman harga layanan. Untuk melihat biaya konfigurasi yang Anda inginkan, portal Azure menujukkan biaya bulanan pada tab Komputasi + penyimpanan berdasarkan opsi yang Anda pilih. Jika Anda tidak memiliki langganan Azure, Anda bisa menggunakan kalkulator harga Azure untuk mendapatkan estimasi harga. Di situs web kalkulator harga Azure, pilih Tambahkan item, perluas kategori Database, pilih Azure Database for MySQL, dan Server Fleksibel sebagai jenis penyebaran untuk menyesuaikan opsi.
Jika Anda ingin mengoptimalkan biaya server, Anda dapat mempertimbangkan tips berikut:
- Turunkan skala tingkat komputasi atau ukuran komputasi (vCore) Anda jika komputasi tidak banyak digunakan.
- Pertimbangkan untuk beralih ke tingkat komputasi Burstable jika beban kerja Anda tidak memerlukan kapasitas komputasi penuh secara terus menerus dari tingkat General Purpose dan Business Critical.
- Hentikan server ketika tidak digunakan.
- Kurangi periode retensi cadangan jika retensi cadangan yang lebih lama tidak diperlukan.
Konten terkait
- Pelajari cara membuat instans server fleksibel Azure Database for MySQL di portal.
- Pelajari tentang keterbatasan layanan.