VPSలో SQLite production databaseగా వాడటం

VPSలో SQLite సరైన production database అయ్యే సందర్భం

చిన్న అప్లికేషన్లలో production కోసం VPSపై SQLite వాడటం సాధారణంగా సరైన ఎంపిక. కారణం సులభం: ఒక machineలో ఒక process ఒక fileలో రాస్తే database server అవసరం ఉండదు. పర్యవేక్షించాల్సిన daemon ఉండదు. firewallలో అనుమతించాల్సిన port ఉండదు. మార్చాల్సిన password ఉండదు. నిరంతరం నడిపించాల్సిన రెండో machine ఉండదు. Query network round trip కాకుండా function callగా అమలవుతుంది. అందువల్ల ఒక page నలభై queries అమలు చేస్తే, దానికి నలభై function calls మాత్రమే ఖర్చవుతాయి.

దీనికి కొన్ని స్పష్టమైన పరిమితులు ఉన్నాయి. మొత్తం database fileపై ఒకేసారి ఒక writerకే SQLite అనుమతిస్తుంది. అలాగే ఆ fileను రెండు machines మధ్య share చేయలేరు. ఒకే VPSపై ఒకే application నడుస్తున్నప్పుడు ఈ రెండు పరిమితులు సమస్య కావు. కానీ ఈ నిర్మాణాన్ని దాటిన వెంటనే అవే పరిమితులు తీవ్రమైన అడ్డంకులుగా మారతాయి. ఈ guideలో serverపై SQLiteను సురక్షితంగా నడిపించే settings, Litestreamతో నిరంతర backup, అలాగే SQLiteను ఎప్పుడు నిలిపివేయాలో వివరిస్తాం.

ముందుగా command line toolను install చేయండి. దిగువన ఉన్న అన్ని commands Ubuntu 24.04పై అమలు చేయబడ్డాయి.

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

ఇది 3.తో ప్రారంభమయ్యే versionను, తరువాత build date మరియు source hashను చూపిస్తుంది. July 2026 నాటికి Ubuntu 24.04లో SQLite 3.45.1 అందుబాటులో ఉంది. మీ application బహుశా ఈ binaryని ఉపయోగించదు. చాలా language runtimes SQLite library యొక్క స్వంత copyని, తరచుగా మరింత కొత్త versionను, bundle చేస్తాయి. అందువల్ల recent featureపై ఆధారపడే ముందు మీ database driver చూపించే versionను పరిశీలించండి.

WAL mode ను ముందుగా ఎందుకు మార్చాలి

డిఫాల్ట్‌గా SQLite rollback journal ను ఉపయోగిస్తుంది. ఏదైనా page ను మార్చే ముందు, అది అసలు page ను -journal file లోకి కాపీ చేసి, తరువాత database ను అదే స్థానంలో సవరించుతుంది. ఈ ప్రక్రియను సురక్షితంగా నిర్వహించడానికి మొత్తం file పై exclusive lock తీసుకుంటుంది. అందువల్ల ఏదైనా write జరుగుతున్నప్పుడు ప్రతి reader వేచి ఉండాలి. Laptop పై దీన్ని ఎవరూ గమనించరు. Web server పై database ను ఉపయోగించే ప్రతి request ను ఒక నెమ్మదైన write నిలిపివేస్తుంది.

WAL (write-ahead log) mode ఈ క్రమాన్ని మార్చుతుంది. Writer కొత్త pages ను ప్రత్యేకమైన -wal file కు append చేసి, ప్రధాన database ను అలాగే ఉంచుతుంది. Readers తాము ప్రారంభించిన సమయంలో ఉన్న snapshot ఆధారంగా ప్రధాన file నుంచే చదవడం కొనసాగిస్తాయి. అందువల్ల readers writer ను block చేయవు; writer కూడా readers ను block చేయదు. తరువాత checkpoint, సేకరించిన WAL pages ను ప్రధాన database లోకి కాపీ చేస్తుంది. SQLite ను web application వెనుక ఉపయోగించగలిగేలా చేసే ప్రధాన కారణాల్లో ఈ ఒక్క మార్పు ముఖ్యమైనది.

