Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
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 Azure Database for MySQL Flexible Server. Server dapat memiliki satu atau banyak database.
Sumber Daya / Tingkat | Mudah meledak | Tujuan Umum | Kritis Bisnis |
---|---|---|---|
Seri VM | Ukuran mesin virtual burstable seri B | Seri Dadsv5Seri Ddsv4 | Edsv4/Seri Edsv5*/Seri Eadsv5 |
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 |
Retensi periode 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 tersebut.
Mudah meledak
Spesifikasi terperinci dari jenis server yang tersedia adalah sebagai berikut untuk tingkat layanan Burstable.
Ukuran ruang komputasi | vCore | Ukuran Memori Fisik (GiB) | Ukuran Memori Total (GiB) | IOPS Maksimum yang Didukung | Koneksi Maksimal | Penyimpanan Sementara (SSD) GiB |
---|---|---|---|---|---|---|
Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
Standard_B2ms | 2 | 8 | 8.8 | tahun 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 | lima ribu | 13653 | 0 |
Catatan: Tingkat komputasi yang dapat meledak dirancang untuk beban kerja nonproduksi seperti lingkungan pengembangan, penahapan, atau pengujian dan karenanya tidak memenuhi syarat untuk dukungan 24/7 atau analisis akar penyebab (RCA) .
Tujuan Umum
Spesifikasi terperinci dari jenis server yang tersedia adalah sebagai berikut untuk tingkat layanan Tujuan Umum
Ukuran ruang komputasi | vCore | Ukuran Memori Fisik (GiB) | Ukuran Memori Total (GiB) | IOPS Maksimum yang Didukung | Koneksi Maksimal | Penyimpanan Sementara (SSD) GiB |
---|---|---|---|---|---|---|
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 | 12.800 | 5461 | 215 |
Standard_D8ds_v4 | 8 | 32 | 44 | 12.800 | 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 | 48000 | 32768 | 1290 |
Standard_D48ds_v4 | 48 | 192 | 264 | 48000 | 32768 | 1290 |
Standard_D64ads_v5 | 64 | 256 | 352 | 48000 | 43691 | 1720 |
Standard_D64ds_v4 | 64 | 256 | 352 | 48000 | 43691 | 1720 |
Standard_D96ds_v5 | 96 | 384 | 528 | 48000 | 65536 | 2580 |
Kritis Bisnis
Spesifikasi terperinci dari jenis server yang tersedia adalah sebagai berikut untuk tingkat layanan Business Critical.
Ukuran ruang komputasi | vCore | Ukuran Memori Fisik (GiB) | Ukuran Memori Total (GiB) | IOPS Maksimum yang Didukung | Koneksi Maksimal | Penyimpanan Sementara (SSD) GiB |
---|---|---|---|---|---|---|
Standard_E2ds_v4 | 2 | 16 | 22 | lima ribu | 2731 | 37 |
Standard_E2ads_v5, Standard_E2ds_v5 | 2 | 16 | 22 | lima ribu | 2731 | 37 |
Standard_E4ds_v4 | 4 | 32 | 44 | 10.000 | 5461 | 75 |
Standard_E4ads_v5, Standard_E4ds_v5 | 4 | 32 | 44 | 10.000 | 5461 | 75 |
Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
Standard_E8ads_v5, Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
Standard_E16ads_v5, Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
Standard_E20ads_v5, Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
Standard_E32ads_v5, Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
Standard_E48ads_v5, Standard_E48ds_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_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
Standard_E80ids_v4 | 80 | 504 | 693 | 72000 | 86016 | 1224 |
Standard_E96ads_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Manajemen memori di Server Fleksibel Azure Database for MySQL
Di MySQL, memori memainkan peran vital dalam berbagai operasi, termasuk pemrosesan kueri dan penyimpanan sementara. Azure Database for MySQL Flexible Server mengoptimalkan alokasi memori untuk proses server MySQL (mysqld), memastikannya 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)
Azure Database untuk MySQL Server Fleksibel menyediakan Total Ukuran Memori (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. Saat startup, ini menginisialisasi semua komponen seperti kumpulan buffer InnoDB dan cache utas, menggunakan memori berdasarkan konfigurasi dan tuntutan beban kerja. Misalnya, pool buffer InnoDB menyimpan data dan indeks yang sering diakses untuk mempercepat eksekusi kueri, sementara cache thread mengelola thread koneksi klien. Pelajari selengkapnya.
Mesin Penyimpanan InnoDB
Sebagai mesin penyimpanan default MySQL, InnoDB menggunakan memori untuk penyimpanan data sementara yang sering diakses dan mengelola struktur internal seperti Buffer Pool InnoDB dan Log Buffer. 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 Azure Database for MySQL Flexible Server.
Rangkaian Diskusi
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 tergolong fleksibel, Dadsv5-series General Purpose, Ddsv4-series, dan Business Critical Edsv4/Edsv5-series/Eadsv5-series.
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 burstable dirancang untuk memberikan solusi hemat biaya untuk beban kerja yang tidak memerlukan penggunaan CPU penuh secara 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 digunakan selama masa penggunaan CPU tinggi, memungkinkan instans melampaui batas 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 - Server Fleksibel dan konsep Ketersediaan tinggi di 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 - Fleksibel Server: Metrik ini menunjukkan jumlah kredit CPU yang dikonsumsi 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 diperluas hingga 32 TiB untuk tingkat layanan Bisnis Kritis. 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 penyimpanan lebih dari 100 GiB akan menjadi hanya-baca ketika penyimpanan bebas 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 dalam mode baca-saja, semua permintaan transaksi tulis baru diblokir, sambil transaksi aktif yang ada terus dijalankan. Ketika server diatur ke mode hanya-baca, semua operasi tulis berikutnya dan penerapan transaksi gagal, tetapi kueri baca tetap berjalan lancar.
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 kapasitasnya ditingkatkan, server siap menerima transaksi tulis kembali.
Kami menyarankan agar Anda mengaktifkan penyimpanan yang bertambah otomatis atau 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.
Pengembangan otomatis penyimpanan
Peningkatan otomatis kapasitas penyimpanan mencegah server Anda kehabisan ruang dan beralih ke mode baca saja. Jika penyimpanan tumbuh otomatis diaktifkan, penyimpanan secara otomatis tumbuh tanpa memengaruhi beban kerja. Peningkatan otomatis kapasitas penyimpanan diaktifkan secara bawaan 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 serta server dengan log yang dipercepat, dan fitur ini tidak dapat dinonaktifkan.
IOPS
Azure Database for MySQL Flexible Server mendukung IOPS yang telah disediakan sebelumnya dan IOPS skala otomatis. IOPS Penyimpanan di Azure Database for MySQL - Server Fleksibel Minimum IOPS adalah 360 untuk semua ukuran komputasi, dan maksimum IOPS 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 - Flexible Server. Anda perlu menskalakan komputasi server Anda jika Anda membutuhkan lebih banyak IOPS daripada IOPS maks berdasarkan komputasi.
IOPS yang telah disediakan sebelumnya
Azure Database for MySQL Flexible Server 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 Azure Database for MySQL Flexible Server 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 Autoscale IOPS diaktifkan, Anda sekarang dapat menikmati manajemen IO bebas kekhawatiran di Azure Database for MySQL Flexible Server karena server menskalakan IOP ke atas atau ke bawah secara otomatis tergantung pada kebutuhan beban kerja. AutoScale IOPS secara otomatis mengoptimalkan hingga 'Max Supported IOPS' untuk setiap lapisan layanan dan ukuran komputasi, sebagaimana disebutkan dalam dokumentasi lapisan 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 Tier-1 yang kritis bagi misi dapat mencapai kinerja yang konsisten dengan menyediakan IO tambahan untuk beban kerja kapan saja. IOPS skala otomatis menghilangkan administrasi yang diperlukan untuk memberikan performa terbaik dengan biaya paling sedikit untuk pelanggan Azure Database for MySQL Flexible Server.
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 ini mencadangkan server Anda secara otomatis. 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.