Comment transferer des DB d'un serveur a un autre

no way

23/11/2018 à 19:10

--0000000000006aa5a8057b58deab
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello,
Possible de savoir quelle est ton archi actuelle ?
On Fri, Nov 23, 2018 at 6:35 PM ajh-valmer wrote:

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 ?

--0000000000006aa5a8057b58deab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="ltr">Hello,<div><br></div><div>Possible de savoir quelle est to n archi actuelle ?</div></div><br><div class="gmail_quote"><div dir="lt r">On Fri, Nov 23, 2018 at 6:35 PM ajh-valmer <<a href="mailto:ajh.val "></a>> wrote:<br></div><blockquote class ="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padd ing-left:1ex">On Friday 23 November 2018 15:11:31 Hugues MORIN wrote:<br>
> Bonjour a tous,<br>
> Je cherche une solution pour transferer plusieurs grosses bases de don nees<br>
> d'un serveur a un autre.<br>
> Ce sont des DB Mariadb et pour certaines, les tables contiennnent plus ieurs<br>
> millions d'enregistrements.<br>
<br>
Dis-je une bêtise ? :<br>
phpmyadmin ?<br>
<br>
</div>
--0000000000006aa5a8057b58deab--

Sébastien Dinot

23/11/2018 à 22:40

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 -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 '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
--
Sébastien Dinot,
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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@remote.example.com -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

--
Sébastien Dinot, sebastien.dinot@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Hugues MORIN

26/11/2018 à 13:10

--000000000000d9302a057b9012b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 ee.fr> a
écrit :

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. P lusieurs
millions d'enregistrements, cela ne réclame pas forcément beauc oup 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. Do mmage.
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'a vais à le faire,
pour ne pas exposer les bases, j'opterais sans doute pour un tunnel
SSH :
ssh -f -L 1111:localhost:3306 -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èr e
classique, on peut rediriger la sortie de mysqldump vers une connexion
SSH afin d'éviter l'écriture intermédiaire des donnée s sur le disque
local et de créer directement le fichier sur le serveur cible :
mysqldump -q database | ssh -C '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
--
Sébastien Dinot,
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passe r !

