Sauvegarde fractionnée

Une stratégie de sauvegarde fractionnée consiste à migrer un serveur de base de données volumineux en divisant la sauvegarde en plusieurs parties. Vous pouvez utiliser différentes approches pour migrer chaque partie de la sauvegarde. Cela peut être la meilleure option pour les cas d'utilisation suivants :

• Grand serveur de base de données mais petites bases de données individuelles : cette approche est recommandée lorsque la taille totale du serveur de base de données est de plusieurs To, mais que la taille de chaque base de données utilisateur indépendante est inférieure à 1 To. Pour réduire la période de migration globale, vous pouvez migrer chaque base de données séparément et en parallèle.

  Prenons l'exemple d'un serveur de base de données de 2 To sur site. Ce serveur est composé de quatre bases de données de 0,5 To chacune. Vous pouvez effectuer des sauvegardes de chaque base de données séparément. Lors de la restauration de la sauvegarde, vous pouvez soit restaurer toutes les bases de données d'une instance en parallèle, soit, si les bases de données sont indépendantes, vous pouvez restaurer chaque sauvegarde sur une instance distincte. Il est recommandé de restaurer des bases de données indépendantes sur des instances distinctes, au lieu de les restaurer sur la même instance. Pour plus d'informations, consultez la section Bonnes pratiques de ce guide.

• Grand serveur de base de données mais petites tables de base de données individuelles : il s'agit d'une bonne approche lorsque la taille totale du serveur de base de données est de plusieurs To, mais que la taille de chaque table de base de données indépendante est inférieure à 1 To. Pour réduire la période de migration globale, vous pouvez migrer des tables indépendantes individuellement.

  Prenons l'exemple d'une base de données mono-utilisateur de 1 To, qui est la seule base de données d'un serveur de base de données sur site. La base de données contient 10 tables, chacune d'une capacité de 100 Go. Vous pouvez effectuer des sauvegardes de chaque table séparément. Lors de la restauration de la sauvegarde, vous pouvez restaurer toutes les tables d'une instance en parallèle.

• Une base de données contient des tables de charge de travail transactionnelles et non transactionnelles. Comme dans le cas d'utilisation précédent, vous pouvez utiliser une approche de sauvegarde fractionnée lorsque vous avez des tables de charge de travail transactionnelles et non transactionnelles dans la même base de données.

  Prenons l'exemple d'une base de données de 2 To composée de 0,5 To de tables de charge de travail critiques utilisées pour le traitement des transactions en ligne (OLTP) et d'une seule table de 1,5 To utilisée pour archiver les anciennes données. Vous pouvez effectuer la sauvegarde de tous les objets de base de données, à l'exception de la table d'archive, dans le cadre d'une sauvegarde cohérente et unique. Ensuite, vous effectuez une autre sauvegarde séparée de la table d'archive uniquement. Pour la sauvegarde de la table d'archive, vous pouvez également envisager d'effectuer plusieurs sauvegardes parallèles en utilisant des conditions pour diviser le nombre de lignes du fichier de sauvegarde. Voici un exemple :

  mysqldump -p your_db1 --tables your_table1 --where=“column1 between 1 and 1000000 " > your_table1_part1.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql

  Lors de la restauration des fichiers de sauvegarde, vous pouvez restaurer la sauvegarde de la charge de travail transactionnelle et la sauvegarde de la table d'archivage en parallèle.

• Limitations des ressources de calcul : si les ressources de calcul du serveur local sont limitées, telles que le processeur, la mémoire ou les E/S de disque, cela peut affecter la stabilité et les performances lors de la sauvegarde. Au lieu de faire une sauvegarde complète, vous pouvez la diviser en plusieurs parties.

  Par exemple, un serveur de production sur site peut être chargé de charges de travail importantes et disposer de ressources CPU limitées. Si vous effectuez une sauvegarde en une seule exécution d'une base de données de plusieurs téraoctets sur ce serveur, cela peut consommer des ressources CPU supplémentaires et affecter négativement le serveur de production. Au lieu d'effectuer la sauvegarde complète de la base de données, divisez-la en plusieurs parties, telles que 2 à 3 tables chacune.