Praktik terbaik untuk performa optimal Azure Database for MySQL - Server Fleksibel

Artikel
12/19/2023

BERLAKU UNTUK: Azure Database for MySQL - Server Tunggal Database Azure untuk MySQL - Server Fleksibel

Penting

Server tunggal Azure Database for MySQL berada di jalur penghentian. Kami sangat menyarankan Agar Anda meningkatkan ke server fleksibel Azure Database for MySQL. Untuk informasi selengkapnya tentang migrasi ke server fleksibel Azure Database for MySQL, lihat Apa yang terjadi pada Server Tunggal Azure Database for MySQL?

Pelajari cara mendapatkan performa terbaik saat bekerja dengan server fleksibel Azure Database for MySQL. Saat kami menambahkan kemampuan baru ke platform, kami akan terus menyempurnakan rekomendasi kami di bagian ini.

Kedekatan fisik

Pastikan Anda menggunakan aplikasi dan database di wilayah yang sama. Pemeriksaan cepat sebelum memulai proses tolok ukur kinerja adalah menentukan latensi jaringan antara klien dan database menggunakan kueri SELECT 1 sederhana.

Ketika sumber daya seperti aplikasi web serta database terkait berjalan di berbagai wilayah, terdapat kemungkinan peningkatan latensi dalam komunikasi antara sumber daya tersebut. Efek lain yang mungkin terjadi pada aplikasi dan database di wilayah terpisah berkaitan dengan biaya transfer data keluar.

Untuk meningkatkan performa dan keandalan aplikasi dalam penyebaran yang dioptimalkan biaya, sangat disarankan agar layanan aplikasi web dan sumber daya server fleksibel Azure Database for MySQL berada di wilayah dan zona ketersediaan yang sama. Kolokasi ini sangat cocok untuk aplikasi yang sensitif terhadap latensi, dan juga memberikan throughput terbaik, karena sumber daya dipasangkan dengan erat.

Jaringan yang dipercepat

Gunakan jaringan yang dipercepat untuk server aplikasi jika Anda menggunakan mesin virtual Azure, Azure Kubernetes, atau App Services. Jaringan Dipercepat memungkinkan virtualisasi I/O root tunggal (SR-IOV) menjadi komputer virtual dan sangat meningkatkan performa jaringannya. Jalur berperforma tinggi ini melewati host dari jalur data, mengurangi latensi, getaran, dan pemanfaatan CPU, untuk digunakan dengan beban kerja jaringan yang paling menuntut pada jenis komputer virtual yang didukung.

Efisiensi koneksi

Membangun koneksi baru selalu merupakan tugas yang mahal dan memakan waktu. Ketika aplikasi meminta koneksi database, aplikasi memprioritaskan alokasi koneksi database menganggur yang ada daripada membuat yang baru. Berikut adalah beberapa opsi untuk praktik koneksi yang baik:

ProxySQL: Gunakan ProxySQL yang menyediakan pengumpulan koneksi bawaan dan menyeimbangkan beban kerja Anda ke beberapa replika baca sesuai permintaan dengan adanya perubahan dalam kode aplikasi.
Heimdall Data Proxy: Atau, Anda juga dapat menggunakan Heimdall Data Proxy, solusi proksi netral-vendor. Ini mendukung caching kueri dan pembelahan baca/tulis dengan deteksi lag replikasi. Anda juga dapat merujuk pada cara mempercepat Performa MySQL dengan proksi Heimdall.
Koneksi Persisten atau Lama: Jika aplikasi Anda memiliki transaksi atau kueri singkat biasanya dengan waktu eksekusi < 5-10 md, maka ganti koneksi singkat dengan koneksi persisten. Ganti koneksi singkat dengan koneksi persisten hanya memerlukan perubahan kecil pada kode, tetapi memiliki efek besar dalam hal meningkatkan performa dalam banyak skenario aplikasi biasa. Pastikan untuk mengatur timeout atau menutup koneksi saat transaksi selesai.
Replika: Jika Anda menggunakan replika, gunakan ProxySQL untuk menyeimbangkan beban antara server utama dan server replika sekunder yang dapat dibaca. Pelajari cara menyiapkan ProxySQL.

Pengumpulan koneksi

