PolarDB:Restauration de bases de données et de tables : restauration à un instant donné

Prérequis

Un ensemble de sauvegarde doit être disponible. La restauration à un instant donné commence par restaurer une sauvegarde complète des données effectuée avant l'instant sélectionné vers le cluster. Elle utilise ensuite les journaux redo pour restaurer les données incrémentielles jusqu'à l'instant choisi. Pour accélérer la restauration, vous pouvez activer la sauvegarde améliorée, ce qui réduit le cycle de sauvegarde et augmente la densité des sauvegardes.

Scénarios

Remarques d'utilisation

• La restauration à un instant donné consiste à sélectionner un moment précis pour restaurer les tables de base de données. Après la restauration, les tables ne contiennent que les données telles qu'elles existaient à cet instant. Autrement dit, les données des tables dans la base de données sont cohérentes avec celles présentes à ce moment précis.

• Actuellement, la méthode « Restore to a past point in time » pour la restauration des bases de données et des tables prend uniquement en charge la restauration à partir d'une sauvegarde de niveau 1. La restauration à partir d'une sauvegarde de niveau 2 n'est pas prise en charge.

• La restauration des bases de données et des tables échoue dans les scénarios suivants.

  • Le nom de la base de données ou de la table spécifié existe déjà dans le cluster d'origine.

  • Entre le moment de la génération du jeu de sauvegarde et l'instant de restauration, la table à restaurer a été supprimée, ou le cluster contient une base de données ou une table portant le même nom que la base de données ou la table de destination.

• La restauration des bases de données et des tables ne restaure que les tables spécifiées. Assurez-vous de sélectionner toutes les tables que vous souhaitez restaurer.

  Remarque

  Si vous ne pouvez pas identifier toutes les tables concernées, restaurez les données historiques de l'ensemble du cluster vers un nouveau cluster, puis migrez les données vers le cluster d'origine. Pour plus d'informations, consultez les rubriques Restaurer à partir d'un jeu de sauvegarde et Restaurer un cluster à un instant donné.

• Si vous ne restaurez pas une base de données entière, vous pouvez restaurer jusqu'à 100 tables de cette base de données à la fois. Si vous restaurez une base de données complète, toutes les tables de celle-ci seront restaurées.

  Remarque

  • La restauration d'un grand nombre de tables simultanément prend beaucoup de temps ; évitez donc de restaurer trop de tables en une seule fois.

  • Si vous devez restaurer un grand nombre de tables, il est préférable de restaurer l'intégralité des données historiques vers un nouveau cluster. Pour connaître la procédure détaillée, consultez les rubriques Restaurer à partir d'un jeu de sauvegarde et Restaurer un cluster à un instant donné.

• Vous pouvez utiliser la restauration des bases de données et des tables même si un cluster contient plus de 50 000 tables, y compris les tables système.

  Remarque

  • Cette fonctionnalité est actuellement en version Canary. Pour l'utiliser, vous pouvez Nous contacter afin de rejoindre la liste d'autorisation et d'activer la fonctionnalité.

  • Interrogez le nombre de tables, y compris les tables système, dans le cluster. Exécutez l'instruction SQL suivante :

    SELECT COUNT(*) FROM information_schema.tables;

  • Interrogez le nombre de tables système dans le cluster. Exécutez l'instruction SQL suivante :

    SELECT COUNT(*) FROM information_schema.tables WHERE table_schema IN ('sys', 'performance_schema', 'mysql', 'information_schema', '__recycle_bin__');

• La restauration des bases de données et des tables ne prend pas en charge la restauration des déclencheurs (triggers). Si la table d'origine possède un déclencheur, celui-ci n'est pas restauré.

• La restauration des bases de données et des tables ne prend pas en charge la restauration des clés étrangères. Si la table d'origine possède une clé étrangère, celle-ci n'est pas restaurée.

• Effectuez la restauration des données pendant les heures creuses.

Étape 1 : Identifier l'heure de l'erreur de manipulation

Si vous connaissez déjà l'heure de l'opération accidentelle, vous pouvez ignorer cette étape. Si vous n'êtes pas certain de l'heure exacte, suivez ces instructions pour la déterminer.

Méthode 1 : SQL Explorer

Si vous avez activé SQL Explorer pour votre cluster PolarDB for MySQL Cluster Edition, vous pouvez utiliser cette fonctionnalité pour afficher le journal d'audit et déterminer l'heure de l'opération accidentelle.

SQL Explorer ne peut afficher que les journaux SQL générés après l'activation de la fonctionnalité. Si SQL Explorer n'était pas activé sur le cluster au moment de l'incident, utilisez la Méthode 2.

