# מסד נתונים

> הרצת Nodaro באירוח עצמי על מערך Supabase המובנה או על פרויקט Supabase מנוהל, החלת המיגרציות ואבטחת המפתחות והסיסמאות של מסד הנתונים.

Source: https://nodaro.ai/he/docs/self-hosting/database

Nodaro שומר את **מסד הנתונים** שלו ב-Supabase: Postgres לנתונים, GoTrue להתחברות ו-PostgREST ל-API של הנתונים, שהעורך קורא ממנו וכותב אליו. מערך השירותים של Compose כולל את שלושתם ומחיל בשבילכם את המיגרציות של מסד הנתונים. אפשר גם לכוון את Nodaro לפרויקט Supabase מנוהל ולהחיל את המיגרציות בעצמכם.

## המערך המובנה
| שירות | אימג׳ | מה הוא עושה |
| --- | --- | --- |
| `db` | Supabase Postgres | מסד הנתונים, ב-volume `db-data` |
| `auth` | GoTrue | הרשמה והתחברות עם אימייל וסיסמה |
| `rest` | PostgREST | ה-API של הנתונים |

הדפדפן וה-API מגיעים לשירות ההתחברות ול-API של הנתונים דרך ה-origin של האפליקציה עצמה, בכתובת `PUBLIC_URL/supabase`. שרת הווב בקונטיינר של Nodaro מעביר את `/supabase/auth/v1` ל-GoTrue ואת `/supabase/rest/v1` ל-PostgREST, כך שלא צריך פורט או דומיין נוספים.

המערך המובנה לא שולח אימיילים: חשבונות עובדים מיד אחרי ההרשמה.

### מיגרציות במערך המובנה
הקונטיינר של האפליקציה מחיל את כל הקבצים ב-`supabase/migrations/` לפני שה-API עולה. הוא צריך את `RUN_MIGRATIONS_ON_BOOT=true` ואת `DATABASE_URL`, שקובץ ה-Compose מגדיר בשבילכם.

- **קבצים שהוחלו נרשמים**, ובאתחול הבא המערך מדלג עליהם.
- **ה-API אף פעם לא רץ מול מסד נתונים שהמיגרציות שלו הוחלו רק בחלקן.** כשמיגרציה נכשלת, ה-API מסרב לעלות, והיומן של הקונטיינר מציין את שם הקובץ.
- **מתקנים ומפעילים שוב.** אחרי שתיקנתם את הגורם, הריצו שוב את `docker compose -f docker-compose.community.yml up`. המערך מדלג על קבצים שכבר הוחלו.

### אבטחת מסד הנתונים המובנה
המפתחות והסיסמאות של ברירת המחדל הם ציבוריים. לפני שחושפים את המערך לרשת:

1. **צרו מפתחות אימות חדשים** עם `node tools/generate-selfhost-keys.mjs >> .env`. הסקריפט מדפיס את `SUPABASE_JWT_SECRET`, `SUPABASE_ANON_KEY` ו-`SUPABASE_SERVICE_ROLE_KEY`. שלושתם חייבים להגיע מאותה הרצה: המפתחות חתומים עם הסוד.
2. **הגדירו את `POSTGRES_PASSWORD` ו-`DATABASE_URL` תואם**, כגון `postgres://postgres:<new-password>@db:5432/postgres`.
3. **החילו את השינויים** עם `docker compose -f docker-compose.community.yml up -d`.

מסד הנתונים מתאים את הסיסמאות של התפקידים הפנימיים שלו, כגון `supabase_auth_admin` ו-`authenticator`, ל-`POSTGRES_PASSWORD` רק בהפעלה ה**ראשונה** שלו. אם ה-volume `db-data` כבר קיים, מחקו את ה-volume, מה שמוחק את הנתונים שלכם, או שנו ידנית את סיסמאות התפקידים בתור `supabase_admin`. אחרת ההתחברות נכשלת עם `password authentication failed for user "supabase_auth_admin"` (אימות הסיסמה נכשל עבור המשתמש supabase_auth_admin).

## שימוש בפרויקט Supabase מנוהל
פרויקט ב-supabase.com מחליף את השירותים המובנים `db`, `auth` ו-`rest`. המסלול החינמי של Supabase מספיק. הגדירו את המשתנים האלה ב-`.env`:

```bash
SUPABASE_URL=https://YOUR-PROJECT.supabase.co
SUPABASE_ANON_KEY=eyJ...
SUPABASE_SERVICE_ROLE_KEY=eyJ...
FRONTEND_SUPABASE_URL=https://YOUR-PROJECT.supabase.co
RUN_MIGRATIONS_ON_BOOT=false
NODARO_ENCRYPTION_KEY=<64-character hex>
```

- **`FRONTEND_SUPABASE_URL`** הוא העותק של כתובת הפרויקט שהדפדפן משתמש בו. האימג׳ שפורסם בנוי למערך המובנה, והוא לומד כתובת אחרת רק מהמשתנה הזה, באתחול.
- **`RUN_MIGRATIONS_ON_BOOT=false`** משבית את מריץ המיגרציות. החילו את המיגרציות בעצמכם, כמו שמתואר בהמשך.
- **`NODARO_ENCRYPTION_KEY`** חייב להיות מוגדר, למשל עם `openssl rand -hex 32`. המערך יוצר את המפתח בשבילכם רק כשמריץ המיגרציות מופעל. בלי המפתח, הדבקה של מפתחות ספק וחיבור ל-Nodaro Cloud נכשלים עם `EncryptionKeyMissingError`.