Pengumpulan koneksi adalah mekanisme yang mengelola pembuatan dan alokasi koneksi database dan melindungi database dari lonjakan koneksi. Pertimbangkan pengumpulan koneksi apabila aplikasi Anda membuka banyak koneksi dalam waktu yang relatif singkat dan koneksi berumur pendek. Jenis koneksi ini dapat terjadi, misalnya, pada ukuran sebanyak ratusan atau ribuan per detik, dan waktu yang diperlukan untuk membangun dan menutupnya signifikan dibandingkan dengan total masa pakai koneksi.

Apabila kerangka kerja pengembangan aplikasi Anda tidak mendukung pengumpulan koneksi, gunakan proksi koneksi, seperti proksi ProxySQL atau Heimdall, antara aplikasi dan server database.

Menangani penskalaan koneksi

Pendekatan umum untuk menskalakan aplikasi web guna memenuhi permintaan yang berfluktuasi adalah menambahkan dan menghapus server aplikasi. Setiap server aplikasi dapat menggunakan kumpulan koneksi dengan database. Pendekatan ini menyebabkan jumlah total koneksi di server database bertambah sehubungan dengan jumlah server aplikasi. Misalnya, jika server database memiliki 10 server aplikasi dan masing-masing dikonfigurasi untuk 100 koneksi database, maka server database akan memfasilitasi 1.000 koneksi database. Apabila beban kerja aplikasi diskalakan karena aktivitas pengguna yang lebih tinggi atau selama jam sibuk dan apabila 50 server aplikasi tambahan ditambahkan, koneksi database akan berjumlah total 6.000. Biasanya, sebagian besar koneksi ini akan menganggur, setelah dimunculkan oleh server aplikasi. Karena koneksi diam menggunakan sumber daya (memori dan CPU) untuk tetap terbuka, skalabilitas database mungkin terpengaruh.

Potensi tantangan tambahan termasuk penanganan jumlah total koneksi ke server database. Ini ditentukan oleh jumlah server aplikasi yang terhubung ke server database, masing-masing membuat set koneksinya sendiri. Dalam skenario ini, pertimbangkan untuk mengubah kumpulan koneksi di server aplikasi. Cobalah untuk mengurangi jumlah koneksi di setiap kumpulan ke jumlah minimum yang dapat diterima untuk memastikan bahwa tidak ada pembengkakan dalam koneksi di sisi server database. Pertimbangkan ini sebagai solusi jangka pendek untuk melawan efek penskalaan server aplikasi daripada solusi permanen untuk menangani pertumbuhan aplikasi.

Sebagai solusi jangka panjang, perkenalkan proksi koneksi, seperti proksi ProxySQL atau Heimdall, antara server database dan server aplikasi. Ini membantu karena proksi akan:

Membuat koneksi ke server database dengan jumlah koneksi tetap.
Menerima koneksi aplikasi dan bertindak sebagai buffer untuk potensi badai koneksi.

Proksi dapat menyediakan fitur lainnya seperti penembolokan kueri, buffering koneksi, penulisan ulang/perutean kueri, dan penyeimbangan beban. Untuk skalabilitas yang jauh lebih besar, pertimbangkan untuk menggunakan beberapa instans proksi.

Penanganan koneksi untuk toleransi kegagalan dan pemulihan yang lebih cepat

Saat merancang aplikasi dan lingkungan Anda untuk toleransi kesalahan dan pemulihan yang lebih cepat, pertimbangkan bahwa di lingkungan database, Anda cenderung mengalami gangguan koneksi atau kegagalan perangkat keras. Ingat juga kebutuhan akan tindakan operasional seperti penskalaan ukuran instans, patching, dan melakukan failover manual.

Misalnya, pertimbangkan skenario yang mana server database Anda menyelesaikan failover dalam satu menit, tetapi aplikasi Anda tidak berfungsi selama beberapa menit lebih lama karena hal-hal seperti DNS TTL terlalu lama berada di sisi aplikasi. Dalam kasus ini, mengurangi nilai TTL akan memberikan pemulihan yang lebih cepat, atau mengintegrasikan proksi koneksi antara aplikasi dan server database dapat membantu menangani kegagalan tersebut.

Partisi

Ketika beban kerja produksi Anda menggunakan tabel yang sangat besar, pemartisian adalah metode yang bagus untuk meningkatkan performa database dan memudahkan pemeliharaan. Pemartisian memudahkan pengelolaan tabel besar, pendekatan ini memungkinkan Anda untuk menambahkan dan menghilangkan partisi guna mengelola tabel besar secara efektif. Pemartisian juga dapat membantu menskalakan mesin dengan meringankan ketidakcocokan struktur internal seperti kunci internal per tabel atau per indeks (misalnya, pertimbangkan btr_search_latch di InnoDB).

