cerhu > linux.debian.user.french

Hugues MORIN (23/11/2018, 16h20)
Bonjour a tous,

Je cherche une solution pour transferer plusieurs grosses bases de donnees
d'un serveur a un autre.

Ce sont des DB Mariadb et pour certaines, les tables contiennnent plusieurs
millions d'enregistrements.

Je connais la solution du mysqldump mais quand il y a autant de donnees, ce
n'ai pas tres efficient. Lors de la derniere utilisation de ce procede sur
une grosse DB, j'ai perdu des donnees et j'ai galere a les reconstituer.
Et dans le cas qui m'occupe actuellement, je parle d'une bonne dizaine de
grosse DB, plus une meme quantite de petites (quelques milliers
d'enregistrements).

Est ce que vous avez ete deja confronter a ce genre de travail?
Quelle solutin avez vous retenu?

Suffit-il de copier le repertoire contenant la DB (/var/lib/mysql/nomdb
dans mon cas) et redemarrer mysql pour que le transfert soit effectif?

Cordialement
Hugues
Basile Starynkevitch (23/11/2018, 16h50)
On 11/23/18 3:11 PM, Hugues MORIN wrote:
> Bonjour a tous,
> donnees d'un serveur a un autre.
> Ce sont des DB Mariadb et pour certaines, les tables contiennnent
> plusieurs millions d'enregistrements.
> Je connais la solution du mysqldump mais quand il y a autant de
> donnees, ce n'ai pas tres efficient. Lors de la derniere utilisation
> de ce procede sur une grosse DB, j'ai perdu des donnees et j'ai galere
> a les reconstituer.


Pour moi (qui ne suis pas un administrateur de base de données)
mysqldump sur la base, pendant qu'elle n'est pas accédée et/ou modifié
par des programmes clients,  est le *procédé canonique* pour sauvegarder
er transférer une base de donnée.

Et la copie des fichiers sous /var/lib/mysql/nomdb est explicitement
documentée (j'ai la flemme de retrouver où) comme étant dangereuse et à
éviter, surtout quand le serveur mysqld tourne.

J'aimerais donc comprendre en détails dans quelles conditions tu as
perdu des données. Bien évidemment, /la base/ que tu mysqldump /ne doit
//*pas*//être utilisée/ par des applications pendant son dump.

Cordialement.
ajh-valmer (23/11/2018, 19h40)
On Friday 23 November 2018 15:11:31 Hugues MORIN wrote:
> Bonjour a tous,
> Je cherche une solution pour transferer plusieurs grosses bases de donnees
> d'un serveur a un autre.
> Ce sont des DB Mariadb et pour certaines, les tables contiennnent plusieurs
> millions d'enregistrements.


Dis-je une bêtise ? :
phpmyadmin ?
no way (23/11/2018, 20h10)
Hello,

Possible de savoir quelle est ton archi actuelle ?

On Fri, Nov 23, 2018 at 6:35 PM ajh-valmer <ajh.valmer> wrote:
[..]
Ph. Gras (23/11/2018, 20h20)
Salut la liste,

> On Friday 23 November 2018 15:11:31 Hugues MORIN wrote:
> Dis-je une bêtise ? :
> phpmyadmin ?


phpMyadmin est une application Web qui te permet de travailler sur tes bases de données :
les afficher dans un format agréablement lisible pour un humain, modifier les données ainsi
qu'importer ou exporter des tables ou des bases.

J'ai transféré un lot de bases de données récemment par SFTP, après un mysqldump, sans
aucun problème. Ceci dit, il convient d'exécuter le dump avec le bon format d'encodage.

Bonne soirée,

Ph. Gras
Sébastien Dinot (23/11/2018, 23h40)
Hugues MORIN a écrit :
> Je cherche une solution pour transferer plusieurs grosses bases de
> donnees d'un serveur a un autre.


Je ne sais pas ce qu'est une « grosse » base de données. Plusieurs
millions d'enregistrements, cela ne réclame pas forcément beaucoup de
place.

> Je connais la solution du mysqldump mais quand il y a autant de
> donnees, ce n'ai pas tres efficient. Lors de la derniere utilisation
> de ce procede sur une grosse DB, j'ai perdu des donnees et j'ai galere
> a les reconstituer.


C'est donc que le moteur utilisé n'était pas transactionnel. Dommage.

> Est ce que vous avez ete deja confronter a ce genre de travail? Quelle
> solutin avez vous retenu?


Je n'ai jamais été confronté à ce besoin, mais si j'avais à le faire,
pour ne pas exposer les bases, j'opterais sans doute pour un tunnel
SSH :

ssh -f -L 1111:localhost:3306 user -N

Ce faisant, le serveur MySQL distant devient accessible localement sur
le port 1111 :

mysql -h localhost -P 1111 database < database.sql

Et du coup, on peut même éviter le passage par un fichier
intermédiaire :

mysqldump -q -h localhost -P 3306 database | mysql -h localhost -P 1111 database

Sinon, pour gagner un peu de temps, tout en procédant de manière
classique, on peut rediriger la sortie de mysqldump vers une connexion
SSH afin d'éviter l'écriture intermédiaire des données sur le disque
local et de créer directement le fichier sur le serveur cible :

mysqldump -q database | ssh -C user@remote-server 'cat > database.sql'

> Suffit-il de copier le repertoire contenant la DB
> (/var/lib/mysql/nomdb dans mon cas) et redemarrer mysql pour que le
> transfert soit effectif?


Non, var il faut aussi dumper et recréer sur le serveur distant les
informations globales stockées dans la base nommée « mysql » :

mysqldump -q mysql > mysql.sql

Sébastien
Hugues MORIN (26/11/2018, 14h10)
Bonjour a tous

Merci pour vos reponses :)

@Bernard: Non je ne peux pas changer de DB et passer sous postgesql. Cela
me demanderai trop de travail

@ajh-valmer: j'utilise beaucoup phpmyadmin mais je n'ai jamais trouve
comment faire cela.
En regardant ce matin, je viens de vois qu'il y a un onglet "Replication",
est ce a cela que tu penses?

@no way: Mon archi est assez simple, j'ai un serveur dedie sous strech qui
heberge des sites internet, chacun ayant sa DB
Certains de ces DB contiennent 300/400 tables et certaines tables
contiennnent plusieurs million d'enregistrements
J'envisage de changer de serveur mais vu le volume des donnees, je cherche
une solution pour transferer toutes les DB en une seule fois.

@Ph. Gras: je l'utilse beaucoup, c'est tres pratique phpmyadmin. Par contre
a la derniere tentative d'un mysqldump, j'ai eu quelques mauvaises
surprises.
surement des problemes de formats comme tu le dis. Dans mon cas c'est un
peu ingerable car je ne connais pas reellement le contenu des DB car un
utilisateur peut tres bien utiliser un caractere que j'utilise comme
delimiteur dans un champs de la DB. De ce fait le mysqldump devient un peu
complique , voir tres complique

@G2PC: merci, je garde ca sous le coude, meme si je connais, c'est un bon
aide memoire ;-)

