VPS üzerinde SQLite kullanımı ve üretim ortamı ayarları

SQLite, bir VPS üzerinde ne zaman doğru üretim veritabanıdır

Bir VPS üzerinde üretim ortamında SQLite çalıştırmak, çoğu küçük uygulama için doğru tercihtir; nedeni basittir: tek bir makinede tek bir dosyaya yazan tek bir süreç, bir veritabanı sunucusuna ihtiyaç duymaz. Denetlenecek bir daemon, güvenlik duvarı ile korunacak bir port, değiştirilecek bir parola veya ayakta tutulacak ikinci bir makine yoktur. Bir sorgu, ağ üzerinden gidiş-dönüş yapmak yerine bir fonksiyon çağrısıdır; bu nedenle kırk sorgu çalıştıran bir sayfa size sadece kırk fonksiyon çağrısına mal olur.

Maliyet dar kapsamlı ancak gerçektir. SQLite, tüm veritabanı dosyası üzerinde aynı anda tek bir yazma işlemine izin verir ve dosya iki makine arasında paylaşılamaz. Her iki sınırlama da tek bir uygulama çalıştıran tek bir VPS için sorun teşkil etmez. Ancak bu yapının dışına çıktığınız anda her iki sınırlama da ölümcül hale gelir. Bu kılavuz, SQLite'ı bir sunucuda güvenli hale getiren ayarları, Litestream ile sürekli yedeklemeyi ve durmanız gereken noktayı ele almaktadır.

Önce komut satırı aracını yükleyin. Aşağıdaki her şey Ubuntu 24.04 üzerinde çalıştırılmıştır.

sudo apt update
sudo apt install -y sqlite3
sqlite3 --version

Bu komut, 3. ile başlayan bir sürüm, ardından bir derleme tarihi ve kaynak hash değeri yazdırır. Ubuntu 24.04, Temmuz 2026 itibarıyla SQLite 3.45.1 sürümünü sunmaktadır. Uygulamanız muhtemelen bu binary dosyasını kullanmıyordur: çoğu dil çalışma zamanı (runtime), kendi SQLite kütüphanesi kopyasını (genellikle daha yeni bir sürüm) paketler; bu nedenle yeni bir özelliğe güvenmeden önce veritabanı sürücünüzün bildirdiği sürümü kontrol edin.

WAL modunun neden ilk değiştirilmesi gereken ayar olduğu

SQLite varsayılan olarak bir rollback journal kullanır. Bir sayfayı değiştirmeden önce, orijinal sayfayı bir -journal dosyasına kopyalar ve ardından veritabanını yerinde düzenler. Bunu güvenli bir şekilde yapmak için tüm dosya üzerinde özel (exclusive) bir kilit alır; bu nedenle herhangi bir yazma işlemi sürerken tüm okuyucular bekler. Bir dizüstü bilgisayarda bunu kimse fark etmez. Bir web sunucusunda ise yavaş bir yazma işlemi, veritabanına erişen her isteği durdurur.

WAL (write-ahead log) modu bu sırayı tersine çevirir. Yazıcı, yeni sayfaları ayrı bir -wal dosyasına ekler ve ana veritabanına dokunmaz. Okuyucular ana dosyayı başladıkları andaki anlık görüntü (snapshot) üzerinden okumaya devam ederler; böylece okuyucular yazıcıyı, yazıcı da okuyucuları engellemez. Daha sonra bir checkpoint işlemi, biriken WAL sayfalarını ana veritabanına geri kopyalar. Bu tek değişiklik, SQLite'ın bir web uygulamasının arkasında kullanılabilir olmasını sağlayan temel unsurdur.

WAL modunu etkinleştirin ve kalıcı olduğunu doğrulayın

mkdir -p ~/app
sqlite3 ~/app/app.db "PRAGMA journal_mode=WAL;"

