ChromaDB ephemeral overlay — suýt mất 609K chunks

Bối cảnh

ChromaDB chạy trên VPS 3 tuần. Em assume mọi thứ OK vì container Up 21 days. Memory bank ghi “chunks đã re-embed sang OpenAI”.

Anh không tin.

Verification day — 26/04

Anh yêu cầu em query ChromaDB API thật, không đọc summary. Em chạy docker exec aae-chromadb, lấy metadata. Sốc:

• Path mount /data (overlay ephemeral) thay vì /chroma/chroma (persistent)
• 99.8% là Gemini cũ chứ không phải OpenAI

Restart 1 lần = mất.

Quyết định đầu tiên: xoá sạch làm lại

Phản xạ đầu tiên của tôi khi thấy đống data nằm sai chỗ: xoá sạch, làm lại từ đầu.

Lý do đơn giản — lúc đó tôi không hiểu trong 609K chunks kia, cái gì còn tái sử dụng được, cái gì hỏng. Không nắm được thì cách an toàn nhất trong đầu tôi là đập đi xây lại.

Nhưng đó là quyết định của người chưa nhìn rõ vấn đề. JARVIS phân tích lại cho tôi: data không hỏng, chỉ là mount sai path — bản thân 8.5GB chunks vẫn nguyên, vấn đề nằm ở chỗ nó nằm trên overlay ephemeral chứ không phải persistent volume. Nghĩa là không cần xoá gì cả: phần nào giữ nguyên, phần nào cần re-embed lại — tách bạch rõ ràng.

Khi đã nắm được “cái gì giữ, cái gì làm lại”, quyết định đổi hoàn toàn: không xoá — restore rồi re-embed.

Migration LIVE — zero data loss

06:08 UTC, hai bên cùng có mặt. Quy trình gọn:

1. Stop container
2. Restore từ tar.gz backup
3. Sửa mount trong compose: /data → /chroma/chroma (persistent)
4. up lại
5. Verify metadata thật — đủ 609K chunks, không mất gì

Bài học đắt nhất không phải kỹ thuật, mà là đừng để phản xạ “xoá làm lại” ra quyết định khi mình chưa nhìn rõ. Nếu lúc đó tôi xoá theo bản năng, 99.8% chunks Gemini đi luôn — re-embed lại tốn thời gian + tiền vô nghĩa.

Re-embed: tôi không tốn 1 giây nghĩ tradeoff

Còn 0.2% chunks cần re-embed sang OpenAI. JARVIS hỏi tôi chọn 6 đô OpenAI hay swap code về Gemini free 0 đô.

Tôi trả lời trong một câu:

6 đô hay 60 đô, được việc thì tôi chịu hết — không cần nghĩ tradeoff.

Với một founder đang vận hành nhiều mảng, thứ đắt nhất không phải vài đô tiền API, mà là thời gian phân tâm vào quyết định nhỏ. Tối ưu 6 đô xuống 0 đô mà tốn nửa buổi swap code + test lại là một cú lỗ. Quyết nhanh, đúng việc, đi tiếp.

Lesson: verify all, ngay từ lúc deploy

Sai lầm gốc: tôi tin container Up 21 days + memory bank ghi “đã re-embed sang OpenAI”. Container chạy không có nghĩa data đúng chỗ.

Từ vụ này, luật cho JARVIS rõ ràng hơn:

• Verify all — không chỉ check container sống, mà query metadata thật, đối chiếu path mount ngay lúc deploy, không đợi 3 tuần sau mới phát hiện.
• Phân tích kỹ để không lặp lại — không vá xong là xong. Mỗi sự cố phải sinh ra một check tự động để lần sau không vấp lại cùng chỗ.

Đây chính là lý do tôi không bao giờ tin một dòng “done” trong docs. Tin filesystem, không tin lời kể.