@Sébastien Dinot: Ce que je considere comme grosse DB, ce sont des DB qui
quand je fais un mysqldump j'obtient un fichier qui fait entre 1 et 2 Go
Je n'ai pas de referentiel pour savoir si c'est de grosse DB ou pas... mais
pour moi c'est deja enorme ;-)

Je vais me pencher sur l'idee du tunnel ssh sans passer par un fichier
intermediaire ou avec redirection de la sortie de mysqldump.
Et sur la "replication" dans le phpmyadmin.

Je vous tiens au courant, et je suis toujours ouvert de nouvelles
suggestions.

Merci pour votre aide
Cordialement
Hugues

Le ven. 23 nov. 2018 à 22:32, Sébastien Dinot <sebastien.dinot> a
écrit :
[..]
Ph. Gras (26/11/2018, 15h00)
Salut,

> @Ph. Gras: je l'utilse beaucoup, c'est tres pratique phpmyadmin. Par contre a la derniere tentative d'un mysqldump, j'ai eu quelques mauvaises surprises.


J'utilise aussi phpmyadmin, c'est effectivement très pratique lorsque tu souhaites intervenir sur une ligne en particulier.

Tu peux également exporter / importer des tables ou des bases, mais uniquement dans la mesure de la mémoire qui a
été allouée à mysql. Donc ça n'ira pas au-delà que quelques Mo, et de toute façon ton disque dur ne suivrait pas…