Dengan menambahkan lima partisi, misalnya, Anda pada dasarnya memecah tabel besar dengan banyak aktivitas menjadi lima tabel yang lebih kecil dan lebih efisien. Hal ini terutama akan membantu untuk kasus yang operasi utamanya adalah pencarian kunci primer di tabel, sehingga kueri dapat memanfaatkan "pemangkasan partisi". Tetapi pemartisian juga dapat membantu dalam hal pemindaian tabel.

Perhatikan bahwa meskipun pemartisian memiliki manfaat tersendiri, pemartisian juga memiliki beberapa keterbatasan, seperti kurangnya dukungan untuk kunci asing dalam tabel yang dipartisi, kurangnya cache kueri, dll. Untuk daftar lengkap batasan ini, dalam manual referensi MySQL, lihat bab Pembatasan dan Batasan Pemartisian.

Memisahkan pembacaan dan penulisan

Sebagian besar aplikasi utamanya dibaca dari database, hanya dengan persentase kecil dari interaksi yang melibatkan penulisan. Jumlah koneksi aktif pada database utama yang kami hitung untuk kumpulan koneksi kemungkinan mencakup lalu lintas baca. Membongkar kueri untuk membaca replika sebanyak mungkin dan menjaga akses ke instans bisa-tulis utama meningkatkan jumlah aktivitas database keseluruhan yang dilakukan oleh server aplikasi tanpa meningkatkan muatan pada database utama. Apabila Anda belum mengakses replika baca setidaknya untuk kueri yang berjalan lebih lama seperti laporan, Anda harus mempertimbangkan untuk segera memindahkan pelaporan atau analitik ke replika baca.

Penggunaan replika baca dalam skala yang lebih luas mungkin memerlukan pertimbangan yang lebih teliti, karena replika sedikit tertinggal di belakang replikasi utama karena sifat asinkron replikasi. Temukan area aplikasi sebanyak mungkin yang dapat dilayani dengan bacaan dari replika dengan perubahan kode kecil. Anda juga harus menerapkan metode ini pada tingkat yang lebih tinggi mengenai penembolokan - menyajikan lebih banyak konten baca saja atau perlahan-lahan berubah dari tingkat penembolokan khusus seperti Azure Cache for Redis.

Menulis penskalaan dan sharding

Seiring waktu, aplikasi berevolusi, dan fungsionalitas baru ditambahkan. Demi kenyamanan atau praktik umum, tabel ditambahkan ke database utama. Untuk menangani beban lalu lintas yang berkembang di database, identifikasi area aplikasi yang dapat dengan mudah dipindahkan ke database terpisah dan pertimbangkan untuk melakukan sharding secara horizontal atau memisahkan database secara vertikal.

Sharding database secara horizontal bekerja dengan membuat beberapa salinan skema aplikasi dalam database terpisah dan memisahkan pelanggan serta semua data terkait berdasarkan ID pelanggan, geografi, atau beberapa atribut per pelanggan atau penyewa lainnya. Ini bekerja sangat baik untuk aplikasi SaaS atau B2C tempat pelanggan individu kecil dan beban pada aplikasi berasal dari penggunaan agregat jutaan pelanggan. Namun, ini lebih sulit dengan aplikasi B2B tempat pelanggan memiliki ukuran yang berbeda dan pelanggan besar individu dapat mendominasi beban lalu lintas untuk shard tertentu.

Pisahkan beban secara vertikal dengan secara fungsional melakukan sharding database - memindahkan domain aplikasi terpisah (atau layanan mikro) ke database mereka sendiri. Ini mendistribusikan beban dari database utama untuk memisahkan database per layanan. Contoh sederhana termasuk tabel pengelogan atau informasi konfigurasi situs yang tidak perlu berada dalam database yang sama dengan tabel pesanan yang terisi penuh. Contoh yang lebih rumit termasuk melanggar domain pelanggan dan akun selain dari pesanan atau domain pemenuhan. Dalam beberapa kasus, ini mungkin memerlukan perubahan aplikasi, misalnya untuk mengubah email atau antrean pekerjaan latar belakang menjadi mandiri dan tidak mengandalkan bergabung kembali ke tabel pelanggan atau pesanan. Memindahkan tabel dan data yang ada ke database utama baru dapat dilakukan dengan replika baca server fleksibel Azure Database for MySQL dan mempromosikan replika dan menunjuk bagian aplikasi ke database bisa-tulis yang baru dibuat. Database yang baru dibuat perlu membatasi akses dengan kumpulan koneksi, menyetel kueri, dan menyebarkan beban dengan replikanya sendiri seperti database utama yang asli.

