Automigrasi di tempat dari Azure Database for MySQL – Server Tunggal ke Server Fleksibel

BERLAKU UNTUK: Azure Database for MySQL - Server Tunggal

Penting

Beberapa instans Server Tunggal mungkin memerlukan input wajib untuk melakukan automigrasi di tempat yang berhasil. Tinjau detail migrasi di bilah Migrasi pada portal Azure untuk memberikan input tersebut. Kegagalan untuk memberikan input wajib 2 hari sebelum migrasi terjadwal akan menyebabkan penjadwalan ulang migrasi ke kemudian hari.

Automigrasi di tempat dari Azure Database for MySQL – Server Tunggal ke Server Fleksibel adalah migrasi di tempat yang dimulai layanan selama jendela pemeliharaan terencana untuk beban kerja database Server Tunggal dengan SKU Dasar, Tujuan Umum, atau Memori yang Dioptimalkan dan tidak ada fitur kompleks (Replika Baca, Jaringan Virtual, enkripsi Infra Ganda, Titik akhir layanan/Aturan VNet) diaktifkan. Server yang memenuhi syarat diidentifikasi oleh layanan dan dikirimi langkah-langkah detail pemberitahuan sebelumnya untuk meninjau detail migrasi.

Migrasi di tempat memberikan pengalaman migrasi offline yang sangat tangguh dan penyembuhan diri selama jendela pemeliharaan terencana, dengan waktu henti kurang dari 5 menit untuk Tujuan Umum dan Memori yang dioptimalkan SKU dan hingga 30 menit untuk SKU Dasar. Ini menggunakan teknologi pencadangan dan pemulihan untuk waktu migrasi yang lebih cepat. Migrasi ini menghapus overhead untuk memigrasikan server Anda secara manual dan memastikan Anda dapat memanfaatkan manfaat Server Fleksibel, termasuk harga & performa yang lebih baik, kontrol terperinci atas konfigurasi database, dan jendela pemeliharaan kustom. Berikut ini dijelaskan adalah fase utama migrasi:

• Server Fleksibel Target disebarkan, mewarisi semua kumpulan fitur dan properti (termasuk parameter server dan aturan firewall) dari Server Tunggal sumber. Server Tunggal Sumber diatur ke baca-saja dan cadangan dari Server Tunggal sumber disalin ke Server Fleksibel target.
• Pengalihan dan cutover DNS berhasil dilakukan dalam jendela pemeliharaan terencana dengan waktu henti minimal, memungkinkan pemeliharaan string koneksi yang sama pascamigrasi. Aplikasi klien terhubung dengan mulus ke server fleksibel target tanpa pembaruan manual yang digerakkan pengguna. Selain format string koneksi (Server Tunggal dan Fleksibel) yang didukung pada Server Fleksibel yang dimigrasikan, format nama pengguna – username@server_name dan nama pengguna juga didukung pada Server Fleksibel yang dimigrasikan.
• Server Fleksibel yang dimigrasikan sedang online dan sekarang dapat dikelola melalui portal Azure/CLI. Server Tunggal yang Dihentikan dihapus tujuh hari setelah migrasi.

Catatan

Jika instans Server Tunggal Anda memiliki SKU Dasar, instans terjadwal Anda akan dimigrasikan dengan jendela waktu henti hingga 30 menit. Instans akan dimigrasikan ke SKU Tujuan Umum yang lebih tinggi untuk memastikan migrasi yang berhasil dan akan diturunkan skalanya ke Burstable SKU dalam 24-48 jam. Jika pasca migrasi ke SKU Burstable, instans Anda kehabisan kredit karena beban kerja CPU yang berat, pertimbangkan untuk meningkatkan ke SKU Tujuan Umum pada instans Server Fleksibel.

Catatan

Jika instans Server Tunggal Anda memiliki penyimpanan General Purpose V1, instans terjadwal Anda akan menjalani operasi hidupkan ulang tambahan 12 jam sebelum waktu migrasi terjadwal. Operasi hidupkan ulang ini berfungsi untuk mengaktifkan parameter server log_bin yang diperlukan untuk meningkatkan instans ke penyimpanan General Purpose V2 sebelum menjalani migrasi otomatis di tempat.

Kelayakan