Komut wal çıktısını verir. Bu çıktı sadece bir süs değildir. PRAGMA journal_mode, veritabanının halihazırda bulunduğu modu döndürür; dolayısıyla delete yanıtı, değişikliğin başarısız olduğunu ve hala rollback journal modunda olduğunuzu gösterir.

WAL modu kalıcıdır. Bu, bir bağlantı ayarından ziyade veritabanı başlığındaki bir bayraktır; bu nedenle her veritabanı dosyası için bir kez çalıştırırsınız ve sonraki tüm bağlantılar, yeniden başlatma sonrasında bile bunu devralır. Bunu yeni bir bağlantı ile kanıtlayın.

sqlite3 ~/app/app.db "PRAGMA journal_mode;"

Şimdi bir tablo oluşturun ve diskte nelerin göründüğüne bakın.

sqlite3 ~/app/app.db <<'SQL'
CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY, body TEXT NOT NULL);
INSERT INTO notes (body) VALUES ('first row');
SQL
ls -l ~/app/

Artık üç dosya var: app.db, app.db-wal ve app.db-shm. -wal dosyası, henüz checkpoint işlemi yapılmamış olan commit edilmiş sayfaları tutar. -shm dosyası, tüm bağlantıların WAL içeriği üzerinde mutabık kalması için eşlediği paylaşımlı bir bellek dizinidir. Her ikisi de veritabanına aittir ve geçici dosyalar değildir. Uygulama çalışırken sadece app.db dosyasını kopyalarsanız, yakın zamanda yapılan tüm commit işlemlerinin eksik olduğu bir dosya elde edersiniz. app.db dosyasını silip diğer ikisini yerinde bırakırsanız, SQLite bu eski WAL sayfalarını o isim altında beliren yeni dosyaya uygular; insanlar bir veritabanını sıfırlamaya çalışırken yeni bir veritabanını bu şekilde bozar.

Her üretim uygulaması için gereken bağlantı ayarları

Veritabanında yalnızca journal_mode saklanır. Aşağıdaki diğer tüm ayarlar bağlantı bazlıdır; bu da uygulamanızın, bir havuzun arka planda oluşturduğu her bağlantı dahil olmak üzere, açtığı her bağlantıda bu ayarları çalıştırması gerektiği anlamına gelir.

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA synchronous = NORMAL;
PRAGMA foreign_keys = ON;

busy_timeout = 5000, SQLite'a kilitli bir veritabanı için database is locked hatası döndürmeden önce 5000 milisaniyeye kadar yeniden deneme yapmasını söyler. Varsayılan değer 0'dır, bu nedenle varsayılan olarak SQLite, iki yazma işlemi çakıştığında ilk seferde başarısız olur. Bu tek değeri ayarlamak, genellikle SQLite'ın kendisine atfedilen kilit hatalarının çoğunu ortadan kaldırır.

synchronous = NORMAL, WAL modunda doğru ayardır ve bu değiş tokuşun anlaşılması gerekir. FULL seviyesinde SQLite, her commit işleminde WAL üzerinde fsync çağrısı yapar. NORMAL seviyesinde ise senkronizasyonu kontrol noktalarında (checkpoint) gerçekleştirir. SQLite belgeleri, bu işlemden vazgeçtikleriniz konusunda nettir: Bir elektrik kesintisi veya ani bir yeniden başlatma sonrasında işlemler artık kalıcı (durable) değildir. Veritabanı bu güç kaybı nedeniyle bozulmaz, yalnızca diske ulaşmamış olan son commit işlemleri kaybolur. Bir VPS üzerinde bu genellikle doğru bir tercihtir, çünkü her yazma işleminin yolundan bir fsync yükünü kaldırır.

foreign_keys = ON, geriye dönük uyumluluk nedeniyle varsayılan olarak kapalıdır ve bağlantı bazlıdır. REFERENCES ifadeleriyle dolu bir şema, her bağlantı bu özelliği açana kadar hiçbir şeyi zorunlu kılmaz.

