Linux, Base de données Postgresql, développement, Internet, emailing et déliverabilité.

Aller au contenu | Aller au menu | Aller à la recherche

PostgreSQL : optimisez vos migrations de versions !


L'un des principal problème lié aux évolutions de PostgreSQL reste la migration des données. Changer de version va souvent de paire avec, une nouvelle installation de PostgreSQL, un dump complet de la base de données, puis un ré-import des données ... Dès que l'on a en place des bases de données de plusieurs centaines de giga-octets cela implique des interruptions de services longues, et donc de l'insatisfaction client. Heureuses la communauté de PostgreSQL est très active et s'est donc mis en tête de trouver des solutions à ce problème. La sortie de la version 8.4 de PostgreSQL fait donc apparaître une nouvelle option : la restauration en parallèle ... compatible également avec les versions précédentes de PostgreSQL (8.2 et 8.3) ! Un must have !

Vous souhaitez donc par exemple migrer d'une version 8.2 vers une 8.3 ou simplement modifier votre plate-forme de 32 vers 64 bits ? Profitez de la nouvelle fonctionnalité de restauration parallèle offerte par la version 8.4 de pg_dump !

L'avantage de la restauration parallèle réside dans le fait que vous pouvez utiliser tout le potentiel d'une machine équipée de plusieurs CPU. C'est un point critique, car par exemple avec une base de données de 300 Go équipée d'une seule CPU vous aurez à attendre environ 12 heures pour faire une migration, alors qu'avec 8 CPU ce temps va se réduire à 3 heures, naturellement en fonction tout de même de la structure de vos données et du reste de l'équipement de la machine (entrées/sorties en particuliers).

Il faut aussi noter que la restauration en parallèle n'est pas forcément intéressante pour tous. Par exemple si 80% de votre base de données n'est constituée que d'une seule table, la restauration en mode parallèle ne sera pas capable de paralléliser et fonctionnera en mode simple. Si cette table est partitionnée, en revanche, le mode parallèle sera efficace. Autre point, si vous avez une machine équipée d'entrées/sortie de faible qualité, et donc si la base de données sature les entrées/sorties alors avoir toutes les CPU de la terre ne feront pas de miracle !

Autre chose à savoir, pour obtenir des performances optimales n'oubliez pas de retirer temporairement les options fsync et l'autovacuum. Augmentez de façon radicale les options work_mem et maintenance_work_mem, en fonction de votre configuration 1Go pour chacun par exemple. Pensez également à contrôler que les options wal_buffers et checkpoint_segments sont suffisamment importante avec au moins 16 ou 32 Mo. Et n'oubliez pas de remettre vos valeurs normales pour la remise en production !

Pensez à faire des tests avant de vous lancer dans cette opération. Vous allez couper votre production pour effectuer cette migration, donc calibrez bien vos tests, et pensez à prévenir les usagers de l'interruption de service.

Comment procéder ? Première chose à faire est donc de télécharger la dernière version de PostgreSQL 8.4 sur le serveur de destination. Vous compilez cette version dans un répertoire différent de celui de la version de PostgreSQL que vous allez utiliser sans option spécifique. Nous dirons donc que l'installation de la version de PostgreSQL de production se trouve dans /usr/local/pgsql et que les binaires de la version 8.4 se trouve dans /usr/local/pg84/bin. Vous devez bien évidemment avoir des droits maximum sur la base de données.

./configure --prefix=/usr/local/pg84
make
make install

Maintenant vous devez faire un dump binaire de votre base de données originale. Comme toujours, vous devez faire ce dump depuis la prochaine version de PostgreSQL que vous allez utiliser, en aucun cas depuis l'ancienne version depuis laquelle vous allez migrer. Donc si vous faites une migration de la version 8.2 vers la version 8.3, vous utiliserez la version 8.3 pour faire le pg_dump.

/usr/local/pgsql/bin/pg_dump -F c -v -f my_db.dump my_database

Maintenant il est temps d'utiliser la version 8.4 avec cette fameuse fonction parallèle de restauration pour restaurer votre base de données. Si vous avez des entrées/sorties de très bonne qualité, vous pourrez utiliser autant de processus de restauration que vous avez de processeurs. Si vous entrées/sorties sont faiblardes, vous devez réduire le nombre de processus jusqu'à ce que la machine ne sature pas. L'idéal reste donc d'avoir tout en fibre optique, avec un disque dédié pour les log et 2 CPU en quad-core.

Lançons donc 8 processus de restauration en parallèle pour créer la base de données :

/usr/local/pg84/bin/pg_restore -F c -j 8 -v -C -f my_db.dump

Maintenant il s'agit de suivre l'évolution de la restauration. Lancez par exemple mpstat et regardez comment le processus de parallélisation est efficace, regardez la charge des CPU, si certains se bloquent alors jetez un oeil à vos entrées / sorties avec iostat.

Après quelques heures, en fonction de la taille de votre base de données, naturellement, votre base doit être restaurée. Dans le cas idéal vous gagnez 50% de temps dès 4 CPU et cette valeur se double avec 8 CPU.

Si vous voulez faire une mise à jour depuis une version 8.3, vers une version 8.4, le passage par le classique dump-restore n'est plus d'actualité, puisqu'il existe maintenant, en natif, un outil merveilleux : pg_migrator.

Partager

  • Favories


Commentaires

1. Le jeudi, 12 novembre 2009, 21:54 par Gôm

Bonjour,

Très intéressant votre article ! ;-)

Je travaille dans le Décisionnel sur un projet très (trop ?!) important où PostgreSQL est utilisé et j'ai un problème lors de l'alimentation de mon entrepôt de données.

Un de mes JOB BO Data Integrator est très très très long lors du 1er passage (une boucle d'une cinquantaine de passages). Je soupçonne un problème d'Entrées/Sorties faiblardes comme tu dis !

Comment puis-je m'assurer que le problème vient bien de là ?

S'il vient bien de là, est-ce que cela explique le fait que le 1er passage est systématiquement beaucoup plus lent que tous les autres qui prennent entre 100 fois et 4 fois moins de temps ?!!

Désolé, je ne m'y connais que (trop) peu en gestion de BDD. Je sais toutefois qu'une même requête exécutée plusieurs fois est toujours plus rapide, mais me dites pas que ça explique mon problème !?

De toute façon, même si cela joue, ce n'est pas la solution à mon problème, car en relançant mon Job plusieurs fois et bien au bout d'un moment, j'arrive à avoir un 1er passage "acceptable".

Merci d'avance si tu prends le temps de me répondre.

Gôm

2. Le mercredi, 18 novembre 2009, 21:54 par footcow

Vous parlez d'un Data Integrator et de requêtes ... Quelle est la méthode exactement utilisée dans votre processus d'intégration de données ? Il faudrait me décrire plus précisément comment vous insérez vos données, est-ce que cela provient de SELECT ... il serait intéressant dans ce cas de voir les explain de vos requêtes, et d'avoir une idée des volumétries impliquées ...

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

La discussion continue ailleurs

URL de rétrolien : http://www.footcow.com/index.php/trackback/80

Fil des commentaires de ce billet