VPS-ல் SQLite-ஐ production-ல் பயன்படுத்தலாமா?

VPS-ல் SQLite சரியான production database ஆக இருக்கும் நிலை

பெரும்பாலான சிறிய applications-க்கு 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 இடையே பகிர முடியாது. ஒரே VPS-ல் ஒரே application இயங்கும் சூழலுக்கு இந்த இரண்டு வரம்புகளும் பொருத்தமானவை. அந்த அமைப்பைத் தாண்டும் தருணத்தில், இரண்டும் கடுமையான தடைகளாக மாறும். இந்த வழிகாட்டி, server-ல் SQLite-ஐ பாதுகாப்பாக இயக்கும் settings, Litestream மூலம் தொடர்ச்சியான backup, மேலும் எப்போது SQLite-ஐ நிறுத்த வேண்டும் என்பதைக் கூறுகிறது.

முதலில் 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-ஐ bundle செய்கின்றன. அது பெரும்பாலும் இன்னும் புதியதாக இருக்கும். எனவே, சமீபத்திய 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 செய்கிறது. Main database மாற்றமின்றி இருக்கும். Readers, தாங்கள் தொடங்கிய நேரத்தின் snapshot-ல் main file-ஐ தொடர்ந்து படிக்கலாம். எனவே readers writer-ஐத் தடுக்காது; writer-உம் readers-ஐத் தடுக்காது. பின்னர், checkpoint செயல்முறை சேர்க்கப்பட்ட WAL pages-ஐ main database-க்கு நகலெடுக்கிறது. இந்த ஒரு மாற்றமே, web application-ன் பின்னால் SQLite-ஐப் பயன்படுத்தக்கூடியதாக மாற்றும் முக்கிய காரணிகளில் பெரும்பகுதியைக் கொண்டுள்ளது.

WAL mode-ஐ இயக்கி, அது நிலைத்திருப்பதை உறுதிசெய்யவும்

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

இந்த command, wal என்பதை அச்சிடும். அந்த வெளியீடு அலங்காரத்திற்கானது அல்ல. PRAGMA journal_mode, database தற்போது உண்மையில் பயன்படுத்தும் mode-ஐ வழங்குகிறது. ஆகவே delete என்ற பதில் கிடைத்தால், மாற்றம் தோல்வியடைந்துள்ளது என்றும் நீங்கள் இன்னும் rollback journal-ஐப் பயன்படுத்துகிறீர்கள் என்றும் பொருள்.

WAL mode நிலைத்திருக்கும். இது connection setting அல்ல; database header-இல் உள்ள flag ஆகும். எனவே ஒவ்வொரு database file-க்கும் இதை ஒருமுறை இயக்கினால் போதும். அதன் பிறகு உருவாகும் அனைத்து connections-களும், reboot-க்குப் பிறகும், இந்த 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. -wal file, இன்னும் checkpoint செய்யப்படாத committed pages-ஐக் கொண்டிருக்கும். -shm file, shared memory index ஆகும். ஒவ்வொரு connection-மும் இதை map செய்வதால், WAL-இல் உள்ளவற்றைப் பற்றி அனைத்தும் ஒரே நிலைப்பாட்டில் இருக்கும். இவை இரண்டும் database-ன் பகுதிகள்; scratch files அல்ல. Application இயங்கிக்கொண்டிருக்கும்போது app.db-ஐ மட்டும் copy செய்தால், சமீபத்திய commits அனைத்தும் இல்லாத file கிடைக்கும். app.db-ஐ நீக்கிவிட்டு, மற்ற இரண்டு files-ஐ அப்படியே விட்டால், அந்தப் பெயரில் தோன்றும் புதிய file-க்கு SQLite பழைய WAL pages-ஐப் பயன்படுத்தும். Database-ஐ reset செய்ய முயற்சிக்கும்போது புதிய database-ஐச் சிதைப்பது இதனால் நிகழ்கிறது.

உற்பத்திச் செயலியில் தேவைப்படும் connection settings