--000000000000d9302a057b9012b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Bo njour a tous <br></div><div><br></div><div><br></div><div>Merci pour vos re ponses :)<br></div><div><br></div><div>@Bernard: Non je ne peux pas changer de DB et passer sous postgesql. Cela me demanderai trop de travail<br></di v><div><br></div><div>@ajh-valmer: j'utilise beaucoup phpmyadmin mais j e n'ai jamais trouve comment faire cela.</div><div>En regardant ce mati n, je viens de vois qu'il y a un onglet "Replication", est ce a cela que tu penses?</div><div><br></div><div>@no way: Mon archi est asse z simple, j'ai un serveur dedie sous strech qui heberge des sites inter net, chacun ayant sa DB</div><div>Certains de ces DB contiennent 300/400 ta bles et certaines tables contiennnent plusieurs million d'enregistremen ts</div><div>J'envisage de changer de serveur mais vu le volume des don nees, je cherche une solution pour transferer toutes les DB en une seule fo is.</div><div><br></div><div>@Ph. Gras: je l'utilse beaucoup, c'est tres pratique phpmyadmin. Par contre a la derniere tentative d'un mysq ldump, j'ai eu quelques mauvaises surprises. <br></div><div>surement de s problemes de formats comme tu le dis. Dans mon cas c'est un peu inger able car je ne connais pas reellement le contenu des DB car un utilisateur peut tres bien utiliser un caractere que j'utilise comme delimiteur dan s un champs de la DB. De ce fait le mysqldump devient un peu complique , vo ir tres complique</div><br></div><div dir="ltr">@G2PC: merci, je garde ca sous le coude, meme si je connais, c'est un bon aide memoire ;-)</div> <div dir="ltr"><br></div><div dir="ltr">@Sébastien Dinot: Ce que j e 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<br></div><div>Je n'ai pas de referentiel pour savoir si c'est de grosse DB ou pas... mais po ur moi c'est deja enorme ;-)</div><div><br></div><div><br></div><div>Je vais me pencher sur l'idee du tunnel ssh sans passer par un fichier in termediaire ou avec redirection de la sortie de mysqldump.</div><div>Et sur la "replication" dans le phpmyadmin.</div><div><br></div><div><b r></div>Je vous tiens au courant, et je suis toujours ouvert de nouvelles s uggestions.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div >Merci pour votre aide<br></div><div>Cordialement</div><div>Hugues<br></div ><div dir="ltr"><div><br></div><div dir="ltr"><div><br></div><div><br>< /div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr ">Le ven. 23 nov. 2018 à 22:32, Sébastien Dinot <<a href="mailto:"></a>> a écrit :<br></div><blockquote class="gmail_quote" style="margi n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hugues MORIN a écrit :<br>
> Je cherche une solution pour transferer plusieurs grosses bases de<br>
> donnees d'un serveur a un autre.<br>
<br>
Je ne sais pas ce qu'est une « grosse » base de don nées. Plusieurs<br>
millions d'enregistrements, cela ne réclame pas forcément bea ucoup de<br>
place.<br>
<br>
> Je connais la solution du mysqldump mais quand il y a autant de<br>
> donnees, ce n'ai pas tres efficient. Lors de la derniere utilisati on<br>
> de ce procede sur une grosse DB, j'ai perdu des donnees et j'a i galere<br>
> a les reconstituer.<br>
<br>
C'est donc que le moteur utilisé n'était pas transactionn el. Dommage.<br>
<br>
> Est ce que vous avez ete deja confronter a ce genre de travail? Quelle <br>
> solutin avez vous retenu?<br>
<br>
Je n'ai jamais été confronté à ce besoin, mais si j 'avais à le faire,<br>
pour ne pas exposer les bases, j'opterais sans doute pour un tunnel<br>
SSH :<br>
<br>
ssh -f -L 1111:localhost:3306 <a href="mailto:" ta rget="_blank"></a> -N<br>
<br>
Ce faisant, le serveur MySQL distant devient accessible localement sur<br>
le port 1111 :<br>
<br>
mysql -h localhost -P 1111 database < database.sql<br>
<br>
Et du coup, on peut même éviter le passage par un fichier<br>
intermédiaire :<br>
<br>
mysqldump -q -h localhost -P 3306 database | mysql -h localhost -P 1111 dat abase<br>
<br>
Sinon, pour gagner un peu de temps, tout en procédant de manière< br>
classique, on peut rediriger la sortie de mysqldump vers une connexion<br>
SSH afin d'éviter l'écriture intermédiaire des donn ées sur le disque<br>
local et de créer directement le fichier sur le serveur cible :<b r>
<br>
mysqldump -q database | ssh -C 'cat > database.sq l'<br>
<br>
> Suffit-il de copier le repertoire contenant la DB<br>
> (/var/lib/mysql/nomdb dans mon cas) et redemarrer mysql pour que le<br >
> transfert soit effectif?<br>
<br>
Non, var il faut aussi dumper et recréer sur le serveur distant les<br >
informations globales stockées dans la base nommée « my sql » :<br>
<br>
mysqldump -q mysql > mysql.sql<br>
<br>
Sébastien<br>
<br>
-- <br>
Sébastien Dinot, <a href="mailto:" target=" _blank"></a><br>
<a href="http://sebastien.dinot.free.fr/" rel="noreferrer" target="_b lank">http://sebastien.dinot.free.fr/</a><br>
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !<br>
<br>
</div>
--000000000000d9302a057b9012b2--

--000000000000d9302a057b9012b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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@fr ee.fr> a
écrit :

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. P lusieurs
millions d'enregistrements, cela ne réclame pas forcément beauc oup 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. Do mmage.

> 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'a vais à le faire,
pour ne pas exposer les bases, j'opterais sans doute pour un tunnel
SSH :

ssh -f -L 1111:localhost:3306 user@remote.example.com -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èr e
classique, on peut rediriger la sortie de mysqldump vers une connexion
SSH afin d'éviter l'écriture intermédiaire des donnée s 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

--
Sébastien Dinot, sebastien.dinot@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passe r !

