Bagaimana Saya Memindahkan Database dan Arsip Log Melintasi Versi Mayor Tanpa Jalan Kembali

Sebuah server bertahun-tahun berjalan di versi software yang itu-itu saja. Bukan karena ada yang memutuskan membiarkannya, melainkan karena ia bekerja, dan selalu ada urusan yang lebih mendesak. Lalu versi yang dipakainya berhenti didukung — dan upgrade-nya ternyata jenis yang tak bisa dibatalkan.

Ketaksetaraan itulah, lebih daripada angka versinya, yang jadi pokok tulisan ini.

Pendahuluan

Tiap software yang berjalan punya versi: nomor yang menandai persis rilis mana yang sedang dipakai. Server menumpuk nomor semacam itu — database punya versi, penyimpan file punya versi, mesin pencari yang mengindeks log punya versi — dan tiap nomor bergerak maju menurut jadwalnya sendiri.

Sebagian besar waktu, nomor itu boleh diabaikan sepenuhnya. Software diperbarui, angkanya naik, tak ada yang berubah dari sisi yang kita pedulikan. Tulisan ini soal segelintir kesempatan dalam setahun ketika kenyataannya tidak begitu, dan soal cara membedakan kesempatan itu dari yang biasa-biasa saja — sebelum pekerjaannya dimulai.

A. Arti angka-angka di nomor versi

Nomor versi lazimnya ditulis sebagai tiga angka berpemisah titik — misalnya 14.2.7. Konvensi di baliknya dipakai luas, dan tiap posisi menjanjikan janji yang berbeda.

Angka terakhir disebut versi patch. Ia naik ketika ada yang diperbaiki dan tak ada lagi yang berubah: sebuah bug, sebuah lubang keamanan. Upgrade-nya dirancang supaya tak terasa.

Angka tengah disebut versi minor. Ia naik ketika ada tambahan yang sebelumnya tak ada. Semua yang tadinya bekerja tetap bekerja; cuma pilihannya bertambah.

Angka pertama disebut versi mayor, dan itulah yang menentukan di sini. Ia naik ketika pemeliharanya membolehkan diri melanggar janji yang selama ini dipegang. Sesuatu yang bekerja di versi sebelumnya boleh berhenti bekerja, dan mereka memberitahukannya lewat perubahan digit pertama itu.

Untuk kebanyakan software, "melanggar janji" berarti sebuah perintah dihapus atau sebuah opsi berganti nama — menjengkelkan, tapi langsung ketahuan dan bisa dikembalikan. Untuk software yang menyimpan data, artinya bisa jauh lebih buruk: susunan datanya di disk berubah.

B. Kenapa data tersimpan membuat versi mayor jadi berbahaya

Ketika database menyimpan catatan, ia tak menuliskannya seperti orang menulis surat. Ia menatanya dalam struktur yang dirancang untuk pencarian cepat dan pemulihan yang aman — disebut format on-disk. Struktur itu urusan internal, dan justru karena itulah pemeliharanya merasa leluasa mengubahnya antar versi mayor.

Akibatnya: versi yang lebih baru boleh saja menatap direktori tulisan versi lama lalu sama sekali tak mengenalinya. Dan itu bisa berlanjut ke dua arah.

Pada kasus yang baik, ia menolak menyala sambil menyebutkan sebabnya. Tak ada yang tersentuh, kerugiannya beberapa menit, dan versi lama tetap bekerja persis seperti semula.

Pada kasus yang buruk, ia mengenali direktorinya cukup jauh untuk mulai mengonversi — menulis ulang datanya ke susunan yang baru sambil berjalan. Kalau rampung, syukur. Kalau tidak, atau kalau di tengah jalan niatnya berubah, direktori itu kini berada dalam keadaan yang tak sepenuhnya dipahami versi mana pun. Software lama tak lagi sanggup membacanya, padahal itu satu-satunya salinan yang ada.

Kasus kedua itulah arti "tak bisa dibatalkan" pada judul tulisan ini. Bukan software-nya yang melarang kembali, melainkan sesudah titik tertentu memang tak ada lagi tempat untuk kembali.