Yalnızca daha sonra önem kazanan bir ayar daha vardır. SQLite, WAL boyutu 1000 sayfayı aştığında otomatik olarak kontrol noktası oluşturur ve bu işlem, o anda işlemini tamamlayan herhangi bir bağlantı tarafından gerçekleştirilir. Bu durum kendi başına bir sorun teşkil etmez. Ancak Litestream çalışıyorsa, kontrol noktalarının ne zaman gerçekleşeceği üzerinde kontrol sahibi olmak istediği için bu bir soru işareti haline gelir.

busy_timeout ayarından sonra database is locked hatası neden devam eder

Bu hata, kullanıcıları Postgres kullanmaya yönelten temel sorundur ve tek bir spesifik nedeni vardır.

Busy timeout bir busy handler kurar ancak SQLite bunu her zaman çağıracağını garanti etmez.

SQLite, busy handler çağrılmasının kilitlenmeye (deadlock) yol açabileceğini tespit ederse, busy handler'ı çağırmak yerine uygulamaya doğrudan SQLITE_BUSY döner.

Kaçınılan bu kilitlenme, işlem (transaction) yükseltme sırasında gerçekleşir. SQLite'ta yalın bir BEGIN, BEGIN DEFERRED anlamına gelir. Eğer bu ifadeden sonraki ilk komut bir SELECT ise, okuma işlemi (read transaction) içindesiniz demektir. Aynı işlem içerisinde daha sonra gelen bir UPDATE, yazma işlemine dönüşmek zorunda kaldığında ve okumanız başladığından beri başka bir bağlantı yazma yaptıysa, SQLite sizi bekletemez. Çünkü snapshot'ınız zaten güncelliğini yitirmiştir ve beklemek, iki bağlantının birbirini kilitlemesine neden olur. Dokümantasyon sonucu doğrudan belirtir:

Sonraki yazma ifadeleri, mümkünse işlemi yazma işlemine yükseltir veya SQLITE_BUSY döner.

5000 milisaniyelik zaman aşımı süreniz hiçbir zaman dikkate alınmaz. Hata anında döner, bu yüzden ayarın hiçbir işe yaramadığı izlenimi oluşur.

Çözüm tek bir kelimedir.

BEGIN IMMEDIATE;
UPDATE notes SET body = 'edited' WHERE id = 1;
COMMIT;

BEGIN IMMEDIATE, herhangi bir okuma yapmadan önce yazma kilidini en başta alır. Yükseltme işlemi olmadığı için kaçınılması gereken bir kilitlenme de oluşmaz; bu nedenle busy handler devreye girer ve bağlantı hata vermek yerine sırasını bekler. Sadece okuma yapılan işlemleri deferred olarak bırakın. Yazma içeren her işlem immediate olmalıdır.

Kilit hatalarının ikinci nedeni tespit edilmesi daha zor olanıdır: yazma işlemini yavaş işlemler boyunca açık tutmak. SQLite yazıcıları sıraya koyar; bu nedenle bir işlem açan, ağ üzerinden harici bir API çağıran ve ardından commit eden bir yapı, o çağrı süresince diğer tüm yazıcıları engeller. İhtiyacınız olan veriyi okuyun, işlemi kapatın, yavaş olan işi yapın ve ardından sonucu kaydetmek için kısa bir yazma işlemi açın.

Litestream ile sürekli yedekleme

Gece yapılan bir kopyalama işlemi bir güne kadar veri kaybına yol açabilir; canlı bir SQLite veritabanı üzerinde cp çalıştırmak ise açılamayan bir kopya oluşturabilir. İki yöntem güvenlidir. sqlite3 app.db ".backup /path/to/backup.db", SQLite'ın çevrimiçi yedekleme arayüzünü kullanır ve kullanımda olan bir veritabanı üzerinde çalışabilir. Litestream daha ileri giderek WAL dosyasını izler ve değişiklikleri sürekli olarak nesne depolama alanına gönderir; bu da en kötü durumdaki veri kaybınızı bir günden yaklaşık bir saniyeye indirir.

