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 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. |
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 attribut 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 restauration PIT. Pendant la restauration, 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 pourrait empêcher mysqlbinlog avec l'option --database de relire 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: s'assurer que les tableaux modifiés appartiennent à la base de données spécifiée dans l'instruction USE s'applique aux transactions générées par l'invite de commande MySQL. Cela s'applique également aux 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 restauration.
|
• |
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é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 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éfini 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éfini 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 :
|
• |
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. |
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 :
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 restauration 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 jusqu'à ce qu'ils aient été répliqués vers l'instance esclave, vous êtes responsable du vidage manuel des journaux binaires.
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 pour le lundi, le mardi et le 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).
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 « Copie seule » sont indépendantes d'une séquence de sauvegardes établie et n'affectent pas la possibilité de restauration 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 « Copie » sont indépendantes d'une séquence de sauvegardes établie et n'affectent pas la possibilité de restauration des sauvegardes complètes, incrémentielles ou différentielles. Cependant, elles ne peuvent pas être utilisées en remplacement d'une sauvegarde complète.
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.
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.