Data Management:Suppression des données historiques

Prérequis

• La base de données est MySQL.

• L'instance de base de données utilise le mode de contrôle Stable Change ou Security Collaboration control mode.

Procédure

1. Connectez-vous à DMS 5.0.

2. Dans la barre de navigation supérieure, accédez à Database Development > Data Change > Historical Data Cleanup.

   Remarque

   En mode simple DMS, cliquez sur l'icône située en haut à gauche, puis sélectionnez All Features > Database Development > Data Change > Historical Data Cleanup.

3. Sur la page de demande de ticket Data Change, configurez les paramètres du ticket et cliquez sur Submit.

   Paramètres clés :

   Parameter	Description
   Database	Sélectionnez une base de données pour laquelle vous disposez d'autorisations de modification. Les autorisations en lecture seule ou au niveau de la table ne suffisent pas. View My Permissions.
   Deletion Settings	Saisissez le Table Name, le Time Field, la Time Accuracy, la Retention Period (Days) et la Filter Condition (Nullable). Le système génère automatiquement un script de nettoyage basé sur ces informations. Remarque Pour les tables logiques, saisissez le nom de la table logique. La période de rétention définit le moment où les données sont automatiquement supprimées. Par exemple, une période de rétention de 7 jours supprime les données datant de plus de 7 jours. Par exemple : si le Table Name est api_call_record_11, le Time Field est gmt_create, la Retention Period est 7 et la Filter Condition est status = 1 or status=2, l'instruction SQL suivante est générée : DELETE FROM api_call_record_11 WHERE gmt_create < SUBDATE(CURDATE(),INTERVAL 7 DAY) AND (status = 1 or status=2);
   Schedule	DMS supprime les données par lots en se basant sur la clé primaire ou une clé unique non nulle. Planifiez le nettoyage pendant les heures creuses et à faible fréquence afin de minimiser l'impact sur les performances. Remarque L'exécution réelle peut s'écarter d'une minute par rapport à l'heure planifiée. L'intervalle minimal pour l'exécution planifiée est d'une heure. Par défaut, la tâche s'exécute tous les jours à 02:00.
   Policy Configuration	Spécifiez une durée d'exécution. La tâche s'interrompt automatiquement après la durée indiquée pour éviter d'impacter les services pendant les heures de pointe. Execute Task Without End Time. Specify End Time (Hours) : définissez une limite de durée pour empêcher que les pipelines de synchronisation en aval (tels que DTS ou AnalyticDB) ne soient affectés. Après avoir spécifié la durée, vous pouvez activer l'option Periodically Optimize Table (défragmentation), désactivée par défaut. Cette option exécute OPTIMIZE TABLE après un nombre spécifié de cycles de nettoyage. Valeur par défaut : tous les 60 cycles. Remarque La fonctionnalité OPTIMIZE TABLE est prise en charge uniquement pour les bases de données RDS for MySQL et PolarDB for MySQL. L'opération OPTIMIZE TABLE est limitée par la durée d'exécution définie dans la configuration de la politique. L'opération OPTIMIZE TABLE s'arrête lorsque cette durée expire.
   Change Stakeholder	Les parties prenantes spécifiées peuvent consulter le ticket et collaborer dessus. Sinon, seuls les administrateurs et les DBA y ont accès.

4. Après avoir soumis le ticket, vous pouvez activer une vérification du retard de réplication, définir un seuil ou modifier l'instruction SQL.

   • (Facultatif) Activez une vérification du retard de réplication pour éviter qu'un retard excessif n'affecte les basculements entre les instances principales et secondaires.

     Dans la section Basic Information, cliquez sur chunk option pour définir un seuil de retard de réplication en secondes. L'exécution SQL est interrompue si le retard dépasse ce seuil.

     Remarque

     Actuellement, cette fonctionnalité est prise en charge uniquement pour les bases de données ApsaraDB RDS for MySQL.

   • (Facultatif) Modifiez l'instruction SQL.

     Le système effectue automatiquement une prévalidation SQL. Si la prévalidation échoue, modifiez l'instruction SQL en fonction de la raison de l'échec et réessayez.

   Remarque

   Avant de soumettre le ticket pour approbation, vous pouvez modifier les configurations d'exécution par lots et de planification. Une fois soumis, ces paramètres ne peuvent plus être modifiés.

5. Cliquez sur Submit. En mode Security Collaboration, le ticket est envoyé pour approbation selon les règles configurées. En mode Stable Change, il est automatiquement approuvé.

6. Après approbation, le système génère une tâche planifiée et envoie un e-mail au propriétaire du ticket. Dans la section Basic Information, cliquez sur View Scheduled Tasks pour afficher les détails de la planification. Vous pouvez également :

   • Pause Schedule

     Remarque

     Pour désactiver définitivement la planification, ouvrez la page des détails du ticket, cliquez sur Close Ticket en haut à droite, saisissez une raison et cliquez sur Submit.

   • Resume Schedule

     Remarque

     Une fois un ticket clôturé, vous devez soumettre un nouveau ticket pour reprendre la planification.

   • Change Ticket Owner

     Le demandeur est le propriétaire du ticket par défaut. Seul le propriétaire peut suspendre ou reprendre la planification, et les notifications d'exécution sont envoyées exclusivement au propriétaire.

7. Le système exécute l'instruction SQL de nettoyage selon la politique de planification. Consultez les détails de la planification et l'historique d'exécution dans le ticket.

   Remarque

   Si une tâche de nettoyage est déjà en cours à l'heure planifiée, aucune nouvelle tâche n'est créée. Configurez la fréquence d'exécution en conséquence.

FAQ

• Q : L'exécution de OPTIMIZE TABLE dans le cadre d'une tâche Historical Data Cleanup aura-t-elle un impact sur l'activité ?

  R : Cela dépend. Avec l'option Lock-free Schema Change activée, OPTIMIZE TABLE n'a aucun impact sur l'activité. Sans cette option, exécutez OPTIMIZE TABLE pendant les heures creuses. Pour activer Lock-free Schema Change, consultez la rubrique Enable and disable lock-free schema change.

• Q : Comment arrêter une opération OPTIMIZE TABLE qui prend trop de temps ?

  R : Accédez à la page Ticket Details et mettez la tâche en pause dans la section Execute.

• Q : Dois-je mettre en pause Historical Data Cleanup pendant que j'exécute OPTIMIZE TABLE en dehors de DMS ?

  R : Oui, mettez d'abord la tâche en pause. OPTIMIZE TABLE consomme temporairement deux à trois fois la taille de la table, et l'exécution simultanée d'un nettoyage basé sur DELETE augmente la pression sur le disque et peut entraîner l'échec de la tâche. Assurez-vous que l'instance dispose d'au moins autant d'espace disque libre que l'espace de table à récupérer, et exécutez OPTIMIZE TABLE pendant les heures creuses. Reprenez Historical Data Cleanup une fois l'opération terminée.