Litestream, uygulamanızın yanında çalışan tek bir Go ikili dosyasıdır. Uygulama ile veritabanı arasında konumlanmaz. Uygulamanız SQLite'a her zamanki gibi yazar, Litestream ise WAL dosyasını okuyarak değişen kısımları yükler.

cd /tmp
curl -fsSL -O https://github.com/benbjohnson/litestream/releases/download/v0.5.14/litestream-0.5.14-linux-x86_64.deb
sudo dpkg -i litestream-0.5.14-linux-x86_64.deb
litestream version

v0.5.14, Temmuz 2026 itibarıyla resmi Linux kurulum sayfasında belgelenen sürümdür; v0.5.15 ise 21 Temmuz 2026 tarihinde yayınlanmıştır. Her iki satırdaki sürümü, yayın sayfasındaki güncel etiketle eşleşecek şekilde değiştirin; eğer VPS'niz arm64 mimarisine sahipse ilgili arm64 paketini kullanın.

Yapılandırma dosyası /etc/litestream.yml konumunda bulunur. Bulut kimlik bilgilerine ihtiyaç duymadan tüm döngüyü doğrulamak için yerel bir dosya replikası ile başlayın.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      type: file
      path: /var/backups/litestream/app

İlgili alanın tekil olarak replica olduğuna dikkat edin. Litestream 0.5, 0.3 serisindeki replicas dizisini tek bir replika bloğu ile değiştirmiştir; bu nedenle iki girdi içeren bir yapılandırma dosyası başlangıçta hata verir. Üçüncü taraf rehberlerin çoğu hala eski dizi yapısını göstermektedir, bu yüzden arama motorlarında karşınıza çıkan ilk örneği değil, yukarıdaki şablonu kopyalayın. 0.5 serisi ayrıca litestream wal alt komutunu litestream ltx olarak yeniden adlandırmıştır, çünkü disk üzerindeki yedekleme formatı değişmiştir.

Herhangi bir özelliği etkinleştirmeden önce yapılandırmanın doğru ayrıştırıldığını kontrol edin.

sudo litestream databases -config /etc/litestream.yml

Ardından gidiş-dönüş sürecini manuel olarak doğrulayın. Bu biçim, yapılandırma dosyasını atlar ve bir veritabanını tek bir yola replike eder.

mkdir -p /tmp/replica
litestream replicate ~/app/app.db file:///tmp/replica/app

Bu komut ön planda çalışır ve çalışmaya devam eder. İkinci bir terminalde bir satır veri yazın ve replikayı yeni bir dosyaya geri yükleyin.

sqlite3 ~/app/app.db "INSERT INTO notes (body) VALUES ('written after replication started');"
litestream restore -o /tmp/restored.db file:///tmp/replica/app
sqlite3 /tmp/restored.db "SELECT count(*) FROM notes;"

Satır sayısı yeni eklenen satırı da içermelidir. Eğer içermiyorsa, değişiklik henüz senkronize edilmemiştir: Litestream, varsayılan olarak 1 saniye olan bir sync-interval süresinde gönderim yapar; bu yüzden bekleyip geri yüklemeyi tekrar deneyin. O bir saniyelik süre aynı zamanda kurtarma noktanızdır. Bir çökme durumunda en fazla son senkronizasyon aralığındaki veriler kaybolur ve hiçbir yapılandırma bu süreyi sıfıra indiremez.

Gerçek depolama için replika bloğunu bir S3 URL'si ile değiştirin. Bu yöntem, Amazon S3 ve diğer sağlayıcıların S3 uyumlu nesne depolama hizmetleri ile çalışır.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      url: s3://your-bucket-name/app
      region: us-east-1

