NetVault Plug-in for MySQL 12.2 - Guide de l'utilisateur


	IMPORTANT: Quest vous recommande fortement d’omettre les caractères spéciaux dans les noms de base de données. Si le nom d'une base de données contient l’un des caractères suivants, le plug-in ne peut pas la restaurer : $ ^ = @ # % + Comme les données de sauvegarde sont transmises en continu du serveur MySQL directement au Media Manager NetVault Backup, l’utilisation des caractères précédents peut être interprétée comme une commande de séquence, ce qui affecte l’intégrité des données de sauvegarde.

Remarques importantes pour MySQL Standard/Community

Si vous avez l’intention d’utiliser l’option MySQL Standard/Community, consultez les directives et les informations suivantes :

•

Tous les caractères sauf les caractères alphanumériques et les traits de soulignement sont considérés comme des caractères spéciaux

•

Utiliser le format de journalisation binaire MIXED

Tous les caractères sauf les caractères alphanumériques et les traits de soulignement sont considérés comme des caractères spéciaux

Si votre environnement utilise des bases de données dont les noms contiennent des caractères spéciaux, tels que des tirets, soyez conscient des limitations suivantes :

•

Tous les types de tableaux sauf MyISAM sont sauvegardés, même si le nom de la base de données contient des tirets. Ces sauvegardes se produisent parce que la commande mysqldump est toujours utilisée pour ces types de tableaux.

•

Si le nom de la base de données contient des tirets, les tableaux MyISAM sont sauvegardés si la méthode de sauvegarde MyISAM est définie sur l'option Mysqldump introduite dans la version 4.2. Les performances des sauvegardes et des restaurations peuvent être affectées négativement.

•

Si la méthode de sauvegarde MyISAM est configurée pour utiliser l’option par défaut Verrouiller et copier les fichiers du tableau et que le nom de la base de données contient des tirets, les tableaux MyISAM ne sont pas sauvegardés. Les sauvegardes ne sont pas générées car le plug-in contourne les commandes MySQL et tente de copier directement les fichiers de tableau. Le plug-in enregistre un message d’erreur indiquant que le fichier de tableau ne peut pas être localisé, puis fait échouer la session de sauvegarde sans créer d’ensemble de sauvegardes.

Dans les versions précédentes, le plug-in tentait de vérifier l’existence du répertoire de la base de données, enregistrait un message d’avertissement lorsqu’il échouait, et poursuivait avec la sauvegarde de la base de données suivante. La sauvegarde se terminait avec des avertissements et créait un ensemble de sauvegardes qui incluait toutes les autres bases de données.

Si vous le souhaitez, vous pouvez maintenir le comportement d’origine et utiliser l’option Verrouiller et copier les fichiers du tableau pour une raison quelconque, comme un impact moindre sur les performances lorsque vous utilisez l’option Mysqldump. Pour ce faire, réglez manuellement le paramètre ValidateDatabaseDatabaseDirectory sur TRUE dans le fichier de configuration du plug-in, « nvmysql.cfg », comme suit :

[MySql:ValidateDatabaseDirectory]

Value=TRUE

Si vous décidez ensuite d’utiliser plutôt le nouveau comportement, vous pouvez définir ce paramètre sur FALSE ou le supprimer du fichier nvmysql.cfg.

•

La restauration d’une sauvegarde incrémentielle ou différentielle qui inclut des instructions SQL pour créer des bases de données ou des objets de base de données (par exemple, tableau, vue, etc.) échoue si l’une des bases de données ou l’un des objets de base de données existe. Pour éviter ce problème, exécutez une sauvegarde complète après avoir créé ou supprimé une ou plusieurs bases de données ou objets de base de données. Cette étape garantit que les sauvegardes incrémentielles ou différentielles ultérieures n’incluent aucune instruction CREATE ou DROP SQL.

Utiliser le format de journalisation binaire MIXED