אם ההתקנה כבר רצה על המערך המובנה, השתמשו שוב במפתח שלה. הוא נמצא ב-volume `app-data`, בנתיב `/data/nodaro/encryption-key`. מפתח חדש לא יכול לקרוא את מה שהמפתח הישן הצפין.

### החלת המיגרציות על פרויקט מנוהל
החילו את כל הקבצים ב-`supabase/migrations/` **לפי סדר שמות הקבצים**. הקידומות המרופדות באפסים, כגון `001_` ו-`002_`, קובעות את הסדר.

- **בעורך ה-SQL.** בלוח הבקרה של Supabase, פתחו את **SQL editor** (עורך SQL) והריצו את הקבצים אחד אחרי השני.
- **עם ה-CLI של Supabase.** כך זה מהיר יותר:

```bash
supabase link --project-ref YOUR-REF
supabase db push
```

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

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

## הגשת פרויקט מנוהל דרך ה-origin שלכם
יש רשתות שמסננות כל בקשה מהדפדפן לפי שם המארח וחוסמות את הדומיין של Supabase. ברשתות כאלה, שרת הווב בקונטיינר של Nodaro יכול להעביר פרויקט מנוהל דרך ה-origin של האפליקציה עצמה. הגדירו את שלושת המשתנים יחד:

```bash
SUPABASE_MANAGED_PROXY=true
FRONTEND_SUPABASE_URL=/supabase
SUPABASE_PROXY_UPSTREAM=https://YOUR-PROJECT.supabase.co
```

- המשתנה `SUPABASE_PROXY_UPSTREAM` הוא origin בלי נתיב.
- השאירו את `SUPABASE_URL` מוגדר לכתובת ה-HTTPS של הפרויקט. ה-API ממשיך להתחבר אליה ישירות.
- הדפדפן משלים את `/supabase` לכתובת מלאה לפי ה-origin של הדף. שרת הווב מעביר לפרויקט בקשות התחברות, REST, אחסון ו-realtime, כולל שדרוגים ל-WebSocket.
- אסימונים ומפתחות API עוברים בלי שינוי. הפרוקסי לא מוסיף פרטי גישה עם הרשאות מוגברות.
- כמה דומיינים יכולים להשתמש באותה הגדרה, בלי דומיין מותאם אישית נוסף ב-Supabase.

קובץ ה-Compose לא מעביר את `SUPABASE_MANAGED_PROXY` ואת `SUPABASE_PROXY_UPSTREAM` מ-`.env`: הוסיפו אותם תחת `environment:` של השירות `nodaro`. כשהם לא מוגדרים, הפרוקסי כבוי, והנתיבים המובנים מתנהגים כמו קודם.

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

```bash
docker compose -f docker-compose.community.yml restart nodaro
```

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

גבו את מסד הנתונים יחד עם מפתח ההצפנה: ראו את הדף [גיבוי ושחזור](https://nodaro.ai/docs/self-hosting/backups). כדי להריץ שתי התקנות על מסד נתונים אחד, ראו את הדף [הרחבת קיבולת](https://nodaro.ai/docs/self-hosting/scaling#two-installs-one-database).

## שאלות נפוצות

### באיזה מסד נתונים Nodaro משתמש?

Nodaro משתמש ב-Supabase, כלומר Postgres עם שירות ההתחברות GoTrue וה-API של הנתונים PostgREST. מערך השירותים של Compose כולל את שלושתם, ואפשר גם לכוון את Nodaro לפרויקט מנוהל ב-supabase.com.

### האם צריך להריץ בעצמי את המיגרציות של מסד הנתונים?

לא במערך השירותים המובנה, שמחיל את המיגרציות בכל אתחול ומדלג על אלה שכבר הוחלו. עם פרויקט Supabase מנוהל, הגדירו RUN_MIGRATIONS_ON_BOOT=false והחילו את הקבצים שבתיקייה supabase/migrations לפי סדר שמות הקבצים, בעורך ה-SQL או עם supabase db push.

### למה מפתחות שהודבקו נכשלים עם EncryptionKeyMissingError בפרויקט Supabase מנוהל?

מערך השירותים יוצר את מפתח ההצפנה של המופע רק כשמריץ המיגרציות שלו מופעל. עם RUN_MIGRATIONS_ON_BOOT=false, הגדירו את NODARO_ENCRYPTION_KEY בעצמכם, או השתמשו שוב במפתח שהתקנה קודמת על המערך המובנה שמרה ב-volume שלה, app-data.

### האם אפשר לשנות את POSTGRES_PASSWORD אחרי ההפעלה הראשונה?

את POSTGRES_PASSWORD אפשר לשנות אחרי ההפעלה הראשונה רק ידנית. מסד הנתונים מתאים את הסיסמאות של התפקידים הפנימיים שלו ל-POSTGRES_PASSWORD רק בהפעלה הראשונה שלו. מחקו את ה-volume db-data, מה שמוחק את הנתונים שלכם, או שנו את סיסמאות התפקידים בתור supabase_admin.

### האם אפשר לבטל מיגרציות?

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