--000000000000d9302a057b9012b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Bo njour a tous <br></div><div><br></div><div><br></div><div>Merci pour vos re ponses :)<br></div><div><br></div><div>@Bernard: Non je ne peux pas changer de DB et passer sous postgesql. Cela me demanderai trop de travail<br></di v><div><br></div><div>@ajh-valmer: j'utilise beaucoup phpmyadmin mais j e n'ai jamais trouve comment faire cela.</div><div>En regardant ce mati n, je viens de vois qu'il y a un onglet "Replication", est ce a cela que tu penses?</div><div><br></div><div>@no way: Mon archi est asse z simple, j'ai un serveur dedie sous strech qui heberge des sites inter net, chacun ayant sa DB</div><div>Certains de ces DB contiennent 300/400 ta bles et certaines tables contiennnent plusieurs million d'enregistremen ts</div><div>J'envisage de changer de serveur mais vu le volume des don nees, je cherche une solution pour transferer toutes les DB en une seule fo is.</div><div><br></div><div>@Ph. Gras: je l'utilse beaucoup, c'est tres pratique phpmyadmin. Par contre a la derniere tentative d'un mysq ldump, j'ai eu quelques mauvaises surprises. <br></div><div>surement de s problemes de formats comme tu le dis. Dans mon cas c'est un peu inger able car je ne connais pas reellement le contenu des DB car un utilisateur peut tres bien utiliser un caractere que j'utilise comme delimiteur dan s un champs de la DB. De ce fait le mysqldump devient un peu complique , vo ir tres complique</div><br></div><div dir="ltr">@G2PC: merci, je garde ca sous le coude, meme si je connais, c'est un bon aide memoire ;-)</div> <div dir="ltr"><br></div><div dir="ltr">@Sébastien Dinot: Ce que j e 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<br></div><div>Je n'ai pas de referentiel pour savoir si c'est de grosse DB ou pas... mais po ur moi c'est deja enorme ;-)</div><div><br></div><div><br></div><div>Je vais me pencher sur l'idee du tunnel ssh sans passer par un fichier in termediaire ou avec redirection de la sortie de mysqldump.</div><div>Et sur la "replication" dans le phpmyadmin.</div><div><br></div><div><b r></div>Je vous tiens au courant, et je suis toujours ouvert de nouvelles s uggestions.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div >Merci pour votre aide<br></div><div>Cordialement</div><div>Hugues<br></div ><div dir="ltr"><div><br></div><div dir="ltr"><div><br></div><div><br>< /div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr ">Le ven. 23 nov. 2018 à 22:32, Sébastien Dinot <<a href="mailto:sebastien.dinot@free.fr">sebastien.dinot@free.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margi n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hugues MORIN a écrit :<br>
> Je cherche une solution pour transferer plusieurs grosses bases de<br>
> donnees d'un serveur a un autre.<br>
<br>
Je ne sais pas ce qu'est une « grosse » base de don nées. Plusieurs<br>
millions d'enregistrements, cela ne réclame pas forcément bea ucoup de<br>
place.<br>
<br>
> Je connais la solution du mysqldump mais quand il y a autant de<br>
> donnees, ce n'ai pas tres efficient. Lors de la derniere utilisati on<br>
> de ce procede sur une grosse DB, j'ai perdu des donnees et j'a i galere<br>
> a les reconstituer.<br>
<br>
C'est donc que le moteur utilisé n'était pas transactionn el. Dommage.<br>
<br>
> Est ce que vous avez ete deja confronter a ce genre de travail? Quelle <br>
> solutin avez vous retenu?<br>
<br>
Je n'ai jamais été confronté à ce besoin, mais si j 'avais à le faire,<br>
pour ne pas exposer les bases, j'opterais sans doute pour un tunnel<br>
SSH :<br>
<br>
ssh -f -L 1111:localhost:3306 <a href="mailto:user@remote.example.com" ta rget="_blank">user@remote.example.com</a> -N<br>
<br>
Ce faisant, le serveur MySQL distant devient accessible localement sur<br>
le port 1111 :<br>
<br>
mysql -h localhost -P 1111 database < database.sql<br>
<br>
Et du coup, on peut même éviter le passage par un fichier<br>
intermédiaire :<br>
<br>
mysqldump -q -h localhost -P 3306 database | mysql -h localhost -P 1111 dat abase<br>
<br>
Sinon, pour gagner un peu de temps, tout en procédant de manière< br>
classique, on peut rediriger la sortie de mysqldump vers une connexion<br>
SSH afin d'éviter l'écriture intermédiaire des donn ées sur le disque<br>
local et de créer directement le fichier sur le serveur cible :<b r>
<br>
mysqldump -q database | ssh -C user@remote-server 'cat > database.sq l'<br>
<br>
> Suffit-il de copier le repertoire contenant la DB<br>
> (/var/lib/mysql/nomdb dans mon cas) et redemarrer mysql pour que le<br >
> transfert soit effectif?<br>
<br>
Non, var il faut aussi dumper et recréer sur le serveur distant les<br >
informations globales stockées dans la base nommée « my sql » :<br>
<br>
mysqldump -q mysql > mysql.sql<br>
<br>
Sébastien<br>
<br>
-- <br>
Sébastien Dinot, <a href="mailto:sebastien.dinot@free.fr" target=" _blank">sebastien.dinot@free.fr</a><br>
<a href="http://sebastien.dinot.free.fr/" rel="noreferrer" target="_b lank">http://sebastien.dinot.free.fr/</a><br>
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !<br>
<br>
</blockquote></div>