Jika Anda memiliki beban kerja Server Tunggal tanpa fitur kompleks (Replika Baca, Jaringan Virtual, enkripsi Infra Ganda, Titik akhir layanan/Aturan VNet) diaktifkan, Anda sekarang dapat mencalonkan diri Anda (jika belum dijadwalkan oleh layanan) untuk automigrasi dengan mengirimkan detail server Anda melalui tiket Dukungan Azure.

Untuk membuat server Anda yang tidak memenuhi syarat untuk migrasi otomatis melakukan langkah-langkah berikut:

• Instans Server Tunggal harus dalam status siap dan tidak boleh dalam status berhenti selama jendela pemeliharaan terencana agar automigrasi berlangsung.
• Jika Server Tunggal Azure Database for MySQL sumber Anda memiliki versi mesin v8.x, pastikan untuk meningkatkan versi driver klien .NET server sumber Anda ke 8.0.32 untuk menghindari ketidakcocokan pengodean pascamigrasi ke Server Fleksibel.
• Jika Server Tunggal Azure Database for MySQL sumber Anda memiliki versi mesin v8.x, pastikan untuk meningkatkan versi TLS server sumber Anda dari v1.0 atau v1.1 ke TLS v1.2 sebelum migrasi karena versi TLS yang lebih lama telah ditolak untuk Server Fleksibel.
• Jika server Anda memiliki Replika Baca, letakkan Replika Baca. Anda dapat mengonfigurasi Replika Baca pasca migrasi otomatis.
• Jika server Anda mengaktifkan Titik Akhir Layanan (Aturan VNet) atau Konfigurasi Virtual Network, pertimbangkan untuk menjatuhkannya atau pindah ke fitur Private Link pada instans Server Tunggal Anda.
• Jika server Anda mengaktifkan Enkripsi Infrastruktur Ganda, pertimbangkan untuk pindah ke fitur Customer Managed Key (CMK) pada instans Server Tunggal Anda.

Mengonfigurasi pemberitahuan migrasi

Server yang memenuhi syarat untuk automigrasi di tempat dikirim pemberitahuan terlebih dahulu oleh layanan.

Berikut ini dijelaskan adalah cara untuk memeriksa dan mengonfigurasi pemberitahuan otomatis:

• Pemilik langganan untuk Server Tunggal yang dijadwalkan untuk automigrasi menerima pemberitahuan email.
• Konfigurasikan pemberitahuan kesehatan layanan untuk menerima jadwal migrasi di tempat dan pemberitahuan kemajuan melalui email/SMS dengan mengikuti langkah-langkah di sini.
• Periksa pemberitahuan migrasi di tempat pada portal Azure dengan mengikuti langkah-langkah di sini.

Meninjau dan mengonfigurasi jadwal dan detail migrasi

Berikut ini dijelaskan adalah cara untuk meninjau jadwal migrasi setelah Anda menerima pemberitahuan automigrasi di tempat:

Catatan

Jadwal migrasi dikunci 2 hari sebelum jendela migrasi terjadwal setelah itu Anda tidak akan dapat menjadwalkan ulang.

• Halaman gambaran umum Server Tunggal untuk instans Anda menampilkan banner portal dengan informasi tentang jadwal migrasi Anda.

• Untuk Server Tunggal yang dijadwalkan untuk automigrasi, bilah Migrasi baru dinyalakan di portal. Anda dapat meninjau jadwal migrasi dengan menavigasi ke bilah Migrasi instans Server Tunggal Anda.

• Jika Anda ingin menukar migrasi, Anda dapat menumpuk satu bulan sekaligus dengan menavigasi ke bilah Migrasi instans server tunggal Anda di portal Azure dan menjadwalkan ulang migrasi dengan memilih jendela migrasi lain dalam sebulan.

• Jika Server Tunggal Anda memiliki SKU Tujuan Umum, Anda memiliki opsi lain untuk mengaktifkan Ketersediaan Tinggi saat meninjau jadwal migrasi. Karena Ketersediaan Tinggi hanya dapat diaktifkan selama waktu pembuatan untuk Server Fleksibel MySQL, sangat disarankan agar Anda mengaktifkan fitur ini saat meninjau jadwal migrasi.