snapshot:
  interval: 24h
  retention: 24h

Kimlik bilgilerini bu dosyada tutmayın. Litestream, LITESTREAM_ACCESS_KEY_ID ve LITESTREAM_SECRET_ACCESS_KEY değerlerini ortam değişkenlerinden okur; bu nedenle bunları root kullanıcısına ait ve 600 izin moduna sahip bir systemd drop-in dosyasına yerleştirin.

Yukarıdaki anlık görüntü (snapshot) değerleri varsayılan ayarlardır ve varsayılan saklama süresi (retention) genellikle kullanıcıları şaşırtır. Saklama süresi, Litestream'in anlık görüntüleri ve bunlara ait dosyaları ne kadar süre tutacağını belirler; dolayısıyla geçmişe dönük ne kadar süre öncesine geri yükleme yapabileceğinizi de tanımlar. Yirmi dört saatlik bir süre, Çarşamba sabahı fark ettiğiniz hatalı bir migrasyonun, Pazartesi günkü durumundan kurtarılamayacağı anlamına gelir. retention: 168h değerini bir hafta olarak ayarlayın ve ek depolama maliyetini karşılayın.

Geri yükleme işlemini ihtiyaç duymadan önce doğrulayın

litestream restore -o /tmp/check.db /home/appuser/app/app.db
sqlite3 /tmp/check.db "PRAGMA integrity_check;"
sqlite3 /tmp/check.db "SELECT count(*) FROM notes;"

Bir veritabanı yolu verildiğinde, litestream restore komutu /etc/litestream.yml içindeki eşleşen kopyayı bulur ve indirir. PRAGMA integrity_check komutu, sağlam bir dosya üzerinde ok çıktısını verir; bunun dışındaki herhangi bir çıktı, geri yüklenen kopyanın kullanılamaz olduğunu gösterir. Bu işlemi bir systemd servisi ve zamanlayıcısı ile düzenli olarak çalıştırın ve çıktıları inceleyin. Bir yedeği başarıyla geri yükleyene kadar, yedeğin çalıştığından emin olamazsınız.

Litestream'i systemd altında çalıştırma

Debian paketi, /etc/litestream.yml dosyasını okuyan bir litestream birimi kurar.

sudo systemctl enable litestream
sudo systemctl start litestream
sudo journalctl -u litestream -f

Sağlıklı bir çıktı, yapılandırmadaki her veritabanını listeler ve ardından periyodik eşitleme satırları dışında sessiz kalır. Veritabanı yolunuzda no such file or directory hatası almanız, yapılandırmadaki yolun yanlış olduğu veya sürecin bu yolu okuyamadığı anlamına gelir. Birim varsayılan olarak root yetkisiyle çalışır; bu, işin gerektirdiğinden daha fazla ayrıcalıktır. Litestream, veritabanı dosyasıyla birlikte dizini de okuyup yazabilmelidir; çünkü veritabanınızın yanındaki -wal ve -shm dosyalarıyla işlem yapar. Bu nedenle, servisi uygulamanızın halihazırda kullandığı hesapla çalıştırın.

# /etc/systemd/system/litestream.service.d/override.conf
[Service]
User=appuser
Group=appuser

Değişiklikleri sudo systemctl daemon-reload ve sudo systemctl restart litestream ile uygulayın. En az ayrıcalığa sahip özel bir servis hesabı oluşturmak birkaç dakika sürer; bu işlem, bir yedekleme aracısı ile sistemde çalışan ikinci bir root süreci arasındaki farkı yaratır.