journal_mode மட்டுமே database-ல் சேமிக்கப்படுகிறது. கீழே உள்ள மற்ற அனைத்து settings-களும் ஒவ்வொரு 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-ஐ return செய்கிறது. இயல்புநிலை மதிப்பு 0. எனவே இரண்டு writers ஒரே நேரத்தில் செயல்படத் தொடங்கும்போது, SQLite முதல் மோதலிலேயே உடனடியாக fail ஆகிறது. இந்த ஒரே value-ஐ அமைப்பது 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 காரணமாக இயல்புநிலையில் off ஆக உள்ளது. இது ஒவ்வொரு connection-க்கும் தனித்தனியாகப் பொருந்தும். REFERENCES clauses நிறைந்த schema இருந்தாலும், ஒவ்வொரு connection-மும் இதை இயக்கும் வரை எந்த enforcement-மும் நடைபெறாது.

மேலும் ஒரு setting பின்னர் முக்கியமாகிறது. WAL 1000 pages-ஐத் தாண்டி வளரும்போது SQLite தானாக checkpoints செய்கிறது. அந்த நேரத்தில் transaction-ஐ முடிக்கும் connection-தான் அந்தப் பணியைச் செய்கிறது. தனியாகப் பார்த்தால் இது சரியான நடைமுறை. ஆனால் Litestream இயங்கும்போது இது ஒரு கேள்வியாகிறது. ஏனெனில் checkpoints எப்போது நடைபெற வேண்டும் என்பதைக் கட்டுப்படுத்துவதை Litestream விரும்புகிறது.

database is locked அமைத்த பிறகும் ஏன் இது தொடர்ந்து நிகழ்கிறது

இந்தப் பிழைதான் பலரை மீண்டும் Postgres-க்கு அனுப்புகிறது. இதற்கு ஒரு குறிப்பிட்ட காரணம் உள்ளது.

busy timeout, busy handler-ஐ நிறுவுகிறது. ஆனால் SQLite அதை அழைக்கும் என்று உத்தரவாதம் அளிக்காது.

busy handler-ஐ அழைப்பது deadlock-ஐ ஏற்படுத்தக்கூடும் என்று SQLite தீர்மானித்தால், busy handler-ஐ அழைப்பதற்குப் பதிலாக application-க்கு நேரடியாக SQLITE_BUSY-ஐத் திருப்பி அனுப்பும்.

ஒரு transaction upgrade ஆகும்போது ஏற்படும் deadlock-ஐ SQLite தவிர்க்கிறது. SQLite-இல் தனியாக உள்ள BEGIN என்பது BEGIN DEFERRED என்று பொருள். அதற்குப் பிறகு வரும் முதல் statement SELECT ஆக இருந்தால், நீங்கள் read transaction-இல் இருக்கிறீர்கள். அதே transaction-இல் பின்னர் வரும் UPDATE, write transaction ஆக மாற வேண்டியிருக்கும். ஆனால் உங்கள் read தொடங்கியதிலிருந்து மற்றொரு connection எழுதிவிட்டால், SQLite உங்களை காத்திருக்கச் செய்ய முடியாது. உங்கள் snapshot ஏற்கனவே காலாவதியாகிவிட்டது. காத்திருப்பது இரண்டு connection-களும் ஒன்றையொன்று deadlock செய்யும் நிலையை மட்டுமே உருவாக்கும். Documentation இதன் முடிவை நேரடியாகக் கூறுகிறது:

அடுத்தடுத்த write statements, இயன்றால் transaction-ஐ write transaction ஆக upgrade செய்யும். இல்லையெனில் SQLITE_BUSY-ஐத் திருப்பி அனுப்பும்.

உங்கள் 5000 millisecond timeout ஒருபோதும் பரிசீலிக்கப்படுவதில்லை. பிழை உடனடியாக வருகிறது. அதனால் அந்த அமைப்பு எந்தப் பயனும் அளிக்கவில்லை என்று தோன்றுகிறது.

இதற்கான தீர்வு ஒரே ஒரு சொல்.

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

BEGIN IMMEDIATE தொடக்கத்திலேயே, எதையும் வாசிப்பதற்கு முன் write lock-ஐப் பெறுகிறது. Upgrade எதுவும் இல்லை. எனவே தவிர்க்க வேண்டிய deadlock-மும் இல்லை. இதனால் busy handler செயல்பட்டு, connection தோல்வியடைவதற்குப் பதிலாக தனது முறை வரும் வரை காத்திருக்கும். வாசிப்பு மட்டும் செய்யும் transactions-ஐ deferred ஆக வைத்திருங்கள். எழுதும் செயலைக் கொண்ட எந்த transaction-மும் immediate ஆக இருக்க வேண்டும்.

