Percona XtraBackup

Percona XtraBackup est un logiciel de ligne de commande open source, portable, gratuit et non bloquant qui agit comme une solution de sauvegarde autonome pour les célèbres moteurs de stockage XtraDB et InnoDB. Il dispose d'une vérification de sauvegarde automatique et offre des temps de disponibilité plus élevés que les autres produits similaires.

Le programme est entièrement compatible avec les serveurs de bases de données MySQL et MariaDB, et il est largement utilisé par le populaire service de réseau social Facebook pour les sauvegardes incrémentales. Il est conçu pour résoudre des problèmes réels lors de la sauvegarde de très grandes bases de données très chargées.

Les fonctionnalités clés incluent la possibilité d'effectuer des sauvegardes en ligne tout en évitant d'interrompre votre base de données, d'effectuer des sauvegardes en continu sur un autre serveur et d'effectuer des sauvegardes incrémentielles tout en économisant de l'espace disque et de la bande passante réseau. >

Avec Percona XtraBackup, vos sauvegardes se termineront de manière fiable et rapide. Vous pouvez également créer facilement de nouveaux esclaves de réplication, effectuer une analyse avancée des fichiers de données et d'index et déplacer des tables individuelles entre les serveurs sans redémarrer, tâche qui nécessite l'importation de XtraDB.

Le logiciel supporte différentes versions de MySQL, parmi lesquelles on peut citer MySQL, MariaDB, le cluster MariaDB Galera, le serveur Percona et le cluster Percona XtraDB. Il prend également en charge tous les systèmes d'exploitation GNU / Linux, fonctionnant bien sur du matériel 32 bits et 64 bits.

Parmi les autres fonctionnalités, citons le blocage des sauvegardes MyISAM, des sauvegardes complètes compressées, des sauvegardes incrémentales compressées, des sauvegardes incrémentales rapides, des sauvegardes incrémentales avec des journaux archivés et des journaux REDO uniquement, des sauvegardes locales parallèles, recopie, apply-log, compression et cryptage.

En outre, rsync est également compatible avec la synchronisation de fichiers de pointe, l'exportation de tables individuelles, la gestion FTWRL améliorée, les sauvegardes compactes, la reprise à un point dans le temps, les sauvegardes hors ligne et le cloud sauvegardes.

Percona XtraBackup est écrit dans les langages de programmation C, C ++ et Perl. C'est un logiciel de ligne de commande, distribué sous forme de paquets binaires pré-construits pour les distributions Ubuntu, Debian et Red Hat Enterprise Linux, ainsi que les archives binaires et sources universelles.

est nouveau dans cette version:

• Percona XtraBackup segfault pendant la phase de préparation de certaines pages FTS. Bug corrigé # 1460138.
• Correction d'une erreur de compilation due à une dépendance manquante causée par le bogue en amont # 77226. Bug corrigé # 1461129.
• Une régression introduite en corrigeant un bogue # 1403237 dans Percona XtraBackup 2.2.8 pouvait amener xtrabackup à lire un journal de rétablissement à partir d'un décalage incorrect qui provoquerait une assertion. Bug corrigé # 1464608.
• Correction de la variable locale current_thd thread-local non initialisée. Cela corrige aussi complètement le bug # 1415191. Bug corrigé # 1467574.
• Après la sortie de Percona XtraBackup 2.2.11, innobackupex lance un fichier FLUSH TABLE avant d'exécuter la commande FLUSH TABLES WITH READ LOCK. Bien que cela aide les sauvegardes dans certaines situations, cela implique également que FLUSH TABLE sera écrit dans le journal binaire. Sur MariaDB 10.0 avec GTID activé, lorsque la sauvegarde a été effectuée sur l'esclave, cela a modifié la GTID de cet esclave et Percona XtraBackup n'a plus vu la bonne GTID. Bug corrigé # 1466446 (Julien Pivotto).
• La compilation RPM de Percona XtraBackup nécessitait toujours bzr. Bug corrigé # 1466888 (Julien Pivotto).
• Compiler les RPM Percona XtraBackup avec l'option XB_VERSION_EXTRA créerait une version RPM incorrecte. Bug corrigé # 1467424 (Julien Pivotto).
• Percona XtraBackup se terminerait correctement même si le journal de reprise n'était pas copié complètement. Cela signifie que les sauvegardes ont été considérées comme réussies même lorsqu'elles étaient corrompues. Bug corrigé # 1470847.
• Dans de rares cas où il y a deux ou plusieurs tablespaces avec le même ID dans le répertoire de données, xtrabackup récupère le premier par ordre lexical, ce qui peut entraîner la perte de la bonne table. Bug corrigé # 1475487.
• Percona XtraBackup manquait revision_id dans les binaires. Bug corrigé # 1394174.