MySQL n’impose pas l’utilisation de l’instruction USE lorsque le format de journalisation binaire MIXED est utilisé. Par conséquent, Quest recommande que tous les utilisateurs de la base de données et les programmes s’assurent que les tableaux modifiés se trouvent dans la base de données sélectionnée par l’instruction USE, et qu’aucune mise à jour de la base de données ne soit publiée. Si cette instruction ne convient pas à votre environnement, Quest vous recommande de ne pas utiliser le format de journalisation binaire MIXED.


	IMPORTANT: les sessions de sauvegarde incrémentielle et différentielle sont accompagnées d’un avertissement si le format de journalisation binaire MIXED est used.

Si votre environnement utilise le format de journalisation binaire MIXED, il se peut qu’il empêche les entrées de journal binaire d'être réexécutées pendant une récupération PIT. Pendant la récupération, le plug-in utilise mysqlbinlog avec l’option --database pour réexécuter uniquement les entrées relatives aux bases de données que vous avez sélectionnées pour la session de restauration. Si --database n’est pas utilisé, toutes les entrées sont réexécutées, ce qui affecte toutes les bases de données. Lorsque le format de journalisation binaire MIXED est utilisé, les entrées sont écrites d’une manière qui risque d’empêcher mysqlbinlog avec l’option --database de réexécuter certaines ou toutes les entrées. Pour plus d’informations, voir https://dev.mysql.com/doc/refman/5.7/en/mysqlbinlog.html#option_mysqlbinlog_database.

Pour s’assurer que le format de journalisation binaire MIXED fonctionne correctement avec l’option --database, toutes les transactions pour des mises à jour spécifiques d’une base de données doivent être émises sous une instruction USE qui sélectionne la base de données.

Cette même situation se produit si les sauvegardes incrémentielles ou différentielles ne sont pas restaurées et que mysqlbinlog applique le journal binaire courant du serveur MySQL. Cette situation se produit en raison de la façon dont le journal binaire est écrit, et non en raison du mode de stockage du journal binaire dans la sauvegarde.


	IMPORTANT: lorsque vous veillez à ce que les tableaux modifiés appartiennent à la base de données spécifiée dans l’instruction USE, cela s’applique aux transactions générées par l’invite de commande MySQL. Cela concerne également les transactions générées par des scripts, programmes et autres applications qui interagissent avec les bases de données du serveur MySQL.

Les exemples suivants montrent différentes manières dont MIXED affecte le comportement de récupération.

•

Exemple 1 : dans cet exemple, une ligne de données est insérée dans my_table de my_database. Il n’y a pas d’instruction USE, donc la base de données utilisée est la base de données par défaut, par exemple, la base de données mysql. Si binlog_format est défini sur MIXED, la transaction suivante n’est pas réexécutée lorsque mysqlbinlog applique l’option ‑-database my_database au journal binaire.

-bash-$ mysql

mysql> insert into my_database.my_table (C1,C2) values(1,now());

Query OK, 1 row affected (0.01 sec)

•

Exemple 2 : dans cet exemple, une ligne de données est insérée dans my_table de my_database. Il y a une instruction USE, mais une base de données différente est spécifiée, c’est-à-dire que my_database n’est pas sélectionnée dans l’instruction USE. Si binlog_format est définie sur MIXED, la transaction suivante n’est pas réexécutée lorsque mysqlbinlog applique l’option ‑-database my_database au journal binaire.

-bash-$ mysql

mysql> use mysql

Database changed

mysql> insert into my_database.my_table (C1,C2) values(2,now());

Query OK, 1 row affected (0.04 sec)

•

Exemple 3 : dans cet exemple, une ligne de données est insérée dans my_table de my_database, et my_database est sélectionné dans une instruction USE. Si binlog_format est définie sur MIXED, la transaction suivante est réexécutée lorsque mysqlbinlog applique l'option ‑-database my_database au journal binaire.

-bash-$ mysql

mysql> use my_database

Database changed

mysql> insert into my_database.my_table (C1,C2) values(3,now());

