Comment puis-je déplacer une base de données d'un serveur à un autre?


136

Comment puis-je déplacer des tables MySQL d'un serveur physique à un autre?

Tels que ce scénario exact: J'ai un serveur MySQL qui utilise la table innodb et est d'environ 20 Go.

Je souhaite le transférer sur un nouveau serveur, quel est le moyen le plus efficace de le faire?


4
J'utiliserais xtrabackup percona.com/docs/wiki/. C'est un peu comme si on le copiait, mais vous pouvez laisser le serveur en marche et en supposant que vous utilisiez principalement des tables innodb (ce que vous avez dit avoir), vous pouvez le considérer comme "chaud". sauvegarde aussi bien.
Jonathan

Je ne profite pas des autres personnes utilisant cet outil. C'est gratuit / open-source et même s'il a été créé par une entreprise, il est assez facile à utiliser pour que vous n'ayez pas à envisager d'acheter une assistance auprès de cette entreprise.
Jonathan

Réponses:


80

Ma méthode préférée consiste à diriger une commande sqldump vers une commande sql. Vous pouvez faire toutes les bases de données ou une spécifique. Donc, par exemple,

mysqldump -uuser -ppassword myDatabase | mysql -hremoteserver -uremoteuser -premoteserverpassword 

Vous pouvez faire toutes les bases de données avec

mysqldump --all-databases -uuser -ppassword | mysql -hremoteserver -uremoteuser -premoteserver 

Le seul problème est que la base de données est trop grosse et que le tuyau se ferme. Dans ce cas, vous pouvez utiliser table par table ou l’une des méthodes mentionnées ci-dessous.


4
Conseil: Si aucune des bases de données n'autorise les connexions distantes, effectuez un pipeline netcat.
Bart van Heukelom

1
Pour que cela fonctionne pour moi, j'ai dû créer une base de données vide portant le même nom sur le serveur distant, puis ajouter le nom de cette base de données à la fin de la commande.
Zugwalt

1
C'est élégant, mais sans compression à peine assez rapide pour une base de données de 20 Go.
Daddy32

Cette solution n'est valable que pour un réseau entièrement contrôlé (si et seulement si sur un réseau privé sécurisé, lisez: pas Internet)! Mais solution rapide et facile!
jeudi

C'est rapide comme l'éclair! Mais ce que @Zugwalt a dit était vrai pour moi aussi. La commande ne fonctionnait pas avant la création de la base de données (vide). Le nom de la base de données a été ajouté à la fin de la commande.
Skeets

65

J'ai récemment déplacé une base de données de 30 Go avec la stratégie suivante:

Ancien serveur

  • Arrêtez le serveur mysql
  • Copier le contenu de datadir vers un autre emplacement sur le disque ( ~/mysqldata/*)
  • Redémarrez le serveur mysql (le temps d'arrêt était de 10 à 15 minutes)
  • compresser les données ( tar -czvf mysqldata.tar.gz ~/mysqldata)
  • copier le fichier compressé sur le nouveau serveur

Nouveau serveur

  • installez mysql (ne commencez pas)
  • décompresser le fichier compressé ( tar -xzvf mysqldata.tar.gz)
  • déplacer le contenu de mysqldata vers le datadir
  • Assurez-vous que votre innodb_log_file_size est identique sur le nouveau serveur, sinon, ne copiez pas les anciens fichiers de log ( mysql les générera )
  • Démarrer mysql

1
Ignore la copie après compression / décompression. Diffusez le fichier tar sur le réseau à l'aide de ssh, ou (si et seulement si, sur un réseau privé sécurisé, n'utilisez pas Internet), utilisez netcat pour éviter la surcharge de cryptage. De plus, si sur un réseau local ignore le gzipping, si vous avez un tuyau réseau rapide, vous trouverez le transfert goulot d'étranglement sur un noyau
indexé

Cela fonctionne à la fois pour innodb et myisam? En outre, les utilisateurs de MySQL sont dans datadir également?
giorgio79

2
@ giorgio79 bien sûr, aussi longtemps que vous déplacez les fichiers ibdata. Par défaut, ceux-ci sont dans le datadir. Les utilisateurs de MySQL sont stockés dans le dossier mysql dans un espace de table utilisateur.
Derek Downey

2
Cette procédure fonctionnera-t-elle pour passer de Windows à Linux?
ypercubeᵀᴹ

2
@ TypoCubeᵀᴹ désolé de prendre plus de deux ans pour répondre, mais cela m'aurait aidé si quelqu'un avait dit définitivement: "Oui, cela fonctionne de Windows à Linux". Dans mon cas, je suis passé de Windows Server 2012 R2 à Cent OS (Red Hat 4.8.5-11) . La version spécifique de MySQL était Maria DB 10.1 . Comme prescrit, j’ai arrêté les deux services mysql, rsyncé le répertoire de données et au démarrage du service mysql sur le nouveau serveur, toutes les bases de données, tables de base de données et utilisateurs de la base de données étaient intacts.
WEBjuju

30

Selon le Guide d’étude de la certification MySQL 5.0 , chapitre 32, section 32.3.4, pages 456, 457 décrivent les conditions de la portabilité binaire, qui permettent de dégager les éléments suivants:

La portabilité binaire est importante si vous souhaitez effectuer une sauvegarde binaire effectuée sur un ordinateur et l'utiliser sur un autre ordinateur doté d'une architecture différente. Par exemple, utiliser une sauvegarde binaire est un moyen de copier des bases de données d’un serveur MySQL à un autre.

Pour MyISAM, la portabilité binaire signifie que vous pouvez copier directement les fichiers d'une table MyISAM d'un serveur MySQL à un autre sur un autre ordinateur et que le second serveur pourra accéder à la table.

Pour InnoDB, la portabilité binaire signifie que vous pouvez copier directement les fichiers de l’espace table d’un serveur MySQL d’une machine à une autre sur une autre machine. Le second serveur pourra accéder à l’espace table. Par défaut, toutes les tables InnoDB gérées par un serveur sont stockées ensemble dans l'espace de tables. La portabilité de l'espace de tables dépend donc du fait que toutes les tables InnoDB sont portables ou non. Si même une table n'est pas portable, ni le tablespace.

Les tables MyISAM et les tablespaces InnoDB sont portables binaires d'un hôte à un autre si deux conditions sont remplies:

  • Les deux machines doivent utiliser une arithmétique entière à deux complément
  • Les deux machines doivent utiliser le format à virgule flottante IEEE ou les tables ne doivent contenir aucune colonne à virgule flottante (FLOAT ou DOUBLE).

En pratique, ces deux conditions posent peu de restrictions. L'arithmétique des entiers à deux complémentaires et le format à virgule flottante IEEE sont la norme sur le matériel moderne. Une troisième condition pour la portabilité binaire InnoDB est l'utilisation de noms minuscules pour les tables et les bases de données. En effet, InnoDB stocke ces noms en interne (dans son dictionnaire de données) en minuscules sous Windows. L'utilisation de noms en minuscules permet la portabilité binaire entre Windows et Unix. Pour forcer l'utilisation de noms en minuscules, vous pouvez insérer les lignes suivantes dans un fichier d'options:

[mysqld]
lower_case_table_names=1

Si vous configurez InnoDB pour utiliser des espaces de table par table, les conditions de portabilité binaire sont également étendues pour inclure les fichiers .ibd des tables InnoDB. (Les conditions pour les espaces de table partagés sont toujours applicables car elles contiennent le dictionnaire de données qui stocke des informations sur toutes les tables InnoDB.)

Si les conditions relatives à la portabilité binaire ne sont pas remplies, vous pouvez copier les tables MyISAM ou InnoDB d'un serveur à un autre en les déchargeant au format de texte (par exemple, avec mysqldump) et en les rechargeant sur le serveur de destination.

Il existe deux moyens principaux, basés sur le moteur de stockage, de déplacer des tables individuelles.

Pour l'exemple donné, supposons ce qui suit:

  1. datadir est / var / lib / mysql
  2. base de données appelée mydb
  3. table mydb base de données appelée MyTable .

Tables MyISAM

Si mydb.mytable utilise le moteur de stockage MyISAM, la table sera matérialisée par trois fichiers distincts.

  1. /var/lib/mysql/mydb/mytable.frm (fichier .frm)
  2. /var/lib/mysql/mydb/mytable.MYD (fichier .MYD)
  3. /var/lib/mysql/mydb/mytable.MYI (fichier .MYI)

Le .frm contient la structure de la table
Le .MYD contient les données de la table
Le .MYI contient la page d'index de la table

Ces fichiers sont utilisés de manière interdépendante pour représenter la table d'un point de vue logique dans mysql. Étant donné que ces fichiers ne sont plus associés logiquement, vous pouvez migrer une table d'un serveur de base de données à un autre. Vous pouvez même y accéder depuis un serveur Windows vers un serveur Linux ou un MacOS. Bien sûr, vous pouvez éteindre mysql et copier les 3 fichiers de la table. Vous pouvez exécuter ce qui suit:

LOCK TABLES mydb.mytable READ;
SELECT SLEEP(86400);
UNLOCK TABLES;

dans une session SSH de tenir la table en lecture seule et de la verrouiller pendant 24 heures. Une seconde plus tard, effectuez la copie dans une autre session ssh. Ensuite, tuez la session mysql avec le verrou 24 heures. Vous n'avez pas besoin d'attendre 24 heures.

Tables InnoDB

Sur la base de la citation susmentionnée du livre de certification, de nombreux facteurs régissent la sauvegarde d'une table InnoDB spécifique. Par souci de simplicité, de clarté et de brièveté, effectuez simplement un mysqldump de la table souhaitée en utilisant les paramètres --single-transaction pour obtenir un dump parfait de la table à un instant précis. Inutile de vous familiariser avec la sémantique InnoDB si vous voulez juste une table. Vous pouvez recharger ce fichier de dump sur n’importe quel serveur MySQL de votre choix.

Depuis que deux questions ont été fusionnées ici (jcolebrand): EDIT

Si vous êtes prêt à vivre avec des performances de base de données lentes, vous pouvez effectuer une série de rsyncs de l’ancien serveur (ServerA) sur le nouveau serveur (ServerB) même si mysql est toujours en cours d’exécution sur ServerA.

Étape 01) installez la même version de mysql sur ServerB que ServerA

Étape 02) Sur ServerA, exécutez à SET GLOBAL innodb_max_dirty_pages_pct = 0;partir de mysql et environ 10 minutes (ceci purge les pages encrassées du pool de mémoire tampon InnoDB. Cela permet également d’arrêter mysql plus rapidement) Si votre base de données est entièrement en MyISAM, vous pouvez ignorer cette étape.

Étape 03) rsync --archive --verbose --stats --partial --progress --human-readable ServerA:/var/lib/mysql ServerB:/var/lib/mysql

Étape 04) Répétez l’étape 03 jusqu’à ce que la synchronisation prenne moins de 1 minute.

Étape 05) service mysql stopsur ServerA

Étape 06) Effectuez un autre rsync

Étape 07) scp ServerA:/etc/my.cnf ServerB:/etc/

Étape 08) service mysql startsur ServerB

Étape 08) service mysql startsur le serveur A (facultatif)

Essaie !!!

CAVEAT

Vous pouvez créer un esclave de réplication comme celui-ci. Rappelez-vous simplement que l'identifiant du serveur est explicitement défini dans le /etc/my.cnf maître et un numéro différent pour l'identifiant du serveur dans l'esclave /etc/my.cnf


29

Vous n'avez même pas besoin de mysqldump si vous déplacez un schéma de base de données complet, et vous êtes prêt à arrêter la première base de données (pour que ce soit cohérent lors du transfert)

  1. Arrêtez la base de données (ou verrouillez-la)
  2. Allez dans le répertoire où se trouvent les fichiers de données mysql.
  3. Transférez le dossier (et son contenu) dans le répertoire de données mysql du nouveau serveur
  4. Lancer la sauvegarde de la base de données
  5. Sur le nouveau serveur, lancez une commande 'créer une base de données'. '
  6. Recréez les utilisateurs et accordez des autorisations.

Je ne me souviens pas si mysqldump gère les utilisateurs et les permissions, ou juste les données ... mais même si c'est le cas, c'est beaucoup plus rapide que de faire un dump et de l'exécuter. Je ne l’utiliserais que si j’avais besoin de vider une base de données mysql pour la réinsérer dans un autre SGBDR, si je devais changer les options de stockage (innodb vs myisam), ou peut-être si je changeais les versions majeures de mysql (mais Je pense l'avoir fait entre 4 et 5 ans)


Ceci est plus efficace, surtout s'il s'agit d'un administrateur système / DBA. BTW mysqldump en utilisant --all-databasesdumps le schéma mysql. Le démarrage de mysql sur la machine suivante ouvre les autorisations à condition que vous ayez transféré le dossier de données vers une autre machine avec la même version majeure de MySQL. (MySQL 5.5.x à MySQL 5.5.x, MySQL 5.1.x à MySQL 5.1.x, MySQL 5.0.x à MySQL 5.0.x)
RolandoMySQLDBA

4
@ Joe, oui, mysqldumpgère les utilisateurs et les autorisations, car celles-ci sont stockées dans le mysqlschéma.
Shlomi Noach

Cette approche est particulièrement utile avec l'hébergement en nuage, comme AWS. Vous pouvez arrêter mysql, démonter et détacher du serveur actuel; attachez et montez sur le nouveau serveur et démarrez mysql. Pas de surcharge de copie si le volume est resté dans la même batterie de serveurs.
LateralFractal

12

Si vous voulez juste déplacer une table spécifique, essayez:

mysqldump -u username -ppassword databasename tablename > databasename.tablename.sql

Vous pouvez spécifier plusieurs noms de table ci-dessus, dans la même commande. Une fois la commande terminée, déplacez le fichier databasename.tablename.sql vers l'autre serveur, puis effectuez la restauration à l'aide de:

mysql -u username -ppassword databasename < databasename.tablename.sql

Notez que le fichier .sql précédent est créé à l'aide du programme mysqldump et que la restauration est effectuée directement dans mysql .


7
  1. Si vous avez un accès ssh, vous pouvez utiliser mysqldump depuis la ligne de commande
  2. Si vous n'avez pas d'accès ssh mais que vous avez un accès phpMyAdmin, vous pouvez l'utiliser pour exporter / importer
  3. Si vous n'avez pas accès à phpMyAdmin, il existe des scripts php pratiques qui dumpent et importent (cependant, de par ma propre expérience, je n'en ai jamais trouvé un aussi fiable que phpMyAdmin).

Il se peut que vous puissiez déplacer les fichiers de base de données eux-mêmes (pour mon installation, ils se trouvent dans / var / lib / mysql), mais je ne suis pas vraiment sûr de la manière dont cela fonctionnera.


5

Vous allez avoir besoin de prendre un temps d'arrêt. Cela va prendre un certain temps en fonction de la vitesse de votre réseau. Je vais supposer que vous utilisez MySQL sous Linux / Unix. Voici le processus que j'utilise:

  1. Arrêtez le démon mysql sur l'hôte source.
  2. Créez un dossier tmp sur votre hôte cible pour recevoir les fichiers.
  3. Utilisez screen pour créer une session shell qui survivra si votre ssh était déconnecté.
  4. Utilisez rsync pour transférer les fichiers entre les hôtes. Quelque chose comme: rsync -avhP source user @ targethost: / path / to / folder /
  5. Exécutez vos cas de test pour vous assurer de ne rien perdre lors du transfert.

Procédez ensuite comme d'habitude à la configuration de MySQL locale.

* Remarque: vous pouvez également utiliser le paramètre -c avec rsync pour ajouter une somme de contrôle au transfert. Toutefois, cette opération sera lente en fonction de la vitesse du processeur.


4

Je peux confirmer que la méthode de DTest fonctionne également pour la copie entre Ubuntu et OSX.

Pour copier toutes les bases de données sans avoir à effectuer de dumping ou similaire:

Assurez-vous que vous avez un mysql propre de mysql (installé le fichier dmg téléchargé depuis mysql http://cdn.mysql.com/Downloads/MySQL-5.1/mysql-5.1.63-osx10.6-x86_64.dmg ), que (VERY IMPORTANT) n'a jamais été exécuté.

Copiez le contenu du dossier / var / lib / mysql / de la machine Ubuntu au-dessus de / usr / local / mysql / data / contents sur le mac. Pour avoir accès à un dossier sur la machine Ubuntu, je devais utiliser sudo, à savoir:

sudo cp /var/lib/mysql /home/foouser/mysql_data_folder
sudo chown -R foouser /home/foouser/mysql_data_folder

J'ai copié le dossier en utilisant scp.

Avant de commencer, prenez une copie du dossier mysql sur le mac pour vous assurer de ne rien gâcher.

Après avoir copié le dossier, procédez comme suit sur la machine Mac:

sudo chown -R _mysql /usr/local/mysql/data/
sudo chgrp -R wheel /usr/local/mysql/data/
sudo chmod -R g+rx /usr/local/mysql/data/

Démarrez le serveur mysql pour la première fois (à partir du volet des préférences sous Préférences Système-> mysql). Tous les utilisateurs et bases de données doivent maintenant être configurés correctement.

Cela a fonctionné avec mysql 5.1.61 sur Ubuntu 64 bit 11.10 et mysql 5.1.63 sur osx lion (macbook pro).


4

Je pense que toutes les réponses précédentes fonctionnent probablement bien, mais n'abordent pas vraiment la question de la définition d'un nom de base de données pendant le transfert.

Voici comment je l'ai fait avec bash:

Vous feriez peut-être mieux d’utiliser rsyncque de scpne pas compresser le fichier si vous le faites souvent.

Sur mon serveur source:

me@web:~$ d=members
me@web:~$ mysqldump $d | gzip > $d.sql.gz
me@web:~$ scp -i .ssh/yourkeynamehere $d.sql.gz $sbox:$d.sql.gz

Sur mon serveur de destination:

me@sandbox:~$ d1=members
me@sandbox:~$ d2=members_sb
me@sandbox:~$ mysqladmin create $d2
me@sandbox:~$ cat $d1.sql.gz | gunzip |  mysql $d2

Sur chaque machine pour voir les progrès:

me@sandbox:~$ ls *.gz 
me@sandbox:~$ cat $d.sql.gz | gunzip |  less

Tout ceci suppose que vous ayez un fichier de configuration MySQL dans votre répertoire personnel sur les deux machines et définissez les permissions:

$ echo "
[client]
user=drupal6
password=metoknow
host=ord-mysql-001-sn.bananas.com
[mysql]
database=nz_drupal" > .my.cnf
$ chmod 0600 ~/.my.cnf

3

le déplacez-vous vers une autre base de données serveur mysql? si c'est le cas, effectuez une exportation dessus

# mysqldump -u username -ppassword database_name > FILE.sql

Mysqldump? C'est à ce moment-là que vous avez affaire à une petite quantité de données?
Oh Chin Boon

2
Je pense que petit / grand est assez subjectif de nos jours. Quand j'ai vu le titre de la question, je m'attendais à ce que la base de données soit beaucoup plus grosse que 20 Go pour être considérée comme "volumineuse" ...
Aaron Bertrand

3

Méthode linux générique:

/etc/init.d/mysqld stop
rsync -avz source_files destination
vi /etc/my.cnf

éditez le datadir (et le socket) pour que mysqld et mysqld_safe (si applicable) pointent vers le nouvel emplacement, puis

/etc/init.d/mysql start

J'ai posté ceci parce que personne ne semblait simplement énumérer le moins d'étapes pour le faire et je pense que c'est la manière la plus simple personnellement.


2

Peut-être que c'est une meilleure façon de le faire:

Version 1 : copie des fichiers de données (MYISAM uniquement)

ssh server1
service mysql stop
cd $mysql-data-dir
rsync -avz dirs-or-files server2:$mysql-data-dir
service mysql start

service ssh server2 redémarrer mysql

  • Si vos fichiers de base de données sont en lecture seule, vous pouvez ignorer l’arrêt du serveur.

Version 2 : mysqldump

Installez pigz - sur les processeurs Xeon ou Opteron modernes, en particulier lorsque vous avez 2 processeurs ou plus, il est BEAUCOUP plus rapide que gzip.

ssh server1 
mysqldump ... | pigz > backup-YYMDD.sql.gz
rsync backup-YYMDD.sql.gz server:location

ssh server2
pigz -dc location/backup-YYMDD.sql.gz | mysql ..

Version 3 : maître / esclave + mysqldump / copie de fichier

In HA environment you should use the following trick:
setup slave server & do all backups from it
before backups - do "slave stop"; 
then do version 1 or version 2

scénario:

touch full.start
mysqladmin -h slave-db stop-slave
echo "show slave status \G" | mysql -h slave-db > FULL/comfi-$NOW.master-position
/usr/bin/mysqldump -h slave-db --default-character-set=utf8 -A --opt --skip-lock-tables | pigz > "FULL/XXXX-$NOW.sql.gz"
mysqladmin -h slave-db start-slave
touch full.end

ln -fs "FULL/XXXX-$NOW.sql.gz" FULL.sql.gz

PS:

pour copier de petites tables, utilisez:

ssh server1 table de schéma mysqldump | schéma sq server2 mysql


2

Je suggérerais les deux étapes simples pour transférer la base de données entière d'un serveur à un autre.

Étape 1 : Effectuez une sauvegarde complète des bases de données sur le serveur source à l'aide de mysqldump .

Étape 2 : Vous pouvez utiliser la commande rsync pour transférer l'intégralité des bases de données sur le serveur de destination.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.