Tombstone Mencegah Data Terhapus Muncul Kembali

Penghapusan bukan sekadar ketiadaan nilai dalam replicated store. Ketiadaan tidak membawa informasi apakah sebuah key sengaja dihapus atau sebuah replica memang belum pernah menerimanya. Ketika replica dapat terputus sementara, perbedaan ini menentukan apakah sinkronisasi mempertahankan penghapusan atau justru mengembalikan data lama.

Tombstone mencatat penghapusan sebagai state berversi. Replica dapat membandingkan marker tersebut dengan nilai lama dan mempertahankan penghapusan saat rekonsiliasi. Marker akhirnya dapat dibuang, tetapi hanya setelah sistem memiliki batas yang kuat bahwa nilai lama tidak dapat kembali.

Ketiadaan tidak dapat mengalahkan nilai lama

Misalkan dua replica awalnya menyimpan nilai yang sama:

A: profile:17 -> active, version 7
B: profile:17 -> active, version 7

Replica B tidak dapat dijangkau. Client menghapus key melalui A. Jika A merepresentasikan penghapusan dengan membuang record secara fisik, state menjadi:

A: tidak ada record
B: profile:17 -> active, version 7

Saat B tersambung kembali, merge procedure melihat nilai di satu sisi dan ketiadaan di sisi lain. Tanpa ordering information pada ketiadaan tersebut, sistem tidak memiliki bukti bahwa A sengaja menghapus state yang lebih baru. Menyalin nilai B kembali ke A akan menghidupkan record itu lagi.

Tombstone mempertahankan bukti tersebut:

A: profile:17 -> tombstone, version 8
B: profile:17 -> active,    version 7

Rekonsiliasi kini dapat membandingkan version dan mempertahankan version 8. Hasil logis tetap terhapus meskipun salinan fisik usang masih ada di tempat lain.

Tombstone adalah data tentang penghapusan

Marker memerlukan metadata yang cukup untuk mengikuti conflict rule milik store. Bergantung pada replication model, metadata itu dapat berupa version yang terurut monotonik, logical timestamp, causal context, atau revision identifier lain.

Secara konseptual:

record {
    key
    value | tombstone
    revision
}

Sifat pentingnya bukan bentuk literal tersebut. Delete harus masuk ke ordering atau causality model yang sama dengan write. Memperlakukan delete sebagai cleanup action terpisah tanpa version akan menciptakan celah dalam model tersebut.

Jika concurrent update dimungkinkan, conflict semantics yang sudah ada tetap berlaku. Tombstone tidak sendirian menentukan setiap race antara delete dan write. Last-write-wins store dapat mengurutkannya dengan timestamp rule; store yang causal-aware dapat mempertahankan concurrent state sampai merge policy menyelesaikannya. Deletion marker membawa delete ke keputusan tersebut alih-alih membuatnya tidak terlihat.

Replica harus menyebarkan marker

Menulis tombstone pada satu node baru merupakan langkah awal. Replication, anti-entropy, repair, hinted delivery, atau jalur sinkronisasi lain harus memindahkannya ke replica yang masih menyimpan data lama.

Rekonsiliasi tipikal membandingkan dua revision:

A: tombstone @ 8
B: value     @ 7

winner: tombstone @ 8

Setelah B menerima revision 8, kedua replica sepakat pada penghapusan logis. B dapat menyimpan tombstone alih-alih langsung menghapus semua jejak karena B mungkin kemudian melakukan sinkronisasi dengan replica C yang masih memiliki revision 7.

Konsekuensi operasionalnya jelas: deletion state sering perlu hidup lebih lama daripada object yang terlihat oleh user. Object sudah hilang dari read path, sementara metadata yang membuktikan penghapusan tetap menjadi bagian dari replication state.

Garbage collection adalah keputusan keselamatan terdistribusi

Tombstone memakai storage dan membuat scan, compaction, serta repair membawa metadata untuk key yang tidak lagi menghasilkan nilai. Menyimpan setiap tombstone selamanya biasanya tidak diinginkan. Namun, membuangnya terlalu cepat akan menciptakan kembali ambiguitas awal.

