VPSలో productionకు SQLite సరైనదేనా?

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

చాలా చిన్న అప్లికేషన్‌లకు VPSలో productionలో 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, అలాగే ఎప్పుడు ఆపి వేరే databaseకు మారాలో వివరిస్తాం.

ముందుగా command line toolను install చేయండి. దిగువన ఉన్న అన్ని ఆదేశాలను 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గా ఉంటుంది. కాబట్టి ఇటీవలి 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 కు జతచేస్తుంది. Main database ను అలాగే ఉంచుతుంది. Readers ప్రారంభించిన snapshot వద్ద main file ను చదువుతూనే ఉంటాయి. అందువల్ల readers writer ను block చేయవు, writer readers ను block చేయదు. తర్వాత checkpoint సేకరించిన WAL pages ను తిరిగి main database లోకి కాపీ చేస్తుంది. ఈ ఒక్క మార్పే web application వెనుక SQLite ను ఉపయోగించగలిగేలా చేయడంలో ప్రధాన కారణం.

WAL మోడ్‌ను ప్రారంభించి, అది కొనసాగుతోందని నిర్ధారించండి

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

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

WAL మోడ్ శాశ్వతంగా ఉంటుంది. ఇది connection setting కాకుండా డేటాబేస్ header‌లోని flag. అందువల్ల ప్రతి database file‌కు దీన్ని ఒక్కసారి అమలు చేస్తే సరిపోతుంది. ఆ తర్వాత ప్రతి connection దీనిని స్వయంచాలకంగా పొందుతుంది. reboot తర్వాత కూడా ఇదే వర్తిస్తుంది. కొత్త 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 నిల్వ చేస్తుంది. ప్రతి connection map చేసుకునే shared memory index‌ను -shm file కలిగి ఉంటుంది. అందువల్ల WAL‌లో ఏమి ఉందో అన్ని connections‌కి ఒకే విధంగా తెలుస్తుంది. ఈ రెండు files డేటాబేస్‌లో భాగం; ఇవి scratch files కావు. అప్లికేషన్ నడుస్తున్నప్పుడు app.db ను మాత్రమే copy చేస్తే, ఇటీవలి ప్రతి commit లేని file మీకు లభిస్తుంది. app.db ను తొలగించి, మిగిలిన రెండు files‌ను అలాగే ఉంచితే, ఆ పేరుతో కనిపించే కొత్త file‌కు SQLite పాత WAL pages‌ను వర్తింపజేస్తుంది. ఒక డేటాబేస్‌ను reset చేయడానికి ప్రయత్నిస్తుండగా fresh database‌ను పాడుచేసే విధానం ఇదే.

ప్రతి 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 కోసం 5000 milliseconds వరకు మళ్లీ ప్రయత్నించమని SQLite కు చెబుతుంది. ఆ సమయం తర్వాత అది database is locked ను తిరిగి ఇస్తుంది. Default విలువ 0. అందువల్ల, ఇద్దరు writers ఒకేసారి పనిచేయడం ప్రారంభించినప్పుడు SQLite మొదటి సారి కలిసిన వెంటనే విఫలమవుతుంది. ఈ ఒక్క విలువను సెట్ చేయడం వల్ల SQLite కారణంగా వస్తున్నాయని భావించే చాలా lock errors తొలగిపోతాయి.

WAL mode లో synchronous = NORMAL సరైన setting. అయితే దాని trade-off ను అర్థం చేసుకోవాలి. FULL వద్ద, ప్రతి commit సమయంలో SQLite WAL పై fsync ను అమలు చేస్తుంది. NORMAL వద్ద, checkpoint సమయంలో 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 కు ప్రత్యేకమైన setting. REFERENCES clauses తో ఉన్న schema, ప్రతి connection దీన్ని on చేసే వరకు ఎలాంటి enforcement చేయదు.

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

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

ఈ సమస్య వల్ల చాలామంది మళ్లీ Postgres‌కు మారుతారు. దీనికి ఒక నిర్దిష్ట కారణం ఉంది.

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

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

ఇది నివారించే deadlock transaction upgrade సమయంలో జరుగుతుంది. 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‌ను రిటర్న్ చేస్తాయి.

మీ 5000 millisecond timeout‌ను అసలు పరిశీలించరు. Error వెంటనే వస్తుంది. అందుకే 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‌ను వరుసగా ఒక్కొక్కటిగా నిర్వహిస్తుంది. అందువల్ల transaction తెరచి, network ద్వారా external API‌ను పిలిచి, ఆ తర్వాత commit చేస్తే, ఆ call పూర్తయ్యేంతకాలం ప్రతి ఇతర writer‌ను అది నిరోధిస్తుంది. అవసరమైన డేటాను చదివి, transaction‌ను మూసివేయండి. Slow work‌ను పూర్తి చేసిన తర్వాత, ఫలితాన్ని నిల్వ చేయడానికి చిన్న write transaction‌ను తెరవండి.

Litestreamతో నిరంతర బ్యాకప్

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

