Restaurer InnoDB à différentes machines
J'ai actuellement des sauvegardes prises avec Percona Xtrabackup de toutes mes bases de données MySQL.
Mon scénario spécifique est que je souhaite restaurer un instantané de base de données InnoDb de mois à ma machine locale pour les tests, mais je ne peux pas sembler trouver des instructions pour ce faire dans la documentation de Percona.
Lire sur Google Je viens à la conclusion que je dois extraire le tar.gz Fichier sur ma machine et "rejouer" le journal des transactions.
Donc, ma question est de savoir quelles étapes spécifiques sont nécessaires et quelles sont les mises en garde à rétablir l'instantané DB à ma machine.
Enfin, il semble que l'utilisation de Xtrabackup en soi ne garantit pas que vous pourrez restaurer vos données si quelque chose ne va pas. Par exemple, si le serveur devait mourir les sauvegardes, je serais inutile sans le journal des transactions. Donc, une phrase générale de ma question pourrait être quelles mesures doivent être prises pour que je puisse restaurer mes données sur n'importe quelle machine que je souhaite.
N'oubliez pas que mon principal domaine d'expertise n'est pas la gestion de la base de données!
Après des instructions qui m'ont été données dans une réponse, j'ai extrait l'archive de sauvegarde et "préparé" la sauvegarde avec innobackupex --apply-log . qui a fini bien. J'ai ensuite arrêté MySQL, copié tous les fichiers de l'AIR de sauvegarde vers le Direction de la DIP MySQL et redémarré MySQL.
Une fois que je me suis connecté (après avoir réinitialisé le mot de passe root), je peux voir les tables de DB et de leurs tables (à l'aide de l'administrateur), mais une fois que j'en ai sélectionné, je suis frappé avec une table n'existe pas d'erreur. Donc, je suis toujours à ma question originale de la façon dont la restauration d'une machine différente et d'autre part, comment vous assurer que mes sauvegardes sont utilisables chaque fois que j'en ai besoin.
Sur une note latérale, de ce que je lis, il devrait y avoir un fichier .idb pour chaque table mais je ne vois rien de tel.
Il semble que je fais tout correctement. Mon script de sauvegarde comprend
#!/bin/bash
BDIR="/disk2/backup/mysql"
/usr/bin/innobackupex --user=backup --password=xxx --ibbackup=xtrabackup --stream=tar /tmp | gzip -c -9 > $BDIR/`date -u +%Y-%m-%dT%H:%M:%SZ`.tar.gz
qui également rsyncs les fichiers hors site.
Je télécharge le fichier, extraire (tar -ixvzf), Appliquez le journal comme mentionné ci-dessus, arrêtez MySQL et copiez les fichiers sur le DataDir (CP), appliquez des autorisations, démarrez et connectez-vous. Parcourir à mon sauvegarde dB me donne l'erreur
140730 16:28:49 [Erreur] Impossible de trouver ou d'ouvrir la table LEAR @ 002DMANAGER @ 002DBACKUP/CRM_WORKBAN du dictionnaire de données interne de Innodb bien que le fichier .frm pour la table existe. Peut-être que vous avez supprimé et recréé des fichiers de données InnoDB, mais vous avez oublié de supprimer les fichiers .FRM correspondants de tables Innodb, ou vous avez déplacé des fichiers .frm vers une autre base de données? Ou, la table contient des index que cette version du moteur ne prend pas en charge.
pour toutes les tables DB.
La version MySQL sur le serveur est 5.1, la version locale est de 5,5
Veuillez vous reporter à la Documentation officielle sur la manière de créer, de stocker et de restaurer une sauvegarde complète avec Percona Xtrabackup . Percona xtrabackup garantit tout d'avoir tout pour aucune perte de données :
Il peut être résumé comme suit:
Effectuez la sauvegarde (
innobackupex). Vous pouvez éventuellement l'envoyer à distance, la compresser, le crypter, etc. En même temps, la sauvegarde est en cours d'exécution. C'est le seul point où vous avez besoin d'accès au serveur de base de données d'origine.Si vous ne l'avez pas envoyé à distance à la première étape, faites-le maintenant. Une sauvegarde locale, bien que utile, n'est pas une stratégie de sauvegarde réelle. Pour que la sauvegarde soit complète, vous souhaiteriez également copier votre fichier de configuration (/etc/my.cnf et vos exécutables binaires, si vous ne pouvez pas les obtenir d'une autre source - votre distribution, par exemple).
À tout moment entre la sauvegarde et le processus de récupération, vous devez faire la phase préparatoire (
innobackupex --apply-log). Cela nécessite uniquement les fichiers de sauvegarde, pas le serveur d'origine. Cela créera les journaux de transaction pour vousUne fois que vous l'avez appliquée, copiez simplement les fichiers dans le répertoire d'origine pendant que le serveur est en panne . Vous pouvez le faire avec
innobackupex --copy-backSi vous avez les fichiers localement, ou simplement faire(s)cp/rsync. N'oubliez pas de modifier les autorisations de fichier sur l'utilisateur approprié (généralement l'utilisateur MySQL) .Démarrer le serveur. Vous avez terminé.
Cela restaurera une sauvegarde complète. Pour vous assurer que c'est une méthode sécurisée, Galera Cluster peut l'utiliser pour cloner des nœuds automatiquement (sans intervention humaine) et c'est la méthode la plus sûre et la plus rapide disponible.
Si vous ne voyez pas de fichiers individuels .ibd, il pourrait s'agir de plusieurs raisons: vous utilisez MyISAM ou un autre moteur qui n'utilisez pas ceux qui n'utilisent pas d'innoDB avec innodb_file_per_table = 0, ou vous avez perdu certains des fichiers sur le processus de copie (ou ils ont de mauvaises autorisations). Veuillez fournir le message d'erreur complet et le journal d'erreur depuis le dernier démarrage et une liste récursive de votre DataDir.
En tant qu'écrivain de la formation à Percona Xtrabackup, je suis assez familier avec toutes les erreurs idiotes typiques Nous faisons lorsque vous travaillez avec elle.
Merci pour les informations supplémentaires, voici mes suggestions comme suivi:
Les dernières versions de Xtrabackup ne sont pas compatibles avec 5.1 sans le plug-in InnoDB . Utilisez-vous MySQL 5.1 avec Stock Innodb (pas le plugin ou Percona/Mariadb)? De plus, la récupération à une nouvelle version de MySQL sous forme binaire peut nécessiter des étapes/précautions de mise à niveau supplémentaires - elle peut être effectuée sous forme binaire. Suggestion: essayez d'utiliser une ancienne version de Xtrabackup ou de la mise à niveau du serveur. 5.1 Sans le plugin est une sortie de 6 ans avec très peu de soutien partout. Je peux également fournir des outils de sauvegarde alternatifs si vous souhaitez rester à <5.1 (mais très peu sont si rapides).
Je n'aime pas la base de données/name - juste pour vérifier, pouvez-vous confirmer que dB: lead @ @ 002dmanager @ 002dbackup Table: CRM_WORD_BANBAN est le bon nom pour l'une de vos tables et que c'est le nom exact d'un .frm déposer? Je veux supprimer les problèmes de système de fichiers.
Ok, suivez les pointeurs @jynus, j'ai enfin obtenu les sauvegardes à restaurer. J'ai fini par créer une autre instance MySQL sur le serveur et la restaurer là-bas.
Juste au cas où une personne circule dans le même problème, les étapes que j'ai prises sont les suivantes ...
Mon environnement est Centos 6.4, MySQL 5.1 avec stock InnoDB autant que je puisse dire, innobackupex --version Donne moi InnoDB Backup Utility v1.5.1-xtrabackup, xtrabackup --version Donne moi xtrabackup version 2.1.8 for Percona Server 5.1.73 Et le serveur a Plesk 11.0.9 installé.
Tout d'abord, j'ai configuré une autre instance MySQL en copiant et en modifiant la valeur par défaut /etc/init.d/mysql script de démarrage. Le problème que j'ai eu là était que de charger un fichier de configuration différent pour ce serveur, le --defaults-file Paramètre que mysqld_safe Besoins doit être donné avant tout autre paramètre (voir ici ). J'ai ensuite copié la valeur par défaut /etc/my.cnf Fichier et modifié les valeurs de là (port, emplacements de journal, etc.) pour convenir à ma configuration.
Pour vous connecter à la nouvelle instance MySQL et configurer un nouvel utilisateur racine, le premier mysqld_safe courir était avec le --skip-grant-tables option dans le script init (voir ici ).
Pour pouvoir gérer la nouvelle instance MySQL avec phpmyadmin, j'ai créé un nouveau serveur de base de données dans Plesk (serveurs de base de données Server-> Database-> Ajouter un serveur de base de données) et entré dans le nouveau port et/ou nouveau IP Le serveur s'exécute sur et le nouveau administrateur. Utilisateur que j'ai mis en place à l'étape précédente. Plesk ne vous permettra pas d'utiliser un nom d'utilisateur "racine", vous devez donc ajouter un nom d'utilisateur différent avec des privilèges root à l'étape précédente.
Après cela, le serveur peut être démarré/arrêté/rechargé en utilisant quelque chose comme /etc/init.d/mysql-backup start.
Pour le processus de récupération réelle, j'ai extrait le fichier de sauvegarde (en prenant soin d'utiliser le -i Drapeau pour le goudron) et une fois dans le Dir de sauvegarde, j'ai appliqué le journal à l'aide de l'exécutable xtrabackup exécutable (xtrabackup --prepare --target-dir=/path/to/extracted/backup/) Parce que innobackupex exige qu'il se connecte à un serveur MySQL exécutant pour déterminer la version, quelque chose que je ne voulais pas comprendre comment faire.
J'ai arrêté mon nouveau serveur MySQL, copié sur le dossier qui contenait ma base de données sur le Datadir, copié sur le fichier ibdata1, a modifié les autorisations et a démarré le serveur.
Je pourrais ensuite parcourir/gérer ma base de données de sauvegarde à l'aide de phpmyadmin.