Konfigurasi impor data

Anda dapat menskalakan instans untuk sementara ke ukuran SKU yang lebih tinggi sebelum memulai operasi impor data lalu menurunkan skalanya saat impor berhasil.
Anda dapat mengimpor data dengan downtime minimal dengan menggunakan Azure Database Migration Service (DMS) untuk migrasi online atau offline.

Rekomendasi memori server fleksibel Azure Database for MySQL

Praktik terbaik performa server fleksibel Azure Database for MySQL adalah mengalokasikan RAM yang cukup sehingga set kerja Anda berada hampir sepenuhnya dalam memori.

Periksa apakah persentase memori yang digunakan dalam mencapai batas menggunakan metrik untuk server fleksibel Azure Database for MySQL.
Siapkan peringatan pada nomor tersebut untuk memastikan bahwa saat server mencapai batas, Anda dapat mengambil tindakan cepat untuk memperbaikinya. Berdasarkan batas yang ditentukan, periksa apakah meningkatkan skala SKU database—baik ke ukuran komputasi lebih tinggi atau ke tingkat harga lebih baik, menghasilkan peningkatan performa yang dramatis.
Naikkan skala hingga jumlah performa Anda tidak lagi turun drastis setelah operasi penskalaan. Untuk informasi tentang memantau metrik instans DB, lihat Metrik DB server fleksibel Azure Database for MySQL.

Gunakan Pemanasan kumpulan buffer InnoDB

Setelah instans server fleksibel Azure Database for MySQL dimulai ulang, halaman data yang berada di penyimpanan dimuat saat tabel dikueri yang menyebabkan peningkatan latensi dan performa yang lebih lambat untuk eksekusi pertama kueri. Ini mungkin tidak dapat diterima untuk beban kerja sensitif latensi.

Memanfaatkan pemanasan kumpulan buffer InnoDB memperpendek periode pemanasan dengan memuat ulang halaman disk yang berada di kumpulan buffer sebelum memulai ulang alih-alih menunggu operasi DML atau SELECT untuk mengakses baris yang sesuai.

Anda dapat mengurangi periode pemanasan setelah memulai ulang instans server fleksibel Azure Database for MySQL, yang mewakili keuntungan performa dengan mengonfigurasi parameter server kumpulan buffer InnoDB. InnoDB menyimpan persentase halaman yang terakhir digunakan untuk setiap kumpulan buffer pada shutdown server dan memulihkan halaman ini pada startup server.

Penting juga untuk dicatat bahwa peningkatan performa akan mengorbankan waktu startup yang lebih lama untuk server. Ketika parameter ini diaktifkan, startup server dan waktu restart diperkirakan akan meningkat tergantung pada IOPS yang diprovisikan di server.

Sebaiknya uji dan pantau waktu restart untuk memastikan performa start-up/restart dapat diterima karena server tidak tersedia selama waktu tersebut. Tidak disarankan untuk menggunakan parameter ini dengan kurang dari 1000 IOPS yang diprovisikan (atau dengan kata lain, ketika penyimpanan yang diprovisikan kurang dari 335 GB).

Untuk menyimpan status kumpulan buffer pada shutdown server, atur parameter server innodb_buffer_pool_dump_at_shutdown ke ON. Demikian, atur parameter server innodb_buffer_pool_load_at_startup ke ON untuk memulihkan status kumpulan buffer pada startup server. Anda dapat mengontrol dampak pada waktu start-up/penghidupan ulang dengan menurunkan dan menyempurnakan nilai parameter server innodb_buffer_pool_dump_pct. Secara default, parameter ini diatur ke 25.

Catatan

Parameter pemanasan kumpulan buffer InnoDB hanya didukung di server penyimpanan tujuan umum dengan penyimpanan hingga 16 TB. Untuk informasi selengkapnya, lihat Opsi penyimpanan server fleksibel Azure Database for MySQL.