C. Kenapa ini tak bisa ditunda lagi

Sistem yang dibicarakan menandatangani dokumen untuk sebuah instansi publik. Ketika seseorang mengirim dokumen lalu menerimanya kembali dalam keadaan tertanda tangan, tanda tangan itu wajib tetap bisa diverifikasi bertahun-tahun, dan catatan siapa menandatangani apa dan kapan wajib bertahan sama lamanya.

Prakteknya, "tak lagi didukung" berarti satu perkara yang sangat spesifik: ketika ditemukan celah keamanan di software itu, takkan ada perbaikan untuk versi tersebut. Celahnya jadi pengetahuan umum, tambalannya cuma turun ke versi yang berlaku, dan yang lama tetap menganga. Tiap bulan berlalu menambah daftar persoalan yang diketahui tanpa obat yang tersedia.

Jadi upgrade itu bukan pilihan, dan bukan pula soal mengikuti mode. Ia beda antara sistem yang menerima perbaikan keamanan dan sistem yang tidak.

Yang membuatnya sulit justru paruh kedua kalimat yang sama. Catatan yang wajib bertahan tersimpan persis di komponen yang perlu di-upgrade — termasuk satu yang upgrade-nya berupa pintu satu arah. Pertanyaannya tak pernah "bisakah ini di-upgrade", melainkan: bagaimana menyeberangi batas yang tak bisa dilangkahi balik, ketika di seberang sana ada catatan bertahun-tahun yang jadi tanggung jawab saya?

D. Dua bentuk sebuah upgrade

Tiap komponen di sistem ini jatuh ke salah satu dari dua golongan, dan membedakan keduanya adalah pekerjaan sungguhan yang pertama.

Yang pertama bisa dibalik. Versi baru membaca data lama; kalau ada yang keliru, hentikan versi baru lalu nyalakan yang lama. Tak ada yang terkonsumsi. Pekan depan bisa dicoba lagi.

Yang kedua satu arah. Begitu versi baru menyentuh direktori datanya, ia menuliskan format yang tak bisa dibaca versi lama. Tak ada berhenti lalu kembali — bukan karena software-nya melarang, melainkan karena data di disk kini berbentuk yang tak dipahami versi lama.

Upgrade satu arah bukan sebuah deployment. Yang terjadi adalah migrasi tanpa rollback, yang artinya tiap serpih keyakinan harus datang dari persiapan, sebab tak satu pun akan datang dari kemampuan mundur.

E. Apa yang sedang saya pindahkan

Sistemnya memegang empat jenis state tersimpan, dan saya akan menyebutnya lewat apa yang dikerjakannya, bukan namanya.

Tiga database relasional memegang catatan yang otoritatif — tabel yang menjawab "apa yang ditandatangani, oleh siapa, kapan". Satu klaster pencarian memegang log, yang di sistem ini bukan barang sekali pakai: ia catatan operasional tiap penandatanganan, dan wajib bertahan sampai akhir masa retensi yang diukur dalam tahun. Satu penyimpan objek memegang file unggahan. Dua cache memegang pekerjaan yang sedang berlangsung — data yang ada semata supaya segalanya lebih cepat, dan bisa dibangun ulang dari nol.

Empat golongan, empat jawaban berbeda.

relational databases  -> logical dump and reload   # format khas per versi
search cluster        -> snapshot and restore      # tulis-ulang di tempat satu arah
object store          -> copy the directory        # format kompatibel maju
caches                -> not migrated at all       # data turunan, dihitung ulang

F. Lima hambatan yang menghalangi

Jadi tujuannya: memindahkan empat jenis state tersimpan ke versi yang masih didukung, tanpa kehilangan satu pun. Dengan satu batasan yang membentuk segalanya di bawah ini — sebagian yang dipindahkan adalah catatan bernilai hukum dengan masa retensi terhitung tahun, dan setidaknya satu komponennya tak menyediakan jalan pulang begitu ia disentuh. Keyakinannya tak mungkin datang dari kesanggupan mundur, sebab untuk komponen itu memang tak ada tempat mundur. Ia harus datang dari persiapan.

