שימוש ב-SQLite בסביבת ייצור על גבי VPS

מתי SQLite הוא בסיס הנתונים הנכון לייצור ב-VPS

הרצת SQLite בסביבת ייצור על גבי VPS היא הבחירה הנכונה עבור רוב היישומים הקטנים, והסיבה לכך פשוטה: תהליך אחד על מכונה אחת הכותב לקובץ אחד אינו זקוק לשרת בסיס נתונים. אין תהליך רקע (daemon) שיש לנטר, אין פורט שיש להגדיר בחומת אש, אין סיסמה שיש להחליף, ואין מכונה שנייה שיש לשמור על פעילותה. שאילתה היא קריאת פונקציה ולא סבב תקשורת ברשת, לכן דף שמריץ ארבעים שאילתות עולה לך בארבעים קריאות פונקציה בלבד.

העלות מוגדרת ומוחשית. SQLite מאפשר כותב אחד בלבד בכל רגע נתון על פני כל קובץ בסיס הנתונים, ולא ניתן לשתף את הקובץ בין שתי מכונות. שתי המגבלות הללו תקינות עבור VPS יחיד המריץ יישום יחיד. שתיהן קטלניות ברגע שאתה חורג ממבנה זה. מדריך זה מכסה את ההגדרות שהופכות את SQLite לבטוח על שרת, גיבוי רציף באמצעות Litestream, והנקודה שבה עליך לעצור.

התקן תחילה את כלי שורת הפקודה. כל מה שמופיע להלן הורץ על Ubuntu 24.04.

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

פעולה זו מדפיסה גרסה המתחילה ב-3. ולאחריה תאריך בנייה ו-hash של קוד המקור. נכון ליולי 2026, Ubuntu 24.04 מספקת את SQLite בגרסה 3.45.1. סביר להניח שהיישום שלך אינו משתמש בקובץ בינארי זה: רוב סביבות ההרצה של שפות תכנות כוללות עותק משלהן של ספריית SQLite, לעיתים קרובות גרסה חדשה יותר, לכן בדוק את הגרסה שמדווח מנהל ההתקן (driver) של בסיס הנתונים שלך לפני שאתה מסתמך על תכונה חדשה.

מדוע מצב WAL הוא הדבר הראשון שיש לשנות

כברירת מחדל, SQLite משתמש ב-rollback journal. לפני שינוי דף, המערכת מעתיקה את הדף המקורי לקובץ -journal, ולאחר מכן עורכת את מסד הנתונים במקומו. כדי לבצע זאת בבטחה, המערכת נועלת את הקובץ כולו בנעילה בלעדית, ולכן כל קורא ממתין בזמן שמתבצעת כתיבה. במחשב נייד איש אינו מבחין בכך. בשרת אינטרנט, פעולת כתיבה איטית אחת מעכבת כל בקשה שניגשת למסד הנתונים.

מצב WAL (write-ahead log) הופך את הסדר. הכותב מצרף את הדפים החדשים לקובץ -wal נפרד ואינו נוגע במסד הנתונים הראשי. הקוראים ממשיכים לקרוא את הקובץ הראשי לפי תמונת המצב (snapshot) שבה החלו, כך שהקוראים אינם חוסמים את הכותב והכותב אינו חוסם את הקוראים. מאוחר יותר, פעולת checkpoint מעתיקה את דפי ה-WAL שנצברו בחזרה למסד הנתונים הראשי. שינוי יחיד זה הוא הגורם העיקרי לכך ש-SQLite שמיש מאחורי יישום אינטרנט.

הפעלת מצב WAL ואימות ההגדרה

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

הפקודה מדפיסה wal. פלט זה אינו קישוט. PRAGMA journal_mode מחזירה את המצב שבו נמצא מסד הנתונים בפועל, לכן תשובה של delete משמעותה שהשינוי נכשל ואתם עדיין משתמשים ב-rollback journal.

