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: Burstable, General Purpose, dan Business Critical. SKU VM yang mendasar membedakan tingkat layanan yang digunakan seri B, seri D, dan seri E. Tingkat komputasi dan pilihan ukuran menentukan memori dan vCore yang tersedia di server. Teknologi penyimpanan yang tepat 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 | Ukuran mesin virtual burstable 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 32 TiB |
| Periode retensi cadangan database | 1 hingga 35 hari | 1 hingga 35 hari | 1 hingga 35 hari |
** Kecuali 64,80, dan 96 vCore, yang masing-masing memiliki memori 504 GiB, 504 GiB, dan 672 GiB.
* Komputasi Ev5 memiliki performa terbaik di antara seri VM lainnya mengenai QPS dan latensi. Pelajari selengkapnya tentang performa dan ketersediaan wilayah komputasi Ev5 dari sini.
Tingkat layanan Server Fleksibel
Untuk memilih tingkat komputasi, gunakan tabel berikut ini sebagai titik awal.
| Tingkat komputasi | Beban kerja target |
|---|---|
| Mudah meledak | Terbaik untuk beban kerja yang terus menerus tidak memerlukan CPU penuh. |
| Tujuan Umum | Sebagian besar beban kerja bisnis memerlukan komputasi dan memori yang 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 membuat server, Anda dapat mengubah tingkat komputasi, ukuran komputasi, dan ukuran penyimpanan. Penskalaan komputasi memerlukan mulai ulang dan membutuhkan waktu 60-120 detik, sementara penskalaan penyimpanan tidak. Anda juga dapat menyesuaikan periode retensi cadangan secara independen ke atas atau ke bawah. Lihat bagian Menskalakan sumber daya untuk informasi selengkapnya.
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.
Mudah meledak
Spesifikasi terperinci dari jenis server yang tersedia adalah sebagai berikut untuk tingkat layanan Burstable.
| Ukuran komputasi | vCore | Ukuran Memori Fisik (GiB) | Ukuran Memori Total (GiB) | IOPS Maksimum yang Didukung | Koneksi Maksimal | GiB Penyimpanan Sementara (SSD) |
|---|---|---|---|---|---|---|
| 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 |
Tujuan Umum
Spesifikasi terperinci dari jenis server yang tersedia adalah sebagai berikut untuk tingkat layanan 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 |
Kritis Bisnis
Spesifikasi terperinci dari jenis server yang tersedia adalah sebagai berikut untuk tingkat layanan 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_E80ds_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 |
Ketahanan Zona Default di Azure Database for MySQL – Tingkat Kritis Bisnis Server Fleksibel: Mulai pertengahan Desember 2024, semua server baru yang disediakan di Azure Database for MySQL – Tingkat Kritis Bisnis Server Fleksibel akan dilengkapi dengan ketahanan zona bawaan—tanpa biaya tambahan! Ini berarti data dan file log Anda akan secara otomatis disimpan pada penyimpanan zona-redundan, memastikan pemulihan cepat dari pemadaman zona. Bahkan tanpa Ketersediaan Tinggi diaktifkan, Anda akan mendapat manfaat dari perlindungan yang mulus dengan cadangan zona-redundan. Pelajari selengkapnya.
Manajemen memori di server fleksibel Azure Database for MySQL
Di MySQL, memori memainkan peran penting di berbagai operasi, termasuk pemrosesan kueri dan penembolokan. 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 hanya fokus pada total memori yang tersedia untuk proses Azure MySQL Server (mysqld) Anda. 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, adalah mesin operasi database inti. 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 ukuran komputer virtual seri B yang dapat meledak, seri Ddsv4 seriGeneral Purpose Dadsv5, dan seri Eadsv5 Seri Business Critical Edsv4/Edsv5./
Batasan performa instans seri yang dapat meledak
Catatan
Untuk ukuran komputer virtual seri B yang dapat meledak, jika VM dimulai/dihentikan atau dimulai ulang, kredit mungkin hilang. Untuk informasi selengkapnya, lihat Ukuran komputer virtual seri B yang dapat meledak.
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. Misalkan server tingkat Burstable menjalankan beban kerja yang membutuhkan lebih banyak performa CPU daripada tingkat dasar dan telah menghabiskan kredit CPU-nya. Dalam hal ini, server mungkin mengalami keterbatasan performa dan akhirnya dapat memengaruhi berbagai operasi sistem seperti Stop/Start/Restart untuk server Anda.
Catatan
Untuk server dalam ukuran komputer virtual seri B yang dapat meledak, seperti Standard_B1s/Standard_B1ms/Standard_B2s, ukuran memori host yang relatif lebih kecil, mungkin 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 di Azure Database for MySQL - Konsep Server Fleksibel dan Ketersediaan tinggi di Fitur Azure Database for MySQL - Server Fleksibel. Tingkat komputasi lainnya, seperti Tujuan Umum atau Bisnis Penting, lebih sesuai untuk beban kerja dan fitur tersebut.
Untuk informasi selengkapnya tentang model kredit CPU seri B Azure, lihat ukuran komputer virtual seri B yang dapat meledak dan model kredit CPU seri B.
Memantau kredit CPU dalam 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 Anda.
Pantau Azure Database for MySQL - Server Fleksibel: 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.
Pantau Azure Database for MySQL - Server Fleksibel: Metrik ini menunjukkan jumlah kredit CPU yang tersisa untuk instans Anda. Memantau metrik ini dapat membantu mencegah instans Anda menurunkan performa karena melelahkan kredit CPU-nya. 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 provisikan adalah kapasitas penyimpanan yang tersedia untuk server fleksibel Anda. Penyimpanan digunakan untuk file database, file sementara, log transaksi, dan log server MySQL. Untuk tingkat layanan Burstable dan General Purpose, rentang penyimpanan mencakup dari minimal 20 GiB hingga maksimum 16 TiB. Sebaliknya, dukungan penyimpanan memperluas hingga 32 TiB untuk tingkat layanan Business Critical. Di semua tingkat layanan, 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 digunakan di server hampir mencapai batas yang disediakan, server dimasukkan ke dalam mode baca-saja untuk melindungi setiap penulisan 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 100 GiB penyimpanan yang disediakan ditandai baca-saja ketika penyimpanan gratis kurang dari 5 GiB.
Misalnya, jika Anda telah menyediakan penyimpanan 110 GiB, dan pemanfaatan aktual melebihi 105 GiB, server 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 tulis berikutnya dan penerapan transaksi gagal, tetapi kueri baca 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.
Pertumbuhan otomatis penyimpanan
Pertumbuhan otomatis penyimpanan mencegah server Anda kehabisan penyimpanan dan menjadi baca-saja. Jika penyimpanan tumbuh otomatis 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 disediakan ditingkatkan sebesar 5 GB ketika penyimpanan gratis di bawah 10% dari penyimpanan yang disediakan. 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 20 GB, ukuran penyimpanan ditingkatkan menjadi 25 GB ketika penyimpanan kurang dari 2 GB gratis.
Ingat bahwa penyimpanan, setelah ditingkatkan secara otomatis, tidak dapat diturunkan skalanya.
Catatan
Autogrow penyimpanan diaktifkan secara default untuk server yang dikonfigurasi dengan ketersediaan tinggi dan tidak dapat dinonaktifkan.
IOPS
Server fleksibel Azure Database for MySQL mendukung IOPS yang telah disediakan sebelumnya dan IOPS skala otomatis. IOPS Penyimpanan di Azure Database for MySQL - Server Fleksibel IOPS minimum adalah 360 di semua ukuran komputasi, dan IOPS maksimum ditentukan oleh ukuran komputasi yang dipilih. Untuk mempelajari lebih lanjut 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 di portal Azure (dengan Azure Monitor) menggunakan metrik Monitor Azure Database for MySQL - Server Fleksibel. Anda perlu menskalakan komputasi server Anda jika Anda membutuhkan lebih banyak IOPS daripada IOPS maks berdasarkan komputasi.
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. Ini dapat ditingkatkan dengan memungkinkan server untuk secara otomatis menskalakan performa server database (IO) dengan mulus tergantung pada kebutuhan beban kerja. Fitur keikutsertaan ini memungkinkan pengguna untuk menskalakan IOPS sesuai permintaan tanpa harus melakukan pra-provisi sejumlah IO per detik. Dengan fitur IOPS Autoscale diaktifkan, Anda sekarang dapat menikmati manajemen IO bebas kekhawatiran di server fleksibel Azure Database for MySQL karena server menskalakan IOP ke atas atau ke bawah secara otomatis tergantung pada kebutuhan beban kerja. IOPS Skala Otomatis secara otomatis meningkatkan skala ke 'Max Supported IOPS' untuk setiap tingkat layanan dan ukuran komputasi, seperti yang ditentukan dalam dokumentasi tingkat layanan. Ini memastikan performa optimal tanpa perlu upaya penskalaan manual
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 Tingkat-1 misi-kritis 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.
Penskalakan 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, yang menentukan batas IOPS tetap dan dibayar terlepas dari penggunaannya, IOPS Skala Otomatis memungkinkan Anda membayar hanya untuk jumlah operasi I/O yang Anda konsumsi.
Cadangan
Layanan secara otomatis mencadangkan server Anda. Anda dapat memilih periode retensi 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 (vCore dan memori), jumlah penyimpanan, dan periode retensi cadangan secara independen. Ukuran komputasi dapat ditingkatkan atau diturunkan skalanya, dan periode retensi cadangan dapat ditingkatkan atau diturunkan dari 1 hingga 35 hari. Ukuran penyimpanan hanya dapat ditingkatkan. Menskalakan 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 harus dimulai ulang agar jenis server baru berlaku. Ketika sistem beralih ke server baru, tidak ada koneksi baru yang dapat dibuat, dan semua transaksi yang tidak dilakukan digulung balik. Jendela ini bervariasi, tetapi dalam banyak kasus, itu antara 60 dan 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.