Nouveautés dans la version 2.4.8:

• Percona XtraBackup segfault pendant la phase de préparation de certaines pages FTS. Bug corrigé # 1460138.
• Correction d'une erreur de compilation due à une dépendance manquante causée par le bogue en amont # 77226. Bug corrigé # 1461129.
• Une régression introduite en corrigeant un bogue # 1403237 dans Percona XtraBackup 2.2.8 pouvait amener xtrabackup à lire un journal de rétablissement à partir d'un décalage incorrect qui provoquerait une assertion. Bug corrigé # 1464608.
• Correction de la variable locale current_thd thread-local non initialisée. Cela corrige aussi complètement le bug # 1415191. Bug corrigé # 1467574.
• Après la sortie de Percona XtraBackup 2.2.11, innobackupex lance un fichier FLUSH TABLE avant d'exécuter la commande FLUSH TABLES WITH READ LOCK. Bien que cela aide les sauvegardes dans certaines situations, cela implique également que FLUSH TABLE sera écrit dans le journal binaire. Sur MariaDB 10.0 avec GTID activé, lorsque la sauvegarde a été effectuée sur l'esclave, cela a modifié la GTID de cet esclave et Percona XtraBackup n'a plus vu la bonne GTID. Bug corrigé # 1466446 (Julien Pivotto).
• La compilation RPM de Percona XtraBackup nécessitait toujours bzr. Bug corrigé # 1466888 (Julien Pivotto).
• Compiler les RPM Percona XtraBackup avec l'option XB_VERSION_EXTRA créerait une version RPM incorrecte. Bug corrigé # 1467424 (Julien Pivotto).
• Percona XtraBackup se terminerait correctement même si le journal de reprise n'était pas copié complètement. Cela signifie que les sauvegardes ont été considérées comme réussies même lorsqu'elles étaient corrompues. Bug corrigé # 1470847.
• Dans de rares cas où il y a deux ou plusieurs tablespaces avec le même ID dans le répertoire de données, xtrabackup récupère le premier par ordre lexical, ce qui peut entraîner la perte de la bonne table. Bug corrigé # 1475487.
• Percona XtraBackup manquait revision_id dans les binaires. Bug corrigé # 1394174.

Quoi de neuf dans la version 2.4.7:

• Percona XtraBackup segfault pendant la phase de préparation de certaines pages FTS. Bug corrigé # 1460138.
• Correction d'une erreur de compilation due à une dépendance manquante causée par le bogue en amont # 77226. Bug corrigé # 1461129.
• Une régression introduite en corrigeant un bogue # 1403237 dans Percona XtraBackup 2.2.8 pouvait amener xtrabackup à lire un journal de rétablissement à partir d'un décalage incorrect qui provoquerait une assertion. Bug corrigé # 1464608.
• Correction de la variable locale current_thd thread-local non initialisée. Cela corrige aussi complètement le bug # 1415191. Bug corrigé # 1467574.
• Après la sortie de Percona XtraBackup 2.2.11, innobackupex lance un fichier FLUSH TABLE avant d'exécuter la commande FLUSH TABLES WITH READ LOCK. Bien que cela aide les sauvegardes dans certaines situations, cela implique également que FLUSH TABLE sera écrit dans le journal binaire. Sur MariaDB 10.0 avec GTID activé, lorsque la sauvegarde a été effectuée sur l'esclave, cela a modifié la GTID de cet esclave et Percona XtraBackup n'a plus vu la bonne GTID. Bug corrigé # 1466446 (Julien Pivotto).
• La compilation RPM de Percona XtraBackup nécessitait toujours bzr. Bug corrigé # 1466888 (Julien Pivotto).
• Compiler les RPM Percona XtraBackup avec l'option XB_VERSION_EXTRA créerait une version RPM incorrecte. Bug corrigé # 1467424 (Julien Pivotto).
• Percona XtraBackup se terminerait correctement même si le journal de reprise n'était pas copié complètement. Cela signifie que les sauvegardes ont été considérées comme réussies même lorsqu'elles étaient corrompues. Bug corrigé # 1470847.
• Dans de rares cas où il y a deux ou plusieurs tablespaces avec le même ID dans le répertoire de données, xtrabackup récupère le premier par ordre lexical, ce qui peut entraîner la perte de la bonne table. Bug corrigé # 1475487.
• Percona XtraBackup manquait revision_id dans les binaires. Bug corrigé # 1394174.