WAL మోడ్‌ను ప్రారంభించి, అది అమలులోనే ఉందని నిర్ధారించండి

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

కమాండ్ wal ను ప్రింట్ చేస్తుంది. ఆ output అలంకరణ కాదు. PRAGMA journal_mode ద్వారా database ప్రస్తుతం ఉపయోగిస్తున్న mode తిరిగి వస్తుంది. కాబట్టి delete అనే సమాధానం వస్తే మార్పు విఫలమైందని, ఇంకా rollback journal mode లోనే ఉన్నారని అర్థం.

WAL mode శాశ్వతంగా ఉంటుంది. ఇది connection setting కాకుండా database header లోని flag. అందువల్ల ప్రతి database file కు దీన్ని ఒక్కసారి అమలు చేస్తే సరిపోతుంది. Reboot తర్వాత కూడా ప్రతి తదుపరి connection ఈ mode ను స్వయంచాలకంగా ఉపయోగిస్తుంది. కొత్త connection తో దీన్ని నిర్ధారించండి.

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

ఇప్పుడు ఒక table సృష్టించి, disk పై ఏమి కనిపిస్తుందో చూడండి.

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/

ఇప్పుడు మూడు files ఉన్నాయి: app.db, app.db-wal మరియు app.db-shm. ఇంకా checkpoint చేయని committed pages ను -wal file లో ఉంచుతుంది. అన్ని connections ఈ file ను map చేసుకుని, WAL లో ఉన్న విషయంపై ఏకాభిప్రాయంతో ఉండేందుకు -shm file shared memory index గా పనిచేస్తుంది. ఈ రెండు files database కు చెందినవే; ఇవి scratch files కావు. Application నడుస్తున్నప్పుడు app.db ను మాత్రమే copy చేస్తే, ఇటీవలి ప్రతి commit లేని file లభిస్తుంది. app.db ను delete చేసి, మిగిలిన రెండు files ను అలాగే ఉంచితే, SQLite ఆ పాత WAL pages ను ఆ పేరుతో కనిపించే కొత్త file కు apply చేస్తుంది. ఒక database ను reset చేయాలనే ప్రయత్నంలో fresh database ను corrupt చేయడానికి ఇదే కారణమవుతుంది.

Productionలో ప్రతి appకు అవసరమైన connection settings

journal_mode మాత్రమే databaseలో నిల్వ చేయబడుతుంది. దిగువన ఉన్న ప్రతి ఇతర setting ఒక్కో connection‌కు వర్తిస్తుంది. అంటే application తెరిచే ప్రతి connection‌పై దీన్ని అమలు చేయాలి. Backgroundలో pool సృష్టించే ప్రతి connection కూడా ఇందులోకి వస్తుంది.

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

busy_timeout = 5000 ద్వారా locked database కోసం SQLite గరిష్ఠంగా 5000 milliseconds వరకు మళ్లీ ప్రయత్నిస్తుంది. ఆ తర్వాత database is locked ను తిరిగి ఇస్తుంది. Default విలువ 0. అందువల్ల ఇద్దరు writers ఒకేసారి పనిచేయడం ప్రారంభించినప్పుడు SQLite వెంటనే విఫలమవుతుంది. ఈ ఒక్క విలువను సెట్ చేయడం వల్ల SQLite సమస్యగా భావించే lock errors‌లో ఎక్కువ భాగం తొలగిపోతాయి.

synchronous = NORMAL అనేది WAL modeలో సరైన setting. అయితే దాని trade-offను అర్థం చేసుకోవాలి. FULL వద్ద ప్రతి commit సమయంలో SQLite WALపై fsync అమలు చేస్తుంది. NORMAL వద్ద checkpoints సమయంలో మాత్రమే sync చేస్తుంది. దీని వల్ల ఏమి కోల్పోతారో SQLite documentation స్పష్టంగా చెబుతుంది: power failure లేదా hard reset తర్వాత transactions ఇక durableగా ఉండవు. ఆ power loss వల్ల database corrupt కాదు. Diskకు చేరని చివరి commits మాత్రమే కోల్పోతారు. VPSలో ఇది సాధారణంగా సరైన trade-off. ఎందుకంటే ప్రతి write మార్గం నుంచి ఒక fsync తొలగిపోతుంది.