Gampang dirumuskan, canggung dibangun. Ada lima hambatan yang menghalangi, dan yang pertama justru yang membuat empat sisanya bisa terlihat sama sekali.

Hambatan pertama: tak ada prosedur yang seragam, dan mencarinya itu sendiri bahayanya. Empat golongan state, empat jawaban berbeda — dan naluri mencari satu jalur migrasi tunggal itulah yang membuat aturan sebuah database berakhir diterapkan ke sebuah search cluster. Keduanya tak serupa: yang satu menolak menyala begitu bertemu data yang tak sanggup ia baca, yang lain justru mulai mengonversinya. Prosedur seragam adalah alternatif yang ditolak di sini, dan menolaknya itulah yang memaksa munculnya pertanyaan yang benar: bukan "bagaimana saya meng-upgrade sistem ini", melainkan "apa sebenarnya yang dituntut tiap komponen".

Hambatan kedua: upgrade di tempat menulis ulang datanya sambil ia membaca. Versi mayor baru search cluster sanggup membaca tulisan versi mayor tepat sebelumnya, dan tak lebih tua dari itu — sementara cluster-nya memuat index dari beberapa zaman. Arahkan versi baru ke direktori yang ada dan ia mulai mengonversi; hentikan di tengah jalan dan direktorinya berada dalam bentuk yang tak dipahami sepenuhnya oleh versi mana pun. Upgrade di tempat adalah alternatif yang ditolak, dan menolaknya terasa tak nyaman justru karena ia akan cepat dan akan berhasil di sebagian besar kesempatan. Pada kesempatan yang tidak, ia akan melahap catatan yang mustahil dilahirkan ulang. Maka cluster-nya dipindahkan lewat mekanisme snapshot: dibaca dari yang lama, dipulihkan ke cluster baru yang berdiri terpisah, dan sumbernya sama sekali tak pernah diubah.

Hambatan ketiga: satu index yang terlalu tua menghentikan seluruh cluster baru dari menyala. Bukan "melewati index itu" — menolak menyala, sebab ia tak sanggup membuka sebagian state-nya sendiri. Waktu penemuannya menentukan segalanya: ditemukan di tengah migrasi, artinya cluster lama sudah telanjur dimatikan, yang baru tak mau naik, layanannya mati, dan operatornya sedang membaca dokumentasi soal reindex pada jam dua pagi. Membiarkannya muncul saat runtime adalah alternatif yang saya tolak, dan penggantinya tak berongkos apa pun — langkah ekspor mencatat versi mana yang menulis tiap index lalu menolak memulai bila menemukan satu yang melewati batas, selagi sistem lamanya masih berjalan dan tak ada tekanan waktu sama sekali.

Hambatan keempat: datanya harus diamankan sebelum tujuannya ada. Server lama sedang berjalan, struktur barunya belum terbangun, dan mengerjakan keduanya berurutan membiarkan jendela ketergantungan pada hardware yang sebentar lagi dipensiunkan tetap terbuka. Satu tool yang memigrasi sekali jalan adalah alternatif yang ditolak; sebagai gantinya ekspor dan impor jadi dua program terpisah, dijalankan bisa berselang berhari-hari, dengan ekspor memperlakukan sumbernya sebagai read-only ketat. Di antara keduanya, sistem lama tetap beroperasi penuh — ia dibaca, bukan diubah.

Hambatan kelima: satu file bisa lolos dari tiap mekanisme yang semestinya menangkapnya. Revocation list milik certificate authority itu state, jadi ia benar dikecualikan dari version control. Ia tak tinggal di database mana pun, jadi migrasi database tak membawanya. Dan ketiadaannya tak menghentikan apa pun dari menyala, jadi tak ada kegagalan yang mengumumkannya. "Semua yang ada di database ditambah semua yang ada di version control" adalah anggapan yang gagal di sini, dan ia gagal tanpa suara. Penggantinya: inventarisasi apa yang tersimpan, bukan apa yang terkelola, sebab file yang jatuh di luar tiap mekanisme pengelolaan justru file yang dilupakan sebuah migrasi.