Nouveautés dans la version 2.4.6:

• Percona XtraBackup segfault pendant la phase de préparation de certaines pages FTS. Bug corrigé # 1460138.
• Correction d'une erreur de compilation due à une dépendance manquante causée par le bogue en amont # 77226. Bug corrigé # 1461129.
• Une régression introduite en corrigeant un bogue # 1403237 dans Percona XtraBackup 2.2.8 pouvait amener xtrabackup à lire un journal de rétablissement à partir d'un décalage incorrect qui provoquerait une assertion. Bug corrigé # 1464608.
• Correction de la variable locale current_thd thread-local non initialisée. Cela corrige aussi complètement le bug # 1415191. Bug corrigé # 1467574.
• Après la sortie de Percona XtraBackup 2.2.11, innobackupex lance un fichier FLUSH TABLE avant d'exécuter la commande FLUSH TABLES WITH READ LOCK. Bien que cela aide les sauvegardes dans certaines situations, cela implique également que FLUSH TABLE sera écrit dans le journal binaire. Sur MariaDB 10.0 avec GTID activé, lorsque la sauvegarde a été effectuée sur l'esclave, cela a modifié la GTID de cet esclave et Percona XtraBackup n'a plus vu la bonne GTID. Bug corrigé # 1466446 (Julien Pivotto).
• La compilation RPM de Percona XtraBackup nécessitait toujours bzr. Bug corrigé # 1466888 (Julien Pivotto).
• Compiler les RPM Percona XtraBackup avec l'option XB_VERSION_EXTRA créerait une version RPM incorrecte. Bug corrigé # 1467424 (Julien Pivotto).
• Percona XtraBackup se terminerait correctement même si le journal de reprise n'était pas copié complètement. Cela signifie que les sauvegardes ont été considérées comme réussies même lorsqu'elles étaient corrompues. Bug corrigé # 1470847.
• Dans de rares cas où il y a deux ou plusieurs tablespaces avec le même ID dans le répertoire de données, xtrabackup récupère le premier par ordre lexical, ce qui peut entraîner la perte de la bonne table. Bug corrigé # 1475487.
• Percona XtraBackup manquait revision_id dans les binaires. Bug corrigé # 1394174.

Nouveautés dans la version 2.4.3:

• Percona XtraBackup segfault pendant la phase de préparation de certaines pages FTS. Bug corrigé # 1460138.
• Correction d'une erreur de compilation due à une dépendance manquante causée par le bogue en amont # 77226. Bug corrigé # 1461129.
• Une régression introduite en corrigeant un bogue # 1403237 dans Percona XtraBackup 2.2.8 pouvait amener xtrabackup à lire un journal de rétablissement à partir d'un décalage incorrect qui provoquerait une assertion. Bug corrigé # 1464608.
• Correction de la variable locale current_thd thread-local non initialisée. Cela corrige aussi complètement le bug # 1415191. Bug corrigé # 1467574.
• Après la sortie de Percona XtraBackup 2.2.11, innobackupex lance un fichier FLUSH TABLE avant d'exécuter la commande FLUSH TABLES WITH READ LOCK. Bien que cela aide les sauvegardes dans certaines situations, cela implique également que FLUSH TABLE sera écrit dans le journal binaire. Sur MariaDB 10.0 avec GTID activé, lorsque la sauvegarde a été effectuée sur l'esclave, cela a modifié la GTID de cet esclave et Percona XtraBackup n'a plus vu la bonne GTID. Bug corrigé # 1466446 (Julien Pivotto).
• La compilation RPM de Percona XtraBackup nécessitait toujours bzr. Bug corrigé # 1466888 (Julien Pivotto).
• Compiler les RPM Percona XtraBackup avec l'option XB_VERSION_EXTRA créerait une version RPM incorrecte. Bug corrigé # 1467424 (Julien Pivotto).
• Percona XtraBackup se terminerait correctement même si le journal de reprise n'était pas copié complètement. Cela signifie que les sauvegardes ont été considérées comme réussies même lorsqu'elles étaient corrompues. Bug corrigé # 1470847.
• Dans de rares cas où il y a deux ou plusieurs tablespaces avec le même ID dans le répertoire de données, xtrabackup récupère le premier par ordre lexical, ce qui peut entraîner la perte de la bonne table. Bug corrigé # 1475487.
• Percona XtraBackup manquait revision_id dans les binaires. Bug corrigé # 1394174.