foreign_keys = ON backwards compatibility కోసం defaultగా offలో ఉంటుంది. ఇది ఒక్కో connection‌కు వర్తిస్తుంది. REFERENCES clausesతో నిండిన schemaలో, ప్రతి connection ఈ settingను on చేసే వరకు ఎటువంటి enforcement జరగదు.

మరో setting తరువాతి దశలో మాత్రమే ముఖ్యమవుతుంది. WAL 1000 pagesను దాటితే SQLite స్వయంచాలకంగా checkpoints అమలు చేస్తుంది. ఆ సమయంలో transactionను పూర్తి చేసే ఏ connection అయినా ఈ పనిని నిర్వహిస్తుంది. సాధారణంగా ఇది సమస్య కాదు. కానీ Litestream నడుస్తున్నప్పుడు ఇది ఒక ప్రశ్నగా మారుతుంది. ఎందుకంటే checkpoints ఎప్పుడు జరగాలో Litestream నియంత్రించాలనుకుంటుంది.

busy_timeout సెట్ చేసిన తర్వాత కూడా database is locked ఎందుకు జరుగుతుంది

ఈ లోపం వచ్చినప్పుడు చాలామంది Postgres కు తిరిగి వెళ్తారు. దీనికి ఒక నిర్దిష్ట కారణం ఉంది.

busy timeout ఒక busy handler ను ఇన్‌స్టాల్ చేస్తుంది. అయితే SQLite ఆ handler ను తప్పనిసరిగా పిలుస్తుందని హామీ ఇవ్వదు.

busy handler ను పిలవడం వల్ల deadlock ఏర్పడే అవకాశం ఉందని SQLite గుర్తిస్తే, busy handler ను పిలవకుండా నేరుగా అప్లికేషన్‌కు SQLITE_BUSY ను return చేస్తుంది.

Transaction upgrade సమయంలో ఇది నివారించే deadlock ఏర్పడుతుంది. SQLite లో ఖాళీ BEGIN అంటే BEGIN DEFERRED. దాని తర్వాతి మొదటి statement SELECT అయితే, మీరు read transaction లో ఉన్నారు. అదే transaction లో తరువాతి UPDATE write transaction గా మారాల్సి వచ్చినప్పుడు, మీ read ప్రారంభమైన తర్వాత మరో connection రాసి ఉంటే, SQLite మిమ్మల్ని వేచి ఉండనివ్వదు. కారణం, మీ snapshot ఇప్పటికే పాతదైపోయింది. వేచి ఉండటం వల్ల రెండు connections పరస్పరం deadlock లో చిక్కుకుంటాయి. Documentation ఫలితాన్ని నేరుగా ఇలా వివరిస్తుంది:

సాధ్యమైతే తరువాతి write statements transaction ను write transaction గా upgrade చేస్తాయి. లేకపోతే SQLITE_BUSY ను return చేస్తాయి.

మీ 5000 millisecond timeout ను అసలు పరిశీలించరు. లోపం వెంటనే వస్తుంది. అందుకే ఆ setting పనిచేయలేదని అనిపిస్తుంది.

పరిష్కారం ఒక్క పదమే.

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

BEGIN IMMEDIATE ఏదైనా చదవకముందే ప్రారంభంలోనే write lock తీసుకుంటుంది. Upgrade జరగదు. అందువల్ల నివారించాల్సిన deadlock ఉండదు. Busy handler వర్తిస్తుంది. Connection విఫలమవకుండా తన వంతు కోసం వేచి ఉంటుంది. Read-only transactions ను deferred గానే ఉంచండి. Write కలిగిన ప్రతి transaction immediate గా ఉండాలి.

Lock errors కు మరో కారణాన్ని గుర్తించడం కష్టం: slow work సమయంలో write transaction ను తెరిచి ఉంచడం. SQLite writers ను serialise చేస్తుంది. అందువల్ల transaction తెరిచి, network ద్వారా external API ను పిలిచి, తరువాత commit చేసే code ఆ call పూర్తయ్యేంత వరకు ప్రతి ఇతర writer ను block చేస్తుంది. అవసరమైన data ను చదివి transaction ను close చేయండి. Slow work ను తరువాత చేయండి. ఆ ఫలితాన్ని నిల్వ చేయడానికి చిన్న write transaction ను మళ్లీ open చేయండి.

