Pagi ini saya selesai memindahkan sistem dan database MySQL Server dari sistem lama berupa server fisik IBM X Series 3400 ke Server (sementara) HP Proliant ML. Server lama menggunakan sistem operasi openSUSE 11.0 sedangkan server baru menggunakan SUSE Linux Enterprise Server (SLES) 11 JeOS yang menjadi Xen Hypervisor Guest. Sistem fisik dari HP Proliant ML ini menggunakan SLES 11 yang dioptimasi untuk menjadi Xen Hypervisor host.
Mengingat database MySQL Server ini merupakan data yang paling urgent dan digunakan oleh semua department, saya agak paranoid memindahkannya. Proses ujicoba dilakukan selama 2 minggu dengan berbagai metode antara lain :
- Proses Dump SQL. Cara ini gagal karena salah satu program aplikasi yaitu program aplikasi penggajian menggunakan data yang dienkripsi. Data yang dienkripsi ini menggunakan karakter dan simbol khusus yang membuat proses dumping menjadi kacau. Daripada satu group perusahaan nggak gajian lebih baik saya batalkan opsi ini 🙂
- Proses Sinkronisasi Database. Proses ini pernah saya lakukan sewaktu memindahkan data SQL Server ke MySQL namun cara ini juga tidak saya ambil karena prosesnya lama dan sinkronisasi hanya berjalan pada tabel, sementara view, stored procedure dan trigger tidak ikut serta.
- Replikasi Database. Metodenya adalah menggunakan model master & slave. Setiap perubahan data pada database master akan langsung direplikasi ke database slave. Opsi ini tidak saya ambil karena saya harus mengubah konfigurasi sistem. Opsi ini tetap menjadi pilihan jika cara lain mengalami kegagalan
- Manual Copy. Cara ini saya ambil karena salah satu staff IT pernah berhasil melakukannya pada salah satu group perusahaan. Metodenya menggunakan perintah rsync.
Berikut adalah detail proses pemindahan menggunakan sistem manual copy yang saya lakukan :
- Siapkan server baru. Install sistem operasi dalam modus seminimal mungkin, itu sebabnya saya menggunakan SLES dengan basis JeOS (Just Enough Operating System), yang bahkan lebih minimalis daripada sekedar install Text Mode
- Install package MySQL Database Server di server baru. Saya melakukan instalasi dari DVD SLES 11 menggunakan perintah : zypper in mysql. Instalasi dapat juga dilakukan menggunakan yast
- Jalankan Service MySQL Database Server di server baru. Jalankan dengan perintah : service mysql start. Pada saat pertama kali dijalankan, MySQL akan membuat struktur data untuk pertama kali. Setelah selesai, matikan kembali service MySQL tersebut dengan perintah : service mysql stop
- Shut down Service MySQL Induk. Kebetulan pada hari Minggu malam tidak ada jadwal kegiatan yang menggunakan database, jadi saya bisa ssh ke kantor untuk melakukan perintah service mysql stop dan kemudian melakukan rsync data ke server baru.
- Salin Data. Saya menggunakan perintah rsync untuk menyalin seluruh isi folder /var/lib/mysql dan kemudian memindahkannya ke server baru. Sebagai tindakan berjaga-jaga, saya menempatkan data ini tidak langsung ke /var/lib/mysql di server baru melainkan di salah satu sub folder /srv. Sebagai catatan, saya juga menyalin file konfigurasi MySQL server lama yang ada di /etc/my.cnf.
Saat pertama kali mencoba, saya menyalin keseluruhan isi folder namun ternyata service MySQL tidak dapat dijalankan. Saya mengulang proses pemindahan namun membiarkan sub folder mysql (yang berisi tabel mysql, user, hak akses dll) tidak tersentuh. Ternyata cara ini berhasil. Service MySQL bisa dijalankan dan program aplikasi bisa mengaksesnya, hanya saja saya perlu melakukan sinkronisasi data user dan hak akses karena saya tidak menimpa folder data MySQL.
Setelah service MySQL Server berjalan dengan baik, ternyata masih ada 1 masalah tersisa, yaitu user tidak bisa menghapus atau membuat view dengan pesan : Error code 13. Googling beberapa workaround tanpa hasil, saya melakukan investigasi permission folder masing-masing database dan ternyata ada database yang hak akses Read/Writenya dipegang oleh root. Saya mengubah permission aksesnya dan masalahnya dapat terselesaikan.
Saat ini MySQL database server sudah dipergunakan sebagaimana biasanya.
8 Comments
saya kok penasaran kenapa dump sql gagal? karna imho, prosedur backup/restore dr dump relatif lebih aman dibanding mengcopy langsung dr filesystem (terutama kalo antara dua db itu berbeda versi)
mungkin sewaktu dump perlu diset charset yg cocok supaya special char yg ada di data nggak kacau ?
Charsetnya sudah diset ke beberapa tipe mas (aku standar pakai UTF-8) tapi gagal maning-gagal maning. Ketahuan gagalnya pas coba di decrypt datanya kacau.
Kalau moving database hosting biasanya aku memang pakai dump tapi kalau data dalam ukuran yang cukup besar dan ada dihadapan, aku ambil berbagai cara.
Anyway, saat ini sih kelihatannya lancar dan nggak ada yang aneh-aneh.
Kalo sampe data asli dg data hasil restore beda, bisa jadi ini bug yg hrsnya dpt prioritas tinggi.
Bisa nggak kira2 saya dpt contoh data (tentunya nggak perlu data asli), supaya saya jg bisa nyoba mereproduksi bug ini ?
/me sedikit khawatir karna selama ini selalu mengandalkan dump unt backup (selain replikasi unt live backup).
Makasih sebelumnya mas
@Dheche,
Hmmh, mungkin akan saya coba salin beberapa isi tabel untuk field tertentu.
Akan saya usahakan mas.
#vavai: saran, mungkin di nomor 4 ada baiknya rsync dilakukan waktu mysql masih hidup. kemudian dilakukan pengulangan rsync dengan kondisi mysql sudah mati. ini akan memperkecil waktu downtime.
#dheche: lagi gak onok kerjaan ta? kene ngewangi aku ae wes.
@Dudi,
Kalau MySQL sedang berjalan, nanti ada pesan soal MySQL sock. Secara prinsip usulannya sudah dilakukan dengan membuat cron jobs backup pada waktu malam/dini hari, cuma tetap ada perintah service mysql stop diawal script backup 🙂
#vavai: owh baru tau kalo akan error di mysql.sock. soalnya dulu pernah coba cara yang sama di firebird gak ada masalah.
err, kalau mysql.sock di exclude dari proses rsync, proses rsyncnya masih mau jalan gak ya? *jadi penasaran*
@dudi: lho mosok perlu diewangi ? gak mampu ta? halah ini kok malah nyampah di tempet orang .. maap oom vavai 🙂
btw, kalo mau ngurangi waktu downtime, backup pake lvm snapshot baru di rsync.