Urutannya mencerminkan seberapa besar tiap hambatan mengikat sisanya. Yang pertama wajib didahulukan sebab ia yang memutuskan bahwa tiap pertanyaan berikutnya diajukan per komponen, bukan sekali untuk semua. Yang kedua dan ketiga sama-sama milik komponen paling berbahaya, dan keduanya terbelah rapi: yang kedua soal bagaimana memindahkannya, yang ketiga soal bagaimana mengetahui lebih dulu bahwa ia belum bisa dipindahkan. Yang keempat soal kapan, dan yang kelima soal apa yang paling gampang tertinggal. Dua sifat mengalir melewati kelimanya — sumbernya tak pernah diubah, dan tiap pemeriksaan yang memblokir dijalankan sebelum komitmennya, bukan di tengah-tengahnya. Dua hal itulah yang membuat operasi tanpa rollback bisa dilewati, bukan sekadar dikerjakan dengan hati-hati.

Metode

A. Tanyai tiap komponen, upgrade apa yang sebenarnya ia tuntut

Inilah jawaban atas hambatan pertama, dan di atasnyalah empat sisanya diajukan.

Database relasional melompati beberapa versi mayor. Format direktori datanya khas per versi, dan software-nya memeriksanya saat start: diarahkan ke direktori tulisan versi mayor yang lebih tua, versi baru menolak menyala dan mengatakannya dengan jelas. Penolakan itu sebuah hadiah. Kegagalannya lantang, dini, dan tak merugikan — jenis yang terbaik. Jalur migrasinya: ekspor isinya sebagai dump logis lalu muat ke instance yang segar.

FATAL:  database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 14,
        which is not compatible with this version 18.

Klaster pencarian yang berbahaya, dan saya akan kembali padanya.

Penyimpan objek kasus yang gampang: format on-disk-nya kompatibel maju di antara versi yang bersangkutan, jadi menyalin direktorinya sudah cukup. Klaim itu saya verifikasi, bukan saya andaikan.

Cache sama sekali tak dimigrasi. Keduanya memegang data turunan dan pekerjaan yang mengantre, bukan catatan. Apa pun yang hilang dihitung ulang. Menyadari bahwa sebuah komponen tak perlu dimigrasi sama bergunanya dengan tahu cara memigrasinya — dan lebih murah.

B. Upgrade yang tak bisa dibatalkan

Inilah jawaban atas hambatan kedua: satu-satunya komponen yang tak punya jalan pulang.

Klaster pencarian punya dua sifat yang berpadu dengan buruk.

Pertama, versi mayor barunya sanggup membaca data tulisan versi mayor tepat sebelumnya, tapi tidak yang lebih tua dari itu. Klasternya memegang indeks dari beberapa era, dan sebagian mendahului batas tersebut.

Kedua — dan inilah yang membuatnya jadi pintu satu arah — upgrade di tempat menulis ulang datanya sambil berjalan. Nyalakan versi baru di atas direktori yang ada, ia mulai mengonversi. Hentikan di tengah jalan, dan yang tersisa adalah direktori yang tak sepenuhnya dipahami versi mana pun.

Maka pendekatan yang paling terpikirkan justru yang keliru. Upgrade di tempat akan cepat dan akan berhasil di sebagian besar kesempatan. Pada kesempatan ketika ia tak berhasil, ia akan memusnahkan catatan yang punya arti hukum, tanpa jalan kembali.

Jadi klaster pencarian dimigrasi lewat mekanisme snapshot-nya: ambil snapshot dari klaster lama, dirikan klaster baru secara terpisah, pulihkan snapshot-nya ke sana. Lebih lambat, dan menuntut ruang disk untuk keduanya sekaligus.