Pertimbangkan tiga replica:

A: tombstone @ 8
B: tombstone @ 8
C: value     @ 7   (offline)

Jika A dan B membuang tombstone sebelum C kembali, cluster dapat kembali hanya memiliki ketiadaan pada A dan B serta nilai lama pada C. Repair berikutnya dapat memasukkan revision 7 lagi kecuali mekanisme lain membuktikan bahwa revision tersebut sudah obsolete.

Reclamation yang aman bergantung pada replication protocol. Sistem dapat meminta bukti bahwa setiap replica relevan sudah bergerak melewati deletion, mempertahankan tombstone lebih lama daripada outage maksimum yang didukung, memakai progress per-replica yang durable, atau menggabungkan beberapa mekanisme. Retention interval tetap hanya aman jika asumsi mengenai outage dan repair benar-benar ditegakkan secara operasional.

Outage panjang berinteraksi dengan retention policy

Replica yang terputus lebih lama daripada tombstone window yang didukung tidak selalu dapat bergabung kembali melalui incremental repair biasa. Data lokalnya dapat berisi nilai yang bukti penghapusannya sudah dibuang di tempat lain.

Salah satu pendekatan adalah memperlakukan replica tersebut terlalu usang untuk incremental reconciliation lalu membangunnya kembali dari replica atau snapshot terkini. Risiko correctness yang implisit berubah menjadi aturan operasional eksplisit:

offline duration <= supported window -> repair
offline duration >  supported window -> rebuild

Batas persisnya bergantung pada sistem. Hal pentingnya adalah tombstone retention, failure detection, repair frequency, backup restoration, dan prosedur replica rejoin memakai asumsi yang sama.

Restore backup lama memiliki bentuk masalah serupa dengan replica lama yang kembali. Backup dapat menyimpan nilai sebelum deletion. Recovery procedure memerlukan sumber deletion state yang lebih baru atau rebuild strategy yang mencegah nilai tersebut menjadi authoritative lagi.

Compaction harus mempertahankan semantik penghapusan

Storage engine biasanya menulis ulang file dan menggabungkan sorted run untuk mengambil kembali ruang. Saat compaction, nilai obsolete yang tertutup tombstone dapat dibuang. Tombstone itu sendiri juga dapat menjadi kandidat penghapusan, tetapi hanya ketika kondisi replication dan retention mengizinkannya.

Layout file lokal saja tidak dapat menetapkan keselamatan terdistribusi. Compactor mungkin tidak melihat version lama pada node saat ini sementara replica lain masih memilikinya. Keputusan untuk membuang tombstone karena itu memerlukan protocol context, bukan sekadar bukti bahwa nilai lokal sudah tertutup.

Pemisahan ini berguna dalam design review: local compaction menentukan byte yang redundant pada satu node; tombstone reclamation menentukan apakah cluster dapat dengan aman melupakan bahwa penghapusan pernah terjadi.

Metrics memperlihatkan tekanan sebelum correctness dikorbankan

Workload dengan banyak delete dapat mengumpulkan tombstone dalam jumlah besar. Operator dapat memantau jumlah tombstone, distribusi umur, disk space, compaction backlog, repair lag, dan umur replica paling usang.

Pengukuran tersebut memisahkan masalah efisiensi storage dari masalah replication safety. Mengurangi retention karena penggunaan disk tinggi dapat membuat sistem terlihat lebih sehat sambil melemahkan kondisi yang mencegah data terhapus kembali. Capacity, compaction throughput, dan repair cadence merupakan tuas yang lebih aman ketika retention boundary menjadi bagian dari correctness model.

Tombstone membuat penghapusan cukup eksplisit untuk bertahan dalam replication asynchronous. Biayanya adalah metadata persisten dan reclamation rule yang lebih ketat. Biaya itu muncul karena sistem replicated tidak dapat menyimpulkan delete masa lalu hanya dari ketiadaan saat ini; sistem memerlukan bukti sampai setiap salinan usang tidak lagi mampu menjadi state terkini.