מצב WAL הוא קבוע. זהו דגל בכותרת מסד הנתונים ולא הגדרת חיבור, לכן מריצים אותו פעם אחת לכל קובץ מסד נתונים וכל חיבור לאחר מכן יורש אותו, גם לאחר אתחול. ניתן להוכיח זאת באמצעות חיבור חדש.

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

כעת צרו טבלה ובדקו מה מופיע בדיסק.

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/

כעת קיימים שלושה קבצים: app.db, app.db-wal ו-app.db-shm. הקובץ -wal מכיל דפים שבוצע להם commit אך טרם עברו checkpoint. הקובץ -shm הוא אינדקס זיכרון משותף שכל חיבור ממפה, כדי שכולם יסכימו על תוכנו של ה-WAL. שניהם שייכים למסד הנתונים ואינם קבצי עבודה זמניים. העתקה של app.db בלבד בזמן שהיישום רץ תניב קובץ שחסרים בו כל ה-commits האחרונים. מחיקה של app.db תוך השארת השניים האחרים תגרום ל-SQLite להחיל את דפי ה-WAL הישנים על כל קובץ חדש שיופיע תחת שם זה; כך משתמשים משחיתים מסד נתונים חדש בזמן ניסיון לאפס אחד קיים.

The connection settings every production app needs

Only journal_mode is stored in the database. Every other setting below is per connection, which means your application has to run it on each connection it opens, including every connection a pool creates in the background.

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

busy_timeout = 5000 tells SQLite to keep retrying a locked database for up to 5000 milliseconds before it returns database is locked. The default is 0, so by default SQLite fails instantly the first time two writers overlap. Setting this single value removes most of the lock errors that get blamed on SQLite itself.

synchronous = NORMAL is the right setting in WAL mode, and the trade is worth understanding. At FULL, SQLite calls fsync on the WAL at every commit. At NORMAL, it syncs at checkpoints instead. The SQLite documentation is blunt about what you give up: transactions are no longer durable after a power failure or a hard reset. The database cannot be corrupted by that power loss, you simply lose the last commits that had not reached the disk. On a VPS that is usually the right trade, because it takes an fsync out of the path of every single write.

foreign_keys = ON is off by default for backwards compatibility, and it is per connection. A schema full of REFERENCES clauses enforces nothing at all until each connection turns this on.

One more setting matters only later. SQLite checkpoints automatically once the WAL grows past 1000 pages, and the work is done by whichever connection happens to finish a transaction at that moment. That is fine on its own. It becomes a question when Litestream is running, because Litestream wants control over when checkpoints happen.

מדוע database is locked עדיין מתרחשת לאחר הגדרת busy_timeout

זהו הכשל שגורם לאנשים לחזור ל-Postgres, ויש לו סיבה אחת ספציפית.

הגדרת busy timeout מתקינה מטפל עמוס (busy handler), אך SQLite אינה מתחייבת להפעיל אותו.

אם SQLite קובעת שהפעלת המטפל העמוס עלולה להוביל למבוי סתום (deadlock), היא תמשיך ותחזיר SQLITE_BUSY ליישום במקום להפעיל את המטפל.

המבוי הסתום שהיא מונעת מתרחש כאשר מתבצע שדרוג של טרנזקציה. פקודת BEGIN פשוטה ב-SQLite משמעותה BEGIN DEFERRED. אם הפקודה הראשונה אחריה היא SELECT, אתם נמצאים בתוך טרנזקציית קריאה. כאשר פקודת UPDATE מאוחרת יותר באותה טרנזקציה צריכה להפוך לטרנזקציית כתיבה, וחיבור אחר ביצע כתיבה מאז שהקריאה שלכם החלה, SQLite אינה יכולה לגרום לכם להמתין. זאת כיוון שצילום המצב (snapshot) שלכם כבר אינו מעודכן, והמתנה רק תגרום לשני החיבורים להינעל זה מול זה. התיעוד מציין את התוצאה באופן ישיר:

פקודות כתיבה עוקבות ישדרגו את הטרנזקציה לטרנזקציית כתיבה אם הדבר אפשרי, או יחזירו SQLITE_BUSY.

הגדרת ה-timeout שלכם ל-5000 מילי-שניות לעולם אינה נלקחת בחשבון. השגיאה מגיעה באופן מיידי, וזו הסיבה שנראה כאילו ההגדרה לא עשתה דבר.

הפתרון הוא מילה אחת.

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

הפקודה BEGIN IMMEDIATE תופסת את נעילת הכתיבה כבר בהתחלה, לפני קריאת דבר מה. אין שדרוג, לכן אין מבוי סתום שיש להימנע ממנו, ולכן המטפל העמוס אכן פועל והחיבור ממתין לתורו במקום להיכשל. השאירו טרנזקציות לקריאה בלבד כ-deferred. כל טרנזקציה המכילה כתיבה צריכה להיות immediate.

הסיבה השנייה לשגיאות נעילה קשה יותר לזיהוי: החזקת טרנזקציית כתיבה פתוחה בזמן ביצוע פעולות איטיות. SQLite מבצעת סריאליזציה לכותבים, לכן טרנזקציה שנפתחת, קוראת ל-API חיצוני דרך הרשת, ורק אז מבצעת commit, תחסום כל כותב אחר למשך זמן הקריאה הזו. קראו את מה שאתם צריכים, סגרו את הטרנזקציה, בצעו את העבודה האיטית, ולאחר מכן פתחו טרנזקציית כתיבה קצרה כדי לשמור את התוצאה.

גיבוי רציף באמצעות Litestream

עותק לילי גורם לאובדן של עד יום שלם של כתיבות, והרצת cp מול מסד נתונים פעיל של SQLite עלולה להפיק עותק שלא ניתן לפתיחה. שני דברים הם בטוחים. sqlite3 app.db ".backup /path/to/backup.db" משתמש בממשק הגיבוי המקוון של SQLite ועובד מול מסד נתונים שנמצא בשימוש. Litestream הולך צעד קדימה: הוא מנטר את ה-WAL ומעביר שינויים לאחסון אובייקטים באופן רציף, מה שמצמצם את אובדן הנתונים במקרה הגרוע ביותר מיום שלם לשנייה אחת בערך.

Litestream הוא קובץ בינארי יחיד של Go שרץ לצד היישום שלך. הוא אינו יושב בין היישום לבין מסד הנתונים. היישום שלך כותב ל-SQLite בדיוק כפי שעשה קודם, ו-Litestream קורא את ה-WAL ומעלה את מה שהשתנה.

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 היא הגרסה שדף ההתקנה הרשמי ל-Linux מתעד נכון ליולי 2026, וגרסה v0.5.15 שוחררה ב-21 ביולי 2026. שנה את הגרסה בשתי השורות כך שתתאים לתג הנוכחי בדף ה-releases, ובחר בחבילת ה-arm64 המתאימה אם ה-VPS שלך הוא בארכיטקטורת arm64.

קובץ ההגדרות נמצא ב-/etc/litestream.yml. התחל עם העתק (replica) לקובץ מקומי, כיוון שזה מוכיח את תקינות התהליך כולו ללא צורך בפרטי גישה לענן.

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

שים לב שהשדה הוא replica, ביחיד. גרסה 0.5 של Litestream החליפה את המערך replicas מסדרת 0.3 בבלוק replica יחיד, וקובץ הגדרות המכיל שתי רשומות ייכשל כעת בעת ההפעלה. מדריכים רבים של צד שלישי עדיין מציגים את המערך הישן, לכן העתק את המבנה שלעיל במקום את הדוגמה הראשונה שמופיעה בחיפוש. סדרת 0.5 גם שינתה את שם תת-הפקודה litestream wal ל-litestream ltx, כיוון שפורמט הגיבוי על הדיסק השתנה.