Lock errors-க்கான இரண்டாவது காரணத்தைக் கண்டறிவது கடினம்: slow work நடைபெறும் முழுக் காலத்திலும் write transaction-ஐ திறந்துவைத்திருப்பது. SQLite writers-ஐ serialise செய்கிறது. ஆகவே transaction திறக்கப்பட்டு, network வழியாக external API அழைக்கப்பட்டு, பின்னர் commit செய்யப்படும் நிலை இருந்தால், அந்த API call நடைபெறும் முழுக் காலத்திலும் மற்ற எல்லா writers-உம் தடுக்கப்படும். தேவையானவற்றை வாசித்து, transaction-ஐ மூடுங்கள். பின்னர் slow work-ஐச் செய்யுங்கள். அதன் முடிவைச் சேமிக்க, குறுகிய write transaction-ஐத் திறக்குங்கள்.

Litestream மூலம் தொடர்ச்சியான காப்புப்பிரதி

ஒவ்வொரு இரவும் எடுக்கப்படும் நகல், ஒரு நாள் வரையிலான writes-ஐ இழக்கச் செய்யலாம். இயங்கிக்கொண்டிருக்கும் SQLite database மீது cp இயக்கினால், திறக்க முடியாத நகல் உருவாகலாம். இரண்டு முறைகள் பாதுகாப்பானவை. sqlite3 app.db ".backup /path/to/backup.db", SQLite-ன் online backup interface-ஐ பயன்படுத்துவதால், பயன்பாட்டில் இருக்கும் database மீது செயல்படும். Litestream இதை விட அதிகமாகச் செய்கிறது: அது WAL-ஐ கண்காணித்து, மாற்றங்களை object storage-க்கு தொடர்ந்து அனுப்புகிறது. இதனால் மிக மோசமான தரவு இழப்பு ஒரு நாளிலிருந்து சுமார் ஒரு வினாடியாகக் குறைகிறது.

Litestream என்பது உங்கள் application-க்கு அருகில் இயங்கும் ஒரு Go binary ஆகும். இது app மற்றும் database இடையில் அமராது. உங்கள் application முன்புபோலவே 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

July 2026 நிலவரப்படி, அதிகாரப்பூர்வ Linux install page ஆவணப்படுத்தும் release v0.5.14 ஆகும். v0.5.15 21 July 2026 அன்று வெளியானது. 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-க்கு பதிலாக single replica block-ஐப் பயன்படுத்துகிறது. இப்போது இரண்டு entries கொண்ட config startup-இல் தோல்வியடையும். பல third-party guides இன்னும் பழைய array-ஐக் காட்டுகின்றன. எனவே search-இல் முதலில் கிடைக்கும் example-ஐப் பயன்படுத்தாமல், மேலே உள்ள வடிவத்தைப் பயன்படுத்தவும். 0.5 series, on-disk backup format மாறியதால் litestream wal subcommand-ஐ litestream ltx எனவும் மாற்றியுள்ளது.

எதையும் 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, இயல்பாக 1 second ஆக இருக்கும் sync-interval அடிப்படையில் changes-ஐ push செய்கிறது. எனவே காத்திருந்து மீண்டும் restore செய்யவும். அந்த ஒரு second-தான் உங்கள் recovery point ஆகும். Crash ஏற்பட்டால், கடைசி sync interval-இல் எழுதப்பட்டவை அதிகபட்சமாக இழக்கப்படும். எந்த configuration-மும் இந்த இழப்பை zero ஆக மாற்றாது.

Production 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 என்றால், Wednesday morning அன்று கவனிக்கும் தவறான migration-ஐ Monday-ன் state-இலிருந்து மீட்டெடுக்க முடியாது. retention: 168h-ஐ ஒரு வாரமாக அமைக்கவும். கூடுதல் storage செலவை ஏற்கவும்.

தேவைப்படும் முன் restore செயல்படுவதைச் சரிபார்க்கவும்

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

