# Reset PostgreSQL / Timescale (Docker) a obnova z dumpu
Přesný postup pro **smazání dat databáze** (volume) a**nový import**`pg_dump -Fc` na serveru typu `/opt/ems-deploy`. Po resetu zmizí veškerá data v DB EMS.
Postup pro **smazání dat databáze** (volume),**nový čistý cluster** a **obnovu** z `pg_dump -Fc`. Platí stejně **na lokálu** i **na cílovém serveru** (např. `/opt/ems-deploy`): neprováděj in-place „upgrade“ starého datadisku jen přepnutím Docker image mezi major verzemi PostgreSQL.
**Související skripty v repu:**`scripts/import_ems_db.sh`, `scripts/export_ems_db.sh`.
**Související skripty v repu:**`scripts/export_ems_db.sh`, `scripts/import_ems_db.sh`.
Major upgrade PostgreSQL se má dělat **`pg_upgrade`** nebo **dump/restore**. Prosté přepnutí image u existujícího volume nestačí a může vést k poškozenému nebo nekompatibilnímu datadir. Oficiální dokumentace: [PostgreSQL: pg_upgrade](https://www.postgresql.org/docs/current/pgupgrade.html).
V Docker Compose je **dump/restore** obvykle jednodušší než `pg_upgrade` (potřebuješ staré i nové binárky a dva datadiry najednou). Bezpečná cesta: **nový prázdný cluster** (nový volume) + **restore zálohy**.
---
## Sladění verzí TimescaleDB
Zdroj zálohy a cílový kontejner musí mít **sladěnou verzi rozšíření TimescaleDB** vůči tomu, co očekává image — jinak často narazíš na **catalog mismatch** při restore nebo po něm. Před migrací ověř na obou stranách:
docker compose exec -T db psql -U "$DB_USER" -d ems -c "select extname, extversion from pg_extension where extname='timescaledb';"
```
Kontext a restore workflow: [TimescaleDB: Troubleshooting (self-hosted)](https://docs.timescale.com/self-hosted/latest/troubleshooting/), [Upgrade TimescaleDB in Docker](https://docs.timescale.com/self-hosted/latest/upgrades/upgrade-docker/).
V repozitáři je pro nové instalace očekávaný image např. `timescale/timescaledb:2.26.1-pg18` (viz `docker-compose.yml`). Pinni tag na cíli stejně jako u zdroje dumpu.
- **`DB_USER` / `DB_PASSWORD` v `.env` na cíli** odpovídají tomu, co očekává init kontejneru `db` (po smazání volume se DB vytvoří znovu se stejnými údaji z `.env`).
-Timescale: image `timescale/timescaledb:latest-pg16` se v čase mění. Záloha ze **staršího** Timescale na **novější** imagi vyžaduje po restore `ALTER EXTENSION timescaledb UPDATE` — to už dělá `import_ems_db.sh`. Při problémech zvaž **pin** imagi (např. `:2.25.2-pg16`) stejně jako u zdroje dumpu.
- **`pg_restore` nikdy s `-j`** (paralelní restore) u Timescale.
docker compose exec -T db psql -U "$DB_USER" -d ems -c "select extname, extversion from pg_extension where extname='timescaledb';"
```
Počkej, až je služba `db`**healthy** (`pg_isready` v healthchecku).
Init image vytvoří prázdnou databázi **`ems`** a uživatele z `POSTGRES_USER` / `POSTGRES_PASSWORD`.
---
## 5. Import dumpu (Timescale hooks + restore)
Dump musí být na serveru, např. `/tmp/ems.dump`.
## 3) Zastavit stack a smazat jen DB volume
```bash
cd /opt/ems-deploy
bash app/scripts/import_ems_db.sh /tmp/ems.dump
docker compose down
docker volume ls | grep db_data
```
Skript v kontejneru `db` postupně:
Smaž volume pro databázi. Název závisí na **Compose project name** (složka nebo `COMPOSE_PROJECT_NAME`), typicky `{projekt}_db_data`, např. `ems_db_data` nebo `ems-deploy_db_data`:
4.`ALTER EXTENSION timescaledb UPDATE;` (srovnání katalogu se verzí v imagi)
5.`SELECT timescaledb_post_restore();`
```bash
docker volume rm ems_db_data
```
Výjimky: `EMS_SKIP_TIMESCALE_RESTORE_HOOKS=1` v prostředí přeskočí body 2 a 5 (jen výjimečně).
Jestli nechceš hledat přesný název a máš jen compose-definované volumes:
```bash
docker compose down -v
```
**Pozor:**`down -v` smaže volumes definované v daném compose souboru — lokální DB tím kompletně zahodíš (v tomto scénáři je to záměr, obnova jde z dumpu).
---
## 4) Compose na cílové verzi Postgresu / Timescale
V `docker-compose.yml` nastav konkrétní tag, např.:
```yaml
services:
db:
image:timescale/timescaledb:2.26.1-pg18
```
Nespoléhej na „upgrade“ starého volume změnou image — viz úvod.
---
## 5) Nový prázdný cluster (jen `db`)
```bash
docker compose up -d db
```
Počkej na **healthy** (`pg_isready` v healthchecku). Init vytvoří prázdnou databázi **`ems`** a uživatele z `POSTGRES_USER` / `POSTGRES_PASSWORD`.
**Alternativa:**`bash scripts/import_ems_db.sh /tmp/ems.dump` (z kořene repa na serveru s naklonovanou aplikací) — skript doplní `CREATE EXTENSION`, `timescaledb_pre_restore`, `pg_restore` s `--clean --if-exists`, pak **`ALTER EXTENSION timescaledb UPDATE`** (srovnání katalogu zálohy s verzí v imagi) a `timescaledb_post_restore`. Na úplně čerstvém volume je ruční sekvence výše ekvivalentní v principu; skript je praktičtější při opakovaném importu na serveru.
**Časté jevy:**
-`pg_restore: warning: errors ignored` — často kvůli FK na hypertable (`ALTER TABLE ONLY`). Po importu **vždy** Flyway (migrace **V034** doplní chybějící FK).
-Selhání **catalog version mismatch** — typicky vyřeší `ALTER EXTENSION` ve skriptu; jinak pin Timescale imagi nebo nový dump po upgrade zdroje.
-`pg_restore: warning: errors ignored` — často kvůli FK na hypertable (`ALTER TABLE ONLY`). Po importu **vždy** Flyway (migrace **V034** a okolí doplňují chybějící FK podle verze repa).
- **Catalog version mismatch** — sladit Timescale tag na cíli se zdrojem nebo pořídit nový dump po upgrade zdroje; skript `import_ems_db.sh` řeší část přes `ALTER EXTENSION timescaledb UPDATE`.
Výjimka v prostředí: `EMS_SKIP_TIMESCALE_RESTORE_HOOKS=1` u skriptu přeskočí pre/post (jen výjimečně).
---
## 6. Flyway migrace
Doplní schéma oproti dumpu (včetně oprav PK/chunků/FK z V032–V034 podle verze repa):
## 8) Flyway migrace (EMS)
```bash
cd /opt/ems-deploy
docker compose --env-file .env run --rm flyway migrate
```
---
## 7. Celý stack
Lokálně z kořene repa (bez `--env-file`, pokud používáš výchozí `.env`):
```bash
docker compose run --rm flyway migrate
```
---
## 9) Celý stack
```bash
docker compose up -d
```
Na serveru např.:
```bash
cd /opt/ems-deploy
docker compose --env-file .env up -d
```
Nebo jednorázový deploy z aplikace:
```bash
/opt/ems-deploy/deploy.sh
```
(`deploy.sh` dělá git sync, `flyway migrate`, `build`, `up -d` — pokud už jsi Flyway spustil v kroku 6, znovu obvykle jen doplní repeatable migrace.)
nebo `/opt/ems-deploy/deploy.sh` (git sync, flyway, build, `up -d` — pokud už je Flyway z kroku 8 hotový, znovu typicky jen doplní repeatable migrace).
Volitelně SQL (z hosta přes `docker compose exec`):
```bash
docker compose --env-file .env exec -T -e PGPASSWORD="$DB_PASSWORD" db \
docker compose exec -T -e PGPASSWORD="$DB_PASSWORD" db \
psql -U "$DB_USER" -d ems -c "SELECT count(*) FROM ems.site;"
```
---
## 9. Slabší varianta bez mazání volume
## 11) Úplně čistá varianta bez mazání stávajícího volume (rollback)
Pokud nechceš mazat celý volume, lze zkusit přepnout databázi uvnitř (méně typické u Timescale; u poškozeného katalogu chunků je **spolehlivější smazat volume**):
Můžeš vedle současného stacku spustit **druhý compose projekt** (jiné `COMPOSE_PROJECT_NAME` nebo jiná složka), **jiný volume** a **jiný mapovaný port**, např.:
- starý stack na host portu `5432`;
- nový PG18 dočasně na `5433`;
- restore do nového, ověření;
- pak starý stack zastavit a volume zahodit, nebo porty přemapovat podle potřeby.
Tím máš možnost vrátit se ke staré DB, dokud novou neověříš.
---
## 12) Slabší varianta: drop databáze `ems` bez mazání celého volume
Pokud nechceš mazat celý Postgres volume, lze zrušit jen databázi `ems` a znovu ji vytvořit (méně typické u hlubších problémů s katalogem Timescale; u poškozených chunků je spolehlivější **smazat volume**):
```bash
docker compose --env-file .env exec -T -e PGPASSWORD="$DB_PASSWORD" db \
docker compose exec -T -e PGPASSWORD="$DB_PASSWORD" db \
psql -U "$DB_USER" -d postgres -c "DROP DATABASE IF EXISTS ems WITH (FORCE);"
docker compose --env-file .env exec -T -e PGPASSWORD="$DB_PASSWORD" db \
docker compose exec -T -e PGPASSWORD="$DB_PASSWORD" db \
Plný „schema odděleně od dat“ a obnova hypertable přes `create_hypertable` popisuje **Tiger Data / Timescale** v dokumentaci k backupu a restore. Tento repozitář používá praktický jednokrokový `-Fc` restore přes `import_ems_db.sh`; u opakovaných problémů zvaž jejich oficiální postup (pre-data dump bez `_timescaledb*`, data zvlášť).
Plný postup „schéma odděleně od dat“ a obnova hypertable přes `create_hypertable` popisuje Tiger Data / Timescale v dokumentaci k zálohám. Tento repozitář používá praktický jednosouborový `-Fc` restore; při opakovaných problémech zvaž jejich oficiální postup.
docker compose --env-file .env run --rm flyway migrate
docker compose --env-file .env up -d
```
Nebo místo tří `exec` řádků s restore použij `bash app/scripts/import_ems_db.sh /tmp/ems.dump` a pak Flyway + `up -d`.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Dusan Vojacek