וודא שקובץ ההגדרות עובר ניתוח (parse) תקין לפני שאתה מפעיל דבר מה.

sudo litestream databases -config /etc/litestream.yml

לאחר מכן, הוכח את תהליך הסנכרון באופן ידני. טופס זה מדלג על קובץ ההגדרות ומשכפל מסד נתונים אחד לנתיב אחד.

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

פקודה זו רצה בחזית וממשיכה לפעול. בטרמינל שני, כתוב שורה ושחזר את העותק לקובץ חדש.

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

הספירה כוללת את השורה החדשה. אם היא לא כוללת אותה, השינוי טרם סונכרן: Litestream מבצע דחיפה לפי sync-interval שערך ברירת המחדל שלו הוא 1 שנייה, לכן המתן ובצע שחזור שוב. אותה שנייה אחת היא גם נקודת השחזור שלך. קריסה תגרום לאובדן של לכל היותר הכתיבות מהמרווח האחרון של הסנכרון, ואין הגדרה שמאפשרת להפוך זאת לאפס.

עבור אחסון אמיתי, החלף את בלוק ה-replica בכתובת S3 URL. זה עובד מול Amazon S3 ומול אחסון אובייקטים תואם S3 מספקים אחרים.

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

snapshot:
  interval: 24h
  retention: 24h

שמור על פרטי הגישה מחוץ לקובץ זה. Litestream קורא את LITESTREAM_ACCESS_KEY_ID ו-LITESTREAM_SECRET_ACCESS_KEY מתוך משתני הסביבה, לכן הכנס אותם לקובץ drop-in של systemd בבעלות root ועם הרשאות 600.

ערכי ה-snapshot שלעיל הם ברירות המחדל, וערך ברירת המחדל של ה-retention מפתיע אנשים. Retention הוא משך הזמן שבו Litestream שומר snapshots והקבצים השייכים להם, ולכן הוא גם קובע כמה זמן אחורה ניתן לשחזר. עשרים וארבע שעות אומרות שמיגרציה כושלת שתבחין בה בבוקר יום רביעי כבר לא תהיה ניתנת לשחזור ממצב של יום שני. הגדר את retention: 168h לשבוע ושלם עבור האחסון הנוסף.

ודאו את השחזור לפני שתזדקקו לו

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

בהינתן נתיב מסד נתונים, litestream restore מאתר את העותק המשוכפל התואם ב-/etc/litestream.yml ומוריד אותו. PRAGMA integrity_check מדפיס ok עבור קובץ תקין, וכל פלט אחר משמעו שהעותק המשוחזר אינו שמיש. הריצו זאת לפי לוח זמנים באמצעות שירות וטיימר של systemd ועקבו אחר הפלט. כל עוד לא ביצעתם שחזור של גיבוי לפחות פעם אחת, אינכם יכולים לדעת אם הוא עובד.

הרצת Litestream תחת systemd

חבילת ה-Debian מתקינה יחידת litestream הקוראת את /etc/litestream.yml.

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

פלט תקין מציג את שם כל מסד נתונים מתוך הקובץ ולאחר מכן נותר שקט, למעט שורות סנכרון תקופתיות. שגיאת no such file or directory מול נתיב מסד הנתונים שלך מעידה על כך שהנתיב בקובץ ההגדרות שגוי, או שהתהליך אינו יכול לקרוא אותו. היחידה רצה כ-root כברירת מחדל, וזו רמת הרשאות גבוהה מהנדרש למשימה זו. על Litestream להיות מסוגל לקרוא ולכתוב הן למסד הנתונים והן לספרייה המכילה אותו, כיוון שהוא עובד עם הקבצים -wal ו--shm לצד מסד הנתונים שלך; לכן, הקצה לו את החשבון שבו האפליקציה שלך כבר משתמשת.

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

החל זאת באמצעות sudo systemctl daemon-reload ו-sudo systemctl restart litestream. הגדרת חשבון שירות ייעודי בעל הרשאות מינימליות אורכת מספר דקות, והיא ההבדל בין סוכן גיבוי לבין תהליך root נוסף על השרת.

