Eski SQLite shard’larından yükseltme

Başlangıçta kesintiye uğramış yeniden-embedding değişimleri kurtarılır, libSQL DiskANN indeksleri mevcut Turso motoruna dönüştürülür ve ardından eski shard şeması doğrulanır veya yükseltilir. Motor dönüşümü, bir depoda tamamlanmış eski migrasyon işaretçisi olsa bile çalışır ve saklanan vektörleri yeniden embedding yapmadan korur. Her dönüştürülen veritabanı <database>.pre-tursodb-<timestamp>.bak olarak yedeklenir.

macOS ve Linux’ta birden fazla OpenCode oturumu, Turso’nun deneysel multiprocess_wal özelliğiyle aynı storagePath’i paylaşabilir (her süreç aynı modu kullanmalıdır — yükseltmeden sonra tüm oturumları yeniden başlatın). Windows’ta motor bu bayrağı reddeder; bu nedenle aynı anda yalnızca bir OpenCode oturumu bellek veritabanlarının sahibi olabilir.

tursoMultiprocessWal: false bunun yerine tek-sahip modunda açar: diğer süreçler depoyu paylaşmak yerine database is locked ile başarısız olur. Eklenti dışı araçlar aynı dosyalara dokunuyorsa bu daha güvenlidir; çünkü yazan yabancı bir SQLite süreci Turso’nun WAL dizinini bayatlatır ve bir sonraki yazma sessizce kaybolur. tursoAutoHeal (varsayılan true), bir açılış bayat WAL dizininden dolayı başarısız olduğunda ana veritabanının bir kopyasını doğruladıktan sonra deponun -shm/-tshm indeks yan dosyalarını storagePath/recovery/<db>-<timestamp>/ altına taşır ve bir kez yeniden dener. Boş olmayan bir -wal asla taşınmaz; böylece commit edilmiş ama henüz checkpoint edilmemiş işlemler korunur; yalnızca eksik veya 0 baytlık -wal kaldırılır. Eşzamanlı oturumlar iyileştirmeyi storagePath/recovery/<db>.lock üzerinden serileştirir.

Yükseltmeden sonraki ilk başlangıçta opencode-mem mevcut bellek shard veritabanlarını yerel Turso/libSQL vektör biçimine otomatik olarak taşır:

• Her shard yeniden yazılmadan önce <shard>.db.legacy.bak olarak yedeklenir
• İlerleme shard başına <shard>.db.turso-migrate.json içinde izlenir
• Genel bir .turso-migrated işaretçisi yalnızca tüm shard’lar başarıyla doğrulandıktan sonra yazılır
• Normal eklemeler ve silmeler tamamlanmış bir shard migrasyonunu geçersiz kılmaz; başlangıçta vektörlerin okunabilir olduğu ve saklanan boyutlarla eşleştiği hâlâ kontrol edilir
• Migrasyon sırasında aynı storagePath’e karşı birden fazla OpenCode örneği çalıştırmayın; bir kilit dosyası (.turso-migrate.lock) eşzamanlı migrasyonu engeller
• Manuel boyut migrasyonları .turso-operation.lock kullanır; diğer eklenti süreçleri migrasyon bitene kadar yeni bellek yazılarını reddeder
• Kilitler, ilerleme zaman damgası güncellemesi olmadan (veya zaman damgası yoksa dosya değişiklik zamanı) 30 dakika sonra sona erer; sahip süreç hâlâ canlı olsa bile. Bu kira duvar saati kullanır: 30 dakikadan büyük ileri saat sıçraması ilerleyen bir işlemi erken sonlandırabilir; geri sıçrama veya geleceğe tarihli kilit hareketsiz bir kilidin ömrünü uzatabilir. Kilitler benzersiz bir edinme kimliği taşır ve bayat temizleme yalnızca incelediği dosyayı kaldırır. Migrasyonlar ilerlerken heartbeat gönderir ve sahipliğin kaybolduğunu fark ederlerse iptal eder. Bayat-kilit temizliği tanı için günlüğe yazılır.

Migrasyon kesintiye uğrarsa, sonraki başlangıç yedekten otomatik olarak devam eder.

Bir shard uyumsuz hale gelirse (örneğin embeddingDimensions değiştikten sonra), yazmalar engellenir ve orijinal veritabanına dokunulmaz. Yerine geçmeden önce bir yedek oluşturup doğrulamak için Web arayüzünün yeniden-embedding migrasyonunu kullanın. Önceki shard <shard>.db.pre-reembed-<pid>-<timestamp>.bak olarak kullanılabilir kalır.