Siapkan dan uji server baru terlebih dahulu, salin data dengan metode konsistensi yang didukung aplikasi, tentukan jendela cutover, dan pertahankan lingkungan lama. Rollback harus memperhitungkan penulisan yang diterima di server baru, bukan hanya perubahan DNS.
Inventarisasi layanan sebelum memindahkan mesin
Migrasi mencakup lebih dari sekadar file aplikasi. Daftarkan database, unggahan, tugas terjadwal, worker antrean, sertifikat, domain, rahasia, dan integrasi keluar. Catat versi perangkat lunak dan asumsi operasional yang penting, seperti izin file dan jalur penyimpanan. Dedicated server yang baru dapat mengungkap dependensi yang terlupakan yang diam-diam dipasang bertahun-tahun sebelumnya di lingkungan lama.
Tetapkan pemilik untuk keputusan cutover dan tentukan seperti apa keberhasilan. Sertakan pemeriksaan yang terlihat pengguna, konsistensi data, dan kemampuan memulihkan akses. Pastikan konfigurasi baru telah dikirimkan dan dapat digunakan sebelum mengumumkan tanggal migrasi. Konfirmasi order atau spesifikasi perangkat keras yang tercantum tidak sama dengan tujuan yang berfungsi dan siap menerima data produksi.
Bangun tujuan sebagai lingkungan yang terpisah
Pasang stack yang diperlukan, tetapkan administrasi, dan konfigurasikan firewall yang dimaksud. Jaga rahasia tetap privat dan tetapkan izin layanan secara sengaja. Verifikasi hostname dan perilaku sertifikat yang diharapkan aplikasi sebelum lalu lintas publik berpindah. Dokumentasi virtual-host Apache menggambarkan mengapa perutean hostname adalah keputusan konfigurasi yang terpisah dari alamat server. Halaman default yang berfungsi tidak membuktikan bahwa host aplikasi yang benar telah dikonfigurasi.
Gunakan kumpulan data hasil pemulihan yang representatif untuk latihan, dengan email keluar, pembayaran, dan tugas terjadwal dinonaktifkan atau dialihkan ke sistem uji yang aman. Ini mencegah lingkungan uji bertindak terhadap pengguna nyata. Latih login, unggahan, pekerjaan latar belakang, dan pemulihan. Catat prosedur dan durasinya agar jendela sebenarnya didasarkan pada proses yang teramati, bukan optimisme.
Pilih batas data yang konsisten
Gunakan metode backup atau replikasi yang didukung oleh database dan aplikasi. PostgreSQL membedakan dump SQL, backup sistem file, dan pengarsipan berkelanjutan, masing-masing dengan asumsinya sendiri. Panduan dump-nya mencatat bahwa dump database dapat konsisten secara internal sementara peran di seluruh cluster dan detail lainnya perlu ditangani secara terpisah. Baca persyaratan untuk sistem persis yang Anda jalankan alih-alih menyalin file data terbuka secara sembarangan.
Rencanakan bagaimana database berhubungan dengan unggahan dan status antrean. Jika catatan menunjuk ke file yang disalin pada waktu berbeda, aplikasi yang dipulihkan dapat menjadi tidak lengkap meskipun kedua salinan berhasil secara individual. Putuskan apakah akan menjeda penulisan sebentar, menggunakan pengaturan replikasi yang telah diuji, atau melakukan ekspor spesifik aplikasi. Jaga keputusan konsistensi itu tetap eksplisit dalam runbook.
| Tahap | Bukti yang diperlukan | Keputusan |
|---|---|---|
| Latihan | Aplikasi dan data yang dipulihkan lulus pemeriksaan | Tujuan dapat dipertimbangkan untuk cutover |
| Sinkronisasi akhir | Titik pemulihan konsisten yang ditetapkan | Lanjutkan hanya dengan perubahan tersisa yang dipahami |
| Peralihan lalu lintas | Perutean dan perilaku sertifikat yang benar | Pantau kedua tujuan |
| Rollback | Lokasi semua penulisan yang baru diterima | Rekonsiliasi data sebelum mengembalikan lalu lintas |
Siapkan perutean lalu lintas tanpa menjanjikan perubahan instan
DNS time-to-live mengontrol berapa lama catatan dapat di-cache, seperti yang dijelaskan dalam dokumentasi DNS Cloudflare. Tinjau TTL lebih awal jika DNS adalah bagian dari migrasi, dan biarkan catatan yang sudah di-cache menua di bawah pengaturan sebelumnya. Mengubah nilai pada saat cutover tidak dapat secara retroaktif memperpendek setiap jawaban yang di-cache. Klien yang berbeda dapat mencapai tujuan yang berbeda selama transisi.
Pertahankan lingkungan lama tetap tersedia sementara perubahan perutean stabil, dengan kebijakan yang disengaja tentang apakah lingkungan itu masih dapat menerima penulisan. Hindari menjalankan konsumen antrean atau tugas terjadwal yang duplikat kecuali aplikasi dirancang untuk itu. Pantau permintaan di kedua sisi dan konfirmasi hostname, sertifikat TLS, dan versi aplikasi yang dimaksud dari klien independen.
Tentukan rollback setelah penulisan dimulai
Sebelum sistem baru menerima perubahan, mengembalikan lalu lintas mungkin relatif sederhana. Setelahnya, pembalikan DNS saja dapat menghilangkan pekerjaan atau menciptakan dua riwayat yang bertentangan. Tentukan bagaimana catatan dan unggahan yang baru dibuat akan dipertahankan atau direkonsiliasi. Jika aplikasi tidak dapat menggabungkannya dengan aman, periode pemeliharaan terkendali mungkin lebih baik daripada kembali secara improvisasi ke salinan lama.
Tetapkan kondisi yang mengharuskan penjedaannya migrasi, dan pastikan pemilik keputusan dapat dihubungi. Simpan log dan bukti yang berguna sesuai aturan retensi proyek. Jangan menghapus mesin lama atau salinan pemulihan independennya hanya karena halaman beranda pernah dimuat sekali. Periode retensi harus mencakup kebutuhan verifikasi dan rollback yang disepakati.
Tutup migrasi dengan pemeriksaan operasional
Setelah cutover, verifikasi cadangan, peringatan, pembaruan sertifikat, pekerjaan terjadwal, dan pemulihan akses. Pastikan bahwa host yang dipantau adalah tujuan baru dan tidak ada integrasi pengujian yang tersisa di produksi. Tinjau kesalahan aplikasi dan waktu yang terlihat oleh pengguna di bawah lalu lintas biasa. Perbarui inventaris dan runbook agar administrator berikutnya tidak perlu menebak apa yang berubah.
Keluarga khusus SwissOctet menawarkan konfigurasi fisik yang berbeda, tetapi pekerjaan migrasi dan bantuan terkelola harus dikonfirmasi untuk layanan yang dipilih. Gunakan katalog untuk memilih sumber daya yang sesuai, lalu bangun pemindahan yang teruji di sekitar data aplikasi Anda. Migrasi selesai ketika layanan dan proses pemulihannya berfungsi di tujuan, bukan sekadar ketika file telah dipindahkan.
Daftar periksa praktis Anda.
- Inventarisasi data, pekerjaan, rahasia, dan integrasi.
- Verifikasi tujuan yang dikirimkan sebelum penjadwalan.
- Lakukan uji coba dengan integrasi eksternal yang aman.
- Tentukan konsistensi basis data dan unggahan.
- Rencanakan transisi perutean dan pencegahan pekerjaan duplikat.
- Tentukan rollback untuk penulisan baru.
- Verifikasi cadangan dan pemantauan setelah cutover.
Detail yang penting.
Bisakah saya bermigrasi dengan menyalin direktori aplikasi?+
Hanya jika itu menangkap semua yang dibutuhkan layanan dan menjaga konsistensi. Basis data, unggahan, pekerjaan, rahasia, dan konfigurasi biasanya memerlukan perhatian terpisah.
Apakah menurunkan TTL DNS membuat cutover instan?+
Tidak. Jawaban yang sebelumnya di-cache dapat tetap ada hingga masa berlakunya yang lebih awal berakhir, dan klien dapat memperbarui pada waktu yang berbeda.
Apakah rollback hanya mengarahkan DNS ke server lama?+
Tidak setelah server baru menerima penulisan. Anda harus memperhitungkan catatan dan file tersebut sebelum mengembalikan lalu lintas.
Kunjungi sumbernya.
Referensi ini mendukung konsep teknis dalam panduan ini. Ikuti dokumentasi terkini sebelum mengubah sistem produksi.
- PostgreSQL: Pencadangan dan Pemulihan www.postgresql.org
- PostgreSQL: Konsistensi dan pemulihan SQL Dump www.postgresql.org
- Apache: Dokumentasi Virtual Host httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Panduan editorial oleh SwissOctet. Contoh bersifat ilustratif. Spesifikasi layanan, opsi yang tersedia, dan ketentuan kontraktual harus diverifikasi secara terpisah.