Praktik terbaik untuk membangun aplikasi dengan Azure Database for MySQL

  • Artikel

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?

Berikut adalah beberapa praktik terbaik untuk membantu Anda membangun aplikasi siap cloud menggunakan Azure Database for MySQL. Praktik terbaik ini dapat mengurangi waktu pengembangan untuk aplikasi Anda.

Konfigurasi aplikasi dan sumber daya database

Mempertahankan aplikasi dan database di wilayah yang sama

Pastikan semua dependensi Anda berada di wilayah yang sama saat menyebarkan aplikasi Anda di Azure. Menyebarkan instans di seluruh wilayah atau zona ketersediaan akan menciptakan latensi jaringan, yang dapat memengaruhi performa keseluruhan aplikasi Anda.

Jaga keamanan server MySQL Anda

Konfigurasikan server MySQL Anda agar aman dan tidak dapat diakses secara publik. Gunakan salah satu opsi ini untuk mengamankan server Anda:

Untuk keamanan, Anda harus selalu tersambung ke server MySQL Anda melalui SSL dan mengonfigurasi server MySQL dan aplikasi Anda untuk menggunakan TLS 1.2. Lihat Cara mengonfigurasi SSL/TLS.

Gunakan jaringan canggih dengan AKS

Ketika jaringan yang dipercepat diaktifkan pada VM, ada latensi yang lebih rendah, berkurangnya jitter, dan penurunan pemanfaatan CPU pada VM. Untuk mempelajari lebih lanjut, lihat Praktik terbaik untuk Azure Kubernetes Service dan Azure Database for MySQL.

Menyetel parameter server Anda

Untuk parameter server penyetelan beban kerja sulit dibaca, tmp_table_size dan max_heap_table_size dapat membantu mengoptimalkan performa yang lebih baik. Untuk menghitung nilai yang diperlukan untuk variabel ini, lihat nilai total per koneksi dan memori dasar. Jumlah parameter memori per koneksi, tidak termasuk tmp_table_size, dikombinasikan dengan akun memori dasar untuk total memori server.

Untuk menghitung ukuran terbesar yang mungkin dari tmp_table_size dan max_heap_table_size, gunakan rumus berikut:

(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections

Catatan

Total memori menunjukkan jumlah total memori yang dimiliki server di seluruh vCores yang disediakan. Misalnya, dalam server General Purpose two-vCore Azure Database for MySQL, total memori akan menjadi 5 GB * 2. Anda dapat menemukan detail lebih lanjut tentang memori untuk setiap tingkatan dalam dokumentasi tingkat harga.

Memori dasar menunjukkan variabel memori, seperti query_cache_size dan innodb_buffer_pool_size, bahwa MySQL akan menginisialisasi dan mengalokasikan pada awal server. Memori per koneksi, seperti sort_buffer_size dan join_buffer_size, adalah memori yang dialokasikan hanya saat kueri membutuhkannya.

Membuat pengguna nonadmin

Buat pengguna nonadmin untuk setiap database. Biasanya, nama pengguna diidentifikasi sebagai nama database.

Mereset kata sandi Anda

Anda dapat mengatur ulang kata sandi untuk server MySQL Anda menggunakan portal Azure.

Mereset kata sandi server Anda untuk database produksi dapat menurunkan aplikasi Anda. Ini adalah praktik yang baik untuk mereset kata sandi untuk setiap beban kerja produksi pada jam sibuk untuk meminimalkan dampak pada pengguna aplikasi Anda.

Performa dan ketahanan

Berikut adalah beberapa alat dan praktik untuk membantu men-debug masalah performa aplikasi Anda.

Aktifkan log kueri lambat untuk mengidentifikasi masalah performa

Anda bisa mengaktifkanlog kueri lambat dan log audit pada server Anda. Menganalisis log kueri lambat dapat membantu mengidentifikasi hambatan performa untuk pemecahan masalah.

Log audit juga tersedia melalui log Azure Diagnostics di log Azure Monitor, Azure Event Hubs, dan akun penyimpanan. Lihat Cara memecahkan masalah performa kueri.

Gunakan pengumpulan koneksi

Mengelola koneksi database dapat berdampak signifikan pada performa aplikasi secara keseluruhan. Untuk mengoptimalkan performa, Anda harus mengurangi berapa kali koneksi dibuat dan waktu untuk membuat koneksi di jalur kode kunci. Gunakan pengumpulan koneksi untuk menyambungkan ke Azure Database for MySQL untuk meningkatkan ketahanan dan performa.

Anda dapat menggunakan pengumpul koneksi ProxySQL untuk mengelola koneksi secara efisien. Menggunakan pengumpul koneksi dapat mengurangi koneksi diam dan menggunakan kembali koneksi yang ada, yang membantu menghindari masalah. Lihat Cara menyiapkan ProxySQL untuk mempelajari lebih lanjut.

Mencoba ulang logika untuk menangani kesalahan sementara

Aplikasi Anda mungkin mengalami kesalahan sementara saat koneksi ke database hilang atau terputus-putus. Dalam situasi seperti itu, server siap dan berjalan setelah satu hingga dua percobaan kembali dalam 5 hingga 10 detik.

Latihan yang baik adalah menunggu selama 5 detik sebelum percobaan kembali Anda yang pertama. Kemudian ikuti setiap percobaan kembali dengan meningkatkan penantian secara bertahap, hingga 60 detik. Batasi jumlah maksimum percobaan ulang, di mana aplikasi Anda menganggap operasi gagal, sehingga Anda dapat menyelidiki lebih lanjut. Lihat Cara memecahkan masalah kesalahan koneksi untuk mempelajari lebih lanjut.

Aktifkan replikasi baca untuk mengurangi failovers

Untuk skenario failover, Anda dapat menggunakan Replikasi Data-in. Tidak ada failover otomatis antara server sumber dan replika yang terjadi saat menggunakan replika baca.

Anda melihat jeda antara sumber dan replika karena replikasi asinkron. Jeda jaringan dapat dipengaruhi oleh banyak faktor, seperti ukuran beban kerja yang berjalan di server sumber dan latensi antara pusat data. Dalam kebanyakan kasus, jeda replika berkisar dari beberapa detik hingga beberapa menit.

Penyebaran database

Konfigurasikan tugas Azure database for MySQL di saluran penyebaran CI/CD Anda

Terkadang, Anda perlu menyebarkan perubahan pada database Anda. Dalam kasus seperti itu, Anda dapat menggunakan integrasi berkelanjutan (CI) dan pengiriman berkelanjutan (CD) melalui Azure Pipelines dan menggunakan tugas untuk server MySQL Anda untuk memperbarui database dengan menjalankan skrip kustom terhadapnya.

Gunakan proses yang efektif untuk penyebaran database manual

Selama penyebaran database manual, ikuti langkah-langkah ini untuk meminimalkan waktu henti atau mengurangi risiko penyebaran yang gagal:

  1. Buat salinan database produksi pada database baru dengan menggunakan mysqldump atau MySQL Workbench.
  2. Perbarui database baru dengan perubahan atau pembaruan skema baru yang diperlukan untuk database Anda.
  3. Letakkan database produksi dalam keadaan read-only. Akan lebih baik jika Anda tidak memiliki operasi tulis pada database produksi hingga penyebaran selesai.
  4. Uji aplikasi Anda dengan database yang baru diperbarui dari langkah 1.
  5. Sebarkan perubahan aplikasi Anda dan pastikan aplikasi sekarang menggunakan database baru dengan pembaruan terbaru.
  6. Pertahankan database produksi lama untuk mengembalikan perubahan. Anda kemudian dapat mengevaluasi untuk menghapus database produksi lama atau mengekspornya di Azure Storage jika diperlukan.

Catatan

Jika aplikasi seperti aplikasi e-niaga dan Anda tidak dapat menempatkannya dalam status baca-saja, sebarkan perubahan langsung pada database produksi setelah membuat cadangan. Perubahan ini harus terjadi selama jam sibuk dengan lalu lintas rendah ke aplikasi untuk meminimalkan dampak karena beberapa pengguna mungkin mengalami permintaan yang gagal.

Pastikan kode aplikasi Anda juga menangani permintaan yang gagal.

Gunakan metrik asli MySQL untuk melihat apakah beban kerja Anda melebihi ukuran tabel sementara dalam memori

Dengan beban kerja baca-berat, kueri terhadap server MySQL Anda mungkin melebihi ukuran tabel sementara dalam memori. Beban kerja baca-berat dapat menyebabkan server Anda beralih menulis tabel sementara ke disk, yang memengaruhi performa aplikasi Anda. Untuk menentukan apakah server Anda menulis ke disk sebagai akibat dari melebihi ukuran tabel sementara, lihat metrik berikut:

show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';

Metrik created_tmp_disk_tables menunjukkan berapa banyak tabel yang dibuat pada disk. Mengingat beban kerja Anda, created_tmp_table metrik memberi tahu Anda berapa banyak tabel sementara yang harus dibentuk dalam memori. Untuk menentukan apakah kueri tertentu menggunakan tabel sementara, jalankan pernyataan EXPLAIN pada kueri. Detail dalam extra kolom menunjukkan Using temporary apakah kueri berjalan menggunakan tabel sementara.

Untuk menghitung persentase beban kerja Anda dengan kueri yang meluap ke disk, gunakan nilai metrik Anda dalam rumus berikut:

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

Idealnya, persentase ini harus kurang dari 25%. Jika persentasenya adalah 25% atau lebih besar, sebaiknya ubah dua parameter server, tmp_table_size, dan max_heap_table_size.

Skema database dan kueri

Berikut adalah beberapa tips yang perlu diingat saat membuat skema dan kueri database Anda.

Gunakan tipe data yang benar untuk kolom tabel Anda

Menggunakan jenis data yang benar berdasarkan jenis data yang ingin Anda simpan dapat mengoptimalkan penyimpanan dan mengurangi kesalahan karena jenis data yang salah.

Menggunakan indeks

Untuk menghindari kueri lambat, Anda bisa menggunakan indeks. Indeks dapat membantu menemukan baris dengan kolom tertentu dengan cepat. Lihat Cara menggunakan indeks di MySQL.

Gunakan JELASKAN untuk kueri PILIH Anda

Gunakan pernyataan EXPLAIN untuk mendapatkan insight tentang apa yang dilakukan MySQL untuk menjalankan kueri Anda. Ini dapat membantu Anda mendeteksi hambatan atau masalah dengan kueri Anda. Lihat Cara menggunakan JELASKAN untuk performa kueri profil.