Query OK, 1 row affected (0.04 sec)

•

Exemple 4 : dans cet exemple, il y a deux requêtes d’insertion. La première insertion concerne my_database, qui est différente de la base de données sélectionnée dans l’instruction USE. La deuxième insertion s’effectue dans le cadre d’une instruction USE qui sélectionne my_database. Si binlog_format est définie sur MIXED, la première insertion n'est pas réexécutée parce que my_database n'est pas spécifié dans l'instruction USE, mais la deuxième insertion est réexécutée parce que my_database est spécifié dans l'instruction USE.

-bash-$ mysql

mysql> use mysql

Database changed

mysql> insert into my_database.my_table (C1,C2) values(4,now());

Query OK, 1 row affected (0.01 sec)

mysql> use my_database

Database changed

mysql> insert into my_database.my_table (C1,C2) values(5,now());

Query OK, 1 row affected (0.04 sec)

Remarques importantes pour MySQL Enterprise Backup

Si vous avez l’intention d’utiliser l’option MySQL Enterprise Backup, consultez les instructions et les informations suivantes :

•

MySQL vous recommande d’utiliser les tableaux InnoDB pour les données critiques car le processus de sauvegarde est plus rapide et la fiabilité et l’évolutivité des fonctionnalités sont considérables. MySQL Enterprise Backup vous permet de sauvegarder différents types de tableaux MySQL, et est optimisé pour la sauvegarde des tableaux InnoDB. Cette option effectue une sauvegarde à chaud de tous les tableaux InnoDB. Les sauvegardes à chaud étant effectuées pendant l’exécution de la base de données, la sauvegarde n’arrête pas les opérations en cours de la base de données. De plus, toutes les modifications apportées à la base de données au cours du processus de sauvegarde sont incluses. Ce comportement est important si votre environnement exige que la base de données reste en ligne tout en soutenant sa croissance, ce qui a un impact sur le temps nécessaire à la réalisation d’une sauvegarde.

•

Lorsque vous utilisez cette option, le tableau MyISAM et les autres tableaux non-InnoDB sont sauvegardés en dernier, à l’aide d’une sauvegarde à chaud. Dans une sauvegarde à chaud, la base de données continue de fonctionner, mais les tableaux sont réglés sur l’accès en lecture seule pendant que la sauvegarde est effectuée.

•

Si vous voulez vous assurer que la majeure partie de vos données est sauvegardée pendant la phase de sauvegarde à chaud, pensez à faire d’InnoDB le moteur de stockage par défaut pour les nouveaux tableaux et à convertir les tableaux existants pour qu’ils utilisent le moteur de stockage InnoDB. Sur le serveur MySQL 5.5 et les versions ultérieures, InnoDB est la valeur par défaut.

•

Une sauvegarde incrémentielle est principalement destinée aux tableaux InnoDB et aux tableaux non-InnoDB qui sont en lecture seule ou rarement mis à jour. Pour les fichiers non-InnoDB, le fichier entier est inclus s’il a changé depuis la dernière sauvegarde.

•

Lors de l’utilisation du plug-in, tous les tableaux InnoDB d’une instance MySQL sont sauvegardés si l’une des conditions suivantes est remplie :

•

Seuls les tableaux sont explicitement sélectionnés pour la sauvegarde, et aucun des tableaux n’est de type ou de moteur de stockage InnoDB.

Exemple : vous disposez d’une instance de MySQL avec deux bases de données, DB1 et DB2. Chaque base de données contient deux tableaux : DB1 possède T1_InnoDB et T1_MyISAM, et DB2 possède T2_InnoDB et T2_MyISAM. Si vous sauvegardez T1_MyISAM et T2_MyISAM, T1_InnoDB et T2_InnoDB sont aussi sauvegardés. Si vous incluez l’un des tableaux InnoDB, seul ce tableau InnoDB est sauvegardé. Si vous sélectionnez une des bases de données, seuls les tableaux de la base de données sont sauvegardés.