Litestream అనేది మీ అప్లికేషన్ పక్కన నడిచే ఒక Go binary. ఇది అప్లికేషన్ మరియు డేటాబేస్ మధ్యలో ఉండదు. మీ అప్లికేషన్ మునుపటిలాగే SQLite కు రాస్తుంది. 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 July నాటికి అధికారిక 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 ను కాకుండా, పైనున్న నిర్మాణాన్ని కాపీ చేయండి. 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 ను కూడా కలిగి ఉంటుంది. అది లేకపోతే, మార్పు ఇంకా sync కాలేదు. Litestream sync-interval పై push చేస్తుంది, దాని default 1 second. కాబట్టి వేచి ఉండి మళ్లీ restore చేయండి. ఆ ఒక second మీ recovery point కూడా. Crash జరిగితే, చివరి sync interval లో చేసిన రాతలు మాత్రమే గరిష్ఠంగా కోల్పోతారు. ఏ configuration కూడా ఈ నష్టాన్ని సున్నాగా చేయదు.

నిజమైన 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 చాలామందికి ఊహించని విధంగా ఉంటుంది. Retention అంటే Litestream snapshots మరియు వాటికి చెందిన files ను ఎంతకాలం ఉంచుతుందో. అందువల్ల గతంలో ఎంత దూరం వరకు restore చేయగలరో కూడా అదే నిర్ణయిస్తుంది. Twenty-four hours అంటే, బుధవారం ఉదయం గుర్తించిన తప్పు migration ను సోమవారం 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ను గుర్తించి, దాన్ని డౌన్‌లోడ్ చేస్తుంది. ఆరోగ్యంగా ఉన్న fileపై PRAGMA integrity_check, okను ప్రింట్ చేస్తుంది. ఇతర output ఏదైనా వస్తే, పునరుద్ధరించిన copy ఉపయోగించలేనిదని అర్థం. దీన్ని systemd service మరియు timerతో షెడ్యూల్ ప్రకారం అమలు చేసి, outputను చదవండి. మీరు ఒకసారి backupను పునరుద్ధరించే వరకు, అది పనిచేస్తుందని మీకు తెలియదు.

systemd కింద Litestream ను అమలు చేయండి

Debian ప్యాకేజీ litestream unit ను ఇన్‌స్టాల్ చేస్తుంది. ఈ unit /etc/litestream.yml ను చదువుతుంది.

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

సక్రమంగా పనిచేసే output లో config నుంచి ప్రతి database పేరు కనిపిస్తుంది. ఆ తర్వాత, కాలానుగుణ sync lines తప్ప output ఉండదు. మీ database path పై no such file or directory అనే error వస్తే, config లోని path తప్పుగా ఉంది లేదా process దాన్ని చదవలేకపోతోంది. డిఫాల్ట్‌గా unit root గా అమలవుతుంది. ఈ పనికి అది అవసరమైన దానికంటే ఎక్కువ privilege. 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 తో ఈ మార్పును అమలు చేయండి. కనిష్ట privilege కలిగిన ప్రత్యేక service account ను ఏర్పాటు చేయడం కు కొన్ని నిమిషాలు పడుతుంది. దీని వల్ల backup agent మరియు ఆ machine పై నడుస్తున్న రెండవ root process మధ్య స్పష్టమైన తేడా ఉంటుంది.

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

VPSలో SQLite ఎక్కడ పరిమితులను ఎదుర్కొంటుంది

నెట్‌వర్క్ ఫైల్ సిస్టమ్‌లు. దీని చుట్టూ కాన్ఫిగర్ చేసి అధిగమించలేని పరిమితి ఇదే. డేటాబేస్‌ను ఉపయోగించే ప్రతి process ఒక చిన్న memory ప్రాంతాన్ని పంచుకోవాలి కాబట్టి WAL modeకి ఇది అవసరం. ఆ ప్రాంతాన్ని -shm file అందిస్తుంది. SQLite documentation ఈ నియమాన్ని ఎలాంటి మినహాయింపు లేకుండా పేర్కొంటుంది:

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

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

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

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

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

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

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

Litestream కవర్ చేయనివి

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

FAQ

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

ఒక serverలో ఒక application కోసం అయితే, అవును. అయితే WAL modeను ఆన్ చేయాలి, busy timeoutను సెట్ చేయాలి, అలాగే నిరంతర backupలు తీసుకోవాలి. ముఖ్యమైన పరిమితులు నిర్మాణపరమైనవి: ఒకేసారి ఒక writer మాత్రమే ఉండాలి, అలాగే ఒక host machine మాత్రమే ఉండాలి. ఈ పరిమితుల్లో పనిచేసే applicationకు network hop లేకుండా, పర్యవేక్షించాల్సిన ప్రత్యేక process లేకుండా database లభిస్తుంది. ఈ పరిమితుల్లో సరిపోని applicationకు 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 మధ్యలో ఉన్న స్థితిని capture చేయవచ్చు. Litestream databaseను మాత్రమే కవర్ చేస్తుంది. కాబట్టి దానితో పాటు సాధారణ file backupను కూడా అమలు చేయండి.