Normalement, tu dois pouvoir récupérer l'encodage de chaque base ou table avec phpmyadmin, et ensuite :
mysqldump -u root -p --default-character-set=utf8 database_name -r database_file.sql

> surement des problemes de formats comme tu le dis. Dans mon cas c'est un peu ingerable car je ne connais pas reellement le contenu des DB car un utilisateur peut tres bien utiliser un caractere que j'utilise comme delimiteur dans un champs de la DB. De ce fait le mysqldump devient un peu complique , voir très complique


Il n'y a pas de délimiteur avec MySQL, tu dois confondre avec CSV ; en revanche il en existe lorsque tu fais un Dump…

Sinon et sans garantie, regarde un peu ce que tu as dans /var/lib/mysql cela te surprendra sans doute :-)
Ceci dit, ça m'est déjà arrivé d'essayer de faire coïncider les fichiers, et je n'y suis pas arrivé.

Dans ton cas particulier et pour éviter d'effectuer et le dump que tu redoutes et l'opération casse-gueule évoquée juste
avant, voici comment je procéderais :

1). D'abord, une sauvegarde automatique incrémentale de toutes mes bases avec backup-manager :
# apt-cache search backup-manager
backup-manager - Outil de sauvegarde en ligne de commande
backup-manager-doc - documentation pour Backup Manager

[..]

Tu programmes ça la nuit ou à la pause déjeuner ;-)

2). Un transfert des fichiers SQL générés de serveur à serveur via SFTP.

3). Re-création de chaque utilisateur et table proprement avec MySQL :
mysql -u root -p
mysql> CREATE USER 'postfix'@'localhost' IDENTIFIED BY 'pwd';
mysql> GRANT USAGE ON * . * TO 'postfix'@'localhost' IDENTIFIED BY 'pwd';
mysql> CREATE DATABASE `postfix` ;
mysql> GRANT ALL PRIVILEGES ON `postfix` . * TO 'postfix'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> quit

4). Importation de chaque base proprement avec MySQL :
mysql -u root -p database_name_X < database_file_X.sql

Si tu en as beaucoup, tu peux mettre ça dans une boucle en bash…

Bon courage,

Ph. Gras
ajh-valmer (26/11/2018, 15h30)
On Monday 26 November 2018 13:55:45 Ph. Gras wrote:
> > je l'utilse beaucoup, c'est tres pratique phpmyadmin.
> > Par contre a la derniere tentative d'un mysqldump, j'ai eu quelques
> > mauvaises surprises.

> mysqldump -u root -p --default-character-set=utf8 database_name -r
> database_file.sql


phpmyadmin utilise cette même ligne commande,
mais en mode graphique, sans avoir besoin de la taper.
En plus, elle l'indique à titre d'infos et de vérification.
Hugues MORIN (26/11/2018, 15h50)
Salut

Normalement, tu dois pouvoir récupérer l'encodage de chaque base ou table
> avec phpmyadmin, et ensuite :
> mysqldump -u root -p --default-character-set=utf8 database_name -r
> database_file.sql


Je specifierais le parametre utf8 a l'avenir meme si je travaille toujours
en UTF8