Yang dibelinya: klaster lama tak pernah diubah. Klaster itu dibaca, dan tetap persis seperti semula. Kalau pemulihannya gagal, atau klaster baru berulah, yang asli masih ada di sana, masih terbaca oleh versi yang melahirkannya. Format snapshot-nya pun portabel lintas versi dengan cara yang tak dimiliki direktori data mentah.

# sumbernya dibaca, tak pernah ditulis
curl -X PUT "$OLD/_snapshot/repo/migration-1?wait_for_completion=true"
curl -X POST "$NEW/_snapshot/repo/migration-1/_restore"

Prinsip yang akan saya sarikan: ketika satu operasi tak bisa dibalik, susun ulang supaya bagian yang tak bisa dibalik itu terjadi di tempat lain. Menyalin data ke tempat baru bisa dibalik — hapus salinannya. Mentransformasi data di tempat, tidak. Di mana pilihannya ada, belilah kemampuan membalik dengan ruang disk, sebab ruang disk itu murah dan catatannya tidak.

C. Menolak menyala saat datanya terlalu tua

Inilah jawaban atas hambatan ketiga, dan seluruhnya soal kapan penemuannya terjadi.

Batas versi itu melahirkan bahaya yang kalau tidak ditangani akan muncul pada saat paling buruk.

Kalau ada satu saja indeks di klaster yang ditulis versi lebih tua dari batas kompatibilitasnya, klaster baru gagal menyala sama sekali. Bukan "melewati indeks itu" — menolak menyala, sebab ia tak sanggup membuka sebagian dari state-nya sendiri.

Ditemukan di tengah migrasi, artinya: klaster lama sudah dimatikan, klaster baru tak mau naik, layanan tak tersedia, dan operatornya baru mulai membaca dokumentasi soal reindex. Pukul dua pagi.

Maka langkah ekspornya mencatat versi pembuat tiap indeks lalu berhenti sebelum mengerjakan apa pun bila menemukan yang terlalu tua, menyebut namanya dan meminta ia di-reindex lebih dulu. Pemeriksaan itu tak berongkos, dan ia memindahkan penemuannya dari tengah migrasi ke permulaan — saat sistem lama masih berjalan dan tak ada tekanan waktu.

# baca versi pembuat tiap indeks SEBELUM apa pun dihentikan
curl -s "$OLD/*/_settings?filter_path=**.version.created_string" \
  | grep -o '"[0-9]\+\.[0-9]\+\.[0-9]\+"' | sort -u

Ini bentuk yang sama dengan dry run, yang muncul di hampir semua tools operasional yang saya tulis: ketahui apa yang akan gagal sebelum terlanjur terikat.

D. Ekspor dan impor sebagai langkah terpisah

Inilah jawaban atas hambatan keempat: mengamankan datanya sebelum tujuannya ada.

Migrasinya dua tools, bukan satu, dan pemisahan itu disengaja.

Data biasanya perlu diamankan sebelum tujuannya siap. Server lama sedang berjalan, struktur barunya belum terbangun, dan menunggu yang kedua sebelum mengerjakan yang pertama berarti membiarkan jendela ketika segalanya bergantung pada perangkat keras yang sebentar lagi dipensiunkan tetap terbuka lebih lama dari perlunya.

Maka ekspor berjalan lebih dulu dan memperlakukan sumbernya sebagai baca-saja secara ketat. Impor berjalan belakangan, mungkin berhari-hari kemudian, dari artefak hasil ekspor. Di antara keduanya, sistem lama tetap sepenuhnya beroperasi — ia dibaca, bukan diubah.

export-legacy-data --src /old/data          # jeda berhari-hari boleh di antaranya
import-legacy-data --from ~/migration- --target production

E. File yang tak ada di version control dan wajib ikut

Inilah jawaban atas hambatan kelima, dan satu-satunya yang ditemukan dengan mencari, bukan dengan gagal.

