Jasa Managed MySQL & MariaDB

Langkah optimasi yang kami jalankan

Optimasi dimulai dari pengukuran, bukan tebakan. Kami mengaktifkan pencatatan kueri lambat, mengumpulkan data selama beberapa hari, lalu memperbaiki yang paling banyak menghabiskan waktu:

• Penyesuaian ukuran buffer pool InnoDB terhadap memori yang tersedia.
• Analisis kueri lambat dan penambahan indeks yang benar-benar dipakai.
• Penghapusan indeks berlebih yang justru memperlambat operasi tulis.
• Penyesuaian parameter koneksi dan penerapan connection pooling bila diperlukan.
• Pemeriksaan tipe data dan skema tabel yang boros ruang.
• Penjadwalan pemeliharaan tabel dan pembersihan data lama.

Replikasi dan ketersediaan

Replikasi memberi salinan data yang selalu segar sekaligus meringankan server utama, karena kueri baca bisa diarahkan ke replika. Untuk aplikasi dengan banyak pembacaan, dampaknya sangat terasa.

Kami menyiapkan topologi sesuai kebutuhan: replikasi sederhana untuk cadangan, atau konfigurasi dengan failover otomatis. Setiap konfigurasi disertai prosedur tertulis tentang langkah yang harus diambil ketika failover terjadi, karena saat itulah kepanikan paling mudah menimbulkan kesalahan baru.

Backup yang konsisten dan teruji

Menyalin direktori data saat basis data sedang berjalan menghasilkan cadangan yang hampir pasti rusak. Karena itu kami memakai perkakas yang memahami internal MySQL sehingga cadangan diambil dalam keadaan konsisten tanpa mengunci tabel terlalu lama.

Cadangan disimpan di lokasi terpisah, dienkripsi, dan diuji pemulihannya secara berkala ke lingkungan uji. Hasil pengujian itu Anda terima sebagai catatan, bukan sekadar pernyataan bahwa backup berjalan.

Menemukan dan memperbaiki optimasi query MySQL lambat

Pekerjaan optimasi query MySQL lambat dimulai dari pengukuran, bukan dugaan. Log kueri lambat diaktifkan dengan ambang yang wajar, dibiarkan mengumpulkan data beberapa hari, lalu diringkas untuk melihat kueri mana yang paling banyak menghabiskan total waktu — bukan yang paling lambat sekali jalan.

Perbedaan itu penting. Kueri yang butuh tiga detik tapi dijalankan sekali sehari jauh kurang penting daripada kueri 200 milidetik yang dijalankan lima ribu kali per jam. Yang kedua itulah yang sesungguhnya membebani server.

Setelah kandidatnya ketemu, rencana eksekusinya dibaca untuk melihat apakah indeks dipakai atau seluruh tabel dipindai. Sebagian besar perbaikan berhenti di situ: menambahkan satu indeks gabungan yang cocok dengan pola filter dan pengurutan kueri tersebut.

Tuning InnoDB buffer dan parameter memori

Nilai bawaan MySQL dirancang agar bisa berjalan di mesin apa pun, termasuk yang bermemori sangat kecil. Pada server produksi, tuning InnoDB buffer adalah perubahan tunggal yang paling sering memberi peningkatan terbesar.

Sebagai titik awal, buffer pool diberi sekitar 60 hingga 70 persen memori server bila mesin itu hanya menjalankan basis data. Kalau aplikasi berjalan di server yang sama, porsinya diturunkan agar tidak saling berebut dan berujung pada pemakaian swap — yang justru membuat semuanya jauh lebih lambat.

Parameter lain yang ikut disetel: ukuran log transaksi, jumlah koneksi maksimum yang realistis, dan perilaku penulisan ke disk. Yang terakhir menentukan keseimbangan antara performa dan seberapa banyak data yang bisa hilang saat mati mendadak — dan itu keputusan bisnis, bukan keputusan teknis, jadi kami tanyakan lebih dulu.

Replikasi MySQL master slave dan pemanfaatannya

Menyiapkan replikasi MySQL master slave memberi dua hal sekaligus: salinan data yang selalu segar untuk keadaan darurat, dan kemampuan mengarahkan kueri baca ke replika sehingga beban server utama berkurang. Untuk aplikasi yang jauh lebih banyak membaca daripada menulis, dampaknya langsung terasa.

Yang perlu diawasi adalah jeda replikasi. Kalau replika tertinggal beberapa detik, aplikasi yang langsung membaca data yang baru saja ditulis bisa mendapat hasil lama. Karena itu pengarahan kueri baca harus selektif — laporan dan pencarian ke replika, sementara alur yang menulis lalu langsung membaca tetap ke server utama.

Jeda replikasi dipantau dengan ambang notifikasi, karena replika yang tertinggal jauh sudah tidak berguna sebagai cadangan darurat.

Backup MySQL otomatis dan recovery database MariaDB

Menyalin direktori data saat basis data sedang menulis hampir pasti menghasilkan cadangan yang rusak. Karena itu backup MySQL otomatis yang kami pasang memakai perkakas yang memahami internal InnoDB, sehingga cadangan konsisten tanpa mengunci tabel terlalu lama.

Untuk kemampuan pemulihan sampai titik waktu tertentu, log biner ikut diarsipkan. Kombinasi cadangan penuh malam hari plus log biner sepanjang hari memungkinkan pemulihan ke menit tertentu — misalnya satu menit sebelum perintah penghapusan yang keliru dijalankan.

Untuk recovery database MariaDB setelah kerusakan, hal pertama yang harus dilakukan justru menghentikan penulisan baru, bukan mencoba memperbaiki. Setiap penulisan setelah kerusakan mengurangi peluang pemulihan yang bersih. Kalau Anda sedang menghadapi situasi ini, hentikan layanannya lalu hubungi kami.

Untuk proyek baru yang basis datanya belum ditentukan, kami menulis perbandingan MySQL dan PostgreSQL yang membahas kapan berpindah sepadan dan kapan justru tidak perlu.