Makineyi sıfırdan yeniden oluşturmanız durumunda bir sıralama detayı önem kazanır. Uygulama başlamadan önce veritabanının geri yüklenmesini istersiniz. litestream restore, dosya zaten mevcut olduğunda 0 koduyla çıkan -if-db-not-exists parametresini kabul eder, bu nedenle her açılışta çalıştırmak güvenlidir. Bunu uygulamanızın birim dosyasındaki bir ExecStartPre satırına ekleyin; böylece yeni bir VPS veritabanını indirirken, mevcut olan hiçbir işlem yapmaz. Eğer her şeyi tek bir yerde tutmak isterseniz, litestream replicate komutunun buna uygun bir -restore-if-db-not-exists bayrağı da mevcuttur.

SQLite'ın bir VPS üzerinde yetersiz kaldığı durumlar

Ağ dosya sistemleri. Bu, yapılandırma ile aşamayacağınız bir sınırdır. WAL modu, veritabanını kullanan her sürecin küçük bir bellek bölgesini paylaşmasını gerektirir; -shm dosyası bu işlevi sağlar. SQLite belgeleri bu kuralı hiçbir istisna olmaksızın belirtir:

Bir veritabanını kullanan tüm süreçler aynı ana bilgisayar üzerinde olmalıdır; WAL, ağ dosya sistemleri üzerinde çalışmaz.

Bu nedenle, mount edilmiş bir NFS (ağ dosya sistemi) veya SMB paylaşımı üzerindeki bir veritabanı bozulabilir ve hiçbir pragma bunu engelleyemez. Burada insanların gözden kaçırdığı bir ayrım vardır. Çoğu VPS sağlayıcısının ek depolama olarak bağladığı ağ blok cihazları, Linux'a üzerinde standart bir dosya sistemi olan sıradan bir disk gibi görünür ve bu durum sorun yaratmaz. Ancak mount edilmiş bir dosya paylaşımı böyle değildir.

İkinci bir uygulama sunucusu. Hiçbir ayar bunun çalışmasını sağlamaz. Aynı veriye hizmet veren iki makineye ihtiyaç duyduğunuz anda, ağ üzerinden konuşabilen bir veritabanına geçmeniz gerekir. Bu geçişi planlamak için vaktiniz varken kararınızı verin.

Yazma yoğunluklu iş yükleri. Aynı anda tek bir yazıcıya izin verilmesi, ayarlanabilir bir parametre değil, dosya biçiminin bir özelliğidir. Kısa yazma işlemleri düşük maliyetlidir çünkü her commit işlemi WAL dosyasına bir eklemedir; bu nedenle verim, CPU gücünden ziyade diskinizin küçük yazma gecikme süresine bağlıdır. Bu farkın nasıl göründüğü hakkında bilgi için VPS üzerinde NVMe ile SATA SSD depolama karşılaştırması bölümüne bakın. Uzun süren işlemler asıl sorundur, çünkü diğer tüm yazma işlemlerini kendi arkalarında sıraya sokarlar.

Analitik sorgular. SQLite, işlemler (transactions) için oluşturulmuş bir satır tabanlı depolama sistemidir. Yüz milyon satırı tarayan bir kontrol paneli, farklı bir aracın işidir ve Sunucu işleri için DuckDB ile SQLite karşılaştırması bölümü bu sınırın nerede olduğunu açıklar.

Replikasyon altında VACUUM. Tam bir VACUUM işlemi tüm veritabanı dosyasını yeniden yazar; bu da Litestream'in dosyanın tamamını tekrar yüklemesi gerektiği anlamına gelir. Litestream belgeleri, replikasyon aktifken bu işlemin yerinde çalıştırılmamasını tavsiye eder. Replikasyon sürecini durdurun, vacuum işlemini yapın, ardından süreci tekrar başlatın ve yeni bir tam snapshot oluşmasını bekleyin.

Tek veritabanı üzerinde iki replikatör. Aynı veritabanı veya aynı replika hedefi üzerinde asla iki Litestream süreci çalıştırmayın. Belgeler, bunu önlemenin sizin sorumluluğunuz olduğunu açıkça belirtir; aksi takdirde geri yükleyemeyeceğiniz bir replika ile karşılaşırsınız.

