Memindahkan database dari server lain
Prosedur migrasi database ke Millida VDS: persiapan, transfer dump melalui jaringan, pemeriksaan integritas, dan pengalihan aplikasi dengan downtime minimal.
Diperbarui 23 Agustus 2026
Migrasi database tidak gagal karena perintahnya — melainkan karena urutan langkahnya: orang-orang mengganti domain terlebih dahulu dan baru kemudian menyadari bahwa separuh data tidak pernah ikut pindah. Berikut adalah urutan yang mencegah hal itu.
Persiapan
Di mesin baru, pasang versi database server yang sama atau lebih baru — PostgreSQL atau MySQL. Downgrade tidak didukung.
psql --version
mysql --version
df -h /
Anda memerlukan ruang kosong sekitar 2,5 kali ukuran database: untuk dump, data yang diekstrak, dan sedikit cadangan. Di VDS-1 totalnya 40 GB, jadi rencanakan sejak awal.
Buat pengguna dan database kosong dengan encoding yang sama seperti di server lama.
Memindahkan data
Cara paling sederhana adalah dump melalui SSH, tanpa file perantara:
ssh root@OLD 'pg_dump -Fc -U shop shop' > /srv/shop.dump
pg_restore -U postgres -d shop --no-owner --role=shop /srv/shop.dump
Untuk MySQL:
ssh root@OLD 'mysqldump --single-transaction --routines --events -u root shop' \
| mysql -u root shop
Role dan pengguna tidak termasuk dalam dump database — ekspor secara terpisah: pg_dumpall --roles-only, atau buat secara manual — lihat pengguna dan grant.
Bandwidth mencapai 500 Mbps, jadi database 20 GB bermigrasi hanya dalam hitungan menit; hambatan biasanya ada pada penulisan disk, yang dibatasi oleh tier.
Verifikasi sebelum beralih
Periksa angkanya, bukan sekadar "situs berhasil dimuat":
SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;
SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='shop';
Bandingkan jumlah baris pada tabel-tabel kunci dengan server lama, pastikan sequence tidak ter-reset (SELECT last_value FROM users_id_seq;), dan jalankan aplikasi terhadap database baru dalam mode uji.
Beralih
- Aktifkan mode maintenance atau hentikan aplikasi di server lama.
- Ambil dump terakhir untuk perubahan yang terjadi selama persiapan.
- Pulihkan di mesin baru.
- Ganti connection string aplikasi dan restart layanan.
- Biarkan server lama tetap berjalan selama satu minggu lagi tanpa menghapus data.
Jangan lewati langkah kelima: menemukan tabel yang hilang tiga hari kemudian adalah hal yang biasa.
Kesalahan umum
| Gejala | Penyebab |
|---|---|
role does not exist saat restore | Role tidak dimigrasikan — gunakan --no-owner ditambah pembuatan role secara manual |
| Karakter rusak | Encoding tidak cocok: pulihkan ke database dengan utf8mb4 atau UTF8 |
| Sequence mulai dari 1 | Dump hanya berisi data, tanpa setval |
| Restore memakan waktu berjam-jam | Index dibangun saat proses berjalan; untuk database besar gunakan pg_restore -j 4 |
| Kehabisan ruang di tengah jalan | Ukuran dump di samping data tidak diperhitungkan |
Sebelum migrasi, pastikan database baru hanya mendengarkan di
127.0.0.1. Tidak perlu mengeksposnya ke publik "selama migrasi" — transfer dilakukan melalui SSH, lihat akses jarak jauh.