•

Certaines ou toutes les bases de données sont sélectionnées pour la sauvegarde et tous les tableaux InnoDB associés sont exclus de la sauvegarde.

Exemple : vous disposez d’une instance de MySQL avec deux bases de données, DB1 et DB2. Chaque base de données contient deux tableaux : DB1 possède T1_InnoDB et T1_MyISAM, et DB2 possède T2_InnoDB et T2_MyISAM. Si vous sauvegardez DB1 et DB2 et excluez T1_InnoDB et T2_InnoDB, T1_InnoDB et T2_InnoDB sont aussi sauvegardés. Si vous n’excluez qu’un seul des deux tableaux InnoDB, seul l’autre tableau InnoDB est sauvegardé.

Cette description reflète le comportement actuel de MySQL Enterprise Backup, l’utilitaire mysqlbackup ; ce comportement pourrait changer dans une prochaine version, post-3.12, de MySQL.

•

Dans MySQL 5.6 et les versions ultérieures, l’option de configuration innodb_file_per_table est activée par défaut. Tous les tableaux InnoDB créés avec l’option innodb_file_per_table désactivée sont stockés dans le tablespace du système InnoDB ; ils ne peuvent pas être omis de la sauvegarde. Si vous devez placer un tableau InnoDB en dehors du tablespace, créez-le alors que l’option innodb_file_per_table est activée dans MySQL. Chaque fichier .ibd contient les données et les index d’un seul tableau.

Définition d'une stratégie de sauvegarde

Lorsque vous définissez une stratégie de sauvegarde MySQL, répondez aux questions suivantes :

•

Est-ce que je veux utiliser l'option MySQL Standard/Community ou MySQL Enterprise Backup ? Même si les deux versions sont implémentées dans votre environnement, vous ne pouvez utiliser qu’une seule stratégie avec le plug-in. Utilisez soit la méthode basée sur MEB, soit la méthode basée sur mysqldump ; vous ne pouvez pas utiliser un mélange des deux.

Si vous utilisez l’option basée sur MEB, l’utilitaire mysqlbackup ou le script NetVault Backup applicable est exécuté une fois pour tous les objets de base de données que vous sélectionnez pour la sauvegarde, et un journal de sortie mysqlbackup est inclus dans le journal des sessions. La sauvegarde des données comporte deux étapes. Dans un premier temps, tous les tableaux InnoDB sont copiés. Dans la deuxième étape, tous les autres types de tableaux sont copiés. En plus de prendre en charge la sauvegarde à chaud des tableaux InnoDB, l’option MEB permet d’améliorer les performances de sauvegarde.

Si vous utilisez l’option basée sur mysqldump, la commande est exécutée une fois pour chaque tableau, déclencheur et procédure stockés. Les sauvegardes à chaud ne sont pas prises en charge.

•

Sachant que l’accès en lecture seule sur l’ensemble de l’instance est nécessaire pendant les sauvegardes complètes, à quelle fréquence les sauvegardes complètes doivent-elles être effectuées ?

•

Quelle est la priorité : des sauvegardes plus rapides ou des restaurations plus rapides ?

•

Quelle est la quantité maximale acceptable de perte de données ?

Répondre à ces questions vous aide à définir le type et la fréquence des sauvegardes qui doivent être mises en œuvre.

•

Révision des types de sauvegarde pour MySQL Standard/Community

•

Révision des types de sauvegarde pour MySQL Enterprise Backup

•

Exemples de séquences de sauvegarde pour MySQL Standard/Community

Révision des types de sauvegarde pour MySQL Standard/Community

Si vous utilisez l’option MySQL Standard/Community, le plug-in utilise mysqldump pour fournir les types de sauvegarde suivants :

•

Sauvegarde complète

•

Sauvegarde incrémentielle

•

Sauvegarde différentielle

•

Sauvegarde de copie de base de données/tableau individuel uniquement

•

Sauvegarde de copie de bases de données entières