Méthode 2 : Récupérer et analyser les journaux binaires à distance

1. Activez la journalisation binaire pour le cluster. Pour obtenir des instructions détaillées, consultez la rubrique Activer la journalisation binaire.

   Remarque

   Vous devez activer la journalisation binaire pour le cluster avant de pouvoir afficher et récupérer le journal binaire. Sinon, une erreur You are not using binary logging est renvoyée.

2. Installez MySQL sur votre serveur local et connectez-vous au cluster à l'aide d'un client MySQL. Pour obtenir des instructions détaillées, consultez la rubrique Se connecter à un cluster de base de données. Cette rubrique utilise un système Linux comme exemple.

   root@xxx:~# mysql -h xxx-polardb.rwlb.rds.aliyuncs.com -P3306 -utest_api -p
   Enter password:
   Welcome to the MySQL monitor.  Commands end with ; or \g.
   Your MySQL connection id is xxx
   Server version: 8.0.13 Source distribution
   Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
   Oracle is a registered trademark of Oracle Corporation and/or its
   affiliates.  Other names may be trademarks of their respective
   owners.
   Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
   mysql>

3. Dans le client MySQL connecté, exécutez la commande suivante pour afficher la liste des fichiers de journaux binaires du cluster cible :

   show binary logs;

   La commande renvoie la sortie suivante :

   +------------------+-----------+
   | Log_name         | File_size |
   +------------------+-----------+
   | mysql-bin.000005 |      2639 |
   +------------------+-----------+
   1 row in set (0.00 sec)

4. Récupérez le journal binaire à distance et enregistrez-le sur votre machine locale.

   Cette rubrique utilise un système Linux comme exemple. Commencez par exécuter exit pour quitter le client MySQL. Ensuite, exécutez la commande suivante pour récupérer le journal binaire.

   mysqlbinlog -u<username> -p<password> -h<endpoint> --read-from-remote-server --raw mysql-bin.******

   Paramètre	Description	Exemple
   -u	Le nom d'utilisateur du compte de base de données dans le cluster.	test_api
   -p	Le mot de passe du compte. Si vous laissez ce champ vide, vous serez invité à le saisir après l'exécution de la commande.	TestPwd123
   -h	L'endpoint public du cluster. Remarque Si l'endpoint de votre cluster utilise le port par défaut 3306, vous pouvez omettre le numéro de port. Sinon, vous devez ajouter le numéro de port à l'endpoint. Actuellement, vous ne pouvez récupérer le journal binaire à distance que via l'endpoint public du nœud principal ou d'un endpoint de cluster (y compris les endpoints de cluster par défaut et personnalisés). Pour savoir comment demander un endpoint public, consultez la rubrique Gérer les endpoints.	test-polardb.rwlb.rds.aliyuncs.com
   --read-from-remote-server	Indique que le journal binaire est lu depuis le serveur MySQL, et non depuis un fichier journal local.	--read-from-remote-server
   --raw	Indique que le fichier de journal binaire récupéré est imprimé dans son format d'origine plutôt que sous forme de données analysées.	--raw
   mysql-bin.	Le nom du fichier de journal binaire cible, tel qu'il apparaît dans la colonne Log_name issue de la commande show binary logs;.	mysql-bin.000005

   Exemple :

   mysqlbinlog -utest_api -p -htest-polardb.rwlb.rds.aliyuncs.com --read-from-remote-server --raw mysql-bin.000005

5. Exécutez la commande suivante pour afficher le contenu du fichier de journal binaire à l'aide de l'outil mysqlbinlog :

   mysqlbinlog -vv --base64-output=decode-rows mysql-bin.****** | more

   Remarque

   • -vv : Affiche les instructions SQL spécifiques et les commentaires.

   • --base64-output=decode-rows : Analyse le fichier de journal binaire.

   La sortie est similaire à la suivante :

   [root@iZxxx ~]# mysqlbinlog -vv --base64-output=decode-rows mysql-bin.000110 | more
   /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
   /*!40019 SET @@session.max_insert_delayed_threads=0*/;
   /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
   DELIMITER /*!*/;
   # at 4
   #160217 23:04:37 server id 2802943055  end_log_pos 107  Start: binlog v 4, server v 5.5.18.1-log created 160217 23:04:37
   # at 107
   #160217 23:04:38 server id 2802943055  end_log_pos 171  Query    thread id=584632    exec time=0    error code=0
   SET TIMESTAMP=1xxx8/*!*/;
   SET @@session.pseudo_thread_id=584632/*!*/;
   SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
   SET @@session.sql_mode=2097152/*!*/;
   SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
   /*!\C utf8 *//*!*/;
   SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
   SET @@session.lc_time_names=0/*!*/;
   SET @@session.collation_database=DEFAULT/*!*/;
   BEGIN
   /*!*/;
   # at 171