ஒரு database path வழங்கப்பட்டால், litestream restore ஆனது /etc/litestream.yml இல் பொருந்தும் replica-ஐத் தேடி, அதை download செய்கிறது. செயல்படும் file-க்கு PRAGMA integrity_check, ok ஐ output செய்கிறது. வேறு எந்த output-மும் restore செய்யப்பட்ட copy பயன்படுத்த முடியாதது என்பதைக் குறிக்கும். இதை ஒரு systemd service மற்றும் timer மூலம் திட்டமிட்ட இடைவெளியில் இயக்கி, output-ஐப் படிக்கவும். ஒரு backup-ஐ குறைந்தது ஒருமுறை restore செய்யும் வரை, அது செயல்படுகிறது என்பது உங்களுக்குத் தெரியாது.

systemd கீழ் Litestream ஐ இயக்குதல்

Debian package, litestream unit-ஐ நிறுவுகிறது. அந்த unit, /etc/litestream.yml-ஐ படிக்கிறது.

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

சரியான output, config-இல் உள்ள ஒவ்வொரு database-ன் பெயரையும் காட்டும். அதன் பிறகு, காலமுறை sync lines-ஐத் தவிர அமைதியாக இருக்கும். உங்கள் database path-க்கு எதிராக no such file or directory பிழை ஏற்பட்டால், config-இல் உள்ள path தவறாக உள்ளது அல்லது process-க்கு அதை வாசிக்க permission இல்லை. இந்த 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 கொண்ட dedicated service account-ஐ அமைத்தல் சில நிமிடங்களே எடுக்கும். இதனால் backup agent மற்றும் அந்த server-ல் இயங்கும் மற்றொரு root process ஆகியவற்றுக்கு இடையிலான வேறுபாடு உருவாகிறது.

Machine-ஐ முற்றிலும் புதிதாக rebuild செய்யும்போது, ஒரு வரிசை முக்கியமானது. Application தொடங்குவதற்கு முன் database restore செய்யப்பட வேண்டும். litestream restore, -if-db-not-exists-ஐ ஏற்கிறது. File ஏற்கனவே இருந்தால் அது 0 என்ற exit status-ஐ வழங்கும். எனவே ஒவ்வொரு boot-லும் அதை பாதுகாப்பாக இயக்கலாம். உங்கள் application's unit-இல் உள்ள ExecStartPre line-ல் இதைச் சேர்க்கவும். அப்போது புதிய VPS database-ஐ download செய்யும். ஏற்கனவே database உள்ள server எதுவும் செய்யாது. இதை ஒரே இடத்தில் வைத்திருக்க விரும்பினால், litestream replicate-க்கு பொருத்தமான -restore-if-db-not-exists flag உள்ளது.

VPS-ல் SQLite செயலிழக்கும் நிலைகள்

Network filesystems. இதை அமைப்புகளை மாற்றி தவிர்க்க முடியாது. WAL mode-க்கு, database-ஐ பயன்படுத்தும் ஒவ்வொரு process-உம் நினைவகத்தின் ஒரு சிறிய பகுதியைப் பகிர வேண்டும். இதற்காகவே -shm file பயன்படுகிறது. SQLite documentation எந்த விதிவிலக்கும் இல்லாமல் இந்த விதியைக் குறிப்பிடுகிறது:

Database-ஐ பயன்படுத்தும் அனைத்து process-களும் ஒரே host computer-ல் இருக்க வேண்டும்; network filesystem வழியாக WAL செயல்படாது.

எனவே mounted NFS (network file system) அல்லது SMB share-ல் உள்ள database corrupt ஆகலாம். எந்த pragma-வும் இதைத் தடுக்காது. இங்கு பலர் கவனிக்காத ஒரு வேறுபாடு உள்ளது. பெரும்பாலான VPS providers கூடுதல் storage ஆக இணைக்கும் network block device, Linux-க்கு சாதாரண filesystem கொண்ட சாதாரண disk ஆகத் தோன்றும். அது சரியாக செயல்படும். ஆனால் mounted file share அவ்வாறு செயல்படாது.

இரண்டாவது application server. எந்த setting-உம் இதைச் செயல்படச் செய்யாது. ஒரே data-வை வழங்க இரண்டு machines தேவைப்பட்டவுடன், network வழியாக தொடர்புகொள்ளும் database தேவைப்படும். திட்டமிடுவதற்கு இன்னும் நேரம் இருக்கும்போதே இந்த மாற்றத்தை முடிவு செய்யுங்கள்.