Comprendre comment ces sauvegardes diffèrent est la première étape dans la sélection d’une séquence de sauvegarde appropriée qui correspond aux exigences de protection des données pour chaque instance MySQL.

Sauvegardes complètes

Dans une sauvegarde complète pour l’option MySQL Standard/Community, le plug-in utilise l’utilitaire mysqldump pour sauvegarder toutes les bases de données incluses dans l’instance. Les sauvegardes complètes sont la base de toute stratégie de sauvegarde, car elles constituent le point de départ de presque tous les scénarios de restauration. Les sauvegardes complètes générées avec le plug-in peuvent être utilisées pour restaurer une instance entière, des bases de données individuelles ou multiples, et des tableaux individuels ou multiples.

L’option Vider les journaux binaires après une sauvegarde complète ou incrémentielle garantit que les journaux binaires sont vidés après une sauvegarde complète ou incrémentielle. Cette option est activée par défaut lorsque le plug-in est utilisé avec une configuration de serveur MySQL standard, Activer la réplication MySQL est désactivé et Activer la récupération PIT est activé. Elle est désactivée lorsque le plug-in est connecté à un cluster ; vous devez gérer le vidage des journaux binaires à l’extérieur du plug-in.


	IMPORTANT: dans un environnement mixte, où un serveur NetVault Backup gère à la fois les serveurs MySQL en cluster et les serveurs MySQL standard, ne réutilisez pas un ensemble d’options de sauvegarde (créé pour un serveur MySQL standard) pour un cluster basé sur MySQL.

Si vous ne sélectionnez pas l’option Vider les journaux binaires..., le plug-in effectue le suivi du dernier journal sauvegardé dans son fichier de configuration ; vous pouvez vider manuellement les journaux binaires à votre discrétion. Par exemple, si vous utilisez un environnement de réplication MySQL dans lequel vous ne voulez pas vider les journaux binaires de l’instance maître tant qu'ils n’ont pas été répliqués sur l’instance esclave, vous êtes responsable du vidage manuel des journaux binaires.

Sauvegardes incrémentielles

Une sauvegarde incrémentielle sauvegarde les journaux de transactions qui ont été générés depuis la dernière sauvegarde complète ou incrémentielle, elle est suivie du vidage des journaux binaires. Comme les journaux binaires sont instanciés, les journaux des transactions de chaque base de données sont sauvegardés et vidés en tant qu’unité.

Les sauvegardes incrémentielles sont essentielles pour réduire les pertes de données après une panne de support ou une corruption de données. Vous pouvez utiliser les sauvegardes incrémentielles pour restaurer les données à un moment situé avant et après une corruption de données, comme une mise à jour incorrecte ou un tableau supprimé. Contrairement aux sauvegardes complètes, les sauvegardes incrémentielles ne nécessitent pas d’accès en lecture seule pendant la sauvegarde.

Les sauvegardes incrémentielles MySQL nécessitent que vous démarriez l’instance MySQL avec l’option -log-bin, qui active le journal binaire. Cette procédure est décrite dans Activer le journal binaire sur le serveur MySQL (option Standard/Community uniquement). Pour plus d’informations, voir la section Journal binaire dans le MySQL Reference Guide (Guide de référence MySQL).

Comme décrit précédemment, l’option Vider les journaux binaires après une sauvegarde complète ou incrémentielle garantit que les journaux binaires sont vidés après une sauvegarde complète ou incrémentielle. Si vous n’utilisez pas cette option, le plug-in effectue le suivi du dernier journal sauvegardé dans son fichier de configuration, et vous pouvez vider manuellement les journaux binaires à votre discrétion.

Sauvegardes différentielles