Litestreamతో నిరంతర backup

ప్రతి రాత్రి తీసే copy వల్ల గరిష్ఠంగా ఒక రోజు writes కోల్పోవచ్చు. నడుస్తున్న SQLite database పై cp అమలు చేస్తే open కాని copy తయారయ్యే అవకాశం ఉంది. రెండు విధానాలు సురక్షితమైనవి. sqlite3 app.db ".backup /path/to/backup.db" SQLite online backup interface ను ఉపయోగిస్తుంది. అందువల్ల database ఉపయోగంలో ఉన్నప్పటికీ అది పనిచేస్తుంది. Litestream ఇంకా ముందుకు వెళ్తుంది. ఇది WAL ను monitor చేసి, మార్పులను object storage కు నిరంతరం పంపుతుంది. దీంతో గరిష్ఠ data loss ఒక రోజు నుంచి సుమారు ఒక సెకనుకు తగ్గుతుంది.

Litestream అనేది మీ application పక్కన నడిచే ఒక Go binary. ఇది app మరియు database మధ్యలో పనిచేయదు. మీ application మునుపటిలాగే SQLite కు writes చేస్తుంది. Litestream WAL ను చదివి, మారిన డేటాను upload చేస్తుంది.

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

జూలై 2026 నాటికి అధికారిక Linux install page లో v0.5.14 release గా నమోదు చేయబడింది. 21 July 2026న v0.5.15 విడుదలైంది. ప్రస్తుత releases page లోని tag కు సరిపోయేలా రెండు lines లోని version ను మార్చండి. మీ VPS arm64 అయితే, దానికి సరిపోయే arm64 package ను ఉపయోగించండి.

Configuration file /etc/litestream.yml వద్ద ఉంటుంది. ముందుగా local file replica తో ప్రారంభించండి. దీనివల్ల cloud credentials అవసరం లేకుండానే మొత్తం ప్రక్రియ పనిచేస్తోందని నిర్ధారించవచ్చు.

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

ఆ field replica అని గమనించండి. ఇది singular. Litestream 0.5లో, 0.3 series లోని replicas array ను ఒకే replica block తో భర్తీ చేశారు. ఇప్పుడు రెండు entries ఉన్న config startup వద్ద విఫలమవుతుంది. అనేక third-party guides ఇప్పటికీ పాత array ను చూపిస్తున్నాయి. అందువల్ల search లో ముందుగా కనిపించే example ను కాకుండా, పైన చూపిన నిర్మాణాన్ని copy చేయండి. 0.5 series లో litestream wal subcommand పేరును litestream ltx గా మార్చారు. కారణం on-disk backup format మారడమే.

ఏదైనా enable చేయడానికి ముందు config ను parse చేయగలదో లేదో తనిఖీ చేయండి.

sudo litestream databases -config /etc/litestream.yml

తర్వాత round trip ను చేతితో నిర్ధారించండి. ఈ విధానం config file ను దాటవేసి, ఒక database ను ఒక path కు replicate చేస్తుంది.

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

ఇది foreground లో నడుస్తూ కొనసాగుతుంది. రెండవ shell లో ఒక row ను రాసి, replica ను కొత్త file లోకి restore చేయండి.

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;"

ఈ count లో కొత్త row కూడా ఉంటుంది. అది లేకపోతే change ఇంకా sync కాలేదు. Litestream sync-interval పై push చేస్తుంది. దీని default విలువ 1 second. కొంతసేపు వేచి ఉండి మళ్లీ restore చేయండి. ఆ 1 second మీ recovery point కూడా. Crash జరిగితే, చివరి sync interval లో రాసిన writes గరిష్ఠంగా కోల్పోవచ్చు. ఏ configuration తోనూ ఈ నష్టాన్ని zero చేయలేరు.

నిజమైన storage కోసం replica block స్థానంలో S3 URL ను ఉపయోగించండి. ఇది Amazon S3 తోనూ, ఇతర providers అందించే S3-compatible object storage తోనూ పనిచేస్తుంది.

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

