Bonjour
J'ai eu des avis tres interessants sur la facon de sauvegarder une base
(ou plusieurs). Je vous remercie beaucoup pour vos avis.
Vu la taille de la chose qui me concerne j'opte pour un DUMP. J'ai fait
des petits tests, c'est raisonnable en temps de restauration.
Maintenant, passons a un autre sujet de debats:
Le jour ou MySQL 4.1 passera en stable et que sur le serveur on devra
passer au 4.1 (4.0 pour le moment), est ce que le dump (puis
restauration de ce dump) est plus efficace que la copie physique (puis
desarchivage tout court)?
Par efficace, j'entend fiable. La rapidité n'est pas un critere qui
compte pour de si petites bases.
Sachant que moi je ne maitrise pas les
types de bases qui sont crées, je m'occupe uniquement de l'aspect
(sauvegarde + restauration + migration vers version superieure) en cas de
besoin.
J'ai des lacunes certaines en administration de bases de données, lacunes
que je compte combler,...
Une fois les avis collectés, les operations en question feront l'objet de
tutoriels qui seront disponibles en libre service.
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Basile Starynkevitch [news]
On 2005-02-02, Rakotomandimby (R12y) Mihamina wrote:
Bonjour J'ai eu des avis tres interessants sur la facon de sauvegarder une base (ou plusieurs). Je vous remercie beaucoup pour vos avis.
Vu la taille de la chose qui me concerne j'opte pour un DUMP. J'ai fait des petits tests, c'est raisonnable en temps de restauration.
Bonne idée.
Maintenant, passons a un autre sujet de debats:
Le jour ou MySQL 4.1 passera en stable et que sur le serveur on devra passer au 4.1 (4.0 pour le moment), est ce que le dump (puis restauration de ce dump) est plus efficace que la copie physique (puis desarchivage tout court)?
Par efficace, j'entend fiable. La rapidité n'est pas un critere qui compte pour de si petites bases.
Je pense que oui. C'est semble-t-il l'un des objectifs de MySQL d'être compatible sur les dumps (evolution mineure de la version).
(Pour le passage de 4.1 vers 5.0, il faudra verifier).
Par ailleurs, mon hebergeur (lost-oasis.fr) dump aussi (par mysqldump) les bases mysql chaque nuit.
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net 8, rue de la Faïencerie, 92340 Bourg La Reine, France
On 2005-02-02, Rakotomandimby (R12y) Mihamina <mihamina@mail.rktmb.org> wrote:
Bonjour
J'ai eu des avis tres interessants sur la facon de sauvegarder une base
(ou plusieurs). Je vous remercie beaucoup pour vos avis.
Vu la taille de la chose qui me concerne j'opte pour un DUMP. J'ai fait
des petits tests, c'est raisonnable en temps de restauration.
Bonne idée.
Maintenant, passons a un autre sujet de debats:
Le jour ou MySQL 4.1 passera en stable et que sur le serveur on devra
passer au 4.1 (4.0 pour le moment), est ce que le dump (puis
restauration de ce dump) est plus efficace que la copie physique (puis
desarchivage tout court)?
Par efficace, j'entend fiable. La rapidité n'est pas un critere qui
compte pour de si petites bases.
Je pense que oui. C'est semble-t-il l'un des objectifs de MySQL d'être
compatible sur les dumps (evolution mineure de la version).
(Pour le passage de 4.1 vers 5.0, il faudra verifier).
Par ailleurs, mon hebergeur (lost-oasis.fr) dump aussi (par mysqldump)
les bases mysql chaque nuit.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France
On 2005-02-02, Rakotomandimby (R12y) Mihamina wrote:
Bonjour J'ai eu des avis tres interessants sur la facon de sauvegarder une base (ou plusieurs). Je vous remercie beaucoup pour vos avis.
Vu la taille de la chose qui me concerne j'opte pour un DUMP. J'ai fait des petits tests, c'est raisonnable en temps de restauration.
Bonne idée.
Maintenant, passons a un autre sujet de debats:
Le jour ou MySQL 4.1 passera en stable et que sur le serveur on devra passer au 4.1 (4.0 pour le moment), est ce que le dump (puis restauration de ce dump) est plus efficace que la copie physique (puis desarchivage tout court)?
Par efficace, j'entend fiable. La rapidité n'est pas un critere qui compte pour de si petites bases.
Je pense que oui. C'est semble-t-il l'un des objectifs de MySQL d'être compatible sur les dumps (evolution mineure de la version).
(Pour le passage de 4.1 vers 5.0, il faudra verifier).
Par ailleurs, mon hebergeur (lost-oasis.fr) dump aussi (par mysqldump) les bases mysql chaque nuit.
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Patrick Mevzek
Le Wed, 02 Feb 2005 13:18:11 +0100, Rakotomandimby (R12y) Mihamina a écrit :
Le jour ou MySQL 4.1 passera en stable et que sur le serveur on devra passer au 4.1 (4.0 pour le moment), est ce que le dump (puis restauration de ce dump) est plus efficace que la copie physique (puis desarchivage tout court)?
Souvent, c'est la seule solution car le format interne change.
Après, comme dit Basile peut être que MySQL garantit que ca va bien se passer.
Mon conseil lors d'une telle migration 1) faire une sauvegarde a) du système de fichiers, avec i) tous les binaires et outils en rapport avec le SGBDR ii) tous les fichiers de données du SGBDR b) de la base via un dump 2) tenter la mise à jour (idéalement sur une machine de test à part) 3) si le format n'a pas changé, ca repart immédiatement, si non on peut espérer une erreur du SGBDR (et il faudra de toute façon vérifier à la main, à coup de SELECT & co), et alors on refait une importation à partir du dump.
1)a)ii) et 1)b) peuvent sembler superflus l'un par rapport à l'autre, mais mieux vaut avoir les deux. Quant à 1)a)i) ca peut paraitre inutile, mais quand on a commencé la mise à jour, viré l'ancienne version, mis la nouvelle version du SGBDR (tout dépend comment vous faites l'installation, mais via des ``paquets'', il est rare de pouvoir faire cohabiter deux versions simultanément), et qu'on s'aperçoit alors que la nouvelle version est totalement incapable de lire les données de l'ancienne, et qu'on n'a pas fait de dump (ie on n'a que les données en binaire), eh bien on est coincé, et là ca peut être la panique si il s'agit de minimer le temps d'arrêt. D'autre part, il ne faut pas se dire qu'on peut de toute façon toujours récupérer les sources d'une vieille version: ce n'est pas toujours facile de remettre la main dessus quand on en a besoin, et la version installée a pu être compilé avec des options spécifiques qui influe sur le format binaire final des données, donc il faut exactement la même compilation, bref mieux vaut sauvegarder directement les binaires.
L'idéal étant bien entendu de tester la migration à part, avant de la faire pour de vrai.
Les scripts d'installation du paquet postgresql debian sont particulièrement astucieux à ce niveau et font automatiquement tout ce que je décris plus haut. Ca me semble être la bonne façon de faire. Et cela m'a déjà sauvé.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Wed, 02 Feb 2005 13:18:11 +0100, Rakotomandimby (R12y) Mihamina a écrit
:
Le jour ou MySQL 4.1 passera en stable et que sur le serveur on devra
passer au 4.1 (4.0 pour le moment), est ce que le dump (puis
restauration de ce dump) est plus efficace que la copie physique (puis
desarchivage tout court)?
Souvent, c'est la seule solution car le format interne change.
Après, comme dit Basile peut être que MySQL garantit que ca va bien se
passer.
Mon conseil lors d'une telle migration
1) faire une sauvegarde
a) du système de fichiers, avec
i) tous les binaires et outils en rapport avec le SGBDR
ii) tous les fichiers de données du SGBDR
b) de la base via un dump
2) tenter la mise à jour (idéalement sur une machine de test à part)
3) si le format n'a pas changé, ca repart immédiatement, si non on peut
espérer une erreur du SGBDR (et il faudra de toute façon vérifier à la
main, à coup de SELECT & co), et alors on refait une importation à partir
du dump.
1)a)ii) et 1)b) peuvent sembler superflus l'un par rapport à l'autre,
mais mieux vaut avoir les deux.
Quant à 1)a)i) ca peut paraitre inutile, mais quand on a commencé la mise
à jour, viré l'ancienne version, mis la nouvelle version du SGBDR (tout
dépend comment vous faites l'installation, mais via des ``paquets'', il
est rare de pouvoir faire cohabiter deux versions simultanément), et
qu'on s'aperçoit alors que la nouvelle version est totalement incapable
de lire les données de l'ancienne, et qu'on n'a pas fait de dump (ie on
n'a que les données en binaire), eh bien on est coincé, et là ca peut
être la panique si il s'agit de minimer le temps d'arrêt.
D'autre part, il ne faut pas se dire qu'on peut de toute façon toujours
récupérer les sources d'une vieille version: ce n'est pas toujours facile
de remettre la main dessus quand on en a besoin, et la version installée
a pu être compilé avec des options spécifiques qui influe sur le format
binaire final des données, donc il faut exactement la même compilation,
bref mieux vaut sauvegarder directement les binaires.
L'idéal étant bien entendu de tester la migration à part, avant de la
faire pour de vrai.
Les scripts d'installation du paquet postgresql debian sont
particulièrement astucieux à ce niveau et font automatiquement tout ce
que je décris plus haut. Ca me semble être la bonne façon de faire.
Et cela m'a déjà sauvé.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Wed, 02 Feb 2005 13:18:11 +0100, Rakotomandimby (R12y) Mihamina a écrit :
Le jour ou MySQL 4.1 passera en stable et que sur le serveur on devra passer au 4.1 (4.0 pour le moment), est ce que le dump (puis restauration de ce dump) est plus efficace que la copie physique (puis desarchivage tout court)?
Souvent, c'est la seule solution car le format interne change.
Après, comme dit Basile peut être que MySQL garantit que ca va bien se passer.
Mon conseil lors d'une telle migration 1) faire une sauvegarde a) du système de fichiers, avec i) tous les binaires et outils en rapport avec le SGBDR ii) tous les fichiers de données du SGBDR b) de la base via un dump 2) tenter la mise à jour (idéalement sur une machine de test à part) 3) si le format n'a pas changé, ca repart immédiatement, si non on peut espérer une erreur du SGBDR (et il faudra de toute façon vérifier à la main, à coup de SELECT & co), et alors on refait une importation à partir du dump.
1)a)ii) et 1)b) peuvent sembler superflus l'un par rapport à l'autre, mais mieux vaut avoir les deux. Quant à 1)a)i) ca peut paraitre inutile, mais quand on a commencé la mise à jour, viré l'ancienne version, mis la nouvelle version du SGBDR (tout dépend comment vous faites l'installation, mais via des ``paquets'', il est rare de pouvoir faire cohabiter deux versions simultanément), et qu'on s'aperçoit alors que la nouvelle version est totalement incapable de lire les données de l'ancienne, et qu'on n'a pas fait de dump (ie on n'a que les données en binaire), eh bien on est coincé, et là ca peut être la panique si il s'agit de minimer le temps d'arrêt. D'autre part, il ne faut pas se dire qu'on peut de toute façon toujours récupérer les sources d'une vieille version: ce n'est pas toujours facile de remettre la main dessus quand on en a besoin, et la version installée a pu être compilé avec des options spécifiques qui influe sur le format binaire final des données, donc il faut exactement la même compilation, bref mieux vaut sauvegarder directement les binaires.
L'idéal étant bien entendu de tester la migration à part, avant de la faire pour de vrai.
Les scripts d'installation du paquet postgresql debian sont particulièrement astucieux à ce niveau et font automatiquement tout ce que je décris plus haut. Ca me semble être la bonne façon de faire. Et cela m'a déjà sauvé.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
