這次針對之前所想的架構進行了些更改，想要將寫入和查詢這兩個分開一些，權限分開(不知道這樣說對不對哈哈)。

總目標

• 資料寫入（內網）：n8n → ingest 後端 → Postgres（僅內部網路能打到）
• 對外讀：網頁前端 → api（對外，走 HTTPS ）→ 讀 使用者只能讀資料
• 權限隔離：ingest_user（只寫 raw/prod 指定表）／api_readonly（只讀 prod）

今天的目標是第一項資料寫入。

因為之前對資料表還沒有很完善規劃，現在要更改之前的設定，但又因為我 n8n workflow那些在舊的 volumes，所以現在要把舊的對應到新的。
我問chatGPT可以怎麼做，他給我兩個做法:

1. 保留舊，原地升級
2. 刪前先備份 & 還原

我看了下他給的做法 覺得第一種比較保險，所以選擇了保留舊，原地升級。

1) 取代 docker-compose.yml（保留舊卷）

1. 建好一個只在內網可存取的寫入通道

   • ingest_api（內網，不對外開 port）← 之後 n8n 打這個來寫資料庫。

2. 主庫（db_primary）啟動，沿用舊的 pg_data 卷

   • 保留了 n8n 原本的資料（工作流等）。

3. 讀庫（db_read）啟動

   • 之後會用邏輯複寫從主庫同步給對外查詢（目前你還沒起 read_api，之後再加）。

4. n8n 啟動

   • 之後把 workflow 的 HTTP 節點 URL 改成 http://ingest_api:8000/... 就能在內網寫庫。

到這步為止：container 都起來了，但兩件事要再確認：init.sql 是否已手動套用（舊卷不會自動跑），以及主→讀庫的「publication/subscription」是否已建立。

2) 先停舊服務，換新 compose，啟動db_primary

考慮資安問題，對於資料庫這方面我打算把爬蟲的寫到RAW資料庫，之後會再Mapping到一個專沒給使用者(網頁)Read的資料庫。

docker compose down

# 確認 docker-compose.yml 已換成上面的版本
# 先只起主庫（沿用舊卷）
docker compose up -d db_primary

# 等 10~20 秒，確認起來
docker compose logs -f db_primary

3) 手動套用 init.sql（因為是舊卷，不會自動跑）

這一步會建立 raw/prod schema、表、函式、觸發器與權限，不會動到 n8n 原有資料。

docker compose exec db_primary  psql -U gu -d n8n -f /docker-entrypoint-initdb.d/00-init.sql

看到 CREATE SCHEMA / CREATE TABLE IF NOT EXISTS 之類訊息就對了。
這一步會建立 raw/prod schema、表、函式、觸發器與權限，不會動到 n8n 原有資料。

4) 建立「主庫(primary) → 讀庫(read)」邏輯複寫

建立爬蟲下來主要的資料表，這邊先pass (有機會補)

5) 啟動其餘服務（ingest、read_api、n8n、scraper）

docker compose up -d ingest read_api n8n scraper

# 看 log 確認
docker compose ps

Bug

1

錯誤訊息：pull access denied for backend-ingest
(backend-ingest是我 寫入資料庫API 的image)
原因：docker-compose.yml 裡的 ingest 指向了一個不存在的image（只是占位名稱），Compose 嘗試從註冊中心拉取失敗。
修正：建立了本地目錄 ingest/，寫了極簡 FastAPI 服務，並以 Dockerfile build 出 backend-ingest:latest。
→ 問題解決，服務能啟動。

2

錯誤訊息：n8n workflow 寫入資料 出現 value {...} is not set。 => 資料轉換一直跳錯。
目標: 在 n8n 做最小必要轉換（扁平化、型別、預設值），並把完整原始物件存 raw_json(JSONB)
為什麼要在n8n做轉換：
1. 因為我們拿取的資料有巢狀物件。資料庫是欄位式，要寫入就得把每個 item 拆出來、巢狀轉成欄位或 JSON 字串。所以如果用原來n8n處理爬蟲這部分的邏輯，就必須在n8n先做資料轉換才存回資料庫。也就是得在中間把資料「對齊」。
2. 像是women有 471 筆商品，一次直接寫入可能容易失敗，通常在 n8n 要把它切成逐筆（或分批）處理並控管失敗重試。
修正: 尚未。還在找原因，應該是我原本是item要轉換這出事。

認真覺得我自己對n8n的用法沒很了解，感覺全自己來好像比較快也比較清楚QQ。
明天(有時間的話)繼續加油 。