> > surement des problemes de formats comme tu le dis. Dans mon cas c'est un

> peu ingerable car je ne connais pas reellement le contenu des DB car un
> utilisateur peut tres bien utiliser un caractere que j'utilise comme
> delimiteur dans un champs de la DB. De ce fait le mysqldump devient un peu
> complique , voir très complique
> Il n'y a pas de délimiteur avec MySQL, tu dois confondre avec CSV ; en
> revanche il en existe lorsque tu fais un Dump?


oui , c'est le delimiteur du dump dont je parlais

1). D'abord, une sauvegarde automatique incrémentale de toutes mes bases
> avec backup-manager :
> # apt-cache search backup-manager
> backup-manager - Outil de sauvegarde en ligne de commande
> backup-manager-doc - documentation pour Backup Manager
> merci :)

(Pour les archive de la liste, voir paragraphe 4.2.3 pour mysql:
[..])

2). Un transfert des fichiers SQL générés de serveur à serveur via SFTP.
> 3). Re-création de chaque utilisateur et table proprement avec MySQL:
> 4). Importation de chaque base proprement avec MySQL :
> mysql -u root -p database_name_X < database_file_X.sql
> Si tu en as beaucoup, tu peux mettre ça dans une boucle en bash?
> Bon courage,


Je vais en avoir besoin ... je crois ;-)

Cordialement
Hugues
Daniel Caillibaud (29/11/2018, 15h30)
Bonjour,

J'arrive un peu tard mais j'ajoute quand même mon grain de sel ;-)

Le 23/11/18 à 15:11, Hugues MORIN <morinh> a écrit :
> Suffit-il de copier le repertoire contenant la DB (/var/lib/mysql/nomdb
> dans mon cas) et redemarrer mysql pour que le transfert soit effectif?


Tu veux copier une seule base ou toutes ?

Pour une seule base ça marche pas à cause des journaux binaires, faut
passer par un dump.

Pour toutes, tu peux copier /var/lib/mysql/, mais :
- il faut que ce soit la même version de mariaDb des deux cotés
- il ne faut pas que le mariadb source tourne pendant cette copie
- si tu as de la réplication attention aux fichiers *.info et
mysqld-relay* dans ce dossier (mais si c'était le cas tu le sais
probablement)
- si tu as des logs binaires il faut les copier aussi, et vérifier que
c'est raccord avec la conf du mariadb de destination
- ça va copier aussi les droits, suivant ta conf tu devras éventuellement
modifier des fichiers de /etc/mysql (je pense au password du user
debian-syst-maint)

Évidemment, le sql destination doit être coupé pendant le transfert

Si tu ne veux pas couper le mariadb source pendant la copie, et que son
filesystem est sous lvm, le plus simple est de
- enchaîner rapidement
- commande sql `FLUSH TABLES WITH READ LOCK`
- snapshot du lv
- commande sql `UNLOCK TABLES`
- rsync snasphot => destination de /var/lib/mysql ET de ton dossier de logs
binaires (en ayant vérifié que la conf précise les même dossiers des
deux cotés)
- virer le snapshot source

Si tu n'as pas de lvm, en laissant tourner la source, tu peux tenter àune
heure de faible utilisation :
- rsync
- commande de lock
- rsync bis
- commande de unlock

Le 1er rsync copie le plus gros pour essayer de réduire la durée du 2e, si
le 2e est trop long tu risque d'avoir un serveur qui réponde plus car
toutes ses connexions sont en attente du unlock.

Pour réduire la durée du rsync tu peux aussi faire un rsync vers un dossier
local (si ça va plus vite d'écrire sur le disque local que d'envoyer sur le
réseau, c'est pas toujours le cas, surtout si c'est le même disque que
celui que tu lis).

Et avant de démarrer le serveur de destination, vérifier les droits sur les
fichiers (mais si c'est les mêmes users des deux cotés ça doit pas poser de
pb).
Pierre Chevalier (30/11/2018, 15h10)
Bonjour,