--000000000000d9302a057b9012b2--

Vous avez filtré cet utilisateur ! Consultez son message

--000000000000d9302a057b9012b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 ee.fr> a
écrit :

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. P lusieurs
millions d'enregistrements, cela ne réclame pas forcément beauc oup 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. Do mmage.
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'a vais à le faire,
pour ne pas exposer les bases, j'opterais sans doute pour un tunnel
SSH :
ssh -f -L 1111:localhost:3306 -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èr e
classique, on peut rediriger la sortie de mysqldump vers une connexion
SSH afin d'éviter l'écriture intermédiaire des donnée s sur le disque
local et de créer directement le fichier sur le serveur cible :
mysqldump -q database | ssh -C '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
--
Sébastien Dinot,
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passe r !

--000000000000d9302a057b9012b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Bo njour a tous <br></div><div><br></div><div><br></div><div>Merci pour vos re ponses :)<br></div><div><br></div><div>@Bernard: Non je ne peux pas changer de DB et passer sous postgesql. Cela me demanderai trop de travail<br></di v><div><br></div><div>@ajh-valmer: j'utilise beaucoup phpmyadmin mais j e n'ai jamais trouve comment faire cela.</div><div>En regardant ce mati n, je viens de vois qu'il y a un onglet "Replication", est ce a cela que tu penses?</div><div><br></div><div>@no way: Mon archi est asse z simple, j'ai un serveur dedie sous strech qui heberge des sites inter net, chacun ayant sa DB</div><div>Certains de ces DB contiennent 300/400 ta bles et certaines tables contiennnent plusieurs million d'enregistremen ts</div><div>J'envisage de changer de serveur mais vu le volume des don nees, je cherche une solution pour transferer toutes les DB en une seule fo is.</div><div><br></div><div>@Ph. Gras: je l'utilse beaucoup, c'est tres pratique phpmyadmin. Par contre a la derniere tentative d'un mysq ldump, j'ai eu quelques mauvaises surprises. <br></div><div>surement de s problemes de formats comme tu le dis. Dans mon cas c'est un peu inger able car je ne connais pas reellement le contenu des DB car un utilisateur peut tres bien utiliser un caractere que j'utilise comme delimiteur dan s un champs de la DB. De ce fait le mysqldump devient un peu complique , vo ir tres complique</div><br></div><div dir="ltr">@G2PC: merci, je garde ca sous le coude, meme si je connais, c'est un bon aide memoire ;-)</div> <div dir="ltr"><br></div><div dir="ltr">@Sébastien Dinot: Ce que j e 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<br></div><div>Je n'ai pas de referentiel pour savoir si c'est de grosse DB ou pas... mais po ur moi c'est deja enorme ;-)</div><div><br></div><div><br></div><div>Je vais me pencher sur l'idee du tunnel ssh sans passer par un fichier in termediaire ou avec redirection de la sortie de mysqldump.</div><div>Et sur la "replication" dans le phpmyadmin.</div><div><br></div><div><b r></div>Je vous tiens au courant, et je suis toujours ouvert de nouvelles s uggestions.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div >Merci pour votre aide<br></div><div>Cordialement</div><div>Hugues<br></div ><div dir="ltr"><div><br></div><div dir="ltr"><div><br></div><div><br>< /div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr ">Le ven. 23 nov. 2018 à 22:32, Sébastien Dinot <<a href="mailto:"></a>> a écrit :<br></div><blockquote class="gmail_quote" style="margi n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hugues MORIN a écrit :<br>
> Je cherche une solution pour transferer plusieurs grosses bases de<br>
> donnees d'un serveur a un autre.<br>
<br>
Je ne sais pas ce qu'est une « grosse » base de don nées. Plusieurs<br>
millions d'enregistrements, cela ne réclame pas forcément bea ucoup de<br>
place.<br>
<br>
> Je connais la solution du mysqldump mais quand il y a autant de<br>
> donnees, ce n'ai pas tres efficient. Lors de la derniere utilisati on<br>
> de ce procede sur une grosse DB, j'ai perdu des donnees et j'a i galere<br>
> a les reconstituer.<br>
<br>
C'est donc que le moteur utilisé n'était pas transactionn el. Dommage.<br>
<br>
> Est ce que vous avez ete deja confronter a ce genre de travail? Quelle <br>
> solutin avez vous retenu?<br>
<br>
Je n'ai jamais été confronté à ce besoin, mais si j 'avais à le faire,<br>
pour ne pas exposer les bases, j'opterais sans doute pour un tunnel<br>
SSH :<br>
<br>
ssh -f -L 1111:localhost:3306 <a href="mailto:" ta rget="_blank"></a> -N<br>
<br>
Ce faisant, le serveur MySQL distant devient accessible localement sur<br>
le port 1111 :<br>
<br>
mysql -h localhost -P 1111 database < database.sql<br>
<br>
Et du coup, on peut même éviter le passage par un fichier<br>
intermédiaire :<br>
<br>
mysqldump -q -h localhost -P 3306 database | mysql -h localhost -P 1111 dat abase<br>
<br>
Sinon, pour gagner un peu de temps, tout en procédant de manière< br>
classique, on peut rediriger la sortie de mysqldump vers une connexion<br>
SSH afin d'éviter l'écriture intermédiaire des donn ées sur le disque<br>
local et de créer directement le fichier sur le serveur cible :<b r>
<br>
mysqldump -q database | ssh -C 'cat > database.sq l'<br>
<br>
> Suffit-il de copier le repertoire contenant la DB<br>
> (/var/lib/mysql/nomdb dans mon cas) et redemarrer mysql pour que le<br >
> transfert soit effectif?<br>
<br>
Non, var il faut aussi dumper et recréer sur le serveur distant les<br >
informations globales stockées dans la base nommée « my sql » :<br>
<br>
mysqldump -q mysql > mysql.sql<br>
<br>
Sébastien<br>
<br>
-- <br>
Sébastien Dinot, <a href="mailto:" target=" _blank"></a><br>
<a href="http://sebastien.dinot.free.fr/" rel="noreferrer" target="_b lank">http://sebastien.dinot.free.fr/</a><br>
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !<br>
<br>
</div>
--000000000000d9302a057b9012b2--

