![[?]](https://social.dk-libre.fr/social/oldsysops/s/7e93fa6bf16b47da4f57ddf9072aff8c.png)
qui aurait pu predire que le -j 60 serait aussi rapide ....
...
![[?]](https://static.piaille.fr/accounts/avatars/109/676/309/314/166/793/original/c1d26355f147d36e.png)
@oldsysops À $job-1 j’ai beaucoup utilisé le -k aussi pour des bases multi-tera… ⚠️, il faut bien tester les backups avant parce que c’est plus définitif ! (Mais avec un barman au petits oignons, pas de soucis) 😉.
En préparant bien, j’ai du faire moins de 10mn de downtime pour une base de 5To 🤔
https://www.postgresql.org/docs/current/pgupgrade.html#:~:text=k%2D%2Dlink
...
la on utlise --clone car xfs le permet..
si j'ai bien compris la procédure d'upgrade c'est :
- recréer les schémas ~10 minutes
- copier les données, rapide en mode clone ~ 5 minutes
- faire un vacuum full ~ 15 minutes
...
@oldsysops J’ai retrouvé un bout de journal de bord pour une db d’à priori 450 Go :
sudo -i -u postgres /usr/pgsql-12/bin/initdb -D /data01/PG12/PROD_5432/ --locale="fr_FR.UTF-8"
(date && time sudo -iu postgres /usr/pgsql-12/bin/pg_upgrade -b /usr/pgsql-9.6/bin/ -B /usr/pgsql-12/bin/ -d /data01/PG96/PROD_5432/ -D /data01/PG12/PROD_5432/ -j 16 -v -k 2>&1 | ts) | tee /tmp/upgrade.log
⇒ 12s
Repack ⇒ 278m (4h38)
En gros, la proc, c’était :
pg_repack (vacuum full, mais online ♥️)
backup barman
coupure des fronts
backup barman (diff)
pg_upgrade « inplace »
réouverture
pg_repack (uniquement reindex pas besoin de toucher aux fichiers data)