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:
- datadir est / var / lib / mysql
- base de données appelée mydb
- 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.
- /var/lib/mysql/mydb/mytable.frm (fichier .frm)
- /var/lib/mysql/mydb/mytable.MYD (fichier .MYD)
- /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 stop
sur ServerA
Étape 06) Effectuez un autre rsync
Étape 07) scp ServerA:/etc/my.cnf ServerB:/etc/
Étape 08) service mysql start
sur ServerB
Étape 08) service mysql start
sur 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