Certificate authority memelihara daftar pencabutan — file bertanda tangan yang mencatat sertifikat mana yang sudah ditarik. File itu state, jadi tepat kalau dikecualikan dari version control. Ia pun tak tersimpan di database mana pun, jadi migrasi database tak membawanya. Dan ketiadaannya tak menghalangi apa pun untuk menyala.

Tempatnya di sebuah celah: bukan kode, bukan database, bukan tanggung jawab siapa pun secara jelas. Daftar periksa migrasinya kini menyebutnya terang-terangan, sebab "segala yang di database ditambah segala yang di version control" bukanlah segalanya.

# state, jadi dikecualikan dari version control — dan tak dibawa apa pun
modules/ca/data/crl.der      # daftar pencabutan bertanda tangan
modules/ca/data/privkey.pem  # keduanya tak tinggal di database mana pun

Pelajaran umumnya: inventarisasi apa yang tersimpan, bukan apa yang terkelola. File yang jatuh di luar tiap mekanisme pengelolaan persis file yang dilupakan sebuah migrasi, dan kerap justru yang penting.

Hasil dan Pembahasan

A. Kegagalan mana yang Anda pilih

Database relasional dan klaster pencarian berbeda dalam satu perkara yang lebih menentukan ketimbang detail teknis mana pun: apa yang terjadi saat operatornya keliru.

Arahkan database yang lebih baru ke direktori data yang lebih tua, ia menolak menyala dengan pesan yang jelas. Kerugiannya beberapa menit.

Arahkan klaster pencarian yang lebih baru ke direktori data yang lebih tua, ia mulai mengonversi. Kalau berhasil, syukur. Kalau datanya lebih tua dari yang sanggup ia tangani, kini yang tersisa adalah direktori yang versi lamanya pun tak lagi sanggup membaca.

Kekeliruan operator yang sama. Yang satu berongkos menit; yang lain berongkos arsipnya. Bedanya kelihatan dari apa yang masing-masing cetak.

# Database: menolak, menyebut ketidakcocokannya, tak mengubah apa pun.
FATAL:  database files are incompatible with server
DETAIL: data directory was initialized by PostgreSQL version 13,
        which is not compatible with this version 16.

# Search cluster: menerima, lalu mulai menulis ulang yang baru saja ia baca.
[INFO] upgrading index [logs-2019.04] to current format
[INFO] segments rewritten: 12/48        # berhenti di sini, tak ada versi yang sanggup membacanya

Itu sebabnya saya berhenti memperlakukan "apakah ia bekerja?" sebagai pertanyaan menarik tentang sebuah jalur upgrade. Pertanyaan yang menarik adalah apa yang terjadi ketika ia tidak bekerja — dan jawabannya menentukan seberapa besar persiapan yang sepadan. Komponen yang gagal dengan lantang dan tanpa merugikan boleh dicoba. Komponen yang gagal dengan cara mengonsumsi masukannya wajib digladi di tempat lain lebih dulu.

B. Apa yang membuat ini bisa dilewati

Dua dari tiga sifat di bawah sudah disebut sejak awal. Menaruhnya berdampingan tetap berguna, sebab tak satu pun khas bagi software yang terlibat — dan yang ketiga baru kelihatan begitu dua yang pertama terpasang.

Sumbernya tak pernah diubah. Tiap langkah membaca dari sistem lama dan menulis ke tempat baru. Tak ada satu titik pun yang punya operasi yang, bila terinterupsi, meninggalkan yang asli dalam keadaan tak terpakai. Sifat itu kelihatan dari bentuk perintahnya sendiri — tiap satunya menyebut tujuan yang sebelumnya belum ada.

# Tiap langkah menyebut tempat baru. Tak ada yang menulis balik ke sumbernya.
pg_dumpall > "$OUT/all.sql"                    # server lama -> file baru
snapshot_create "$OLD_CLUSTER" "$SNAP_REPO"     # cluster lama -> repository baru
cp -a "$OLD_OBJECTS" "$NEW_OBJECTS"             # direktori lama -> direktori baru

# Sifat yang diperiksa: tak ada perintah yang memakai sumbernya sebagai keluaran.

