Forums PostgreSQL.fr

dev.isc84

Membre

Upgrade 9.6 vers 11

Bonjour,
Nous sommes actuellement en 9.6 et souhaitons upgrader vers pg11.

Notre base pèse environ 60GB, ce qui prend un peu de temps pour le restore.

On pensait à créer un nouveau serveur en v11, se servir du PITR pour initialiser puis mettre à jour cette base. Ensuite le moment venu, déconnecter les clients, jouer les wall en attente puis rediriger les clients de la 9.6 vers la 11.
Ca permettrait de bloquer les utilisateurs un minimum de temps.

Est-ce envisageable comme solution? (PITR entre deux versions majeures possible?)
Sinon, auriez vous une autre idée svp?

Merci de votre aide!

gleu

Administrateur

Re : Upgrade 9.6 vers 11

Non, pas possible. Vous avez trois possibilités pour une mise à jour majeure : 1. dump/restore (de préférence parallélisée pour que ce soit plus rapide), 2. réplication logique (donc Slony vu votre version), 3. pg_upgrade.

La solution 1 est la plus lente mais la plus sûre. La solution 2 est certainement la plus intéressante au niveau fonctionnalité (vous laissez vos utilisateurs travailler normalement pendant la synchronisation des données, la bascule vers la nouvelle version est très rapide, et le retour arrière est possible... mais ça demande d'installer, de connaître et d'administrer un outil tiers pas très simple de prime abord). La solution 3 est très rapide, mais a souffert de nombreux bugs qui font qu'on ne l'utilise que quand il n'y a pas de possibilité de faire autrement.

Dans votre cas (ie, pour 60 Go), je ne chercherais pas à m'embêter et je ferais un dump/restore parallélisé.

---

Guillaume.

dev.isc84

Membre

Re : Upgrade 9.6 vers 11

Merci pour l'information Guillaume, on va juste faire un restore parallélisé alors.

On est sur une infra virtialisée avec des disques NVMe.

On se demandait:

    1)  y a-t-il une distribution linux à privilégier (actuellement nous sommes sous Debian)

    2)  Comment profiter au max des disques NVMe? Je pensais baisser le random_page_cost à une valeur proche de 1 vu la rapidité des disques. Qu'en pensez vous? Y aurait-il un autre paramètre à retoucher selon vous?

Merci d'avance

Olivier Bouiron

gleu

Administrateur

Re : Upgrade 9.6 vers 11

1. Non, pas de distribution à privilégier.
2. Au niveau PostgreSQL, je baisserais en effet le random_page_cost mais je ne toucherais à aucun autre paramètre.

---

Guillaume.

dev.isc84

Membre

Re : Upgrade 9.6 vers 11

parfait, merci pour votre aide.

dev.isc84

Membre

Re : Upgrade 9.6 vers 11

Le module chkpass n'est plus présent dans la V11, je viens de lire dans la doc de la release 11 que c'est voulu par soucis de sécurité si j'ai bien compris.
Mais son absence me génère 15 erreurs sur le restore:

pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la fonction public.chkpass_in(cstring) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la fonction public.chkpass_out(public.chkpass) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la fonction public.chkpass_in(cstring) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la fonction public.eq(public.chkpass, text) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la fonction public.ne(public.chkpass, text) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la fonction public.raw(public.chkpass) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  le type « public.chkpass » est seulement un shell
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  l'opérateur n'existe pas : public.chkpass public.<> text
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  le type « public.chkpass » est seulement un shell
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  l'opérateur n'existe pas : public.chkpass public.= text

Quelle procédure conviendrais pour ces problèmes? Faut-il ajouter un module?

gleu

Administrateur

Re : Upgrade 9.6 vers 11

Toutes ces erreurs concernent l'installation du module, donc rien d'étonnant ni rien à modifier. Utilisez-vous le type de données chkpass dans vos tables ?

---

Guillaume.

dev.isc84

Membre

Re : Upgrade 9.6 vers 11

Il ne me semble pas. J'aurais d'autres erreurs si c''était le cas non?

gleu

Administrateur

Re : Upgrade 9.6 vers 11

Oui. De ce fait, l'extension ne sert à rien. Le mieux est de la supprimer du serveur ancienne version pour que la restauration (après nouvelle sauvegarde) se passe au mieux.

---

Guillaume.

dev.isc84

Membre

Re : Upgrade 9.6 vers 11

C'est assez surprenant, l'extension est visible via select * from pg_available_extensions , mais n'est pas installée.
Donc pas moyen de faire un drop extension

Pourtant j'ai bien les fonctions et le type dans la base (la base a été créée en v7 à l'époque il me semble, ça a peut etre un lien)

J'hésite à faire un create extension chkpass suivi d'un drop de l'extension ou faire des drop des méthodes, opérateurs et du type à la main. On est sur une base de prod... je ne voudrais pas faire d'erreurs.
Que me conseillez vous?

rjuju

Administrateur

Re : Upgrade 9.6 vers 11

Avez-vous vérifié la présence de l'extension sur chacune des bases de données de votre instance source ?

Sinon, si vous avez installé chkpass sur une version 7.x, donc avant l'arrivée des extensions, il est possible que vous ne l'ayez jamais converti en extension.  Vous pouvez vérifier l'utilisation sur chacune des bases avec

select * from information_schema.columns where udt_name = 'chkpass';

---

Julien.
https://rjuju.github.io/

gleu

Administrateur

Re : Upgrade 9.6 vers 11

Et ça expliquerait les messages d'erreur du dump en restauration (sinon ce serait un CREATE EXTENSION en erreur).

---

Guillaume.

dev.isc84

Membre

Re : Upgrade 9.6 vers 11

ça n'est utilisé sur aucune base.
L'idéal c'est donc un drop manuel des fonctions, opérateurs et du type?

gleu

Administrateur

Re : Upgrade 9.6 vers 11

Oui.

---

Guillaume.

dev.isc84

Membre

Re : Upgrade 9.6 vers 11

Ok merci de votre aide!

herve.lefebvre

Membre

Re : Upgrade 9.6 vers 11

2. Au niveau PostgreSQL, je baisserais en effet le random_page_cost mais je ne toucherais à aucun autre paramètre.

Je ne suis pas d'accord, il faut que le ratio random_page_cost/seq_page_cost corresponde à la réalité du matériel (à mesurer par exemple avec FIO https://dotlayer.com/how-to-use-fio-to- … -in-linux/ ).

En effet, sans cet ajustement, le planner risque par exemple d'utiliser un index alors qu'un sequential scan aurait été moins coûteux (ou le contraire).

Dernière modification par herve.lefebvre (11/12/2018 15:34:28)

gleu

Administrateur

Re : Upgrade 9.6 vers 11

Dans le cas d'un disque NVMe, il n'y a pas de tête de lecture à déplacer et la différence entre random_page_cost et seq_page_cost est typiquement le coût de ce déplacement. De ce fait, avoir une valeur très proche pour ces deux paramètres est généralement une bonne idée de base.

---

Guillaume.

herve.lefebvre

Membre

Re : Upgrade 9.6 vers 11

Dans le cas d'un disque NVMe, il n'y a pas de tête de lecture à déplacer et la différence entre random_page_cost et seq_page_cost est typiquement le coût de ce déplacement. De ce fait, avoir une valeur très proche pour ces deux paramètres est généralement une bonne idée de base.

Ah j'avais pas vu qu'il y avait du NVMe :-p

Mais pour info, sur du Power P9 avec NVMe, j'ai eu un surcoût FIO d'environ 50% sur du random par rapport au sequential. J'ai supposé que le NVMe avait son propre mécanisme de read-ahead...