Setiap kisah horor migrasi punya bagian tengah yang sama: seseorang mengganti DNS lebih dulu, baru kemudian mulai menyalin. Downtime saat pindah hampir tidak pernah disebabkan oleh penyalinan yang lambat. Penyebabnya adalah urutan langkah yang salah.
Inilah urutan yang berhasil, baik Anda meninggalkan penyedia lain maupun pindah di antara dua tarif kami.
1. Dua hari sebelumnya: turunkan TTL
Cari catatan DNS yang akan Anda ubah (biasanya A, AAAA, dan CNAME yang menunjuk ke sana) lalu turunkan TTL-nya menjadi 300 detik. Kemudian tunggu setidaknya selama TTL lama. Catatan dengan TTL sehari berarti sebagian resolver akan terus memberikan alamat lama sehari setelah perubahan, dan tidak ada yang Anda lakukan di server yang bisa mempercepatnya.
Ini langkah yang paling sering dilewati, dan langkah inilah yang mengubah peralihan lima menit menjadi sehari ketika separuh pengguna melihat server lama.
2. Inventarisasi server lama
Anda akan membangun ulang mesin ini di tempat lain, jadi catat apa yang sebenarnya ia kerjakan. Bukan yang Anda ingat. Yang ia kerjakan:
ss -tlnp # what is listening, and which process
crontab -l; ls /etc/cron.d # scheduled jobs
systemctl list-timers --all # the scheduled jobs people forget
systemctl list-units --type=service --state=running
Tambahkan ke daftar: sertifikat TLS dan cara perpanjangannya, file environment berisi rahasia, aturan firewall, pengguna dan kunci SSH mereka, database dan ukurannya, serta apa pun yang berkomunikasi dengan server lewat alamat IP. Kelompok terakhir ini yang licik: allowlist milik mitra, pengaturan webhook penyedia pembayaran, pemeriksaan pemantauan.
3. Bangun server baru di samping yang lama
Pesan server baru dan biarkan yang lama. Pilih tarif dari daftar VPS dengan disk yang sama atau lebih besar dari yang benar-benar Anda pakai, bukan yang dijual kepada Anda. Jika mesin lama menerima trafik masuk apa pun (situs web, webhook, API), yang baru butuh IPv4 sendiri. Tarif NAT hanya menerima koneksi masuk di port SSH-nya, dan apa yang bisa dan tidak bisa dilakukan satu port yang diteruskan menjelaskan mengapa itu penting.
Hubungkan, pasang paket yang sama, buat ulang pengguna dan firewall. Panduan koneksi membahas kunci dan login pertama.
4. Sinkronkan file dua kali
Sinkronisasi pertama menyalin semuanya sementara server lama tetap bekerja. Bisa memakan waktu berjam-jam; tidak masalah.
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
--numeric-ids mempertahankan kepemilikan file berdasarkan nomor, sehingga menghindari kejutan klasik "semuanya milik pengguna yang salah" saat kedua sistem membuat pengguna dengan urutan berbeda. Jika Anda belum pernah memakai rsync lewat SSH, cara mentransfer file ke VPS menjelaskannya langkah demi langkah.
Sinkronisasi kedua, tepat sebelum peralihan, hanya menyalin yang berubah sejak yang pertama. Biasanya hanya beberapa detik.
5. Pindahkan database dengan sengaja
File itu mudah. Database yang menerima penulisan adalah satu-satunya bagian di mana "tanpa downtime" butuh sedikit kompromi atau kerja tambahan.
Cara sederhana: buat dump dan pulihkan sekali untuk pengujian, lalu saat peralihan hentikan penulisan selama satu menit (ubah aplikasi ke mode baca saja atau hentikan), buat dump baru, pulihkan di server baru, dan jalankan aplikasinya di sana. Untuk kebanyakan proyek kecil, itu jeda satu atau dua menit yang diumumkan sebelumnya.
Cara tanpa jeda: siapkan replikasi dari database lama ke yang baru, biarkan menyusul, lalu jadikan yang baru sebagai utama saat peralihan. Penyiapannya lebih banyak, dan sepadan bila bahkan satu menit penulisan yang hilang tidak bisa diterima.
6. Uji server baru sebelum orang lain melihatnya
DNS masih menunjuk ke server lama, jadi Anda bisa menguji yang baru secara pribadi. Kirim permintaan untuk domain asli Anda ke alamat baru:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
Jika sertifikatnya belum ada, uji dengan cara yang sama lewat HTTP, atau tambahkan baris sementara di file hosts lalu jelajahi situs di browser. Periksa login, unggahan, tugas latar belakang, dan email keluar. Ini saat termurah untuk menemukan ekstensi PHP yang hilang.
7. Beralih, dan biarkan server lama tetap menyala
Lakukan sinkronisasi file terakhir dan langkah database, lalu ganti catatan DNS. Dengan TTL 300 detik, sebagian besar trafik pindah dalam hitungan menit. Pantau log akses server lama: masih akan ada tetesan permintaan dari resolver dan klien yang mengabaikan TTL. Biarkan menyala tanpa diubah selama beberapa hari. Lalu perbarui semua yang menunjuk ke IP lama: allowlist mitra, URL webhook, dan untuk email, reverse DNS alamat baru (pada tarif IP khusus kami, Anda mengaturnya sendiri, lihat reverse DNS) serta catatan SPF Anda.
Yang paling sering rusak
Kira-kira sesuai urutan seberapa sering kami melihatnya: timer systemd yang tidak dicatat siapa pun, file konfigurasi dengan IP lama tertulis langsung, file milik pengguna yang salah, firewall yang memblokir port aplikasi itu sendiri, sertifikat yang diperpanjang di server lama tetapi tidak di server baru, dan email yang masuk spam karena alamat baru belum punya reverse DNS.
Di mana daftar periksa ini tidak cocok
Database sibuk dengan penulisan terus-menerus dan tanpa toleransi jeda butuh replikasi sungguhan dan gladi bersih, bukan daftar periksa dari blog. Server Windows dipindahkan dengan alat yang berbeda dari rsync. Dan jika pindahnya sebenarnya soal ukuran, baca ini dulu: di sini tarif bisa tumbuh di tempat. Pindah ke tarif lebih besar dengan jenis jaringan yang sama menambah vCPU, RAM, dan disk dengan satu kali reboot, tanpa migrasi apa pun. Server baru hanya diperlukan untuk mengecil. Jika Anda pindah karena tidak yakin mesinnya cukup besar, kapan Anda benar-benar butuh RAM 64 GB mungkin menghemat perjalanan Anda, dan VPS vs shared hosting vs dedicated vs cloud membantu jika Anda ragu VPS adalah rumah yang tepat.
Komentar
Belum ada komentar. Jadilah yang pertama.