Pindahkan data dengan aman

Pertanyaan

Bagaimana memindahkan partisi yang sedang menerima tulisan ke node lain tanpa kehilangan penulisan atau menghasilkan dua pemilik?

Setelah baca ini, kamu bisa menyusun urutan migrasi (salin, susul, verifikasi, cutover, bersihkan), memperkirakan durasinya, dan menyebut apa yang terjadi pada penulisan di setiap tahap.

Prasyarat dan contoh

Kamu sudah paham hash ring (M07.02) dan perutean dengan epoch (M07.04).

Ring memberi tahu bahwa partisi 17 harus pindah dari node-c ke node-f. Ring nggak memindahkan satu byte pun. Partisi itu berisi 200 GB dan menerima 500 tulis per detik, masing-masing sekitar 1 KB. Kalau kamu menyalin lalu mengganti pemilik begitu saja, semua tulisan yang masuk selama penyalinan hilang dari salinan baru.

Migrasi aman adalah urutan langkah, dan tiap langkah punya jawaban untuk "bagaimana nasib penulisan sekarang?".

Mekanisme

Lima tahap:

1. Rencanakan dan batasi laju. Tentukan partisi sumber, node tujuan, dan batas bandwidth salin supaya traffic produksi nggak terganggu. Salin 200 GB pada 50 MB/s memerlukan 200.000 MB / 50 = 4.000 detik, sekitar 67 menit. Pada 100 MB/s sekitar 33 menit.

2. Salin snapshot. Ambil snapshot konsisten (atau posisi log tertentu) dan alirkan ke node tujuan. Sumber tetap pemilik dan tetap melayani baca dan tulis.

3. Susul perubahan. Selama penyalinan, sumber tetap menerima 500 tulis per detik, jadi 4.000 detik menghasilkan 2 juta tulisan baru yang belum ada di tujuan. Catat tulisan itu (lewat log perubahan atau penanda posisi), lalu putar ulang di tujuan. Pada laju replay 20.000 tulis per detik, 2 juta tulisan selesai dalam 100 detik, sambil sumber tetap menerima tulisan baru. Ulangi sampai selisihnya kecil, misalnya di bawah 1 detik tulisan.

4. Verifikasi. Bandingkan checksum atau jumlah record per rentang di sumber dan tujuan. Jangan cutover tanpa bukti bahwa isi sama.

5. Cutover berpagar. Naikkan epoch kepemilikan dari 8 ke 9 dan arahkan partisi ke tujuan. Urutannya:

1. Sumber berhenti menerima tulisan baru (pagar): tulisan sesudah titik ini ditolak dengan NOT_OWNER atau ditahan sebentar.
2. Tujuan menyusul sisa terakhir sampai posisi log sama.
3. Peta diperbarui ke epoch 9. Tujuan hanya menerima tulisan yang membawa epoch 9 atau lebih baru.
4. Sumber tetap menyimpan data sebagai jalur rollback selama jendela pengamatan, misalnya 24 jam, sebelum dihapus.

Jeda tulis pada langkah 5 biasanya hitungan detik. Kalau kamu butuh nol jeda, kamu menulis ganda ke dua tempat, dan itu membawa masalah urutan dan konflik tersendiri.

Epoch adalah pagar. Pemilik lama yang lambat atau terpisah jaringan mungkin masih menganggap dirinya pemilik. Kalau penyimpanan menolak tulisan berepoch lebih rendah dari yang terakhir ia lihat, pemilik lama nggak bisa merusak data.

Saat rancangan ini gagal

• Tulisan hilang saat salin. Tanpa tahap susul, semua tulisan setelah snapshot tidak ada di tujuan.
• Dua pemilik. Peta diperbarui, tapi sumber tidak dipagari, sehingga klien dengan peta lama masih menulis ke sumber dan tulisan itu terkubur. Pagar epoch di sisi node mencegahnya.
• Migrasi menjatuhkan produksi. Salin tanpa batas laju menghabiskan disk atau jaringan sumber, dan latensi baca pengguna naik. Beri batas bandwidth dan jeda.
• Cutover tanpa verifikasi. Salinan rusak (bug serialisasi atau data terpotong) baru ketahuan setelah sumber dihapus.
• Hapus terlalu cepat. Sumber dibersihkan segera, dan ketika bug muncul sejam kemudian, nggak ada jalur rollback.
• Beberapa migrasi sekaligus. Penambahan satu node biasanya memindahkan banyak partisi. Batasi jumlah migrasi paralel, karena tiap migrasi menambah beban baca di sumbernya.

Latihan

Partisi 12 berukuran 300 GB, menerima 800 tulis per detik (1 KB tiap tulis). Batas salin 75 MB/s. Replay sanggup 25.000 tulis per detik.

1. Berapa lama penyalinan snapshot, dan berapa tulisan menumpuk selama itu?
2. Berapa lama replay awal sampai menyusul, dengan asumsi tulisan terus masuk?
3. Urutan apa pada cutover yang mencegah tulisan hilang?

Lihat pembahasan+

1. 300 GB = 300.000 MB. Pada 75 MB/s: 4.000 detik, sekitar 67 menit. Selama itu masuk 800 x 4.000 = 3,2 juta tulisan.
2. Replay berjalan 25.000 tulis per detik sementara tulisan baru masuk 800 per detik, jadi selisih berkurang 24.200 per detik. 3,2 juta / 24.200 kira-kira 132 detik. Selama 132 detik itu masuk sekitar 105.600 tulisan tambahan, yang ikut tersusul pada putaran berikutnya (sekitar 4 detik). Hasilnya tujuan tertinggal beberapa detik saja.
3. Pagari sumber (tolak atau tahan tulisan baru), putar ulang sisa terakhir sampai posisi log tujuan sama dengan sumber, verifikasi checksum, naikkan epoch, lalu buka tujuan untuk tulisan berepoch baru. Sumber disimpan 24 jam untuk rollback, lalu dihapus. Jeda tulis hanya selama pagar sampai peta diperbarui, biasanya beberapa detik.

Tulisan yang ditolak selama jeda harus dicoba ulang oleh klien. Itu sebabnya klien perlu logika retry dengan batas, bukan error langsung ke pengguna.

Terkait

• Sebelumnya: M07.04 Rutekan request.
• Lanjut ke M07.06 Rancang akses lintas partisi.
• Batas waktu, lease, dan fencing token yang lebih lengkap dibahas di M08, yang belum tersedia sebagai lesson. Lab L07 dan proyek B04 belum tersedia. Lab L07 menunjukkan perpindahan key, tapi penempatan saja tidak menjamin migrasi langsung yang aman.

Catatan

• Asumsi: sumber punya log perubahan atau posisi yang bisa diputar ulang, dan penyimpanan bisa menolak tulisan berepoch lama.
• Yang nggak dibahas: migrasi lintas versi skema, replikasi selama migrasi (M08), dan koordinasi migrasi banyak partisi.
• Durasi memakai angka ilustrasi. Ukur bandwidth nyata dan replay nyata di lingkungan kamu.
• Terakhir ditinjau: 26 Oktober 2026.