6. Une fois que vous avez récupéré le contenu du fichier de journal binaire, vous pouvez analyser le journal binaire.

Étape 2 : Démarrer la restauration des bases de données et des tables

1. Connectez-vous à la console PolarDB. Dans le volet de navigation de gauche, cliquez sur Clusters. Sélectionnez la Region où le cluster est déployé, puis cliquez sur l'ID du cluster pour accéder à la page des détails du cluster.

2. Dans le volet de navigation de gauche, accédez à Settings and Management > Backup and Restoration, puis cliquez sur Restore Databases/Tables.

3. Dans la boîte de dialogue qui s'affiche, définissez le paramètre Restoration Type sur Point in Time et sélectionnez l'instant souhaité pour le paramètre Restoration Time.

   Remarque

   • La valeur de Restoration Time doit se situer dans la plage définie par le paramètre Restore To. Par ailleurs, pour que la fonctionnalité de restauration Point in Time fonctionne correctement, l'ensemble de sauvegarde complète le plus proche de l'instant sélectionné doit contenir la table à restaurer. La plage des instants de restauration disponibles dépend de la période de conservation spécifiée par le paramètre Log Retention Period (Days) dans les paramètres de sauvegarde. La valeur par défaut est de 7 jours.

   • En fonction de la consommation d'IOPS, la restauration de bases de données et de tables propose trois configurations de vitesse de restauration : Quick, Standard et Secure. Choisissez une configuration adaptée à vos besoins. Pour connaître le temps estimé requis pour chaque configuration de vitesse de restauration, consultez la rubrique Données de test de référence pour la vitesse de restauration des bases de données et des tables.

     • Quick : La restauration des données vers le cluster actuel peut consommer un grand nombre d'IOPS. Privilégiez cette configuration pendant les heures creuses.

     • Standard (recommandé pour les spécifications supérieures à 4 cœurs) : La restauration des données vers le cluster actuel peut consommer une partie des IOPS.

     • Secure (recommandé pour les spécifications inférieures ou égales à 4 cœurs) : La restauration des données vers le cluster actuel ne consomme qu'un faible nombre d'IOPS, mais peut réduire considérablement la vitesse de restauration.

     Pour les clusters dont les spécifications sont inférieures ou égales à 4 cœurs, assurez-vous que les paramètres innodb_io_capacity et innodb_io_capacity_max correspondent aux spécifications. Pour consulter les spécifications des clusters et le nombre maximal d'IOPS pris en charge, reportez-vous aux rubriques Spécifications des nœuds de calcul pour l'édition Enterprise et Spécifications des nœuds de calcul pour l'édition Standard, et utilisez la vitesse de restauration Secure.

4. Dans la section Databases and Tables to Restore, sélectionnez la base de données cible à restaurer dans la partie gauche, puis choisissez les tables cibles dans la partie droite.

   Remarque

   • Si vous ne spécifiez pas de nouveaux noms de base de données ou de tables, le système les génère automatiquement en ajoutant le suffixe _backup au nom d'origine. Par exemple, si la table d'origine est test, le nom de table généré automatiquement sera test_backup.

   • Si vous sélectionnez une base de données cible sans spécifier de tables, toutes les données de cette base de données sont restaurées par défaut.

5. Une fois que vous avez confirmé la sélection des bases de données et des tables à restaurer, cliquez sur OK.

Étape 3 : Comparer les données

Une fois la restauration des bases de données et des tables terminée, connectez-vous au cluster pour comparer et vérifier les données.

Vous pouvez vous connecter au cluster via Data Management Service (DMS), un autre client ou la ligne de commande. Cette rubrique décrit la procédure de connexion au cluster via DMS pour vérifier les données. Pour en savoir plus sur les autres méthodes, consultez la rubrique Se connecter à un cluster.

1. Dans le coin supérieur droit de la page Basic Information du cluster, cliquez sur Log on to Database.

2. Dans la boîte de dialogue qui s'affiche, saisissez le Database Account et le Database Password du cluster, puis cliquez sur Search.

3. Après vous être connecté à DMS, actualisez la page. Dans le volet de navigation de gauche, cliquez sur Logged in instance.

4. Dans la liste Logged in instance, cliquez sur le nom du cluster cible, puis recherchez et double-cliquez sur le nom de la base de données cible pour basculer vers celle-ci et la gérer.

5. Localisez les données affectées par l'opération accidentelle. Vérifiez si les données ont bien été restaurées à leur état antérieur à l'opération et si les autres données correspondent également à cet état.