• Jika instans Server Tunggal Anda memiliki satu atau beberapa Private Link, Customer Managed Key (CMK) dan Microsoft Entra Admin diaktifkan, migrasi otomatis di tempat memerlukan input wajib untuk titik akhir privat, CMK dan Microsoft Entra Admin untuk dimigrasikan dari instans Server Tunggal Anda ke instans Server Fleksibel target. Input pengguna harus diberikan 2 hari sebelum jendela migrasi terjadwal. Jika input pengguna tidak disediakan sebelum detail migrasi dikunci, migrasi Anda akan dijadwalkan ulang ke titik waktu selanjutnya. Setelah memberikan semua input, pastikan untuk Menyimpan konfigurasi dalam wizard migrasi otomatis. Langkah-langkah untuk memberikan input pengguna :

  • Buka bilah Migrasi instans Server Tunggal Anda dan pilih edit migrasi terjadwal.
  • Di bagian Detail migrasi otomatis klik tombol Autentikasi untuk mengautentikasi dan menyimpan koneksi ARM API untuk memigrasikan server Anda.
  • Jika server Anda memiliki Microsoft Entra Admin yang dikonfigurasi, Anda dapat memberikan input di bawah bagian Admin Microsoft Entra di wizard migrasi otomatis :
    • Memigrasikan admin Microsoft Entra untuk server target mengharuskan Identitas ditambahkan ke Azure Database for MySQL – Server Fleksibel. Identitas memerlukan hak istimewa berikut – User.Read.All, GroupMember.Read.All dan Application.Read.All untuk diberikan. Silakan pilih identitas terkelola yang ditetapkan pengguna yang sesuai dan berikan izin yang tepat dengan mengikuti langkah-langkah di sini.
  • Jika server Anda memiliki Kunci Terkelola Pelanggan yang dikonfigurasi, Anda dapat memberikan input di bawah bagian Enkripsi Data di wizard migrasi otomatis :
    • Memigrasikan enkripsi kunci yang dikelola pelanggan mengharuskan Identitas ditambahkan ke Azure Database for MySQL – Server Fleksibel. Pilih identitas terkelola yang ditetapkan pengguna yang sesuai. Pengidentifikasi/kunci kunci yang tercantum akan dimigrasikan dari sumber ke server target dan harus diberikan hak istimewa berikut - Dapatkan, Kunci Bungkus, Buka Bungkus Kunci untuk mengakses brankas kunci.
  • Jika Server Tunggal Anda memiliki titik akhir privat, lakukan langkah-langkah wajib berikut saat meninjau jadwal migrasi setidaknya 2 hari sebelum migrasi terjadwal:
    • Tinjau titik akhir privat yang tercantum untuk dimigrasikan. Pastikan mereka ditandai sebagai Siap Untuk Bermigrasi. Jika ditandai sebagai tidak memenuhi syarat, pilih langganan dan Zona DNS privat yang sesuai.
      • Zona DNS Privat Kustom tidak didukung oleh migrasi otomatis. Zona DNS Privat harus privatelink.mysql.database.azure.com.
      • Metode persetujuan koneksi titik akhir privat harus ditetapkan sebagai persetujuan otomatis dan bukan persetujuan manual. Titik akhir privat persetujuan manual tidak didukung oleh migrasi otomatis.
    • Pastikan Anda memiliki tingkat Langganan atau akses peran Kontributor tingkat Grup Sumber Daya untuk menghindari masalah izin saat mengautentikasi.
    • Pilih kotak centang konfirmasi setelah melakukan pemeriksaan prasyarat yang tercantum untuk memigrasikan titik akhir privat.

  Catatan

  Jika input wajib untuk migrasi tidak disediakan setidaknya 2 hari sebelum migrasi terjadwal, migrasi dijadwalkan ulang ke kemudian hari.

  Catatan

  Untuk instans Server Tunggal dengan titik akhir privat, hapus instans sumber Server Tunggal pasca validasi migrasi. Jika tidak ada operasi penghapusan server yang dilakukan, instans sumber dipertahankan hingga posting 14 hari yang akan dihapus oleh layanan.

Pemeriksaan prasyarat untuk automigrasi di tempat

Tinjau prasyarat berikut untuk memastikan keberhasilan automigrasi di tempat:

• Instans Server Tunggal harus dalam status siap dan tidak boleh dalam status berhenti selama jendela pemeliharaan terencana agar automigrasi berlangsung.
• Parameter server, pengaturan, konfigurasi, dan aturan firewall instans Server Tunggal tidak boleh diperbarui selama jendela 2 hari sebelum automigrasi terjadwal.
• Untuk instans Server Tunggal dengan SSL diaktifkan, pastikan Anda memiliki ketiga sertifikat (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 Root CA dan DigiCertGlobalRootCA Root CA) yang tersedia di penyimpanan akar tepercaya. Selain itu, jika Anda memiliki sertifikat yang disematkan ke string koneksi membuat sertifikat CA gabungan dengan ketiga sertifikat sebelum automigrasi terjadwal untuk memastikan kelangsungan bisnis pascamigrasi.
• Mesin MySQL tidak menjamin urutan sortir apa pun jika tidak ada klausa 'SORT' yang ada dalam kueri. Pasca automigrasi di tempat, Anda mungkin mengamati perubahan dalam urutan pengurutan. Jika mempertahankan urutan pengurutan sangat penting, pastikan kueri Anda diperbarui untuk menyertakan klausul 'SORT' sebelum automigrasi di tempat yang dijadwalkan.
• Jika Server Tunggal Azure Database for MySQL sumber Anda memiliki versi mesin v8.x, pastikan untuk meningkatkan versi driver klien .NET server sumber Anda ke 8.0.32 untuk menghindari ketidakcocokan pengodean pascamigrasi ke Server Fleksibel.
• Jika Server Tunggal Azure Database for MySQL sumber Anda memiliki versi mesin v8.x, pastikan untuk meningkatkan versi TLS server sumber Anda dari v1.0 atau v1.1 ke TLS v1.2 sebelum migrasi karena versi TLS yang lebih lama telah ditolak untuk Server Fleksibel.
• Jika Server Tunggal Azure Database for MySQL sumber Anda memiliki nama aturan firewall yang melebihi 80 karakter, ganti namanya untuk memastikan panjang nama kurang dari 80 karakter. (Panjang nama aturan firewall yang didukung di Server Fleksibel adalah 80 karakter sedangkan pada Server Tunggal panjang yang diizinkan adalah 12 8 karakter.)
• Jika Server Tunggal Azure Database for MySQL sumber Anda menggunakan port nondefault seperti 3308.3309 dan 3310, ubah port konektivitas Anda menjadi 3306 karena port nondefault yang disebutkan di atas tidak didukung di Server Fleksibel.

Bagaimana target MySQL Flexible Server diprovisikan secara otomatis?

Tingkat komputasi dan SKU untuk server fleksibel target disediakan berdasarkan tingkat harga server tunggal sumber dan VCore berdasarkan detail dalam tabel berikut.

Tingkat Harga Server Tunggal	VCore Server Tunggal	Tingkat Server Fleksibel	Nama SKU Server Fleksibel
Dasar	1	Mudah meledak	Standard_B1s
Dasar	2	Mudah meledak	Standard_B2s
Tujuan Umum	2	GeneralPurpose	Standard_D2ds_v4
Tujuan Umum	4	GeneralPurpose	Standard_D4ds_v4
Tujuan Umum	8	GeneralPurpose	Standard_D8ds_v4
Tujuan Umum	16	GeneralPurpose	Standard_D16ds_v4
Tujuan Umum	32	GeneralPurpose	Standard_D32ds_v4
Tujuan Umum	64	GeneralPurpose	Standard_D64ds_v4
Memori Dioptimalkan	4	MemoryOptimized	Standard_E4ds_v4
Memori Dioptimalkan	8	MemoryOptimized	Standard_E8ds_v4
Memori Dioptimalkan	16	MemoryOptimized	Standard_E16ds_v4
Memori Dioptimalkan	32	MemoryOptimized	Standard_E32ds_v4

• Versi MySQL, wilayah, *ukuran penyimpanan, langganan, dan grup sumber daya untuk Server Fleksibel target sama dengan server tunggal sumber.
• Untuk Server Tunggal dengan penyimpanan kurang dari 20 GiB, ukuran penyimpanan diatur ke 20 GiB karena merupakan batas penyimpanan minimum pada Azure Database for MySQL - Server Fleksibel.
• Kedua format nama pengguna – username@server_name (Server Tunggal) dan nama pengguna (Server Fleksibel) didukung pada Server Fleksibel yang dimigrasikan.
• Baik format string koneksi – Server Tunggal dan Server Fleksibel didukung di Server Fleksibel yang dimigrasikan.
• Untuk instans Server Tunggal dengan penyimpanan Kueri diaktifkan, parameter server 'slow_query_log' pada instans target diatur ke AKTIF untuk memastikan paritas fitur saat bermigrasi ke Server Fleksibel. Untuk beban kerja tertentu, ini dapat memengaruhi performa dan jika Anda mengamati penurunan performa apa pun, atur parameter server ini ke 'NONAKTIF' pada instans Server Fleksibel.