פרט אחד בנוגע לסדר הפעולות חשוב אם תצטרך אי פעם לבנות את המכונה מחדש מאפס. עליך לוודא שמסד הנתונים משוחזר לפני שהאפליקציה עולה. הפקודה litestream restore מקבלת את -if-db-not-exists, אשר מחזירה 0 אם הקובץ כבר קיים, ולכן בטוח להריץ אותה בכל עלייה של המערכת. הוסף אותה לשורת ExecStartPre ביחידת השירות של האפליקציה שלך, כך ששרת VPS חדש ימשוך את מסד הנתונים, בעוד שרת קיים לא יבצע דבר. ל-litestream replicate יש דגל תואם בשם -restore-if-db-not-exists אם אתה מעדיף לרכז זאת במקום אחד.

היכן SQLite נכשל ב-VPS

מערכות קבצים מבוססות רשת. זוהי מגבלה שלא ניתן לעקוף באמצעות הגדרות. מצב WAL מחייב את כל התהליכים המשתמשים במסד הנתונים לשתף אזור זיכרון קטן, וזהו התפקיד של הקובץ -shm. התיעוד של SQLite מציג את הכלל ללא סייגים:

כל התהליכים המשתמשים במסד נתונים חייבים להימצא על אותו מחשב מארח; WAL אינו פועל מעל מערכת קבצים מבוססת רשת.

לפיכך, מסד נתונים המאוחסן על גבי NFS (מערכת קבצים ברשת) או שיתוף SMB עלול להיפגם, ושום pragma לא ימנע זאת. קיימת כאן הבחנה שאנשים מפספסים. התקן בלוקים רשתי (network block device), שהוא האופן שבו רוב ספקי ה-VPS מחברים אחסון נוסף, מופיע בלינוקס כדיסק רגיל עם מערכת קבצים רגילה, וזה תקין. שיתוף קבצים (file share) מותקן אינו כזה.

שרת יישומים שני. אין הגדרה שתגרום לזה לעבוד. ברגע שאתה זקוק לשני מחשבים המשרתים את אותם הנתונים, אתה זקוק למסד נתונים שמדבר דרך הרשת. קבל החלטה על מעבר כזה בעוד יש לך זמן לתכנן אותו.

עומסי עבודה עתירי כתיבה. כותב אחד בכל פעם הוא מאפיין של פורמט הקובץ, לא פרמטר שניתן לכוונון. כתיבות קצרות הן זולות מכיוון שכל commit הוא הוספה ל-WAL, לכן קצב העבודה (throughput) מושפע יותר מהשהיית הכתיבה הקטנה של הדיסק מאשר מה-CPU שלך. ראה NVMe לעומת אחסון SATA SSD ב-VPS כדי להבין כיצד נראה ההבדל הזה. טרנזקציות ארוכות הן הבעיה האמיתית, מכיוון שהן גורמות לכל כותב אחר להמתין בתור אחריהן.

שאילתות אנליטיות. SQLite הוא מאגר נתונים מבוסס שורות שנבנה עבור טרנזקציות. לוח מחוונים הסורק מאה מיליון שורות הוא משימה שונה עבור כלי שונה, והמאמר DuckDB בהשוואה ל-SQLite עבור עבודה בשרת מכסה היכן עובר הגבול הזה.

VACUUM תחת שכפול. פעולת VACUUM מלאה כותבת מחדש את כל קובץ מסד הנתונים, מה שאומר ש-Litestream נדרש להעלות את כולו מחדש, והתיעוד של Litestream ממליץ לא להריץ זאת במקום בזמן שהשכפול פעיל. עצור את המשכפל (replicator), בצע vacuum, הפעל אותו מחדש, והיערך לתמונת מצב (snapshot) מלאה וחדשה.