snapshot:
  interval: 24h
  retention: 24h

Credentials ను ఆ file లో ఉంచవద్దు. Litestream environment నుంచి LITESTREAM_ACCESS_KEY_ID మరియు LITESTREAM_SECRET_ACCESS_KEY చదువుతుంది. అందువల్ల వాటిని root యాజమాన్యంలోని mode 600 కలిగిన systemd drop-in లో ఉంచండి.

పైన ఉన్న snapshot values defaults. Retention default చాలామందిని ఆశ్చర్యపరుస్తుంది. Litestream snapshots మరియు వాటికి సంబంధించిన files ను ఎంతకాలం ఉంచాలో retention నిర్ణయిస్తుంది. అందువల్ల గతంలో ఎంత దూరం వరకు restore చేయగలరో కూడా అదే నిర్ణయిస్తుంది. Twenty-four hours అంటే Wednesday morning గుర్తించిన bad migration ను Monday state నుంచి ఇక restore చేయలేమని అర్థం. retention: 168h ను ఒక వారం కోసం సెట్ చేయండి. అదనపు storage కోసం అయ్యే ఖర్చును అంగీకరించండి.

మీకు అవసరం రాకముందే పునరుద్ధరణను ధృవీకరించండి

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;"

డేటాబేస్ path ఇచ్చినప్పుడు, litestream restore, /etc/litestream.yml లో సరిపోలే replicaను గుర్తించి, దాన్ని download చేస్తుంది. ఆరోగ్యంగా ఉన్న fileపై PRAGMA integrity_check, ok ను print చేస్తుంది. ఇతర output ఏదైనా వస్తే, పునరుద్ధరించిన copy ఉపయోగించలేనిదని అర్థం. దీన్ని systemd service మరియు timer తో schedule ప్రకారం run చేసి, outputను పరిశీలించండి. కనీసం ఒకసారి backupను restore చేసే వరకు అది పనిచేస్తుందని మీకు తెలియదు.

systemd కింద Litestream ను నడపడం

Debian package litestream unit ను ఇన్‌స్టాల్ చేస్తుంది. ఇది /etc/litestream.yml ను చదువుతుంది.

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

సరిగ్గా పనిచేస్తున్నప్పుడు config లోని ప్రతి database పేరు output లో కనిపిస్తుంది. తరువాత periodic sync lines తప్ప సాధారణంగా మరే output ఉండదు. మీ database path పై no such file or directory error వస్తే config లోని path తప్పుగా ఉండవచ్చు, లేదా process దాన్ని చదవలేకపోవచ్చు. ఈ unit default గా root గా నడుస్తుంది. ఈ పనికి అది అవసరమైన దానికంటే ఎక్కువ privileges. Litestream కు database ను, దాన్ని కలిగి ఉన్న directory ను రెండింటినీ చదవడం మరియు రాయడం సాధ్యమై ఉండాలి. ఎందుకంటే అది మీ database పక్కన ఉన్న -wal మరియు -shm files తో పనిచేస్తుంది. అందువల్ల మీ application ఇప్పటికే ఉపయోగిస్తున్న account ను దీనికి ఇవ్వండి.

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

దీన్ని sudo systemctl daemon-reload మరియు sudo systemctl restart litestream తో అమలు చేయండి. కనిష్ఠ privileges కలిగిన ప్రత్యేక service account ఏర్పాటు చేయడానికి కొన్ని నిమిషాలే పడుతుంది. దీని వల్ల backup agent సాధారణ process గా ఉంటుంది; server పై రెండవ root process గా మారదు.

మీరు machine ను పూర్తిగా కొత్తగా rebuild చేయాల్సి వస్తే ఒక startup క్రమం ముఖ్యమైనది. Application ప్రారంభమయ్యే ముందు database restore కావాలి. litestream restore లో -if-db-not-exists ను అంగీకరిస్తుంది. File ఇప్పటికే ఉంటే ఇది 0 తో exit అవుతుంది. అందువల్ల ప్రతి boot లో దీన్ని అమలు చేయడం సురక్షితం. మీ application unit లోని ExecStartPre line లో దీన్ని ఉంచండి. అప్పుడు కొత్త VPS database ను download చేస్తుంది, ఇప్పటికే ఉన్న VPS లో మాత్రం ఏమీ చేయదు. దీన్ని ఒకే చోట ఉంచాలనుకుంటే litestream replicate కు దీనికి సరిపోయే -restore-if-db-not-exists flag ఉంది.