Le 26/11/2018 à 12:59, Hugues MORIN a écrit :
> @Bernard: Non je ne peux pas changer de DB et passer sous postgesql.
> Cela me demanderai trop de travail


Ah, il peut aisément se trouver des gens qui feraient ça en un
tournemain. Et des bénévoles qui feraient ça bien aussi.

Ça dépend beaucoup de ce qu'il y a dans la base mysql, s'il y a des vues
un peu compliquées et qui ne respectent pas les standards, ça peut être
délicat. Mais certainement pas infaisable.

D'une manière générale, depuis une dizaine d'années que travaille avec
PostgreSQL, vu la volumétrie de votre système, vu ce que vous en
attendez, je pense sincèrement que vous auriez intérêt à envisager de
passer à PostgreSQL, pour un grand nombre de raisons que je ne saurais
développer sans passer pour un prêcheur.

Parmi ces raisons (tout de même), la réplication multi-maîtres, des
solutions d'équilibrage de charge, des stratégies simples à mettre en
?uvre pour peaufiner les performances, même pour des cas d'usages
démentiels.
Bref/

Anecdote: voilà la raison pour laquelle j'ai choisi PostgreSQL par
rapport à MySQL, il y a une dizaine d'années de cela, au fond du Sahara:

[..]
> Chronométrage activé.
> pierre=# select count(id) from collars where id in (select id from collars group by id having count(id)>1) ;
> count
> -------
> 251
> (1 ligne)
> Temps : 15,906 ms
> Ordre de grandeur 1000 fois + rapide. Bon, mon choix est fait!


[..]

À+
Pierre
Pierre Chevalier (30/11/2018, 15h20)
Bonjour,

J'arrive encore plus tard et je rajoute encore du sel ;-D

Le 29/11/2018 à 14:28, Daniel Caillibaud a écrit :
> Bonjour,
> ...
> J'arrive un peu tard mais j'ajoute quand même mon grain de sel ;-)
> Et avant de démarrer le serveur de destination, vérifier les droits sur les
> fichiers (mais si c'est les mêmes users des deux cotés ça doit pas poser de
> pb).


Plein d'excellents conseils.
Avec un PostgreSQL, un pg_dumpall fait tout le boulot, ou presque. Trop
facile.

> --
> Daniel
> Le respect de la démocratie veut que j'ai le dernier mot.
> Georges Marchais (1973)


Un grand humoriste. Mais je suis étonné qu'il n'ait pas employé le
subjonctif; n'aurait-il pas plutôt écrit que "le respect de la
démocratie veut que j'ai*e* le dernier mot"?

À+
Pierre GrainDeSelDémocrate
Hugues MORIN (03/12/2018, 17h50)
Salut

@Daniel: Je veux copier toutes les DB
La procedure que tu me donnes ressemble beaucoup a ce a quoi je pensais
mais j'avais pas imaginer ca aussi complexe.
Il va falloir que je me documente sur quelques commandes que tu me fournis
(rsync car je n'ai jamais eu a l'utiliser)

@Pierre: oui effectivement ca serai surement plus efficace postgresql.
Je n'ai pas actuellement le temps de m'investir dans cette modification car
ce serai un travail trop colossal.
mais je garde cela sous le coude pour les futurs developpement.

Un grand merci pour ces info :D

Cordialement
Hugues

Le ven. 30 nov. 2018 à 14:15, Pierre Chevalier <pierre.chevalier1967>
a écrit :
[..]
Discussions similaires
comment transférer une licence d'une machine à une autre ?

Transférer tous les mails d'un serveur à un autre

Comment transferer un compte d'utilisateur d'un mac a un autre ?

Comment transférer un Serveur de licences TS d'un serveur à un aut


Fuseau horaire GMT +2. Il est actuellement 08h05. | Privacy Policy