Validation des données AWS DMS - AWS Service de Migration de Base de Données

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Validation des données AWS DMS

AWS DMS assure la prise en charge de la validation des données, afin de garantir que vos données ont été migrées avec précision de la source vers la cible. Si elle est activée, la validation commence immédiatement après un chargement complet d'une table. La validation compare les modifications incrémentielles d'une tâche avec capture des données modifiées activée au fur et à mesure qu'elles apparaissent.

Lors de la validation des données, AWS DMS compare chaque ligne de la source avec sa ligne correspondante dans la cible, vérifie que les lignes contiennent les mêmes données et signale toute incohérence. Pour ce faire, AWS DMS émet les requêtes appropriées pour récupérer les données. Notez que ces requêtes consomment des ressources supplémentaires au niveau de la source et de la cible, ainsi que des ressources réseau supplémentaires.

Pour une tâche de CDC uniquement avec la validation activée, toutes les données préexistantes d'une table sont validées avant le début de la validation de nouvelles données.

La validation de données fonctionne avec les bases de données sources suivantes quand AWS DMS les prend en charge en tant que points de terminaison sources :

  • Oracle

  • Base de données compatible PostgreSQL (PostgreSQL, Aurora PostgreSQL ou Aurora sans serveur pour PostgreSQL)

  • Base de données compatible MySQL (MySQL, MariaDB, Aurora MySQL ou Aurora sans serveur pour MySQL)

  • Microsoft SQL Server

  • IBM Db2 LUW

La validation des données fonctionne avec les bases de données cibles suivantes quand AWS DMS les prend en charge en tant que points de terminaison cibles :

  • Oracle

  • Base de données compatible PostgreSQL (PostgreSQL, Aurora PostgreSQL ou Aurora sans serveur pour PostgreSQL)

  • Base de données compatible MySQL (MySQL, MariaDB, Aurora MySQL ou Aurora sans serveur pour MySQL)

  • Microsoft SQL Server

  • IBM Db2 LUW

  • Amazon Redshift

  • Amazon S3. Pour en savoir plus sur la validation des données cibles Amazon S3, consultez Validation des données cibles Amazon S3.

Pour plus d'informations sur les points de terminaison pris en charge, consultez Utilisation des points de terminaison AWS DMS.

La validation des données nécessite du temps supplémentaire, au-delà de celui requis pour la migration elle-même. Le temps supplémentaire requis dépend de la quantité de données ayant migré.

Pour plus d'informations sur ces paramètres, consultez la page Paramètres de la tâche de validation des données.

Pour obtenir un exemple de paramètres de tâche ValidationSettings dans un fichier JSON, consultez Exemple de paramètres de tâche.

Statistiques des tâches de réplication

Lorsque la validation des données est activée, AWS DMS fournit les statistiques suivantes au niveau de la table :

  • ValidationState : état de validation de la table. Le paramètre peut avoir les valeurs suivantes :

    • Not enabled – La validation n'est pas activée pour la table de la tâche de migration.

    • Pending records – Certains enregistrements de la table sont en attente de validation.

    • Enregistrements non concordants : certains enregistrements de la table ne concordent pas entre la source et la cible. Une incohérence peut se produire pour diverses raisons. Pour plus d'informations, consultez la table awsdms_control.awsdms_validation_failures_v1 sur le point de terminaison cible.

    • Suspended records (Enregistrements suspendus) – Certains enregistrements de la table ne peuvent pas être validés.

    • No primary key (Aucune clé primaire) – La table ne peut pas être validée, car elle n'avait pas de clé primaire.

    • Table error (Erreur de table) – La table n'a pas été validée, car elle était dans un état d'erreur et certaines données n'ont pas été migrées.

    • Validé : toutes les lignes de la table sont validées. Si la table est mise à jour, l'état peut devenir Validated.

    • Error (Erreur) – La table ne peut pas être validée en raison d'une erreur inattendue.

    • En attente de validation : la table attend sa validation.

    • Préparation de la table : préparation de la table activée dans la tâche de migration pour validation.

    • En attente de revalidation : toutes les lignes de la table sont en attente de validation après la mise à jour de la table.

  • ValidationPending (Validation en attente) – Nombre d'enregistrements qui ont été migrés vers la cible, mais qui n'ont pas encore été validés.

  • ValidationSuspended – Nombre d'enregistrements qu'AWS DMS ne peut pas comparer. Par exemple, si un enregistrement de la source est constamment mis à jour, AWS DMS ne peut pas comparer la source et la cible.

  • ValidationFailed : nombre d'enregistrements qui n'ont pas réussi la phase de validation des données.

