PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 12/11/2018 17:49:28

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!

Hors ligne

#2 12/11/2018 23:03:19

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.

Hors ligne

#3 13/11/2018 11:06:03

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

Hors ligne

#4 13/11/2018 22:50:42

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.

Hors ligne

#5 14/11/2018 09:40:40

dev.isc84
Membre

Re : Upgrade 9.6 vers 11

parfait, merci pour votre aide.

Hors ligne

#6 14/11/2018 11:17:14

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?

Hors ligne

#7 14/11/2018 11:21:03

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.

Hors ligne

#8 14/11/2018 12:12:04

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?

Hors ligne

#9 14/11/2018 17:46:43

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.

Hors ligne

#10 15/11/2018 12:24:18

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?

Hors ligne

#11 16/11/2018 09:59:27

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';

Hors ligne

#12 16/11/2018 11:10:53

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.

Hors ligne

#13 16/11/2018 17:14:23

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?

Hors ligne

#14 16/11/2018 19:28:04

gleu
Administrateur

Re : Upgrade 9.6 vers 11

Oui.


Guillaume.

Hors ligne

#15 19/11/2018 11:06:56

dev.isc84
Membre

Re : Upgrade 9.6 vers 11

Ok merci de votre aide!

Hors ligne

#16 11/12/2018 15:33:33

Re : Upgrade 9.6 vers 11

gleu a écrit :

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)

Hors ligne

#17 11/12/2018 16:52:04

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.

Hors ligne

#18 11/12/2018 17:03:30

Re : Upgrade 9.6 vers 11

gleu a écrit :

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...

Hors ligne

Pied de page des forums