Une sauvegarde différentielle sauvegarde les journaux de transactions qui ont été générés depuis la dernière sauvegarde complète ou incrémentielle. Cependant, les journaux binaires ne sont pas vidés à la fin de la sauvegarde. Par conséquent, les sauvegardes différentielles ultérieures augmentent en taille et en durée. La taille et la durée augmentent parce que chaque sauvegarde de ce type inclut les journaux binaires qui étaient également inclus dans la sauvegarde différentielle précédente et les journaux binaires qui ont été générés depuis la sauvegarde différentielle précédente. Par exemple, si une sauvegarde complète a été effectuée le dimanche avec des sauvegardes différentielles programmées du lundi au samedi, la sauvegarde différentielle du lundi inclut les journaux binaires générés depuis la sauvegarde complète du dimanche, tandis que la sauvegarde différentielle du mardi inclut les journaux binaires générés le lundi et les journaux générés le mardi. La sauvegarde différentielle du mercredi inclut les journaux binaires du lundi, mardi et mercredi, et ainsi de suite.

Semblable à une sauvegarde incrémentielle, une sauvegarde différentielle peut également être utilisée pour réduire la perte de données après une panne de support ou une corruption de données, avec la possibilité de restaurer à une heure antérieure et postérieure à la panne ou à la corruption. Contrairement à une sauvegarde complète, une sauvegarde différentielle ne nécessite pas d’accès en lecture seule pendant la sauvegarde.

Les sauvegardes différentielles nécessitent que vous démarriez l’instance MySQL avec l’option -log-bin, qui active le journal binaire. Cette procédure est décrite dans Activer le journal binaire sur le serveur MySQL (option Standard/Community uniquement). Pour plus d’informations, voir la section Journal binaire dans le MySQL Reference Guide (Guide de référence MySQL).

Sauvegardes incrémentielles et différentielles

Comme les sauvegardes incrémentielles vident les journaux binaires après leur sauvegarde, les sauvegardes incrémentielles suivantes sont plus rapides car seuls les journaux binaires créés depuis la dernière sauvegarde incrémentielle sont sauvegardés. Cependant, les séquences de restauration qui utilisent des sauvegardes incrémentielles exigent que chaque sauvegarde incrémentielle effectuée entre la sauvegarde complète et le point d’échec soit restaurée successivement. Ce processus peut entraîner des restaurations plus longues en raison de l’intervention accrue des administrateurs de bases de données, nécessaire pour initier les multiples sessions de restauration.

Comme les sauvegardes différentielles ne vident pas les journaux binaires après leur sauvegarde, chaque sauvegarde différentielle suivante prend plus de temps car tous les journaux binaires depuis la dernière sauvegarde complète sont inclus dans la sauvegarde. Néanmoins, les séquences de restauration qui utilisent des sauvegardes différentielles exigent qu’une seule sauvegarde différentielle soit restaurée après la restauration de la sauvegarde complète. Ce processus permet d’accélérer les restaurations car il limite l’intervention des administrateurs de bases de données pendant le processus de restauration.

Sauvegardes de copie de base de données/tableau individuel uniquement

Parfois, une sauvegarde doit être effectuée à des fins particulières et ne devrait pas affecter les procédures globales de sauvegarde et de restauration d’une base de données complète. Par exemple, les sauvegardes peuvent être une source pour un environnement de test ou une synchronisation initiale pour une instance esclave de réplication. Les sauvegardes de copie de base de données/tableau individuel uniquement sont conçues à ces fins spéciales, en ce sens qu’elles vous permettent de « copier » un environnement MySQL. Les sauvegardes de « Copie seule » sont indépendantes d’une séquence de sauvegardes établie et n’affectent pas la récupération des sauvegardes complètes, incrémentielles ou différentielles. Cependant, elles ne peuvent pas être utilisées en remplacement d’une sauvegarde complète.

Sauvegardes de copie de bases de données entières