Write-heavy workloads. ஒரே நேரத்தில் ஒரு writer மட்டுமே இயங்குவது file format-ன் பண்பு; அதை tunable ஆக மாற்ற முடியாது. ஒவ்வொரு commit-உம் WAL-ல் append ஆகச் சேர்வதால் short writes குறைந்த செலவில் முடியும். எனவே throughput, CPU-வைவிட disk-ன் small-write latency-யைப் பொறுத்தே அதிகமாக இருக்கும். அந்த வேறுபாடு எப்படி இருக்கும் என்பதை VPS-ல் NVMe மற்றும் SATA SSD storage ஒப்பீடு பார்க்கவும். உண்மையான சிக்கல் long transactions ஆகும். அவை மற்ற அனைத்து writers-ஐயும் தங்களுக்குப் பின்னால் queue-ல் நிறுத்துகின்றன.

Analytical queries. SQLite என்பது transactions-க்காக உருவாக்கப்பட்ட row store. நூறு மில்லியன் rows-ஐ scan செய்யும் dashboard வேறொரு tool-க்கு உரிய வேறுபட்ட பணியாகும். அந்த வரம்பு எங்கு வருகிறது என்பதை server பணிகளுக்கான DuckDB மற்றும் SQLite ஒப்பீடு விளக்குகிறது.

Replication-இல் VACUUM. முழுமையான VACUUM முழு database file-ஐ மீண்டும் எழுதும். எனவே Litestream அதை மீண்டும் முழுமையாக upload செய்ய வேண்டும். Replication செயல்பாட்டில் இருக்கும்போது அதை நேரடியாக இயக்க வேண்டாம் என்று Litestream documentation அறிவுறுத்துகிறது. Replicator-ஐ நிறுத்தி, vacuum இயக்கி, மீண்டும் தொடங்குங்கள். புதிய முழுமையான snapshot உருவாகும் என எதிர்பார்க்கவும்.

ஒரே database-ல் இரண்டு replicators. ஒரே database அல்லது ஒரே replica destination மீது இரண்டு Litestream processes-ஐ ஒருபோதும் இயக்க வேண்டாம். இதைத் தடுப்பது உங்கள் பொறுப்பு என்று documentation தெளிவாகக் கூறுகிறது. இல்லையெனில் restore செய்ய முடியாத replica உருவாகும்.

Litestream கையாளாதவை

Litestream database file-ஐ மட்டும் பாதுகாக்கும். வேறு எதையும் அது பாதுகாக்காது. Uploaded files, application config, TLS (transport layer security) certificates மற்றும் unit files ஆகியவற்றை நீங்கள் தனியாகக் கையாள வேண்டும். திட்டமிட்ட இடைவெளியில் restic-ஐப் பயன்படுத்தி off-box encrypted backups உடன் இதை இணைக்கவும். அப்போது இரு பகுதிகளும் பாதுகாக்கப்படும். Machine புதியதாக இருந்தால், இந்த வழிகாட்டி ஏற்கனவே முடிந்ததாகக் கருதும் user account மற்றும் firewall பணிகளை புதிய VPS-இல் முதல் பத்து நிமிடங்கள் உள்ளடக்கும்.

FAQ

உற்பத்தி பயன்பாட்டுக்கு SQLite போதுமானதா?

ஒரே server-ல் இயங்கும் ஒரு பயன்பாட்டுக்கு, ஆம். ஆனால் WAL mode-ஐ இயக்கி, busy timeout-ஐ அமைத்து, தொடர்ந்து backup எடுக்க வேண்டும். முக்கியமான வரம்புகள் கட்டமைப்பு சார்ந்தவை: ஒரே நேரத்தில் ஒரு writer மட்டுமே இருக்க முடியும்; மேலும் ஒரு host machine மட்டுமே பயன்படுத்த முடியும். இந்த வரம்புகளுக்குள் இயங்கும் பயன்பாட்டுக்கு, network hop இல்லாததும் தனி process-ஐ monitor செய்ய வேண்டிய அவசியமில்லாததுமான 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 ஏற்கனவே stale ஆகிவிட்டதால், 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 மூலம் shared 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 செய்வதைவிட இது பாதுகாப்பானது. ஏனெனில் அந்த முறையில் write நடைபெறும் நடுவில் database capture செய்யப்படலாம். Litestream database-ஐ மட்டுமே பாதுகாக்கும். எனவே அதனுடன் சேர்த்து பொதுவான file backup-ஐயும் தொடர்ந்து இயக்குங்கள்.