Quoi de neuf dans la version 2.2.9:

• Percona XtraBackup 2.1.2 se bloque lors de l'exécution d'un état Transfert d'instantané. Bug corrigé # 1182698.

Quoi de neuf dans la version 2.2.8:

• Percona XtraBackup 2.1.2 se bloque lors de l'exécution d'un état Transfert d'instantané. Bug corrigé # 1182698.

Quoi de neuf dans la version 2.1.2:

• Bogues corrigés:
• L'utilisation du paquetage DBD :: MySQL de Perl pour la communication avec le serveur au lieu de générer le client en ligne de commande MySQL a introduit une régression qui a provoqué l'échec de l'option innobackupex -galera-info. Bug corrigé # 1180672.
• Le séparateur ':' manquait au format de xtrabackup_galera_info entre les valeurs de wsrep_local_state_uuid et de wsrep_last_committed. Bug corrigé # 1181222.
• La détection de version automatique d'innobackupex ne fonctionnait pas correctement pour les dernières versions de Percona Server et de MySQL 5.1, ce qui pouvait provoquer l'échec d'innobackupex. Bugs corrigés # 1181092, # 1181099 et # 1180905.
• Lors de la sauvegarde d'un serveur qui n'est pas un esclave de réplication avec l'option innobackupex -slave-info, innobackupex a échoué avec une erreur fatale. Remplacé l'erreur fatale par un message de diagnostic sur innobackupex -slave-info étant ignoré dans un tel cas. Bug corrigé # 1180662.
• Des valeurs faibles pour wait_timeout sur le serveur peuvent entraîner la fermeture de la connexion par le serveur pendant la sauvegarde. Correction en définissant la plus grande valeur de l'option wait_timeout sur le serveur pour empêcher le serveur de fermer les connexions si la valeur globale wait_timeout est trop basse. Bug corrigé # 1180922.
• Autres corrections de bugs: bug corrigé # 1177182.

Nouveautés dans la version 2.0.7:

• Nouvelles fonctionnalités:
• Cette version de Percona XtraBackup a implémenté la prise en charge complète des nouvelles fonctionnalités de MySQL 5.6 (GTID, tablespaces distants / transportables, tablespace undo séparés, fichiers de vidage de pool de tampons de style 5.6).
• Percona XtraBackup a implémenté le support pour le pré-chargement du pool de tampons InnoDB introduit en MySQL 5.6. À partir de MySQL 5.6, les sauvegardes de pools de mémoire tampon peuvent être produites et chargées pour accélérer le démarrage du serveur après le démarrage. Cette fonctionnalité est similaire à Dump / Restore du pool de tampons dans Percona Server. Le vidage du pool de mémoire tampon MySQL 5.6 est copié dans le répertoire de sauvegarde pendant la phase de sauvegarde. Pendant la phase de copie (restauration), elle est recopiée dans le répertoire de données. Une fois la sauvegarde restaurée, le vidage du pool de mémoire tampon peut être chargé par le serveur automatiquement au démarrage ou à la demande.
• L'intervalle de temps entre les vérifications effectuées par le thread de copie de journal est maintenant configurable par innobackupex -log-copy-interval. La définition de l'intervalle permet de réduire le délai entre les vérifications, ce qui peut empêcher les échecs de XtraBackup provoqués par les enregistrements de journal dans le journal transactionnel d'être écrasés avant d'être copiés par le thread de copie de journal.
• Percona XtraBackup stocke maintenant la valeur GTID dans xtrabackup_binlog_info lors de la sauvegarde de MySQL et de Percona Server 5.6 avec le mode GTID activé. Exemple de comment cette information peut être utilisée pour créer / restaurer un esclave peut être trouvé dans ce blogpost.
• Option Percona XtraBackup xtrabackup -export prend désormais en charge les tablespaces transportables introduites dans MySQL 5.6. Cette option peut être utilisée pour produire des fichiers de métadonnées de style 5.6, qui peuvent être importés par ALTER TABLE IMPORT TABLESPACE sur MySQL et Percona Server 5.6 comme décrit dans le guide Exportation et importation de tables.
• Bogues corrigés:
• xtrabackup_56 binary était présent dans les paquets rpm et deb, mais il manquait dans le paquet source .tar.gz. Corrigé en ajoutant le binaire manquant à .tar.gz. Bug corrigé # 1158948.
• innobackupex peut tomber en panne lors de la sauvegarde 5.6 en raison de la liaison de la mauvaise bibliothèque SSL. Bug corrigé # 1168540.
• Percona XtraBackup planterait lors de la préparation de la sauvegarde 5.6 avec des tables partitionnées. Bug corrigé # 1169169.
• Les tables abandonnées entre une sauvegarde complète et une sauvegarde incrémentielle étaient présentes dans le répertoire de sauvegarde complet et n'étaient pas supprimées lorsque des sauvegardes incrémentielles avaient été fusionnées. Corrigé en supprimant les fichiers correspondant aux tables manquantes dans le répertoire de sauvegarde incrémentielle. Bug corrigé # 856400.
• Percona XtraBackup laisserait des fichiers obsolètes xtrabackup_tmp * dans l'datadir après avoir appliqué des sauvegardes incrémentielles. Bug corrigé # 1079135.
• Correction de quelques avertissements trouvés dans innobackupex quand tous les avertissements ont été faits FATAL. Bug corrigé # 1116177.
• S'il y a des milliers de tables et des E / S lentes alors XtraBackup peut passer beaucoup de temps à ouvrir tous les espaces de table. L'optimisation a été implémentée et XtraBackup évite désormais de charger des tablespaces non pertinentes lors d'une sauvegarde partielle qui accélère le processus de sauvegarde. Bug corrigé # 1130145.
• Percona XtraBackup n'a pas initialisé les données par thread dans le thread de copie de journal, ce qui peut provoquer le blocage de XtraBackup. Bug corrigé # 1166888.
• La dépendance du paquet a été changée du mysql abstrait au fichier real / usr / bin / mysql, car les paquets rpm d'Oracle ne satisfont plus la dépendance mysql qui est requise par les rpms de XtraBackup. Bug corrigé # 1095972.
• Percona XtraBackup échouerait lors de la préparation de la sauvegarde MySQL 5.6 si les fichiers journaux étaient plus gros que 4G sur le serveur source. Bug corrigé # 1164979.
• En raison d'une implémentation différente dans MySQL 5.6, les messages d'erreur n'étaient pas directement imprimés sur stderr. Pour cette raison, toutes les erreurs InnoDB ou messages de diagnostic ne sont jamais imprimés par xtrabackup_56. Bug corrigé # 1169971.
• innobackupex fonctionnerait toujours avec FLUSH TABLES WITH READ LOCK même si xtrabackup échouait lors de la copie des journaux. Correction en terminant le processus xtrabackup immédiatement en cas d'échec de la copie du journal. Bug corrigé # 1170806.
• innobackupex échouerait si le SQL_MODE était défini sur ANSI_QUOTES. Bug corrigé # 945161.
• Space_id manquant de * .ibd.meta conduirait à l'assertion. Corrigé en remplaçant l'assertion par le message d'erreur. Bug corrigé # 1112224.
• Correction de la faute de frappe dans la sortie d'erreur innobackupex. Bug corrigé # 1157225.
• Lors de la construction à partir de la source, la cible innodb56 n'avait pas l'option de désactiver DTrace comme le fait innodb55. Correction en ajoutant -DENABLE_DTRACE = OFF option de construction pour innodb56 ainsi. Bug corrigé # 1169509.
• innobackupex ne gérait pas l'option innodb_data_file_path qui pouvait entraîner l'échec de la sauvegarde. Bug corrigé # 1169726.
• Pour les binaires Debian et Linux, le message --version qui devrait inclure la révision indiquait "undefined". Bug corrigé # 1171721.
• Le code redondant a été supprimé de xtrabackup.cc. Bug corrigé # 1162765.
• Autres corrections de bugs: bug corrigé # 1158154, correction d'un bug # 1170340, correction d'un bug # 1088309, correction d'un bogue # 1088307.

Nouveautés dans la version 2.0.6:

• Nouvelles fonctionnalités:
• XtraBackup a implémenté le support de base pour MySQL 5.6, Percona Server 5.6 et MariaDB 10.0. La prise en charge de base signifie que ces versions sont reconnues par XtraBackup et que la sauvegarde / restauration fonctionne tant qu'aucune fonctionnalité spécifique à 5.6 n'est utilisée (telles que GTID, tablespaces distantes / transportables, tablespace undo séparé, fichiers de vidage du pool de tampons de style 5.6)
• Bogues corrigés:
• Les espaces table InnoDB individuels d'une taille inférieure à 1 Mo ont été étendus à 1 Mo dans l'opération de préparation de sauvegarde. Cela a conduit à une augmentation importante de l'utilisation du disque dans les cas où il existe de nombreux petits espaces de table InnoDB. Bug corrigé # 950334 (Daniel Frett, Alexey Kopytov).
• Correction du problème qui faisait que les bases de données correspondant aux sous-répertoires inaccessibles de datadir étaient ignorées par XtraBackup sans avertissement ni message d'erreur. Cela arrivait parce que le code InnoDB ignorait silencieusement les sous-répertoires datadir qu'il ne pouvait pas ouvrir. Bug corrigé # 664986 (Alexey Kopytov).
• Dans certains cas, XtraBackup peut ne pas copier un espace table avec une valeur d'option --parallel élevée et une valeur innodb_open_files faible. Bug corrigé # 870119 (Alexey Kopytov).
• Correction du bogue # 711166 introduisait une régression qui provoquait l'échec des sauvegardes de partitions individuelles lorsqu'elles étaient utilisées avec l'option --include dans innobackupex ou l'option --tables dans xtrabackup. Bug corrigé # 1130627 (Alexey Kopytov).
• innobackupex n'a pas ajouté le paramètre de fichier par table pour les sauvegardes indépendantes de la table. Correction en rendant XtraBackup auto-enable innodb_file_per_table lorsque l'option --export est utilisée. Bug corrigé # 930062 (Alexey Kopytov).
• Dans certaines circonstances, XtraBackup peut échouer sur une sauvegarde avec innodb_flush_method = O_DIRECT. Bug corrigé # 1055547 (Alexey Kopytov).
• innobackupex n'a pas transmis l'option --tmpdir au fichier binaire xtrabackup, ce qui a entraîné l'utilisation du fichier tmpdir du serveur pour les fichiers temporaires. Bug corrigé # 1085099 (Alexey Kopytov).
• XtraBackup a amélioré le rapport d'erreurs pour les versions de serveur non reconnues. Bug corrigé # 1087219 (Alexey Kopytov).
• Correction de la dépendance rpm manquante pour le paquet Perl Time :: HiRes qui provoquait l'échec d'innobackupex sur les installations minimales de CentOS. Bug corrigé # 1121573 (Alexey Bychko).
• innobackupex échouerait si --no-lock et --rsync étaient utilisés conjointement. Bug corrigé # 1123335 (Sergei Glushchenko).
• Correction du bug # 1055989 introduit une régression qui a causé le fichier xtrabackup_pid à rester dans le répertoire temporaire après l'exécution. Bug corrigé # 1114955 (Alexey Kopytov).
• Des messages de débogage inutiles ont été supprimés de la sortie XtraBackup. Bug corrigé # 1131084 (Alexey Kopytov).
• Autres corrections de bugs: bug corrigé # 1153334 (Alexey Kopytov), ​​correctif corrigé # 1098498 (Laurynas Biveinis), correctif corrigé # 1132763 (Laurynas Biveinis), correctif corrigé # 1142229 (Laurynas Biveinis), correctif corrigé # 1130581 (Laurynas Biveinis) ).

Nouveautés dans la version 2.0.5:

• Nouvelles fonctionnalités:
• Nouvelle option --defaults-extra-file a été introduit. Cette option spécifie à partir de quel fichier supplémentaire lire les options MySQL par défaut avant le fichier par défaut standard. Il peut être utilisé pour charger la combinaison utilisateur / mot de passe pour l'utilisateur de sauvegarde dédié à partir d'un fichier de configuration séparé, pour éviter de le stocker dans la crontab ou un script quelque part dans le système.
• Bogues corrigés:
• Dans le cas de sauvegardes en continu, innobackupex reprendrait le processus XtraBackup et attendrait ensuite qu'il se termine avant d'exécuter UNLOCK TABLES. Cette base de données a été verrouillée inutilement avec FLUSH TABLES WITH READ LOCK. Innobackupex attend maintenant que la copie du journal soit terminée pour déverrouiller les bases de données. Bug corrigé # 1055989 (Alexey Kopytov).