Comme décrit pour les sauvegardes de copie de base de données/tableau individuel uniquement, l’option Sauvegarde de copie de bases de données entières n’est utilisée qu’à des fins spéciales car elle crée une copie des bases de données MySQL sélectionnées, y compris tous les tableaux InnoDB correspondants des bases de données sélectionnées. Les sauvegardes de « Copie » sont indépendantes d’une séquence de sauvegardes établie et n’affectent pas la récupération des sauvegardes complètes, incrémentielles ou différentielles. Cependant, elles ne peuvent pas être utilisées en remplacement d'une sauvegarde complète.


	IMPORTANT: Vous ne pouvez utiliser cette option que si tous les tableaux des bases de données sélectionnées sont des tableaux InnoDB.

Sauvegardes de copie de base de données/tableau individuel uniquement et Sauvegardes de copie de bases de données entières

Pour chaque base de données sélectionnée, même si un seul tableau de la base de données est sélectionné, l’option Sauvegarde de copie de bases de données entières sauvegarde l’ensemble de la base de données. Cette option vous permet de sélectionner des bases de données individuelles pour la sauvegarde, mais elle ne vous permet pas de sélectionner des tableaux individuels. De plus, cette option ne prend en charge que la sauvegarde des tableaux InnoDB.

L’option Sauvegarde de copie de base de données/tableau individuel uniquement vous permet de sélectionner des bases de données individuelles et des tableaux individuels. De plus, vous pouvez inclure les tableaux InnoDB et MyISAM dans la sauvegarde. Cependant, les sauvegardes sont généralement plus rapides avec l’option Sauvegarde de copie de bases de données entières qu’avec l’option Sauvegarde de copie de base de données/tableau individuel uniquement.

Révision des types de sauvegarde pour MySQL Enterprise Backup

Pour l’option MySQL Enterprise Backup, le plug-in exécute la commande mysqlbackup une fois pour tous les objets de base de données sélectionnés afin d’obtenir les types de sauvegarde suivants : complète, incrémentielle et TTS.

Sauvegardes complètes

Dans une sauvegarde complète pour l’option MySQL Enterprise Backup, le plug-in utilise l’utilitaire mysqlbackup ou le script NetVault Backup applicable pour sauvegarder tous les objets de la base de données sélectionnée inclus dans l’instance. Les sauvegardes complètes sont la base de toute stratégie de sauvegarde, car elles constituent le point de départ de presque tous les scénarios de restauration. Les sauvegardes complètes générées avec le plug-in peuvent être utilisées pour restaurer une instance entière, des bases de données individuelles ou multiples, et des tableaux individuels ou multiples.

Sauvegardes incrémentielles

Pour un tableau InnoDB, seules les données qui ont changé depuis la dernière sauvegarde complète ou incrémentielle sont sauvegardées. Pour un tableau non-InnoDB, le tableau entier est sauvegardé si un élément a changé dans le tableau depuis la dernière sauvegarde complète ou incrémentielle.

Sauvegardes de tablespace transportable (TTS)

Si vous effectuez une sauvegarde TTS, le plug-in émet une sauvegarde complète et ajoute l’option MySQL --use-tts.


	IMPORTANT: Quest vous recommande fortement de générer des sauvegardes TTS uniquement en tant que sauvegardes autonomes, séparées de votre plan de sauvegarde. Comme les sauvegardes TTS sont des sauvegardes partielles, vous ne pouvez pas les utiliser pour remplacer ou compléter une stratégie de sauvegarde complète ou incrémentielle, ni pour une opération de reprise après sinistre.

Si vous avez l’intention de générer des sauvegardes TTS, soyez conscient des limitations suivantes :

•

Les sauvegardes TTS ne sont prises en charge que dans MySQL Server 5.6 et les versions ultérieures.

•

Seuls les tableaux InnoDB sont inclus dans la sauvegarde.

•

Seuls les tableaux créés avec l’option innodb_file_per_table activée sont inclus dans la sauvegarde.

•

La sauvegarde d’un tableau partitionné échoue si la partition a été créée dans un tablespace partagé.

•

La sauvegarde exclut le journal binaire ou de relais.

Pour plus d’informations sur les limitations de l’option --use-tts, voir https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/backup-partial-options.html.