Langkah setelah migrasi

Berikut adalah info yang perlu Anda ketahui pasca migrasi di tempat:

Catatan

Pasca-migrasi tidak memulai ulang instans Server Tunggal yang dihentikan karena mungkin menghambat konektivitas aplikasi dan klien Anda.

• Salin properti berikut dari Server Tunggal sumber ke Server Fleksibel target pasca operasi migrasi di tempat berhasil diselesaikan:
  • Memantau pengaturan halaman (Pengaturan Pemberitahuan, Metrik, dan Diagnostik) dan Pengaturan kunci
  • Setiap skrip Terraform/CLI yang Anda host untuk mengelola instans Server Tunggal Anda harus diperbarui dengan referensi Server Fleksibel.
• Untuk instans Server Tunggal dengan penyimpanan Kueri diaktifkan, parameter server 'slow_query_log' pada instans target diatur ke AKTIF untuk memastikan paritas fitur saat bermigrasi ke Server Fleksibel. Perhatikan, untuk beban kerja tertentu ini dapat memengaruhi performa dan jika Anda mengamati penurunan performa apa pun, atur parameter server ini ke 'NONAKTIF' pada instans Server Fleksibel.
• Untuk instans Server Tunggal dengan titik akhir privat, hapus instans sumber Server Tunggal pasca validasi migrasi. Jika tidak ada operasi penghapusan server yang dilakukan, instans sumber dipertahankan hingga posting 14 hari yang akan dihapus oleh layanan.
• Untuk instans Server Tunggal dengan Microsoft Defender untuk Cloud diaktifkan, status pengaktifan dimigrasikan. Untuk mencapai paritas di Server Fleksibel pasca automigrasi untuk properti yang dapat Anda konfigurasikan di Server Tunggal, pertimbangkan detail dalam tabel berikut:

Properti	Konfigurasi
Menekan jenis pemberitahuan tertentu	Nonaktifkan jenis pemberitahuan tertentu dengan platform Microsoft Defender untuk Cloud. Untuk informasi selengkapnya, kunjungi Panduan menyembunyikan pemberitahuan dari Microsoft Defender untuk Cloud. Pengguna Server Tunggal dapat menggunakan properti API: properties.disabledAlerts
Pemberitahuan email	Tentukan pemberitahuan email untuk pemberitahuan Microsoft Defender untuk Cloud untuk semua sumber daya dalam langganan. Untuk informasi selengkapnya, kunjungi Mengonfigurasi pemberitahuan email untuk pemberitahuan keamanan. Pengguna Server Tunggal dapat menggunakan properti API: properties.emailAccountAdmins, properties.emailAddresses
Mengekspor pemberitahuan untuk pemrosesan dan/atau pengarsipan lebih lanjut	Pemberitahuan disimpan di platform Microsoft Defender untuk Cloud dan diekspos melalui Azure Resource Graph. Anda dapat mengekspor pemberitahuan ke penyimpanan lain dan mengelola retensi secara terpisah. Untuk informasi selengkapnya, kunjungi Menyiapkan ekspor berkelanjutan di portal Azure - Microsoft Defender untuk Cloud. Pengguna Server Tunggal dapat menggunakan properti API: properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint

Tanya Jawab Umum (FAQ)

T. Mengapa saya dimigrasikan secara otomatis?

J. Instans Azure Database for MySQL - Server Tunggal Anda memenuhi syarat untuk migrasi di tempat ke penawaran unggulan kami Azure Database for MySQL - Server Fleksibel. Migrasi di tempat ini akan menghapus overhead untuk memigrasikan server Anda secara manual dan memastikan Anda dapat memanfaatkan manfaat Server Fleksibel, termasuk harga & performa yang lebih baik, kontrol terperinci atas konfigurasi database, dan periode pemeliharaan kustom.