VPSలో SQLite పరిమితులు

Network filesystems. దీన్ని configuration ద్వారా అధిగమించలేరు. WAL mode కోసం database ను ఉపయోగించే ప్రతి process ఒక చిన్న memory ప్రాంతాన్ని పంచుకోవాలి. ఈ ప్రాంతాన్ని -shm file అందిస్తుంది. SQLite documentation ఎలాంటి మినహాయింపు లేకుండా ఈ నియమాన్ని చెబుతుంది:

Database ను ఉపయోగించే అన్ని processes ఒకే host computer పై ఉండాలి; network filesystem ద్వారా WAL పనిచేయదు.

అందువల్ల mounted NFS (network file system) లేదా SMB share పై ఉన్న database పాడైపోవచ్చు. ఏ pragma కూడా దీనిని నిరోధించదు. ఇక్కడ చాలామంది గమనించని ఒక తేడా ఉంది. చాలా VPS providers అదనపు storage గా జతచేసే network block device Linuxకు సాధారణ diskగా, దానిపై సాధారణ filesystemతో కనిపిస్తుంది. అది సమస్య కాదు. Mounted file share మాత్రం వేరు.

రెండవ application server. ఏ setting తోనూ ఇది పనిచేయదు. ఒకే data ను రెండు machines అందించాల్సి వస్తే, network ద్వారా పనిచేసే database అవసరం. ప్రణాళిక చేసుకునే సమయం ఉన్నప్పుడే ఈ మార్పు చేయాలని నిర్ణయించుకోండి.

Write-heavy workloads. ఒకేసారి ఒక writer మాత్రమే పనిచేయడం file format లక్షణం. ఇది మార్చగలిగే setting కాదు. ప్రతి commit WALకు append కావడం వల్ల చిన్న writes తక్కువ ఖర్చుతో పూర్తవుతాయి. అందువల్ల throughput మీ CPU కంటే disk యొక్క small-write latencyపై ఎక్కువగా ఆధారపడి ఉంటుంది. ఆ తేడా ఎలా ఉంటుందో VPSలో NVMe మరియు SATA SSD storage పోలికలో చూడండి. అసలు సమస్య దీర్ఘమైన transactions. అవి మిగిలిన ప్రతి writerను queueలో వేచి ఉండేలా చేస్తాయి.

Analytical queries. SQLite transactions కోసం రూపొందించిన row store. వంద మిలియన్ rows ను scan చేసే dashboard వేరే పని, దానికి వేరే tool అవసరం. ఆ పరిమితి ఎక్కడ వస్తుందో server పనుల కోసం DuckDB మరియు SQLite పోలికలో వివరించాం.

Replicationలో VACUUM. పూర్తి VACUUM మొత్తం database fileను మళ్లీ రాస్తుంది. అందువల్ల Litestream దాన్ని మళ్లీ పూర్తిగా upload చేయాలి. Replication చురుకుగా ఉన్నప్పుడు దానిని అదే స్థలంలో run చేయవద్దని Litestream documentation సూచిస్తుంది. Replicatorను stop చేసి, vacuum అమలు చేసి, మళ్లీ start చేయండి. కొత్త full snapshot తయారవుతుందని అంచనా వేయండి.

ఒకే databaseపై రెండు replicators. ఒకే database లేదా ఒకే replica destinationపై రెండు Litestream processesను ఎప్పుడూ run చేయవద్దు. దీన్ని నిరోధించడం మీ బాధ్యత అని documentation స్పష్టంగా చెబుతుంది. లేకపోతే restore చేయలేని replica తయారవుతుంది.

Litestream ఏ అంశాలను కవర్ చేయదు