Daniel Caillibaud

29/11/2018 à 14:30

Bonjour,
J'arrive un peu tard mais j'ajoute quand même mon grain de sel ;-)
Le 23/11/18 à 15:11, Hugues MORIN 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 éventu ellement
modifier des fichiers de /etc/mysql (je pense au password du user
debian-syst-maint)
Évidemment, le sql destination doit être coupé pendant le tr ansfert
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 lo gs
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'envo yer sur le
réseau, c'est pas toujours le cas, surtout si c'est le même disqu e que
celui que tu lis).
Et avant de démarrer le serveur de destination, vérifier les droi ts sur les
fichiers (mais si c'est les mêmes users des deux cotés ça do it pas poser de
pb).
--
Daniel
Le respect de la démocratie veut que j'ai le dernier mot.
Georges Marchais (1973)

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@gmail.com> 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 éventu ellement
modifier des fichiers de /etc/mysql (je pense au password du user
debian-syst-maint)

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

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 lo gs
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'envo yer sur le
réseau, c'est pas toujours le cas, surtout si c'est le même disqu e que
celui que tu lis).

Et avant de démarrer le serveur de destination, vérifier les droi ts sur les
fichiers (mais si c'est les mêmes users des deux cotés ça do it pas poser de
pb).

--
Daniel

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

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,
J'arrive un peu tard mais j'ajoute quand même mon grain de sel ;-)
Le 23/11/18 à 15:11, Hugues MORIN 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 éventu ellement
modifier des fichiers de /etc/mysql (je pense au password du user
debian-syst-maint)
Évidemment, le sql destination doit être coupé pendant le tr ansfert
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 lo gs
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'envo yer sur le
réseau, c'est pas toujours le cas, surtout si c'est le même disqu e que
celui que tu lis).
Et avant de démarrer le serveur de destination, vérifier les droi ts sur les
fichiers (mais si c'est les mêmes users des deux cotés ça do it pas poser de
pb).
--
Daniel
Le respect de la démocratie veut que j'ai le dernier mot.
Georges Marchais (1973)