Les messages d'erreur
• innobackupex référençant le répertoire de données ont été étendus pour afficher le chemin du répertoire de données mentionné dans le message d'erreur. Bug corrigé # 1089375 (Hartmut Holzgraefe).
• Les tables partitionnées n'étaient pas correctement gérées par les options --databases, --include, --tables-file d'innobackupex, et par les options --tables et --tables-file de XtraBackup. Corrigé en supprimant le suffixe de partition (#P # ...) avant d'effectuer le filtrage. Bug corrigé # 711166 (Sergei Glushchenko).
• Lorsque la compression intégrée était utilisée, XtraBackup effectuait des écritures non tamponnées vers le fichier de destination ou le flux en très petits morceaux qui, en retour, causaient des E / S inefficaces. Correction en utilisant un tampon 1M pour une sortie similaire aux sauvegardes non compressées. Bug corrigé # 1095249 (Alexey Kopytov).
• Un long sommeil inutile () dans innobackupex conduit à des TIRAGES FLUSH AVEC READ LOCK prenant trop de temps. Correction en remplaçant 2 secondes d'intervalle de sommeil par 100 millisecondes. Bug corrigé # 1095551 (Sergei Glushchenko).
• Si innobackupex tombe en panne, le fichier xtrabackup_suspended restera sur le système de fichiers. Cela pourrait alors amener Innobackupex à penser que XtraBackup s'est suspendu au moment où il a démarré, et quand XtraBackup se suspendra, innobackupex attendra que cela se termine et ne supprimera pas le fichier suspendu, ce qui conduira à un blocage d'attente. Corrigé en supprimant le fichier xtrabackup_suspended obsolète lors du démarrage d'innobackupex. Bug corrigé # 1007446 (George Ormond Lorch III).
• innobackupex ne reconnaîtrait pas MariaDB 5.2 et MariaDB 5.3. Correction en augmentant les vérifications de version dans innobackupex. Bug corrigé # 733665 (Daniel van Eeden, Alexey Kopytov).
• Autres corrections de bugs: bug corrigé # 924492 (Alexey Kopytov), ​​bug corrigé # 1097158 (Alexey Kopytov), ​​bug corrigé # 1081882 (Alexey Kopytov), ​​bug corrigé # 1096584 (Alexey Kopytov).

Nouveautés dans la version 1.6.7:

• Bogues corrigés:
• xtrabackup_binary n'était pas inclus dans l'archive tar lors de la diffusion, mais dans le répertoire en cours. Cela peut entraîner l'utilisation d'un binaire xtrabackup incorrect lors de la préparation de sauvegardes créées avec les options --stream ou --remote-host. Bugs corrigés # 723318 et # 787988 (Stewart Smith).
• Les tables FLUSH avec READ LOCK n'étaient pas utilisées lors de la création de sauvegardes incrémentielles, ce qui pouvait entraîner des sauvegardes incohérentes lorsque des mises à jour de tables non-InnoDB ou DDL sur des tables se produisaient pendant le processus de sauvegarde. Bug corrigé # 771981 (Alexey Kopytov).
• Option --safe-slave-backup entraînait des informations binlog incorrectes, car dans certains cas, innobackupex a confondu la réponse de SHOW SLAVE STATUS avec celle de SHOW MASTER STATUS. Bug corrigé # 977101 (Alexey Kopytov).
• innodb_data_file_path n'a pas été écrit dans backup-my.cnf, il s'agit d'une régression introduite dans XtraBackup 1.6.5. Bug corrigé # 983685 (Sergei Glushchenko).
• Correction d'échecs de suites de tests parasites avec grep 2.10. Bug corrigé # 996483 (Alexey Kopytov).
• Lorsque innobackupex fonctionnait avec --apply-log, il lisait la configuration à partir du fichier de configuration du serveur au lieu de backup-my.cnf dans le répertoire de sauvegarde. Bug corrigé # 996493 (Sergei Glushchenko).
• innobackupex peut copier des fichiers dans un mauvais répertoire lors de la fusion d'une sauvegarde incrémentielle en une sauvegarde complète. Bug corrigé # 1002688 (Alexey Kopytov).
• XtraBackup binaire fuyait des descripteurs de fichier sur --backup. Cela a été corrigé en réutilisant le descripteur de fichier existant afin qu'aucune fuite ne se produise. Bug corrigé # 713267 (Alexey Kopytov).

Quoi de neuf dans la version 2.0.4:

• Bogues corrigés:
• Le correctif de # 932623 introduisait la régression dans XtraBackup 2.0.2 qui provoquait l'échec des sauvegardes incrémentielles car les valeurs des paramètres init n'étaient pas normalisées par rapport aux valeurs utilisées dans InnoDB. Bug corrigé # 1062684 (Sergei Glushchenko).
• Le correctif de # 932623 introduisait la régression dans XtraBackup 2.0.2 car il ne prenait pas l'espace de table doublewrite séparé dans un compte. Bug corrigé # 1066843 (Sergei Glushchenko).
• XtraBackup traitait le fichier de tampon doublewrite séparément de manière incorrecte. Le chemin de fichier du tampon doublewrite n'a pas été ajouté à la sauvegarde-my.cnf et après l'ancien fichier de restauration de la mémoire tampon doublewrite a été utilisé au lieu d'un fichier créé pendant l'étape de préparation. Bug corrigé # 1068470 (Sergei Glushchenko).
• XtraBackup accepte maintenant l'option --innodb = force, auparavant, il lancerait une erreur si l'option était définie. Bug corrigé # 528752 (Laurynas Biveinis).
• L'option safe-slave-backup ne fonctionnait pas correctement. Bug corrigé # 887803 (Alexey Kopytov).
• Dans le cas où safe-slave-backup-timeout a été atteint lors de l'utilisation de l'option safe-slave-backup, SQL_THREAD est resté à l'état stoppé, provoquant un retard du thread esclave. Ceci a été corrigé en vérifiant l'état initial de SQL_THREAD et en le démarrant avant de terminer avec une erreur de timeout et en démarrant le SQL_THREAD seulement s'il était initialement lancé. Bug corrigé # 1037379 (Alexey Kopytov).
• XtraBackup échouerait sur --apply-log lorsque le système de fichiers ne prend pas en charge Linux AIO. Bug corrigé # 1065561 (Alexey Kopytov).
• Le binaire XtraBackup ignorait innodb_use_native_aio lorsqu'il est spécifié dans my.cnf ou comme option de ligne de commande. Bug corrigé # 1068459 (Alexey Kopytov).
• XtraBackup affichera un message d'avertissement lors de la phase de préparation à propos de la suppression de l'objet innodb_file_io_threads, même si la variable n'a pas été définie. Bug corrigé # 1068485 (Alexey Kopytov).
• Les tests XtraBackup Galera peuvent maintenant être exécutés simultanément. Bug corrigé # 1077800 (Stewart Smith).

Quoi de neuf dans la version 2.0.3:

• Nouvelles fonctionnalités:
• innobackupex supporte maintenant une nouvelle option -move-back qui peut être utilisée à la place de -copy-back au cas où il n'y aurait pas assez d'espace libre sur le serveur pour copier les fichiers. Comme cette option supprime les fichiers de sauvegarde, elle doit être utilisée avec précaution.
• Bogues corrigés:
• Symlink pour binaire innobackupex-1.5.1 a été rompu dans la version précédente de XtraBackup. Bug corrigé # 1038198 (Ignacio Nin).
• XtraBackup 2.0.2 n'était pas rétrocompatible, ce qui a entraîné l'échec des sauvegardes incrémentielles créées avec les versions précédentes. Bug corrigé # 1038127 (Sergei Glushchenko).
• Correction du bug # 1022562 introduit une régression qui peut potentiellement conduire à une augmentation de 5 fois l'espace disque occupé par les sauvegardes incrémentielles. Bug corrigé # 1043762 (Laurynas Biveinis).
• Une régression a été introduite dans le correctif pour le bogue n ° 932623 qui a causé une mauvaise gestion des tablespaces compressées avec la taille de page de 16K, qui ont été créées entre la dernière sauvegarde complète ou incrémentielle et la sauvegarde incrémentielle suivante. Bugs corrigés # 1049174 et # 1044398 (Laurynas Biveinis).

Quoi de neuf dans la version 1.6.4:

• Il contient des corrections de bogues importantes pour la série stable 1.6 des versions de Percona XtraBackup.