Litestream database file ను మాత్రమే రక్షిస్తుంది. మిగతా ఏదీ దాని పరిధిలోకి రాదు. Uploaded files, application config, TLS (transport layer security) certificates, unit files ను మీరు స్వయంగా నిర్వహించాలి. షెడ్యూల్ ప్రకారం restic ఉపయోగించి గుప్తీకరించిన off-box backups తో దీన్ని కలిపితే, రెండు భాగాలూ కవర్ అవుతాయి. యంత్రం కొత్తదైతే, ఈ guide ఇప్పటికే పూర్తయిందని భావించే user account మరియు firewall పనుల కోసం కొత్త VPS పై మొదటి పది నిమిషాలు చూడండి.

FAQ

ఉత్పత్తి వాతావరణంలోని అప్లికేషన్‌కు SQLite సరిపోతుందా?

ఒక సర్వర్‌పై ఒక అప్లికేషన్‌కు అయితే సరిపోతుంది. అయితే WAL mode ను ఆన్ చేసి, busy timeout సెట్ చేసి, నిరంతర backup నిర్వహించాలి. ముఖ్యమైన పరిమితులు నిర్మాణాత్మకమైనవి: ఒకేసారి ఒక writer మాత్రమే ఉండగలదు, అలాగే ఒక host machine మాత్రమే ఉండాలి. ఈ పరిమితుల్లో పనిచేసే అప్లికేషన్‌కు network hop లేదా పర్యవేక్షించాల్సిన ప్రత్యేక process అవసరం లేని database లభిస్తుంది. ఈ పరిమితుల్లో సరిపోని అప్లికేషన్‌కు client-server database అవసరం. ఎంత tuning చేసినా ఆ పరిమితులు మారవు.

busy_timeout సెట్ చేసిన తర్వాత కూడా database is locked ఎందుకు వస్తోంది?

వేచి ఉండటం deadlock కు దారితీసే అవకాశం ఉన్నప్పుడు SQLite busy handler ను దాటవేస్తుంది. సాధారణ BEGIN తో ప్రారంభమయ్యే transaction deferred గా ఉంటుంది: ప్రారంభ SELECT దానిని read transaction గా ఉంచుతుంది, తరువాతి write దాన్ని upgrade చేయాలి. మధ్యలో మరొక connection write చేస్తే, మీ read snapshot ఇప్పటికే పాతదై ఉంటుంది. అందువల్ల SQLite మీ busy handler ను పిలవకుండా వెంటనే SQLITE_BUSY ను తిరిగి ఇస్తుంది. Write చేసే ప్రతి transaction ను BEGIN IMMEDIATE తో ప్రారంభించండి. అప్పుడు write lock ప్రారంభంలోనే తీసుకోబడుతుంది, timeout వర్తిస్తుంది.

నా SQLite database ను network storage పై ఉంచవచ్చా?

NFS లేదా SMB వంటి network filesystem పై ఉంచకూడదు. WAL mode కు అన్ని processes -shm file ద్వారా memory ను పంచుకోవాలి. Database ను ఉపయోగించే ప్రతి process ఒకే host computer పై ఉండాలని SQLite documentation స్పష్టం చేస్తుంది. మీ provider అందించే network block device వేరు. Linux దాన్ని సాధారణ filesystem కలిగిన సాధారణ disk గా చూస్తుంది. అక్కడ SQLite పనిచేస్తుంది.

నేను ఇప్పటికే nightly backups నడుపుతున్నప్పుడు Litestream అవసరమా?

మీరు ఎంత data కోల్పోవడానికి సిద్ధంగా ఉన్నారనే దానిపై ఆధారపడి ఉంటుంది. Nightly job ఉంటే గరిష్ఠంగా ఇరవై నాలుగు గంటల writes కోల్పోవచ్చు. Litestream సుమారు ప్రతి సెకనుకు sync చేస్తుంది. అందువల్ల crash సమయంలో సాధారణంగా చివరి సెకను data మాత్రమే కోల్పోతారు. cp తో database file ను copy చేయడం కంటే ఇది సురక్షితం. ఎందుకంటే ఆ copy database మధ్యలో write జరుగుతున్న సమయంలో తీసుకోబడవచ్చు. Litestream database ను మాత్రమే కవర్ చేస్తుంది. కాబట్టి దాని పక్కనే సాధారణ file backup కూడా కొనసాగించండి.