Pierre Chevalier

30/11/2018 à 14:10

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:

06/08/2007 21:55:14
temperature: 51 C
Je teste postgresql et mysql, pour comparer: ya pas photo! Avec les mêmes données:
mysql:
mysql> select count(id) from collars where id in (select id from collars group by id having count(id)>1) ;
+-----------+
| count(id) |
+-----------+
| 251 |
+-----------+
1 row in set (46.16 sec)
postgresql:
pierre=# timing
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!

https://image.slidesharecdn.com/presentationgeolllibrepostgeolfr-160531183107/95/prsentation-geolllibre-postgeol-23-638.jpg?cb64722795
À+
Pierre
--
Pierre Chevalier Mesté Duran 32100 Condom
Tél : 09 75 27 45 62 - 06 37 80 33 64
http://pierremariechevalier.free.fr/
Logiciels Libres dans le Gers: http://gnusquetaires.org/ <= 404 sur
un plateau

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:

06/08/2007 21:55:14
temperature: 51 C
Je teste postgresql et mysql, pour comparer: ya pas photo! Avec les mêmes données:
mysql:
mysql> select count(id) from collars where id in (select id from collars group by id having count(id)>1) ;
+-----------+
| count(id) |
+-----------+
| 251 |
+-----------+
1 row in set (46.16 sec)

postgresql:
pierre=# timing
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!

https://image.slidesharecdn.com/presentationgeolllibrepostgeolfr-160531183107/95/prsentation-geolllibre-postgeol-23-638.jpg?cb64722795

À+
Pierre
--
Pierre Chevalier Mesté Duran 32100 Condom
Tél : 09 75 27 45 62 - 06 37 80 33 64
http://pierremariechevalier.free.fr/
Logiciels Libres dans le Gers: http://gnusquetaires.org/ <= 404 sur
un plateau

Vous avez filtré cet utilisateur ! Consultez son message

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:

06/08/2007 21:55:14
temperature: 51 C
Je teste postgresql et mysql, pour comparer: ya pas photo! Avec les mêmes données:
mysql:
mysql> select count(id) from collars where id in (select id from collars group by id having count(id)>1) ;
+-----------+
| count(id) |
+-----------+
| 251 |
+-----------+
1 row in set (46.16 sec)
postgresql:
pierre=# timing
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!

https://image.slidesharecdn.com/presentationgeolllibrepostgeolfr-160531183107/95/prsentation-geolllibre-postgeol-23-638.jpg?cb64722795
À+
Pierre
--
Pierre Chevalier Mesté Duran 32100 Condom
Tél : 09 75 27 45 62 - 06 37 80 33 64
http://pierremariechevalier.free.fr/
Logiciels Libres dans le Gers: http://gnusquetaires.org/ <= 404 sur
un plateau

Pierre Chevalier

30/11/2018 à 14:20

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
--
Pierre Chevalier Mesté Duran 32100 Condom
Tél : 09 75 27 45 62 - 06 37 80 33 64
http://pierremariechevalier.free.fr/
Logiciels Libres dans le Gers: http://gnusquetaires.org/ <= 404 sur
un plateau

Comment transferer des DB d'un serveur a un autre

6 réponses

Veuillez sélectionner un problème