Pour obtenir un exemple de paramètres de tâche ValidationSettings dans un fichier JSON, consultez Exemple de paramètres de tâche.

Vous pouvez consulter les informations de validation des données à l'aide de la console, d'AWS CLI ou de l'API AWS DMS.

  • Sur la console, vous pouvez choisir de valider une tâche lorsque vous créez ou modifiez la tâche. Pour afficher le rapport de validation des données à l'aide de la console, choisissez la tâche sur la page Tâches et choisissez l'onglet Statistiques de table dans la section des détails.

  • À l'aide de l'interface de ligne de commande, définissez le paramètre EnableValidation sur true lorsque vous créez ou modifiez une tâche pour commencer la validation des données. L'exemple suivant crée une tâche et active la validation des données.

    create-replication-task --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}' --replication-instance-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q --source-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CSZAEFQURFYMM --target-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CGPP7MF6WT4JQ --migration-type full-load-and-cdc --table-mappings '{"rules": [{"rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": {"schema-name": "data_types", "table-name": "%"}, "rule-action": "include"}]}'

    Utilisez la commande describe-table-statistics pour recevoir le rapport de validation des données au format JSON. La commande suivante affiche le rapport de validation des données.

    aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q

    Le rapport doit se présenter comme suit :

    { "ReplicationTaskArn": "arn:aws:dms:us-west-2:5731014:task:VFPFTYKK2RYSI", "TableStatistics": [ { "ValidationPendingRecords": 2, "Inserts": 25, "ValidationState": "Pending records", "ValidationSuspendedRecords": 0, "LastUpdateTime": 1510181065.349, "FullLoadErrorRows": 0, "FullLoadCondtnlChkFailedRows": 0, "Ddls": 0, "TableName": "t_binary", "ValidationFailedRecords": 0, "Updates": 0, "FullLoadRows": 10, "TableState": "Table completed", "SchemaName": "d_types_s_sqlserver", "Deletes": 0 } }
  • À l'aide de l'API AWS DMS, créez une tâche utilisant l'action CreateReplicationTask et définissez le paramètre EnableValidation sur true pour valider les données qui ont été migrées par la tâche. Utilisez l'action DescribeTableStatistics pour recevoir le rapport de validation des données au format JSON.

Statistiques des tâches de réplication avec Amazon CloudWatch

Quand Amazon CloudWatch est activé, AWS DMS fournit les statistiques suivantes sur les tâches de réplication :

  • ValidationSucceededRecordCount : nombre de lignes validées par minute par AWS DMS.

  • ValidationAttemptedRecordCount - Nombre de lignes pour lesquelles la validation a été tentée, par minute.

  • ValidationFailedOverallCount - Nombre de lignes pour lesquelles la validation a échoué.

  • ValidationSuspendedOverallCount - Nombre de lignes pour lesquelles la validation a été suspendue.

  • ValidationPendingOverallCount - Nombre de lignes pour lesquelles la validation est toujours en attente.

  • ValidationBulkQuerySourceLatency : AWS DMS peut effectuer la validation en bloc des données, en particulier dans certains scénarios lors d'un chargement complet ou d'une réplication continue avec de nombreuses modifications. Cette métrique indique le temps de latence requis pour lire un ensemble de données à partir du point de terminaison source.

  • ValidationBulkQueryTargetLatency : AWS DMS peut effectuer la validation en bloc des données, en particulier dans certains scénarios lors d'un chargement complet ou d'une réplication continue avec de nombreuses modifications. Cette métrique indique le temps de latence requis pour lire un ensemble de données en direction du point de terminaison cible.

  • ValidationItemQuerySourceLatency : au cours de la réplication continue, la validation des données peut identifier les modifications en cours et les valider. Cette métrique indique le temps de latence lors de la lecture de ces modifications à partir de la source. La validation peut exécuter plus de requêtes que nécessaire, en fonction du nombre de modifications, si des erreurs se produisent lors de la validation.

  • ValidationItemQueryTargetLatency : au cours de la réplication continue, la validation des données peut identifier les modifications en cours et les valider ligne par ligne. Cette métrique indique le temps de latence lors de la lecture de ces modifications à partir de la cible. La validation peut exécuter plus de requêtes que nécessaire, en fonction du nombre de modifications, si des erreurs se produisent lors de la validation.

Pour collecter des informations de validation des données à partir des statistiques activées par CloudWatch, sélectionnez Activer CloudWatch Logs lorsque vous créez ou modifiez une tâche à l'aide de la console. Ensuite, pour consulter les informations de validation des données et garantir que vos données ont été migrées avec précision depuis la source vers la cible, procédez comme suit.

  1. Choisissez la tâche sur la page Tâches de migration de base de données.

  2. Choisissez l'onglet Métriques CloudWatch.

  3. Sélectionnez Validation dans le menu déroulant.

Revalidation de tables pendant une tâche

Pendant l'exécution d'une tâche, vous pouvez demander à AWS DMS d'effectuer une validation des données.

AWS Management Console

  1. Connectez-vous à la AWS Management Console et ouvrez la console AWS DMS à l'adresse https://console.aws.amazon.com/dms/v2/.

    Si vous êtes connecté en tant qu'utilisateur AWS Identity and Access Management (IAM), veillez à disposer des autorisations appropriées pour accéder à AWS DMS. Pour connaître les autorisations requises, consultez Autorisations IAM nécessaires pour utiliser AWS DMS.

  2. Choisissez Tâches dans le volet de navigation.

  3. Choisissez la tâche en cours d'exécution contenant la table à revalider.

  4. Choisissez l'onglet Statistiques de table.

  5. Choisissez la table à revalider (vous pouvez choisir jusqu'à 10 tables en même temps). Si la tâche n'est plus en cours d'exécution, vous ne pouvez pas revalider la ou les tables.

  6. Choisissez Revalider.

Utilisation de l'éditeur JSON pour modifier les règles de validation

Pour ajouter une règle de validation à une tâche à l'aide de l'éditeur JSON depuis la console AWS DMS, procédez comme suit :

  1. Sélectionnez Tâches de migration de base de données.

  2. Sélectionnez votre tâche dans la liste des tâches de migration.

  3. Si votre tâche est en cours d'exécution, sélectionnez Arrêter dans le menu déroulant Actions.

  4. Une fois la tâche arrêtée, pour modifier votre tâche, sélectionnez Modifier dans le menu déroulant Actions.

  5. Dans la section Mappages de table, sélectionnez Éditeur JSON et ajoutez votre règle de validation à vos mappages de tables.

Par exemple, vous pouvez ajouter la règle de validation suivante pour exécuter une fonction de remplacement sur la source. Dans ce cas, si la règle de validation rencontre un octet null, elle le valide en tant qu'espace.

{ "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "Test-Schema", "table-name": "Test-Table", "column-name": "Test-Column" }, "rule-action": "override-validation-function", "source-function": "REPLACE(${column-name}, chr(0), chr(32))", "target-function": "${column-name}" }

Tâches de validation uniquement

Vous pouvez créer des tâches de validation uniquement pour prévisualiser et valider les données sans effectuer de migration ni de réplication de données. Pour créer une tâche de validation uniquement, définissez les paramètres EnableValidation et ValidationOnly sur true. Lors de l'activation de ValidationOnly, des exigences supplémentaires s'appliquent. Pour de plus amples informations, veuillez consulter Paramètres de la tâche de validation des données.

Pour un type de migration à chargement complet uniquement, une tâche de validation uniquement s'exécute beaucoup plus rapidement que son équivalent CDC lorsque de nombreux échecs sont signalés. Toutefois, les modifications apportées au point de terminaison source ou cible sont signalées comme des échecs en mode de chargement complet, ce qui peut constituer un inconvénient.

Une tâche de validation CDC uniquement retarde la validation en fonction de la latence moyenne et effectue de nouvelles tentatives en cas d'échecs avant de les signaler. Si la majorité des comparaisons de données aboutissent à des échecs, une tâche de validation uniquement pour le mode CDC est très lente, ce qui constitue un inconvénient potentiel.

Une tâche de validation uniquement doit être configurée dans le même sens que la tâche de réplication, en particulier pour la CDC. Cela est dû au fait qu'une tâche de validation CDC uniquement détecte les lignes qui ont changé et doivent être revalidées en fonction du journal des modifications de la source. Si la cible est spécifiée en tant que source, elle ne connaît que les modifications envoyées à la cible par DMS et il n'est pas garanti qu'elle détecte les erreurs de réplication.

Validation du chargement complet uniquement

À partir de AWS DMS version 3.4.6, une tâche de validation de chargement complet uniquement compare rapidement toutes les lignes des tables source et cible en un seul passage, signale immédiatement tous les échecs, puis s'arrête. La validation n'est jamais suspendue en raison d'échecs dans ce mode, elle est optimisée pour la vitesse. Toutefois, les modifications apportées au point de terminaison source ou cible sont signalées comme des échecs.

Note

À partir de AWS DMS version 3.4.6, ce comportement de validation s'applique également à la tâche de migration à chargement complet avec validation activée.

Validation CDC uniquement

Une tâche de validation CDC uniquement valide toutes les lignes existantes entre les tables source et cible lors d'un nouveau départ. En outre, une tâche de validation CDC uniquement s'exécute en continu, revalide les modifications de réplication continue, limite le nombre d'échecs signalés à chaque passage et effectue de nouvelles tentatives avec les lignes non concordantes avant de signaler un échec. Elle est optimisée pour éviter les faux positifs.

La validation d'une table (ou de l'ensemble de la tâche) est suspendue si les seuils FailureMaxCount ou TableFailureMaxCount sont dépassés. Cela s'applique également à une tâche de migration CDC ou Chargement complet+CDC avec la validation activée. De plus, une tâche CDC avec la validation activée retarde la revalidation pour chaque ligne modifiée en fonction de la latence moyenne sur la source et la cible.

Toutefois, une tâche de validation CDC uniquement ne migre pas de données et n'a pas de latence. Elle définit ValidationQueryCdcDelaySeconds sur 180 par défaut. Vous pouvez également augmenter ce montant pour tenir compte des environnements à latence élevée et éviter les faux positifs.

Cas d'utilisation relatifs à la validation uniquement

Les cas d'utilisation pour scinder la partie validation des données d'une tâche de migration ou de réplication en une tâche de validation uniquement distincte incluent, sans toutefois s'y limiter, les cas suivants :

  • Contrôlez exactement le moment où la validation a lieu : les requêtes de validation ajoutent une charge supplémentaire aux points de terminaison sources et cibles. Il peut donc être avantageux de migrer ou de répliquer les données d'abord dans une tâche, puis de valider les résultats dans une autre tâche.

  • Réduisez la charge sur l'instance de réplication : il peut être avantageux de diviser la validation des données pour l'exécuter sur sa propre instance.

  • Obtenez rapidement le nombre de lignes qui ne correspondent pas à un moment donné : par exemple, juste avant ou pendant une interruption de production pendant une fenêtre de maintenance par rapport à un point de terminaison cible, vous pouvez créer une tâche de validation de chargement complet uniquement pour obtenir une réponse à votre question.

  • Lorsque des échecs de validation sont attendus pour une tâche de migration avec un composant CDC : par exemple, lors de la migration de données varchar2 Oracle vers jsonb PostgreSQL, la validation CDC réessaie sans cesse ces lignes qui ont échoué et limite le nombre d'échecs signalés chaque fois. Mais vous pouvez créer une tâche de validation de chargement complet uniquement et obtenir une réponse plus rapide.

  • Vous avez développé un script/utilitaire de réparation de données qui lit la table des échecs de validation : (voir également, Résolution des problèmes). Une tâche de validation de chargement complet uniquement signale rapidement les échecs afin que le script de réparation des données puisse agir.

Pour obtenir un exemple de paramètres de tâche ValidationSettings dans un fichier JSON, consultez Exemple de paramètres de tâche.

Résolution des problèmes

Pendant la validation, AWS DMS crée une nouvelle table au point de terminaison de la cible : awsdms_control.awsdms_validation_failures_v1. Si l'état d'un enregistrement devient ValidationSuspended ou ValidationFailed, AWS DMS écrit les informations de diagnostic sur awsdms_control.awsdms_validation_failures_v1. Vous pouvez interroger cette table pour aider à résoudre les erreurs de validation.

Pour en savoir plus sur la modification du schéma par défaut dans lequel la table est créée sur la cible, consultez Paramètres de tâche de la table de contrôle.

Voici une description de la table awsdms_control.awsdms_validation_failures_v1 :

Nom de la colonne Type de données Description

TASK_NAME

VARCHAR(128) NOT NULL

Identificateur de tâche AWS DMS.

TABLE_OWNER VARCHAR(128) NOT NULL

Schéma (propriétaire) de la table.

TABLE_NAME

VARCHAR(128) NOT NULL

Nom de la table.

FAILURE_TIME DATETIME(3) NOT NULL

Heure où la défaillance s'est produite.

KEY_TYPE VARCHAR(128) NOT NULL

Réservé pour une utilisation future (la valeur est toujours « Row »)

KEY TEXT NOT NULL

Il s'agit de la clé primaire du type Row Record.

FAILURE_TYPE VARCHAR(128) NOT NULL

Gravité de l'erreur de validation. Peut avoir la valeur RECORD_DIFF, MISSING_SOURCE ou MISSING_TARGET.

DETAILS VARCHAR(8000) NOT NULL

Chaîne au format JSON contenant toutes les valeurs des colonnes source/cible qui ne correspondent pas pour la clé donnée.

La requête suivante affiche toutes les défaillances d'une tâche en interrogeant la table awsdms_control.awsdms_validation_failures_v1. Le nom de la tâche doit être l'ID de ressource externe de la tâche. L'ID de ressource externe de la tâche est la dernière valeur de l'ARN de la tâche. Par exemple, pour une tâche avec la valeur d'ARN arn:aws:dms:us-west-2:5599:task: VFPFKH4FJR3FTYKK2RYSI, l'ID de ressource externe de la tâche sera VFPFKH4FJR3FTYKK2RYSI.

select * from awsdms_validation_failures_v1 where TASK_NAME = 'VFPFKH4FJR3FTYKK2RYSI' TASK_NAME VFPFKH4FJR3FTYKK2RYSI TABLE_OWNER DB2PERF TABLE_NAME PERFTEST FAILURE_TIME 2020-06-11 21:58:44 KEY_TYPE Row KEY {"key": ["3451491"]} FAILURE_TYPE RECORD_DIFF DETAILS [[{'MYREAL': '+1.10106036e-01'}, {'MYREAL': '+1.10106044e-01'}],]

Vous pouvez examiner le champ DETAILS pour déterminer quelles colonnes ne correspondent pas. Comme vous avez la clé primaire de l'enregistrement ayant échoué, vous pouvez interroger les points de terminaison sources et cibles pour voir quelle partie de l'enregistrement ne correspond pas.

Performances de validation Redshift

Amazon Redshift se distingue des bases de données relationnelles à plusieurs égards : stockage en colonnes, MPP, compression des données, etc. Ces différences confèrent à Redshift un profil de performance différent de celui des bases de données relationnelles.

Pendant la phase de réplication à chargement complet, la validation utilise des requêtes d’intervalle, la taille des données étant régie par le paramètre PartitionSize. Ces requêtes d’intervalle sélectionnent tous les enregistrements de la table source.

Pour une réplication continue, les requêtes passent d’une recherche par intervalle à une recherche par enregistrement. Le type de requête est déterminé dynamiquement en fonction de plusieurs facteurs, tels que :

  • Volume des requêtes

  • Types de requêtes DML sur la table source

  • Latence des tâches

  • Nombre total d’enregistrements

  • Paramètres de validation tels que PartitionSize

Il est possible que votre cluster Amazon Redshift soit soumis à une charge supplémentaire en raison des requêtes de validation. Comme les facteurs ci-dessus varient selon les cas d’utilisation, vous devez passer en revue les performances de vos requêtes de validation et ajuster votre cluster et votre table en conséquence. Parmi les options permettant d’atténuer les problèmes de performances, citons les suivantes :

  • Réduisez les paramètres PartitionSize et ThreadCount pour réduire la charge de travail pendant la validation à chargement complet. Notez que la validation des données sera ralentie.

  • Bien que Redshift n’applique pas de clés primaires, AWS DMS s’appuie sur des clés primaires pour identifier de manière unique les enregistrements sur la cible à des fins de validation des données. Si possible, définissez la clé primaire de manière à ce qu’elle corresponde à la clé de tri, afin que les requêtes de validation à chargement complet s’exécutent plus rapidement.

Limites

  • La validation des données exige que la table dispose d'une clé primaire ou d'un index unique.

    • Les colonnes de clé primaire ne peuvent pas être de type CLOB, BLOB ou BYTE.

    • Pour les colonnes de clé primaire de type VARCHAR ou CHAR, la longueur doit être inférieure à 1 024. Vous devez spécifier la longueur du type de données. Vous ne pouvez pas utiliser de types de données de longueur illimitée comme clé primaire pour la validation des données.

    • Une clé Oracle créée avec la clause NOVALIDATE n'est pas considérée comme une clé primaire ou un index unique.

    • Pour une table Oracle sans clé primaire et uniquement avec une clé unique, les colonnes avec la contrainte unique doivent également avoir une contrainte NOT NULL.

  • La validation des valeurs NULL PK/UK n'est pas prise en charge.

  • Si le classement de la colonne de clé primaire dans l'instance PostgreSQL cible n'est pas défini sur « C », l'ordre de tri de la clé primaire est différent de celui d'Oracle. Si l'ordre de tri est différent dans PostgreSQL et dans Oracle, la validation des données ne parvient pas à valider les enregistrements.

  • La validation des données génère des requêtes supplémentaires sur les bases de données source et cible. Vous devez vous assurer que les deux bases de données aient des ressources suffisantes pour gérer cette charge supplémentaire. Cela est particulièrement vrai pour les cibles Redshift. Pour plus d’informations, consultez Performances de validation Redshift ci-après.

  • La validation des données n'est pas prise en charge si plusieurs bases de données sont consolidées en une seule.

  • Pour un point de terminaison Oracle source ou cible, AWS DMS utilise DBMS_CRYPTO pour valider les LOB. Si votre point de terminaison Oracle utilise les LOB, vous devez accorder l'autorisation d'exécution sur dbms_crypto au compte d'utilisateur qui permet d'accéder au point de terminaison Oracle. Vous pouvez le faire en exécutant l'instruction suivante :

    grant execute on sys.dbms_crypto to dms_endpoint_user;
  • Si la base de données cible est modifiée en dehors d'AWS DMS pendant la validation, les écarts peuvent ne pas être signalés avec précision. Ce résultat peut se produire si l'une de vos applications écrit des données dans la table cible, tandis qu'AWS DMS exécute la validation sur cette même table.

  • Si une ou plusieurs lignes sont modifiées de façon continue au cours de la validation, AWS DMS ne peut pas valider ces lignes.

  • Si AWS DMS détecte plus de 10 000 enregistrements suspendus ou ayant échoué, il arrête la validation. Avant de poursuivre, vous devez résoudre les problèmes sous-jacents relatifs aux données.

  • AWS DMS ne prend pas en charge la validation des données des vues.

  • AWS DMS ne prend pas en charge la validation des données lorsque les paramètres de tâche de substitution de caractères sont utilisés.

  • AWS DMS ne prend pas en charge la validation du type Oracle LONG.

  • AWS DMS ne prend pas en charge la validation du type Oracle Spatial lors d'une migration hétérogène.

Pour connaître les limites d’utilisation de la validation des cibles S3, consultez Limitations liées à l'utilisation de la validation des cibles S3.