Pemeriksaan yang menghentikan berjalan sebelum keterikatan. Menemukan indeks yang terlalu tua untuk dimigrasi adalah prasyarat, bukan runtime error.

Tiap komponen dimigrasi menurut aturannya sendiri. Godaan mencari satu prosedur yang mencakup semuanya itu kuat, dan menyerah padanya berarti menerapkan teknik yang paling lemah ke data yang paling berharga.

C. Berapa ongkosnya

Menjalankan dua klaster berbarengan menuntut ruang disk untuk keduanya, dan untuk sementara mesinnya memegang dua salinan arsip log. Itulah harga dari tidak mengubah sumbernya, dan harga itu dibayar dengan sumber daya yang paling murah yang tersedia.

Ekspor dan impornya juga memakan waktu sebanding dengan datanya, dan selama itu sistemnya tak melayani. Ini bisa diterima untuk layanan internal yang punya jendela pemeliharaan. Takkan bisa diterima untuk sistem yang tak boleh berhenti, dan sistem semacam itu menuntut pendekatan yang sama sekali berbeda — replikasi ke versi baru lalu cut-over — yang jauh lebih berat mesinnya ketimbang yang dibenarkan keadaan ini.

D. Apa yang berlaku umum

Apa pun yang sedang di-upgrade, tiga pertanyaan layak dijawab sebelum memulai.

Apakah ini bisa dibalik? Persisnya: apakah versi baru mengubah datanya sambil membacanya? Kalau ya, jangan kerjakan di tempat.

Apa benda tertua yang ada di dalamnya? Kompatibilitas lazimnya dinyatakan terhadap versi sebelumnya, dan sistem berumur panjang menumpuk data dari beberapa versi yang lalu.

Apa yang tersimpan di luar benda-benda yang saya tahu cara memigrasinya? Tiap sistem punya file yang bukan kode dan bukan baris database. Merekalah yang tertinggal.

Simpulan

Menyeberangi batas versi mayor bukan satu prosedur. Yang ada adalah keputusan terpisah per komponen, dan keputusannya bertumpu pada apa yang terjadi saat ia gagal, bukan pada apa yang terjadi saat ia berhasil.

Pilihan yang paling akan saya bela adalah yang lambat: memigrasi arsip log lewat snapshot ketimbang meng-upgrade-nya di tempat. Ia makan waktu lebih lama, menuntut ruang disk untuk dua salinan, dan berarti seluruhnya bisa ditinggalkan kapan saja dengan yang asli tetap utuh. Upgrade di tempat akan lebih cepat dan kemungkinan besar akan berhasil.

"Kemungkinan besar berhasil" adalah standar yang wajar untuk pekerjaan yang bisa diulang. Untuk catatan yang wajib bertahan bertahun-tahun masa retensi, dan yang tak lagi bisa dibaca software lama begitu software baru menyentuhnya, standarnya harus berbeda. Di mana satu operasi tak bisa dibatalkan, pekerjaannya bukan mengerjakannya dengan hati-hati, melainkan menyusunnya ulang supaya ia tak perlu dibatalkan.

Istilah

Versi mayor

Rilis yang dibolehkan mengubah format data tersimpan, sehingga versi yang lebih baru mungkin tak bisa membaca data versi lama.

Upgrade di tempat

Menyalakan versi baru di atas direktori data yang sudah ada, membiarkannya mengonversi sambil berjalan. Cepat, dan kerap tak bisa dibalik.

Snapshot

Salinan isi sebuah datastore yang portabel, terbaca lintas versi dengan cara yang tak dimiliki direktori data mentah.

Dump logis

Ekspor isi database sebagai instruksi untuk membangunnya kembali, bukan salinan file-nya.

Kompatibilitas maju

Sifat format tersimpan yang tetap terbaca oleh versi berikutnya, dan itulah yang membuat menyalin direktori sudah cukup.

Reindex

Menulis ulang data tersimpan dalam format yang berlaku, dibutuhkan saat ia terlalu tua bagi versi yang dituju.