Migration Mysql du serveur A

[nikot]

Plop plop plop !

Je suis alternant dans une boite qui vient de me confier mon projet de fin d'année (BTS IG).

Il va consister à déplacer des applications internes (en PHP) qui sont à l'heure actuelle stockées sur des serveurs réservés à nos clients. Comme on trouve que c'est vachement pas glop, je vais migrer donc les bases mysql et tout le toutim pour mettre ça sur un nouveau serveur tout beau. Mais autant installer une application PHP sur un linux me pose pas de soucis mais MIGRER la base et tout ce qui va bien, je n'ai jamais fait. Mes recherches Google ne donnent rien, tout le monde parle de migration d'un SGBD à l'autre ou d'un upgrade de mysql.

Donc les z'amis, je vous demande votre aide avec mes yeux pleins de larmes : Auriez-vous une doc, un tuto expliquant comment migrer propremment tout ça (en perdant le moins d'infos possible) et le plus rapidement possible évidemment ^^

Bonne journée !

Nikot

[Mephisto]

bah, récupérer la structure des tables (champs, types, ...), puis leur contenu

je suis plus sous postgre, mais mysql fonctionne +/- pareil

en gros, je l'aurais fait comme ça:

script=create_db.sql
for i in `psql -A -t -F' ' -c "\d" $db $user | grep ".* table pgsql$" | awk '{print "table"NR"="$2}'` #pour i, une table
do
eval `psql -A -t -F'		' -c "\d $i" $db $user | awk -F'\t' '{print "id"NR"="$1" type"NR"="$2" attributes"NR"="$3}'`
# le premier -F, c'est un tab (pour pas s'emmerder avec les espaces qu'enverra postgre)
r=1
cmd=
while :
do
	eval "id=\$id$r type=\$type$r attr=\$attributes$r"
	[ -z "$id" -o -z "$type" -o -z "$attr" ] && break
	[ -z "$cmd" ] && cmd="CREATE TABLE $i ('$id' $type," || cmd="$cmd, '$id' $type"
	r=`expr $r + 1`
done
cmd="$cmd);"
echo $cmd >>$script
done

bon, c'est très sommaire

faudrait trouver de quoi se resservir des attributes (default null, ..., PK/FK, ...)

et... à adapter sous mysql...

la suite, c'est du select * pour recopier le contenu

et, tu peux le faire avec SELECT "INSERT INTO matable VALUES (" || id || ", " || name || "," || .... || ");" FROM matable;

qui te génèrera le script à donner à la nouvelle DB

[nikot]

Bon en clair il faudrait que je récupère toute la structure des tables et que je fasse un petit script qui recopie lesdites tables sur ma nouvelle machine. Dans ton script, le contenu est aussi dupliqué ?

Et ton script je me doute que tu l'as fait avec une main dans l'slip mais t'aurais pas une doc un peu plus user friendly parce que ton script brut ne parle pas des masses ^^

Merci en tout cas d'avoir pris le temps de me répondre.

Je vais essayer de bien comprendre ton script ^^

[theocrite]

Pourquoi pas juste un mysqldump ?

[fabien29200]

Mysqldump est justement fait pour sauvegarder / restaurer une base mysql.

[Mephisto]

Bon en clair il faudrait que je récupère toute la structure des tables et que je fasse un petit script qui recopie lesdites tables sur ma nouvelle machine. Dans ton script, le contenu est aussi dupliqué ?

c'est le principe

dans le bout que j'ai fait, le contenu n'est pas dupliqué (seulement la structure est récupéré)

mais ce que je donne à la fin (le select qui renvoit des insert into) devrait dupliquer les données, dans un second temps.

Et ton script je me doute que tu l'as fait avec une main dans l'slip mais t'aurais pas une doc un peu plus user friendly parce que ton script brut ne parle pas des masses ^^

euh, doc, pas vraiment (enfin, google)

dans le principe, regarde comment est constitué la base (c'est avec DESCRIBE ma_base sous mysql, de mémoire)

et ensuite, pour chaque table, regarde quels sont les champs (DESCRIBE ma_table)

(pas très clair, boulot, je repasserai, courrage)

[AHP_Nils]

Mysqldump est justement fait pour sauvegarder / restaurer une base mysql.

+1, mysqldump sert à cela. Fais un dump par base, ça sera plus pratique. N'oublie pas les versions de MySQL depuis lesquelles tu fais tes exports, juste au cas où tu aurais des difficultés lors de l'importation sur le nouveau serveur.

[nikot]

Déjà merci à tous de prendre votre temps pour faire des réponses claires et détaillées.

J'ai compris ton script dans sa globalité mephisto mais je serais incapable de l'adapter à ma sauce avec mes connaissances du moment ^^

Concernant les autres qui me parlent de mysqldump, je vais me renseigner sur cet outil, je me doutais bien que des gentils môssieurs avaient fait une appli un peu plus user friendly car je dois pas être le seul a vouloir migrer des bases ^^

Avant de me plonger dans la doc, est-ce que les données utilisateurs mysql seront exportées elles aussi ?

Merci vraiment, ça met du baume au coeur d'arriver au boulot et de voir qu'on a un début de solution. Je paniquais un peu et merci à tous

et je tiens à remercier ma maison de disque sans qui je ne serais rien

Edit : Je viens de parler 2-3 minutes avec mon collègue, il m'a dit qu'il suffisait de prendre la table Mysql pour que les données users soient répliqués. Nous changerons de versions durant la migration (nous prendrons la derniere stabe pour CentOS) donc les données deviendront obsolètes

Merci encore ^^

[Amour]

Si MySQL est en même version, pour ma part je pioche tout le répertoire data directement, je m'embête pas

[theocrite]

Si tu peux migre d'une version à la même version, puis met à jour la version cible.

[nikot]

Re :)

Quel est l'avantage de migrer et de faire l'update ensuite ?

Merci

[theocrite]

Les scripts d'update sont prévus pour mettre à jour ta base si besoin est.

Alors que si tu écrase une base déjà à jour, tu risque de ne pas profiter des éventuelles améliorations voire même de casser quelque chose.

[nikot]

Merci bien l'ami

Glissons un peu dans le HS, j'ai la flemme d'ouvrir un autre fil ^^

Connaissez-vous un outil de réplication en temps réel pour CentOS, Fedora et assimilés ? A l'heure actuelle ça tourne en script le soir pour faire les saves (sur site distant) et j'aimerais bien moderniser le tout ^^

[theocrite]

Tu peux créer un cluser mysql. Tu crée un maître et un esclave ou deux maîtres.