Litestream'in kapsamadığı durumlar

Litestream yalnızca veritabanı dosyasını korur, başka hiçbir şeyi değil. Yüklenen dosyalar, uygulama yapılandırması, TLS (transport layer security) sertifikaları ve unit dosyalarının yönetimi tamamen sizin sorumluluğunuzdadır. Bunu, restic kullanarak şifreli ve sunucu dışı yedekleme ile belirli bir takvime göre eşleştirirseniz her iki tarafı da güvence altına almış olursunuz. Eğer makine yeniyse, yeni bir VPS üzerinde ilk on dakika rehberi, bu kılavuzda halihazırda yapıldığı varsayılan kullanıcı hesabı ve güvenlik duvarı işlemlerini kapsar.

FAQ

SQLite üretim ortamındaki bir uygulama için yeterli midir?

Tek bir sunucuda çalışan tek bir uygulama için, WAL modunu etkinleştirdiğiniz, bir busy timeout süresi belirlediğiniz ve sürekli yedekleme yaptığınız sürece evet. Önemli olan yapısal sınırlar şunlardır: aynı anda tek bir yazıcı ve tek bir ana makine. Bu sınırlar dahilindeki bir uygulama, ağ trafiği veya izlenmesi gereken ayrı bir süreç gerektirmeyen bir veritabanına sahip olur. Bu sınırlara uymayan bir uygulama ise istemci-sunucu mimarisinde bir veritabanına ihtiyaç duyar ve hiçbir optimizasyon bunu değiştiremez.

busy_timeout ayarını yapmama rağmen neden hala database is locked hatası alıyorum?

Çünkü SQLite, beklemenin kilitlenmeye (deadlock) yol açabileceği durumlarda busy handler mekanizmasını atlar. Doğrudan BEGIN ile başlayan bir işlem ertelenmiş (deferred) kabul edilir: bir açılış SELECT komutu işlemi bir okuma işlemine sokar ve daha sonraki bir yazma işlemi yükseltme gerektirir. Eğer bu sırada başka bir bağlantı yazma işlemi gerçekleştirirse, okuma anlık görüntünüz (snapshot) geçersiz kaldığı için SQLite, busy handler'ı çağırmak yerine doğrudan SQLITE_BUSY hatasını döndürür. Yazma işlemi yapacak her türlü işlemi BEGIN IMMEDIATE ile başlatın; böylece yazma kilidi en başta alınır ve zaman aşımı süresi geçerli olur.

SQLite veritabanımı ağ depolama biriminde tutabilir miyim?

NFS veya SMB gibi ağ dosya sistemlerinde tutulamaz. WAL modu, tüm süreçlerin -shm dosyası üzerinden belleği paylaşmasını gerektirir ve SQLite belgeleri, veritabanını kullanan her sürecin aynı ana bilgisayarda olması gerektiğini belirtir. Sağlayıcınız tarafından bağlanan bir ağ blok aygıtı (network block device) farklı bir durumdur: Linux bunu normal bir dosya sistemine sahip normal bir disk olarak görür ve SQLite burada çalışır.

Zaten günlük yedekleme yapıyorsam Litestream kullanmama gerek var mı?

Bu, ne kadar veri kaybını göze alabileceğinize bağlıdır. Günlük bir yedekleme işi, yirmi dört saate kadar olan yazma işlemlerini kaybetmek anlamına gelir. Litestream saniyede yaklaşık bir kez eşitleme yapar, bu nedenle bir çökme durumunda yaklaşık son bir saniyelik veriyi kaybedersiniz. Ayrıca, veritabanını yazma işlemi sırasında kopyalayabilen cp komutu ile dosya kopyalamaktan daha güvenlidir. Litestream yalnızca veritabanını kapsar, bu nedenle yanında genel bir dosya yedekleme sistemi çalıştırmaya devam edin.