שני משכפלים על מסד נתונים אחד. לעולם אל תריץ שני תהליכי Litestream מול אותו מסד נתונים או מול אותו יעד שכפול. התיעוד מפורש בכך שמניעת מצב זה היא באחריותך, והתוצאה היא עותק משוכפל שלא ניתן לשחזר.

מה Litestream אינו מכסה

Litestream מגן על קובץ מסד הנתונים בלבד. קבצים שהועלו, הגדרות התצורה של היישום, אישורי TLS (אבטחת תעבורת רשת) וקובצי ה-unit נותרים באחריותך. מומלץ לשלב אותו עם גיבויים מוצפנים מחוץ לשרת באמצעות restic על פי לוח זמנים, ובכך לכסות את שני החלקים. אם מדובר במכונה חדשה, המדריך עשר הדקות הראשונות ב-VPS חדש מכסה את הגדרת חשבון המשתמש וחומת האש, פעולות שמדריך זה מניח שכבר בוצעו.

FAQ

האם SQLite מתאים ליישום בסביבת ייצור (Production)?

עבור יישום בודד על שרת בודד, התשובה היא כן, בתנאי שמפעילים את מצב WAL, מגדירים busy timeout, ומבצעים גיבוי רציף. המגבלות המשמעותיות הן מבניות: כותב אחד בלבד בכל רגע נתון, ומכונה מארחת אחת. יישום שעומד במגבלות אלו נהנה מבסיס נתונים ללא צורך בתקשורת רשת וללא תהליך נפרד לניטור. יישום שאינו עומד במגבלות אלו זקוק לבסיס נתונים מסוג client-server, ושום כוונון לא ישנה זאת.

מדוע אני עדיין מקבל database is locked לאחר הגדרת busy_timeout?

מכיוון ש-SQLite מדלג על ה-busy handler כאשר המתנה עלולה לגרום ל-deadlock. טרנזקציה שמתחילה ב-BEGIN פשוט היא מושהית (deferred): פקודת SELECT ראשונית מכניסה אותה לטרנזקציית קריאה, וכתיבה מאוחרת יותר מחייבת שדרוג. אם חיבור אחר ביצע כתיבה בפרק זמן זה, SQLite מחזיר SQLITE_BUSY באופן מיידי במקום להפעיל את ה-busy handler, כיוון שצילום הקריאה (read snapshot) שלך כבר אינו עדכני. התחל כל טרנזקציה שעתידה לכתוב באמצעות BEGIN IMMEDIATE, כך שנעילת הכתיבה תתבצע מראש וה-timeout יחול כנדרש.

האם ניתן לשמור את בסיס הנתונים של SQLite על אחסון רשת?

לא על מערכת קבצים מבוססת רשת כגון NFS או SMB. מצב WAL מחייב את כל התהליכים לשתף זיכרון דרך קובץ ה--shm, ותיעוד SQLite קובע שכל תהליך המשתמש בבסיס הנתונים חייב להימצא על אותה מכונה מארחת. התקן בלוקים ברשת (network block device) שמחובר על ידי ספק האחסון הוא עניין שונה: Linux מזהה דיסק רגיל עם מערכת קבצים רגילה עליו, ו-SQLite פועל שם כראוי.

האם אני זקוק ל-Litestream אם אני כבר מריץ גיבויים ליליים?

זה תלוי בכמות הנתונים שאתה יכול להרשות לעצמך לאבד. משימה לילית משמעותה אובדן של עד עשרים וארבע שעות של כתיבה. Litestream מסנכרן נתונים בערך פעם בשנייה, כך שקריסה תעלה לך לכל היותר בשנייה האחרונה של הנתונים. הוא גם בטוח יותר מאשר העתקת קובץ בסיס הנתונים באמצעות cp, פעולה שעלולה לתפוס את בסיס הנתונים באמצע תהליך כתיבה. Litestream מכסה רק את בסיס הנתונים, לכן מומלץ להמשיך ולהריץ גיבוי קבצים כללי לצדו.