Chat now with support
Chat with Support

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

Présentation de Plug-in NetVault Backup for MySQL Installation et retrait du plug-in Configuration du plug-in Sauvegarde de données Restauration de données
Restauration de données : présentation Restauration de données dans MySQL Utilisation des procédures de restauration avancées pour MySQL Standard/Community
Utilisation de la réplication native MySQL Utilisation du plug-in dans un environnement de clusters de basculement Dépannage

Sauvegarde de données : présentation

Avant de réaliser une sauvegarde, consultez les informations des rubriques suivantes :

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

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 :

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.
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 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.

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.
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.
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.
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.

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

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.
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.

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

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

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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

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

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

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.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating