Vous n'êtes pas identifié(e).
Pages : 1
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
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
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
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
parfait, merci pour votre aide.
Hors ligne
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
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
Il ne me semble pas. J'aurais d'autres erreurs si c''était le cas non?
Hors ligne
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
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
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/
Hors ligne
Et ça expliquerait les messages d'erreur du dump en restauration (sinon ce serait un CREATE EXTENSION en erreur).
Guillaume.
Hors ligne
ç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
Oui.
Guillaume.
Hors ligne
Ok merci de votre aide!
Hors ligne
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
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
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
Pages : 1