T. Bagaimana automigrasi berlangsung? Apa yang dimigrasikannya?

J. Server Fleksibel disediakan untuk mencocokkan VCore dan penyimpanan yang sama dengan Server Tunggal Anda. Selanjutnya sumber Server Tunggal dihentikan statusnya, rekam jepret file data diambil dan disalin ke Server Fleksibel target. Sakelar DNS dilakukan untuk merutekan semua koneksi yang ada ke target dan Server Fleksibel target dibawa online. Automigrasi memigrasikan seluruh file data server (termasuk skema, data, login) selain parameter server (semua parameter server yang dimodifikasi pada sumber disalin ke target, parameter server yang tidak dimodifikasi mengambil nilai default yang ditentukan oleh Server Fleksibel) dan aturan firewall. Ini adalah migrasi offline tempat Anda melihat waktu henti hingga 5 menit atau kurang.

T. Bagaimana cara menyiapkan atau menampilkan pemberitahuan migrasi di tempat?

J. Berikut ini adalah cara Anda dapat menyiapkan pemberitahuan:

• Konfigurasikan pemberitahuan kesehatan layanan untuk menerima jadwal migrasi di tempat dan pemberitahuan kemajuan melalui email/SMS dengan mengikuti langkah-langkah di sini.
• Periksa pemberitahuan migrasi di tempat pada portal Azure dengan mengikuti langkah-langkah di sini.

T. Bagaimana cara menunda migrasi terjadwal?

J. Anda dapat meninjau jadwal migrasi dengan menavigasi ke bilah Migrasi instans Server Tunggal Anda. Jika Anda ingin menukar migrasi, Anda dapat menangguhkan paling banyak satu bulan dengan menavigasi ke bilah Migrasi instans server tunggal Anda di portal Azure dan menjadwalkan ulang migrasi dengan memilih jendela migrasi lain dalam waktu satu bulan. Detail migrasi dikunci tujuh hari sebelum jendela migrasi terjadwal setelah itu Anda tidak dapat menjadwalkan ulang. Migrasi di tempat ini dapat ditangguhkan setiap bulan hingga 16 September 2024.

T. Nama pengguna dan string koneksi apa yang akan didukung untuk Server Fleksibel yang dimigrasikan? ​​

J. Format nama pengguna - username@server_name (format Server Tunggal) dan nama pengguna (format Server Fleksibel) didukung untuk Server Fleksibel yang dimigrasikan, dan karenanya Anda tidak diharuskan memperbaruinya untuk mempertahankan kelangsungan aplikasi Anda pasca migrasi. Selain itu, format string koneksi (format server Tunggal dan Fleksibel) juga didukung untuk Server Fleksibel yang dimigrasikan.

T. Bagaimana cara mengaktifkan KETERSEDIAAN TINGGI (Ketersediaan Tinggi) untuk server saya yang dimigrasikan secara otomatis??

J. Secara default, automigrasi menyiapkan migrasi ke instans non-HA. Karena Ketersediaan Tinggi hanya dapat diaktifkan pada waktu pembuatan server, Anda harus mengaktifkan Ketersediaan Tinggi sebelum automigrasi terjadwal menggunakan opsi edit jadwal otomatis di portal. HA hanya dapat diaktifkan untuk Tujuan umum\Memori Yang Dioptimalkan SKU pada Server Fleksibel target, karena migrasi SKU Dasar ke Burstable tidak mendukung konfigurasi HA.

T. Saya melihat perbedaan harga pada potensi perpindahan saya dari MySQL Basic Single Server ke MySQL Flexible Server??

J. Beberapa server mungkin melihat kenaikan harga kecil setelah migrasi (perkiraan biaya dapat dilihat dengan memilih opsi edit jadwal automigrasi di portal), karena batas penyimpanan minimum pada kedua penawaran berbeda (5 GiB di Server Tunggal; 20 GiB di Server Fleksibel) dan biaya penyimpanan (0,1$ di Server Tunggal; 0,115 $ di Server Fleksibel) untuk Server Fleksibel sedikit lebih tinggi daripada Server Tunggal. Untuk server yang terpengaruh, peningkatan harga di Server Fleksibel ini memberikan throughput dan performa yang lebih baik dibandingkan dengan Server Tunggal.

Konten terkait

• Mengelola Azure Database for MySQL - Server Fleksibel menggunakan portal Azure.