Footcow Blog - Mot-clé - migrationLinux, Base de données Postgresql, développement, Internet, emailing et déliverabilité.2024-03-29T15:46:38+01:00Hervé Piedvache alias Bill Footcow pour les intimesurn:md5:ef5d07bad25e414feca607a3b7f2af11DotclearChangement de version majeure de PostgreSQL sous Debian / Ubuntuurn:md5:6a32dfb2f594c39bc9dcbcce16d676c82017-11-08T10:08:00+01:002023-05-17T17:11:59+02:00footcowPostgreSQLdebianmigrationpostgresqlupgrade<p><img src="https://www.footcow.com/public/.postgres-ubuntu_m.jpg" alt="" style="display:table; margin:0 auto;" height="297" width="448" /></p>
<p>Chaque release majeure de PostgreSQL (passage de la version 9.6 à la 10 par exemple) nécessite d'effectuer un dump et un restore de la base de données. Le travail n'est pas si fastidieux, mais nécessite quelques manipulations. Debian propose une migration plus simplifiée, destinées, à mon avis, aux bases de données de petites tailles, pour une migration rapide. Si vous travaillez sur des bases de plusieurs Go, cela fonctionnera, bien sur, mais l'interruption de service pourra être longue. Il existe d'autres moyens pour faire ce genre de chose avec des serveurs de réplication par exemple. Je vais donc vous décrire le process simple à mettre en place.</p> <p>Première étape installer la dernière release majeure de PostgreSQL qui ne sera pas forcément intégrée dans votre distribution. Pour cela suivez la procédure décrite sur l<a href="https://www.postgresql.org/download/linux/debian/" hreflang="en" title="Debian last PostgreSQL version">e site de PostgreSQL</a>.</p>
<p>Vous installez donc par exemple la dernière version de PostgreSQL actuelle. Nous admettrons que vous passez comme c'est le cas actuellement de la Jessie de la verison 9.0 à la version 10 de PostgreSQL. Vous aurez donc la version 9 et la version 10 d'instalées sur votre machine.</p>
<p><strong>Attention</strong>, il est toujours préférable d'effectuer un pg_dumpall de votre base de données que vous conservez précieusement avant d'effectuer cette opération.
Pensez également à couper les applications ou services qui accèdent à votre base de données avant de faire la migration.</p>
<p>On arrête PostgreSQL :</p>
<pre>
service postgresql stop
</pre>
<p>On nettoye la nouvelle version du cluster postgreSQL pour être certain qu'il n'y a rien dedans, elle est neuve, normalement c'est toujours le cas :</p>
<pre>
pg_dropcluster --stop 10 main
</pre>
<p>On effectue la migration des données de la versino 9.0 vers la version la plus élevée, la 10 dans notre exemple :</p>
<pre>
pg_upgradecluster -m upgrade 9.0 main
</pre>
<p>On arrête la version précédente de PostreSQL :</p>
<pre>
pg_dropcluster 9.0 main --stop
</pre>
<p>On efface complètement la version 9.0 et ses données, attention ici vous pouvez tout perdre, donc un pg_dumpall ne fera jamais de mal !</p>
<pre>
apt-get autoremove --purge postgresql-9.0</pre>
<p>Puis on redémarre PostgreSQL, sur la nouvelle version avec les données migrées :</p>
<pre>service postgresql start</pre>
<p>Voilà, le tour est joué. Simple comme Debian. Naturellement si vous utilisez des versions différentes de celle présentées dans cet exemple, il suffit de remplacer 9.0 par votre version courante.</p>https://www.footcow.com/index.php/post/2017/11/08/Changement-de-version-majeure-de-PostgreSQL-sous-Debian-/-Ubuntu#comment-formhttps://feeds.feedburner.com/FootcowBlog/comments/110PostgreSQL : optimisez vos migrations de versions !urn:md5:0e0c4075ce7c053ac7f45918962e75b32009-10-24T12:38:00+02:002009-10-24T12:38:00+02:00footcowPostgreSQLmigrationparallèlepostgresqlrestauration<p><br />
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 !</p> <p>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 !</p>
<p>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).</p>
<p>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 !</p>
<p>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 !</p>
<p>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.</p>
<p><strong>Comment procéder ?</strong>
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.</p>
<pre>
./configure --prefix=/usr/local/pg84
make
make install
</pre>
<p>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.</p>
<pre>
/usr/local/pgsql/bin/pg_dump -F c -v -f my_db.dump my_database
</pre>
<p>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.</p>
<p>Lançons donc 8 processus de restauration en parallèle pour créer la base de données :</p>
<pre>
/usr/local/pg84/bin/pg_restore -F c -j 8 -v -C -f my_db.dump
</pre>
<p>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.</p>
<p>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.</p>
<p>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 : <a href="https://pgfoundry.org/projects/pg-migrator/" hreflang="en">pg_migrator</a>.</p>https://www.footcow.com/index.php/post/2009/10/24/Postgresl-%3A-optimisez-vos-dumps-%21#comment-formhttps://feeds.feedburner.com/FootcowBlog/comments/80Accélérer une migration de versionurn:md5:594eef67e915044c5c1bd817812e543d2009-09-19T20:05:00+02:002010-01-22T18:22:41+01:00footcowPostgreSQLdumpmigrationpostgresqlrestore <p>Un très bon article pour réaliser une migration de <a href="https://www.postgresql.org" hreflang="en">PostgreSQL</a> v8.2 vers <a href="https://www.postgresql.org" hreflang="en">PostgreSQL</a> v8.3 ... 9h sur le papier par un processus "classique", 2h30 au final ... joli travail !</p>
<p>Tous les détails sont à lire sur <a href="https://www.depesz.com/index.php/2009/09/19/speeding-up-dumprestore-process/" hreflang="en">Speeding up dump/restore process</a></p>https://www.footcow.com/index.php/post/2009/09/19/Acc%C3%A9l%C3%A9rer-une-migration-de-version#comment-formhttps://feeds.feedburner.com/FootcowBlog/comments/68Dotclear 2urn:md5:c7033a6efb5e8c0b8fe26c9d7fdb50fd2006-07-06T18:54:00+00:002006-07-07T00:12:58+00:00footcowGénéralblogdotclearmigration <p>Pas le moindre regret ... je migre Footcow Blog sur Dotclear 2 ... nous sommes sur la version Béta ... mais cela me semble plutôt très stable. Naturellement les principaux plugins utilisés jusque là ne sont pas encore portés ... mais bon voilà juste pour vous dire que je remercie très vivement <a href="https://www.neokraft.net/" hreflang="fr">Olivier</a> pour son travail. C'est un produit très simple à mettre en oeuvre qui permet à tous le monde de monter son blog en quelques minutes ...<br />
J'ai mis en place un template dérivé du template original pour la présentation de ce blog ... histoire de reste dans le même genre que la version précédente ... rien de bien révolutionnaire.<br /></p>
<p>A bientôt donc ...</p>https://www.footcow.com/index.php/post/2006/07/06/Dotclear-2#comment-formhttps://feeds.feedburner.com/FootcowBlog/comments/12Sony migre Sony Online d'Oracle vers PostgreSQLurn:md5:ba2005dd57643eb6e33a196a26430ea92006-03-27T23:54:00+00:002010-01-22T17:27:36+00:00footcowPostgreSQLdatabasemigrationoraclepostgresqlsony <p>Cette annonce bien officielle pourra en faire réfléchir plus d'un, je l'espère ... <a href="https://www.computerworld.com/softwaretopics/software/story/0,10801,109850,00.html" hreflang="en">Sony Online Shifts From Oracle to Open-source Database - Computerworld</a><br /></p>
<p>Le coût des licences Oracle et le peu travail nécessaire à la migration des applications sont les principales motivations de ce choix.<br /></p>
<p>Une très bonne nouvelle et une reconnaissance publique de plus pour <a href="https://www.postgresql.org" hreflang="en">PostgreSQL</a>.</p>