Changement de serveur MYSQL - Cherche Conseil pour migration
9 réponses
Olive 64
Bonsoir,
Nous venons d'installer un nouveau serveur linux et nous voudrions profiter
de ce changement pour migrer nos bases mysql 3.23 qui se trouvent sur un
autre serveur vers notre notre nouveau serveur ou il y a mysql 4.1.
Mais probléme, la gestion des charset et des collations dans la version 4.1
m'empeche de faire une copie physique du rep /var/lib/mysql sur le nouveau
serveur, j'ai fait l'essai et ca m'a foutu un bordel au niveau des données
contenant des caractères accentués.
Je cherche donc un moyen de tranférer mes bases sur le nouveau serveur avec
les contraintes suivantes :
1) base origine mysql 3.23
2) nouvelle base mysql 4.1
3) grosses bases de données ( >=1Go )
4) la migration doit etre rapide ou en batch a cause de l'utilisation durant
la journée
J'ai essayé plusieurs logiciel d'administration de gestion de base mysql
mais aucun n'aient a tranférer les bases (plantages).
J'ai essayé egalement de faire des dump des bases mais plantage du client
mysql
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-03-02, Olive 64 wrote:
Bonsoir,
Nous venons d'installer un nouveau serveur linux et nous voudrions profiter de ce changement pour migrer nos bases mysql 3.23 qui se trouvent sur un autre serveur vers notre notre nouveau serveur ou il y a mysql 4.1. Mais probléme, la gestion des charset et des collations dans la version 4.1 m'empeche de faire une copie physique du rep /var/lib/mysql sur le nouveau serveur, j'ai fait l'essai et ca m'a foutu un bordel au niveau des données contenant des caractères accentués.
La copie physique (ou la sauvegarde physique) de /var/lib/mysql est en principe à éviter, surtout si mysqld tourne!
Je cherche donc un moyen de tranférer mes bases sur le nouveau serveur avec les contraintes suivantes : 1) base origine mysql 3.23 2) nouvelle base mysql 4.1 3) grosses bases de données ( >=1Go ) 4) la migration doit etre rapide ou en batch a cause de l'utilisation durant la journée
Pourquoi ne pas faire la classique commande (à lancer sur l'ancien serveur):
mysqldump --all-databases | ssh nouveauserveur mysql
on pourrait le faire base par base avec mysqldump labase | ssh nouveauserveur mysql labase
il faut préalablement créer chaque base par mysqladmin create labase
D'après mon estimation (par une grossière règle de trois à partir d'une base de quelques mégaoctets) une base de quelques gigaoctets se transfererait en quelques heures (et je pense même parfois moins d'une heure). Et je suis sûr qu'en essayant sur une base de 1 à 5Go vous pourrez correctement prévoir le temps que ça met pour le reste.
A mon avis, le plus robuste pour un tel transfert passe par l'execution de requêtes SQL sur le nouveau serveur (à partir d'un /var/lib/mysql initialisé vide de toute base), et ça revient à ce que je suggère. Je crois qu'un débit de 10Mo par seconde est possible (et c'est d'ailleurs le débit d'un Ethernet 100Mb saturé).
Sans être spécialiste de MySQL j'aimerais comprendre pourquoi les gens veulent éviter mysqldump etc.. alors que c'est explicitement documenté pour servir à ça!
Il serait peut-être possible de transferer plus rapidement -ca m'étonnerait un peu mais il serait bon de le mesurer - un contenu compressé par:
Si vous utiliser une méthode similaire à celle que je suggère, je serais interessé, et les autres lecteurs du forum aussi, par le temps réellement pris (et par le volume des bases transférées, et le débit du réseau).
Cordialement
-- 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-03-02, Olive 64 <oromeyer@wanadoo.fr> wrote:
Bonsoir,
Nous venons d'installer un nouveau serveur linux et nous voudrions profiter
de ce changement pour migrer nos bases mysql 3.23 qui se trouvent sur un
autre serveur vers notre notre nouveau serveur ou il y a mysql 4.1.
Mais probléme, la gestion des charset et des collations dans la version 4.1
m'empeche de faire une copie physique du rep /var/lib/mysql sur le nouveau
serveur, j'ai fait l'essai et ca m'a foutu un bordel au niveau des données
contenant des caractères accentués.
La copie physique (ou la sauvegarde physique) de /var/lib/mysql est
en principe à éviter, surtout si mysqld tourne!
Je cherche donc un moyen de tranférer mes bases sur le nouveau serveur avec
les contraintes suivantes :
1) base origine mysql 3.23
2) nouvelle base mysql 4.1
3) grosses bases de données ( >=1Go )
4) la migration doit etre rapide ou en batch a cause de l'utilisation durant
la journée
Pourquoi ne pas faire la classique commande (à lancer sur l'ancien
serveur):
mysqldump --all-databases | ssh nouveauserveur mysql
on pourrait le faire base par base avec
mysqldump labase | ssh nouveauserveur mysql labase
il faut préalablement créer chaque base par
mysqladmin create labase
D'après mon estimation (par une grossière règle de trois à partir
d'une base de quelques mégaoctets) une base de quelques gigaoctets se
transfererait en quelques heures (et je pense même parfois moins d'une
heure). Et je suis sûr qu'en essayant sur une base de 1 à 5Go vous
pourrez correctement prévoir le temps que ça met pour le reste.
A mon avis, le plus robuste pour un tel transfert passe par
l'execution de requêtes SQL sur le nouveau serveur (à partir d'un
/var/lib/mysql initialisé vide de toute base), et ça revient à ce que
je suggère. Je crois qu'un débit de 10Mo par seconde est possible (et
c'est d'ailleurs le débit d'un Ethernet 100Mb saturé).
Sans être spécialiste de MySQL j'aimerais comprendre pourquoi les gens
veulent éviter mysqldump etc.. alors que c'est explicitement documenté
pour servir à ça!
Il serait peut-être possible de transferer plus rapidement -ca
m'étonnerait un peu mais il serait bon de le mesurer - un contenu
compressé par:
Si vous utiliser une méthode similaire à celle que je suggère, je
serais interessé, et les autres lecteurs du forum aussi, par le temps
réellement pris (et par le volume des bases transférées, et le débit
du réseau).
Cordialement
--
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
Nous venons d'installer un nouveau serveur linux et nous voudrions profiter de ce changement pour migrer nos bases mysql 3.23 qui se trouvent sur un autre serveur vers notre notre nouveau serveur ou il y a mysql 4.1. Mais probléme, la gestion des charset et des collations dans la version 4.1 m'empeche de faire une copie physique du rep /var/lib/mysql sur le nouveau serveur, j'ai fait l'essai et ca m'a foutu un bordel au niveau des données contenant des caractères accentués.
La copie physique (ou la sauvegarde physique) de /var/lib/mysql est en principe à éviter, surtout si mysqld tourne!
Je cherche donc un moyen de tranférer mes bases sur le nouveau serveur avec les contraintes suivantes : 1) base origine mysql 3.23 2) nouvelle base mysql 4.1 3) grosses bases de données ( >=1Go ) 4) la migration doit etre rapide ou en batch a cause de l'utilisation durant la journée
Pourquoi ne pas faire la classique commande (à lancer sur l'ancien serveur):
mysqldump --all-databases | ssh nouveauserveur mysql
on pourrait le faire base par base avec mysqldump labase | ssh nouveauserveur mysql labase
il faut préalablement créer chaque base par mysqladmin create labase
D'après mon estimation (par une grossière règle de trois à partir d'une base de quelques mégaoctets) une base de quelques gigaoctets se transfererait en quelques heures (et je pense même parfois moins d'une heure). Et je suis sûr qu'en essayant sur une base de 1 à 5Go vous pourrez correctement prévoir le temps que ça met pour le reste.
A mon avis, le plus robuste pour un tel transfert passe par l'execution de requêtes SQL sur le nouveau serveur (à partir d'un /var/lib/mysql initialisé vide de toute base), et ça revient à ce que je suggère. Je crois qu'un débit de 10Mo par seconde est possible (et c'est d'ailleurs le débit d'un Ethernet 100Mb saturé).
Sans être spécialiste de MySQL j'aimerais comprendre pourquoi les gens veulent éviter mysqldump etc.. alors que c'est explicitement documenté pour servir à ça!
Il serait peut-être possible de transferer plus rapidement -ca m'étonnerait un peu mais il serait bon de le mesurer - un contenu compressé par:
Si vous utiliser une méthode similaire à celle que je suggère, je serais interessé, et les autres lecteurs du forum aussi, par le temps réellement pris (et par le volume des bases transférées, et le débit du réseau).
Cordialement
-- 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
Olive 64
Merci basile pour ton point de vue, je ne suis pas contre la commande :
mysqldump --all-databases | ssh nouveauserveur mysql
mais mon problème principal c'est le changement de version entre les 2 serveurs mysql. j'ai fait la manip que tu cites sur une base de test et je me suis retrouvé avec de data sans caractère spéciaux. as tu un retour d'expérience sur ce type de migration ?
merci
olive
Merci basile pour ton point de vue, je ne suis pas contre la commande :
mysqldump --all-databases | ssh nouveauserveur mysql
mais mon problème principal c'est le changement de version entre les 2
serveurs mysql. j'ai fait la manip que tu cites sur une base de test et je
me suis retrouvé avec de data sans caractère spéciaux.
as tu un retour d'expérience sur ce type de migration ?
Merci basile pour ton point de vue, je ne suis pas contre la commande :
mysqldump --all-databases | ssh nouveauserveur mysql
mais mon problème principal c'est le changement de version entre les 2 serveurs mysql. j'ai fait la manip que tu cites sur une base de test et je me suis retrouvé avec de data sans caractère spéciaux. as tu un retour d'expérience sur ce type de migration ?
merci
olive
Patrick Mevzek
Le Wed, 02 Mar 2005 22:04:48 +0100, Olive 64 a écrit :
Merci basile pour ton point de vue, je ne suis pas contre la commande :
mysqldump --all-databases | ssh nouveauserveur mysql
mais mon problème principal c'est le changement de version entre les 2 serveurs mysql. j'ai fait la manip que tu cites sur une base de test et je me suis retrouvé avec de data sans caractère spéciaux. as tu un retour d'expérience sur ce type de migration ?
Il y a probablement un encodage à changer à la volée, style passer d'isolatin1 à utf8. A vérifier dans vos deux versions de MySQL et selon vos données. Pour la conversion en elle-même vous pouvez utiliser iconv. Vous pouvez le mettre dans le pipe plus haut, mais je vous recommande plutôt: 1) mysqldump 2) vérification que le dump est bon 3) application de iconv dessus 4) vérification que le nouveau dump est bon 5) faire un scp (copie du dump) 6) exécuter l'importation sur le serveur distant
Même sans convertion (3 et 4 en moins donc), pour un gros volume de données, je vous recommande de décomposer, plutôt que de tout faire dans un seul flux. Cette dernière option fonctionne tout à fait mais c'est binaire: soit tout fonctionne (le dump, la copie, la réimportation) soit ca casse à n'importe quel niveau et il faut tout reprendre au début. En faisant progressivement, ca donne plus d'endroit où l'on peut vérifier que tout va bien et d'où on peut reprendre si l'endroit suivant se casse la gueule.
-- 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 Mar 2005 22:04:48 +0100, Olive 64 a écrit :
Merci basile pour ton point de vue, je ne suis pas contre la commande :
mysqldump --all-databases | ssh nouveauserveur mysql
mais mon problème principal c'est le changement de version entre les 2
serveurs mysql. j'ai fait la manip que tu cites sur une base de test et
je me suis retrouvé avec de data sans caractère spéciaux. as tu un
retour d'expérience sur ce type de migration ?
Il y a probablement un encodage à changer à la volée, style passer
d'isolatin1 à utf8. A vérifier dans vos deux versions de MySQL et selon
vos données.
Pour la conversion en elle-même vous pouvez utiliser iconv.
Vous pouvez le mettre dans le pipe plus haut, mais je vous recommande
plutôt:
1) mysqldump
2) vérification que le dump est bon
3) application de iconv dessus
4) vérification que le nouveau dump est bon
5) faire un scp (copie du dump)
6) exécuter l'importation sur le serveur distant
Même sans convertion (3 et 4 en moins donc), pour un gros volume de
données, je vous recommande de décomposer, plutôt que de tout faire dans
un seul flux. Cette dernière option fonctionne tout à fait mais c'est
binaire: soit tout fonctionne (le dump, la copie, la réimportation) soit
ca casse à n'importe quel niveau et il faut tout reprendre au début.
En faisant progressivement, ca donne plus d'endroit où l'on peut vérifier
que tout va bien et d'où on peut reprendre si l'endroit suivant se casse
la gueule.
--
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 Mar 2005 22:04:48 +0100, Olive 64 a écrit :
Merci basile pour ton point de vue, je ne suis pas contre la commande :
mysqldump --all-databases | ssh nouveauserveur mysql
mais mon problème principal c'est le changement de version entre les 2 serveurs mysql. j'ai fait la manip que tu cites sur une base de test et je me suis retrouvé avec de data sans caractère spéciaux. as tu un retour d'expérience sur ce type de migration ?
Il y a probablement un encodage à changer à la volée, style passer d'isolatin1 à utf8. A vérifier dans vos deux versions de MySQL et selon vos données. Pour la conversion en elle-même vous pouvez utiliser iconv. Vous pouvez le mettre dans le pipe plus haut, mais je vous recommande plutôt: 1) mysqldump 2) vérification que le dump est bon 3) application de iconv dessus 4) vérification que le nouveau dump est bon 5) faire un scp (copie du dump) 6) exécuter l'importation sur le serveur distant
Même sans convertion (3 et 4 en moins donc), pour un gros volume de données, je vous recommande de décomposer, plutôt que de tout faire dans un seul flux. Cette dernière option fonctionne tout à fait mais c'est binaire: soit tout fonctionne (le dump, la copie, la réimportation) soit ca casse à n'importe quel niveau et il faut tout reprendre au début. En faisant progressivement, ca donne plus d'endroit où l'on peut vérifier que tout va bien et d'où on peut reprendre si l'endroit suivant se casse la gueule.
-- 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>
Patrick Mevzek
Le Wed, 02 Mar 2005 21:38:05 +0100, Basile Starynkevitch [news] a écrit :
Mais probléme, la gestion des charset et des collations dans la version 4.1 m'empeche de faire une copie physique du rep /var/lib/mysql sur le nouveau serveur, j'ai fait l'essai et ca m'a foutu un bordel au niveau des données contenant des caractères accentués.
La copie physique (ou la sauvegarde physique) de /var/lib/mysql est en principe à éviter, surtout si mysqld tourne!
Pour les archives, et comme on l'a dit dans d'autres threads: en toute généralité (ie tout SGBDR confondu) il ne faut *PAS* toucher aux fichiers utilisés directement par le SGBDR, surtout si ce dernier tourne.
Comme toute règle générale, elle admet des exceptions (cf autres threads pour les détails), mais ces exceptions sont à réserver : 1) aux utilisateurs avertis 2) aux utilisateurs qui ont lu la documentation du logiciel et qui y auront lu que cette possibilité existe bien (pour la sauvegarde pendant que le SGBDR tourne) ou qui auront compris toutes les conséquences, et qui auront donc _aussi_ copié les binaires+bibliothèques de ``l'ancienne'' version.
-- 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 Mar 2005 21:38:05 +0100, Basile Starynkevitch [news] a écrit :
Mais probléme, la gestion des charset et des collations
dans la version 4.1 m'empeche de faire une copie physique du rep
/var/lib/mysql sur le nouveau serveur, j'ai fait l'essai et ca m'a
foutu un bordel au niveau des données contenant des caractères
accentués.
La copie physique (ou la sauvegarde physique) de /var/lib/mysql est
en principe à éviter, surtout si mysqld tourne!
Pour les archives, et comme on l'a dit dans d'autres threads:
en toute généralité (ie tout SGBDR confondu) il ne faut *PAS* toucher aux
fichiers utilisés directement par le SGBDR, surtout si ce dernier tourne.
Comme toute règle générale, elle admet des exceptions (cf autres threads
pour les détails), mais ces exceptions sont à réserver :
1) aux utilisateurs avertis
2) aux utilisateurs qui ont lu la documentation du logiciel et qui y
auront lu que cette possibilité existe bien (pour la sauvegarde pendant
que le SGBDR tourne) ou qui auront compris toutes les conséquences, et
qui auront donc _aussi_ copié les binaires+bibliothèques de
``l'ancienne'' version.
--
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 Mar 2005 21:38:05 +0100, Basile Starynkevitch [news] a écrit :
Mais probléme, la gestion des charset et des collations dans la version 4.1 m'empeche de faire une copie physique du rep /var/lib/mysql sur le nouveau serveur, j'ai fait l'essai et ca m'a foutu un bordel au niveau des données contenant des caractères accentués.
La copie physique (ou la sauvegarde physique) de /var/lib/mysql est en principe à éviter, surtout si mysqld tourne!
Pour les archives, et comme on l'a dit dans d'autres threads: en toute généralité (ie tout SGBDR confondu) il ne faut *PAS* toucher aux fichiers utilisés directement par le SGBDR, surtout si ce dernier tourne.
Comme toute règle générale, elle admet des exceptions (cf autres threads pour les détails), mais ces exceptions sont à réserver : 1) aux utilisateurs avertis 2) aux utilisateurs qui ont lu la documentation du logiciel et qui y auront lu que cette possibilité existe bien (pour la sauvegarde pendant que le SGBDR tourne) ou qui auront compris toutes les conséquences, et qui auront donc _aussi_ copié les binaires+bibliothèques de ``l'ancienne'' version.
-- 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>
Rakotomandimby (R12y) Mihamina
( Thu, 03 Mar 2005 00:28:22 +0100 ) Patrick Mevzek :
6) exécuter l'importation sur le serveur distant
Je suis passé au centre de documentation cet apres-midi, mais un gugus avait emprunté le bouquin que j'avais repéré qui décrivait les opérations d'importation.
pour mysqldump on est OK en théorie. maintenant pour restaurer, c'est quoi? j'ai vu ici (http://dev.mysql.com/doc/mysql/fr/crash-recovery.html) qu'onparle de myisamchk. c'est lui le copain de mysqldump ?
-- 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)
( Thu, 03 Mar 2005 00:28:22 +0100 ) Patrick Mevzek :
6) exécuter l'importation sur le serveur distant
Je suis passé au centre de documentation cet apres-midi, mais un gugus
avait emprunté le bouquin que j'avais repéré qui décrivait les
opérations d'importation.
pour mysqldump on est OK en théorie.
maintenant pour restaurer, c'est quoi? j'ai vu ici
(http://dev.mysql.com/doc/mysql/fr/crash-recovery.html) qu'onparle de
myisamchk. c'est lui le copain de mysqldump ?
--
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)
( Thu, 03 Mar 2005 00:28:22 +0100 ) Patrick Mevzek :
6) exécuter l'importation sur le serveur distant
Je suis passé au centre de documentation cet apres-midi, mais un gugus avait emprunté le bouquin que j'avais repéré qui décrivait les opérations d'importation.
pour mysqldump on est OK en théorie. maintenant pour restaurer, c'est quoi? j'ai vu ici (http://dev.mysql.com/doc/mysql/fr/crash-recovery.html) qu'onparle de myisamchk. c'est lui le copain de mysqldump ?
-- 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)
loufoque
Patrick Mevzek a dit le 03/03/2005 à 00:28:
Il y a probablement un encodage à changer à la volée, style passer d'isolatin1 à utf8. A vérifier dans vos deux versions de MySQL et selon vos données.
À priori, il suffit d'ajouter une requête SET NAMES au début du dump. Encore plus simple, configurer mysql4.1 sur le nouveau serveur pour qu'il fonctionne avec iso-8859-1 par défaut.
Patrick Mevzek a dit le 03/03/2005 à 00:28:
Il y a probablement un encodage à changer à la volée, style passer
d'isolatin1 à utf8. A vérifier dans vos deux versions de MySQL et selon
vos données.
À priori, il suffit d'ajouter une requête SET NAMES au début du dump.
Encore plus simple, configurer mysql4.1 sur le nouveau serveur pour
qu'il fonctionne avec iso-8859-1 par défaut.
Il y a probablement un encodage à changer à la volée, style passer d'isolatin1 à utf8. A vérifier dans vos deux versions de MySQL et selon vos données.
À priori, il suffit d'ajouter une requête SET NAMES au début du dump. Encore plus simple, configurer mysql4.1 sur le nouveau serveur pour qu'il fonctionne avec iso-8859-1 par défaut.
Patrick Mevzek
Le Thu, 03 Mar 2005 01:24:19 +0100, loufoque a écrit :
À priori, il suffit d'ajouter une requête SET NAMES au début du dump. Encore plus simple, configurer mysql4.1 sur le nouveau serveur pour qu'il fonctionne avec iso-8859-1 par défaut.
Pour des nouveaux développements, mieux vaut partir avec Unicode.
-- 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 Thu, 03 Mar 2005 01:24:19 +0100, loufoque a écrit :
À priori, il suffit d'ajouter une requête SET NAMES au début du dump.
Encore plus simple, configurer mysql4.1 sur le nouveau serveur pour
qu'il fonctionne avec iso-8859-1 par défaut.
Pour des nouveaux développements, mieux vaut partir avec Unicode.
--
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 Thu, 03 Mar 2005 01:24:19 +0100, loufoque a écrit :
À priori, il suffit d'ajouter une requête SET NAMES au début du dump. Encore plus simple, configurer mysql4.1 sur le nouveau serveur pour qu'il fonctionne avec iso-8859-1 par défaut.
Pour des nouveaux développements, mieux vaut partir avec Unicode.
-- 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>
Patrick Mevzek
Le Thu, 03 Mar 2005 01:04:35 +0100, Rakotomandimby (R12y) Mihamina a écrit :
6) exécuter l'importation sur le serveur distant
Je suis passé au centre de documentation cet apres-midi, mais un gugus avait emprunté le bouquin que j'avais repéré qui décrivait les opérations d'importation.
A priori, le but d'une exportation c'est d'obtenir un fichier texte avec dedans des lignes du style: CREATE TABLE ... INSERT INTO t ...
Bref, du SQL qu'on peut injecter dans n'importe quel SGBDR via un outil en ligne de commande (mysql, psql, etc...)
On peut parfois exporter aussi dans d'autres formats et/ou avec une compression, mais il y a un risque de générer un dump qui ne pourra alors être relu que par le même SGBDR, voire la même version. Exporter en texte les requêtes SQL, ca prend de la place, mais c'est sûr.
maintenant pour restaurer, c'est quoi? j'ai vu ici (http://dev.mysql.com/doc/mysql/fr/crash-recovery.html) qu'onparle de myisamchk. c'est lui le copain de mysqldump ?
Vous n'êtes pas dans une situation de crash. myisamchk c'est pour remettre d'aplomb des bases qui font la gueule, rien à voir avec une importation donc.
-- 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 Thu, 03 Mar 2005 01:04:35 +0100, Rakotomandimby (R12y) Mihamina a écrit
:
6) exécuter l'importation sur le serveur distant
Je suis passé au centre de documentation cet apres-midi, mais un gugus
avait emprunté le bouquin que j'avais repéré qui décrivait les
opérations d'importation.
A priori, le but d'une exportation c'est d'obtenir un fichier texte avec
dedans des lignes du style:
CREATE TABLE ...
INSERT INTO t ...
Bref, du SQL qu'on peut injecter dans n'importe quel SGBDR via un outil
en ligne de commande (mysql, psql, etc...)
On peut parfois exporter aussi dans d'autres formats et/ou avec une
compression, mais il y a un risque de générer un dump qui ne pourra alors
être relu que par le même SGBDR, voire la même version.
Exporter en texte les requêtes SQL, ca prend de la place, mais c'est sûr.
maintenant pour restaurer, c'est quoi? j'ai vu ici
(http://dev.mysql.com/doc/mysql/fr/crash-recovery.html) qu'onparle de
myisamchk. c'est lui le copain de mysqldump ?
Vous n'êtes pas dans une situation de crash.
myisamchk c'est pour remettre d'aplomb des bases qui font la gueule, rien
à voir avec une importation donc.
--
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 Thu, 03 Mar 2005 01:04:35 +0100, Rakotomandimby (R12y) Mihamina a écrit :
6) exécuter l'importation sur le serveur distant
Je suis passé au centre de documentation cet apres-midi, mais un gugus avait emprunté le bouquin que j'avais repéré qui décrivait les opérations d'importation.
A priori, le but d'une exportation c'est d'obtenir un fichier texte avec dedans des lignes du style: CREATE TABLE ... INSERT INTO t ...
Bref, du SQL qu'on peut injecter dans n'importe quel SGBDR via un outil en ligne de commande (mysql, psql, etc...)
On peut parfois exporter aussi dans d'autres formats et/ou avec une compression, mais il y a un risque de générer un dump qui ne pourra alors être relu que par le même SGBDR, voire la même version. Exporter en texte les requêtes SQL, ca prend de la place, mais c'est sûr.
maintenant pour restaurer, c'est quoi? j'ai vu ici (http://dev.mysql.com/doc/mysql/fr/crash-recovery.html) qu'onparle de myisamchk. c'est lui le copain de mysqldump ?
Vous n'êtes pas dans une situation de crash. myisamchk c'est pour remettre d'aplomb des bases qui font la gueule, rien à voir avec une importation donc.
-- 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>
loufoque
Patrick Mevzek a dit le 03/03/2005 à 14:37:
Pour des nouveaux développements, mieux vaut partir avec Unicode.
Si les données d'entrée sont en iso-8859-1, il suffit d'informer le sgbd d'utiliser iso-8859-1 pour la connexion. Après c'est totalement indépendant du charset utilisé pour le stockage, il pratique automatiquement une conversion. C'est là tout l'intérêt d'un SGBD qui gère les encodages.
Patrick Mevzek a dit le 03/03/2005 à 14:37:
Pour des nouveaux développements, mieux vaut partir avec Unicode.
Si les données d'entrée sont en iso-8859-1, il suffit d'informer le sgbd
d'utiliser iso-8859-1 pour la connexion.
Après c'est totalement indépendant du charset utilisé pour le stockage,
il pratique automatiquement une conversion. C'est là tout l'intérêt d'un
SGBD qui gère les encodages.
Pour des nouveaux développements, mieux vaut partir avec Unicode.
Si les données d'entrée sont en iso-8859-1, il suffit d'informer le sgbd d'utiliser iso-8859-1 pour la connexion. Après c'est totalement indépendant du charset utilisé pour le stockage, il pratique automatiquement une conversion. C'est là tout l'intérêt d'un SGBD qui gère les encodages.
