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. # AWS Validation des données DMS **Topics** + [ ## Statistiques des tâches de réplication ](#CHAP_Validating.TaskStatistics) + [ ## Statistiques des tâches de réplication avec Amazon CloudWatch ](#CHAP_Validating.TaskStatistics.CloudWatch) + [ ## Revalidation de tables pendant une tâche ](#CHAP_Validating.Revalidating) + [ ## Utilisation de l’éditeur JSON pour modifier les règles de validation ](#CHAP_Validating.JSONEditor) + [ ## Tâches de validation uniquement ](#CHAP_Validating.ValidationOnly) + [ ## Résolution des problèmes ](#CHAP_Validating.Troubleshooting) + [ ## Performances de validation Redshift ](#CHAP_Validating.Redshift) + [ ## Validation des données améliorée pour AWS Database Migration Service ](#CHAP_Validating_Enhanced) + [ ## Limitations ](#CHAP_Validating.Limitations) + [ # Validation des données cibles Amazon S3 ](CHAP_Validating_S3.md) + [ # AWS DMS resynchronisation des données ](CHAP_Validating.DataResync.md) AWS DMS fournit un support pour la validation des données afin de garantir que vos données ont été migrées correctement 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 la ligne correspondante de la cible, vérifie que les lignes contiennent les mêmes données et signale toute incompatibilité. Pour ce faire, AWS DMS lancez des 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 des données fonctionne avec les bases de données sources suivantes partout où elles sont prises AWS DMS en charge en tant que points de terminaison source : + 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 partout où elles sont prises AWS DMS 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](CHAP_Validating_S3.md). Pour plus d'informations sur les points de terminaison pris en charge, consultez [Utilisation des points de AWS terminaison DMS](CHAP_Endpoints.md). 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](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md). Pour obtenir un exemple de paramètres de tâche `ValidationSettings` dans un fichier JSON, consultez [Exemple de paramètres de tâche](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). ## 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**: l'é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**: le nombre d'enregistrements qui ont été migrés vers la cible, mais qui n'ont pas encore été validés. + **ValidationSuspended**: le nombre d'enregistrements AWS DMS impossibles à comparer. Par exemple, si un enregistrement à la source est constamment mis à jour, AWS DMS vous ne pouvez pas comparer la source et la cible. + **ValidationFailed**: le nombre d'enregistrements qui n'ont pas passé 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](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). Vous pouvez consulter les informations de validation des données à l'aide de la console AWS CLI, de ou de l' AWS DMS API. + 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' AWS DMS API, créez une tâche à l'aide de l'**CreateReplicationTask**action et définissez le `EnableValidation` paramètre sur **true** pour valider les données migrées par la tâche. Utilisez cette **DescribeTableStatistics**action pour recevoir le rapport de validation des données au format JSON. ## Statistiques des tâches de réplication avec Amazon CloudWatch Lorsque Amazon CloudWatch est activé, AWS DMS fournit les statistiques suivantes sur les tâches de réplication : + **ValidationSucceededRecordCount**— Nombre de lignes AWS DMS validées, par minute. + **ValidationAttemptedRecordCount**— Nombre de lignes que la validation a été tentée, par minute. + **ValidationFailedOverallCount**— Nombre de lignes où la validation a échoué. + **ValidationSuspendedOverallCount**— Nombre de lignes où la validation a été suspendue. + **ValidationPendingOverallCount**— Nombre de lignes où la validation est toujours en attente. + **ValidationBulkQuerySourceLatency**— AWS DMS peut effectuer une validation des données en masse, en particulier dans certains scénarios lors d'un chargement complet ou d'une réplication continue lorsque de nombreuses modifications sont apportées. 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 une validation des données en masse, en particulier dans certains scénarios lors d'un chargement complet ou d'une réplication continue lorsque de nombreuses modifications sont apportées. 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 en cours, la validation des données permet d'identifier les modifications en cours et de valider ces modifications. 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 en cours, la validation des données permet d'identifier les modifications en cours et de valider les modifications 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 CloudWatch activées, sélectionnez **Activer CloudWatch les journaux** 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**. 1. Choisissez l'onglet **CloudWatch Metrics**. 1. 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 à effectuer une validation des données. ### AWS Management Console 1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). Si vous êtes connecté en tant qu'utilisateur Gestion des identités et des accès AWS (IAM), assurez-vous de disposer des autorisations d'accès appropriées AWS DMS. Les autorisations requises, voir[Autorisations IAM nécessaires pour utiliser AWS DMS](security-iam.md#CHAP_Security.IAMPermissions). 1. Choisissez **Tasks** dans le volet de navigation. 1. Choisissez la tâche en cours d'exécution contenant la table à revalider. 1. Choisissez l'onglet **Table Statistics** (Statistiques de la table). 1. 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. 1. 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 AWS DMS console, procédez comme suit : 1. Sélectionnez **Tâches de migration de base de données**. 1. Sélectionnez votre tâche dans la liste des tâches de migration. 1. Si votre tâche est en cours d’exécution, sélectionnez **Arrêter** dans le menu déroulant **Actions**. 1. Une fois la tâche arrêtée, pour modifier votre tâche, sélectionnez **Modifier** dans le menu déroulant **Actions**. 1. 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}" } ``` **Note** `override-validation-function`ne prend pas effet si la colonne fait partie de la clé primaire. ## 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](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md). 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 le 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 la version 3.4.6 et des versions ultérieures, une tâche de validation du chargement complet uniquement compare rapidement toutes les lignes des tables source et cible en un seul passage, signale immédiatement tout échec, 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 la version 3.4.6 et des versions ultérieures, 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\$1CDC 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é une réparation de données script/utility qui lit le tableau des échecs de validation* (voir également,[Résolution des problèmes](#CHAP_Validating.Troubleshooting)). 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](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). ## Résolution des problèmes Lors de la validation, AWS DMS crée une nouvelle table au point de terminaison cible :`awsdms_control.awsdms_validation_failures_v1`. Si un enregistrement passe à l'état *ValidationSuspended*ou à l'*ValidationFailed*état, AWS DMS écrit les informations de diagnostic dans`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](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md). 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` | AWS DMS identifiant de tâche. | | TABLE\$1OWNER | VARCHAR(128) NOT NULL | Schéma (propriétaire) de la table. | | `TABLE_NAME` | VARCHAR(128) NOT NULL | Nom de la table. | | FAILURE\$1TIME | DATETIME(3) NOT NULL | Heure où la défaillance s'est produite. | | KEY\$1TYPE | 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\$1TYPE | VARCHAR(128) NOT NULL | Gravité de l'erreur de validation. Peut être l'un ou l'autre `RECORD_DIFF` `MISSING_SOURCE``MISSING_TARGET`, ou`TABLE_WARNING`. | | DETAILS | VARCHAR(8000) NOT NULL | Chaîne au format JSON contenant toutes les valeurs de source/target colonne qui ne correspondent pas à la clé donnée. | Voici un exemple de requête pour une cible MySQL qui vous montrera tous les échecs d'une tâche en interrogeant la `awsdms_control.awsdms_validation_failures_v1` table. Notez que le nom du schéma et la syntaxe des requêtes varient selon les versions du moteur cible. 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 dont la valeur ARN est arn:aws:dms:us-west- 2:5599:task : VFPFKH4 FJR3 FTYKK2 RYSI, l'ID de ressource externe de la tâche serait RYSI. VFPFKH4 FJR3 FTYKK2 ``` 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. ### `awsdms_validation_failures_v2`table de commande Lors de la validation, dans les AWS DMS versions 3.6.1 et supérieures, DMS crée une nouvelle table sur le point de terminaison cible de PostgreSQL :. `awsdms_validation_failures_v2` Ce tableau répertorie les échecs de toutes les tâches DMS pour lesquelles la validation des données est activée. Lorsque la `awsdms_validation_failures_v2` table est créée, vous ne devez pas la supprimer ou la tronquer, car cela peut entraîner des erreurs pour les tâches lorsque la validation et la resynchronisation sont activées. `awsdms_validation_failures_v2`la table possède une fonction de clé primaire à incrémentation automatique. Ce tableau comprend de nouvelles colonnes destinées à prendre en charge la fonctionnalité de resynchronisation des données. Il s'agit des options suivantes : `RESYNC_RESULT` **Valeurs** : `SUCCESS` ou`FAILURE`. **`RESYNC_TIME`** Horodatage avec une précision de la milliseconde. La valeur par défaut est `NULL` si aucune tentative de resynchronisation des données n'est effectuée pour cet échec. **`RESYNC_ACTION`** **Valeurs** : `UPSERT` ou`DELETE`. `RESYNC_ID` Colonne clé primaire avec incrémentation automatique activée. Dans le `awsdms_validation_failures_v2` tableau, un index est ajouté aux `FAILURE_TIME` colonnes`TASK_NAME`,, `TABLE_OWNER` `TABLE_NAME``FAILURE_TYPE`, et afin de lire efficacement les échecs pour une table donnée de votre base de données cible. Vous trouverez ci-dessous un exemple d'instruction create pour créer une `awsdms_validation_failures_v2` table : ``` CREATE TABLE public.awsdms_validation_failures_v2 ( "RESYNC_ID" int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL, CONSTRAINT awsdms_validation_failures_v2_pkey PRIMARY KEY ("RESYNC_ID") ); ``` ## 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 les clés primaires, elle AWS DMS s'appuie sur les 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. ## Validation des données améliorée pour AWS Database Migration Service AWS Database Migration Service a amélioré les performances de validation des données pour les migrations de bases de données, permettant aux clients de valider de grands ensembles de données avec des temps de traitement nettement plus rapides. Cette validation améliorée des données est désormais disponible dans la version 3.5.4 du moteur de réplication pour le chargement complet et le chargement complet avec les tâches de migration CDC. Actuellement, cette amélioration prend en charge les chemins de migration d'Oracle vers PostgreSQL, de SQL Server vers PostgreSQL, d'Oracle vers Oracle et de SQL Server vers SQL Server, des chemins de migration supplémentaires étant prévus pour les futures versions. ### Conditions préalables + *Oracle :* accordez l'`EXECUTE`autorisation `SYS.DBMS_CRYPTO` au compte utilisateur qui accède au point de terminaison Oracle : ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user; ``` + Installez l'`pgcrypto`extension sur la base de données PostgreSQL : Pour les instances PostgreSQL autogérées, vous devez installer les bibliothèques de modules et `contrib` créer l'extension : + Installez les bibliothèques `contrib` de modules. Par exemple, sur une instance Amazon EC2 avec Amazon Linux et PostgreSQL 15 : ``` sudo dnf install postgresql15-contrib ``` + Créez l'`pgcrypto`extension : ``` CREATE EXTENSION IF NOT EXISTS pgcrypto; ``` + Pour les instances Amazon RDS for PostgreSQL, configurez le mode SSL pour le point de terminaison : AWS DMS + Par défaut, Amazon RDS force une connexion SSL. Lorsque vous créez un AWS DMS point de terminaison pour une instance Amazon RDS for PostgreSQL, utilisez l'option « mode SSL » = « required ». + Si vous souhaitez utiliser l'option « mode SSL » = « none », définissez le `rds.force_ssl` paramètre sur 0 dans le groupe de paramètres RDS. + Pour PostgreSQL 12 et 13, créez l'agrégat : `BIT_XOR` ``` CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit); ``` ### Limites de validation des données améliorées Cette fonctionnalité améliorée de validation des données présente les limites suivantes : + Exigences relatives aux points de terminaison de base de données : Cette amélioration est activée uniquement pour les points de terminaison de base de données qui répondent aux critères suivants : + AWS Secrets Manager À utiliser pour stocker les informations d'identification. + Pour Microsoft SQL Server, l'authentification Kerberos est également prise en charge. + Support des versions de base de données : + PostgreSQL 12 et versions ultérieures + Oracle 12.1 et versions ultérieures + Pour les versions de Microsoft SQL Server antérieures à 2019, la validation des types de données NCHAR et NVARCHAR n'est pas prise en charge. ## Limitations + 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``BINARY`,, 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 PK/UK valeurs NULL 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](#CHAP_Validating.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`. Si vous utilisez la validation des données sur le point de terminaison Oracle, vous devez accorder l'autorisation d'exécution `dbms_crypto` au compte utilisateur utilisé pour 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 de la AWS DMS période de validation, les incohérences risquent de ne pas être signalées avec précision. Ce résultat peut se produire si l'une de vos applications écrit des données dans la table cible alors qu'elle AWS DMS effectue une validation sur cette même table. + Si une ou plusieurs lignes sont continuellement modifiées pendant la validation, vous ne AWS DMS pouvez pas valider ces lignes. + S'il AWS DMS détecte plus de 10 000 enregistrements défaillants ou suspendus, 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 des tâches 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. + La validation des données ignore les colonnes des tables pour lesquelles des transformations de masquage de données existent dans le mappage des tables. + La validation des données ignore une table entière s'il existe une règle de transformation par masquage des données pour sa PK/UK colonne. L'état de validation indiquera « Aucune clé primaire » pour ces tables. + La validation des données ne fonctionne pas avec Amazon Aurora PostgreSQL Limitless. Lorsque vous tentez de valider des tables dans une base de données illimitée, l'état de validation indique « Aucune clé primaire » pour ces tables. 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](CHAP_Validating_S3.md#CHAP_Validating_S3_limitations). # Validation des données cibles Amazon S3 AWS DMS prend en charge la validation des données répliquées dans les cibles Amazon S3. Comme AWS DMS les données répliquées sont stockées sous forme de fichiers plats dans Amazon S3, nous utilisons des requêtes [Amazon](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) `CREATE TABLE AS SELECT` Athena (CTAS) pour valider les données. Les requêtes sur les données stockées dans Amazon S3 nécessitent beaucoup de ressources informatiques. Ainsi, n' AWS DMS exécute la validation des données Amazon S3 lors de la capture des données de modification (CDC) qu'une fois par jour, à minuit (00:00) UTC. Chaque validation quotidienne AWS DMS exécutée est appelée *validation par intervalles*. Au cours d'une validation par intervalles, AWS DMS valide tous les enregistrements de modification qui ont été migrés vers le compartiment Amazon S3 cible au cours des 24 heures précédentes. Pour plus d’informations sur les limitations de validation par intervalle, consultez [Limitations liées à l’utilisation de la validation des cibles S3](#CHAP_Validating_S3_limitations). La validation des cibles Amazon S3 utilise Amazon Athena, ce qui occasionne des frais supplémentaires. Pour plus d'informations, consultez [Tarification Amazon Athena](https://aws.amazon.com/athena/pricing/). **Note** La validation de la cible S3 nécessite AWS DMS la version 3.5.0 ou ultérieure. **Topics** + [Conditions préalables](#CHAP_Validating_S3_prerequisites) + [Permissions](#CHAP_Validating_S3_permissions) + [Limitations](#CHAP_Validating_S3_limitations) + [Tâches de validation uniquement](#CHAP_Validating_S3_only) ## Conditions préalables à la validation des cibles S3 Avant d’utiliser la validation des cibles S3, vérifiez les paramètres et autorisations suivants : + Définissez la valeur de `DataFormat` dans les paramètres [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) du point de terminaison sur `parquet`. Pour de plus amples informations, veuillez consulter [Paramètres Parquet pour S3](CHAP_Target.S3.md#CHAP_Target.S3.EndpointSettings.Parquet). + Veillez à ce que le rôle affecté au compte d’utilisateur utilisé pour créer la tâche de migration dispose de l’ensemble d’autorisations correct. Consultez [Permissions](#CHAP_Validating_S3_permissions) ci-dessous. Pour les tâches utilisant la réplication continue (CDC), vérifiez les paramètres suivants : + Activez la journalisation supplémentaire afin de disposer d’enregistrements complets dans les données de CDC. Pour en savoir plus sur l’activation de la journalisation supplémentaire, consultez [Ajout automatique d’une journalisation supplémentaire à un point de terminaison source Oracle](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.AutoSupplLogging) dans la section [Résolution des problèmes et assistance au diagnosticRésolution des problèmes de latence](CHAP_Troubleshooting.md) de ce guide. + Définissez le paramètre `TimestampColumnName` du point de terminaison cible. Le nom de la colonne d’horodatage n’est soumis à aucune limitation. Pour plus d’informations, consultez [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html). + Configurez le partitionnement des dossiers basé sur la date pour la cible. Pour de plus amples informations, veuillez consulter [Utilisation du partitionnement de dossiers basé sur la date](CHAP_Target.S3.md#CHAP_Target.S3.DatePartitioning). ## Autorisations d’utilisation de la validation des cibles S3 Pour configurer l’accès afin d’utiliser la validation des cibles S3, veillez à ce que le rôle affecté au compte d’utilisateur utilisé pour créer la tâche de migration dispose de l’ensemble d’autorisations suivant. Remplacez les exemples de valeurs par vos valeurs. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:CreateWorkGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:CreateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetTables", "glue:CreateTable", "glue:DeleteTable", "glue:GetTable" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "*" } ] } ``` ------ ## Limitations liées à l’utilisation de la validation des cibles S3 Consultez les limitations supplémentaires suivantes qui s’appliquent lors de l’utilisation de la validation des cibles S3. Pour connaître les limitations qui s’appliquent à toutes les validations, consultez [Limitations](CHAP_Validating.md#CHAP_Validating.Limitations). + Votre valeur `DatePartitionSequence` a besoin d’une composante de jour. La validation des cibles S3 ne prend pas en charge le format `YYYYMM`. + Quand la validation par intervalle est en cours pendant la CDC, vous pouvez voir de fausses erreurs de validation dans la table `awsdms_validation_failures_v1`. Ces erreurs se produisent car AWS DMS les modifications arrivées pendant l'intervalle de validation sont migrées vers le dossier de partition du jour suivant. Normalement, ces modifications sont écrites dans le dossier de partitionnement du jour actuel. Ces fausses erreurs limitent la validation de la réplication depuis une base de données source dynamique vers une cible statique, telle qu’Amazon S3. Pour mener des investigations sur ces fausses erreurs, examinez les enregistrements situés près de la fin de la fenêtre de validation (00:00 UTC), où ces erreurs apparaissent généralement. Pour minimiser le nombre de fausses erreurs, veillez à ce que la valeur `CDCLatencySource` de la tâche soit faible. Pour en savoir plus sur la surveillance de la latence, consultez [Métriques de tâches de réplication](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task). + Les tâches à l’état `failed` ou `stopped` ne valident pas les modifications de la veille. Pour minimiser les erreurs de validation dues à des échecs inattendus, créez des tâches distinctes de validation uniquement avec les mêmes mappages de tables et les points de terminaison sources et cibles. Pour plus d’informations sur les tâches de validation uniquement, consultez [Utilisation de tâches de validation uniquement avec la validation des cibles S3](#CHAP_Validating_S3_only). + La colonne **Statut de la validation**, dans les statistiques de table, reflète l’état de la dernière validation par intervalle. Par conséquent, une table présentant des incohérences peut apparaître comme validée après la validation par intervalle du jour suivant. Vérifiez le `s3_validation_failures folder` dans le compartiment Amazon S3 cible et recherchez des incohérences survenues il y a plus d’un jour. + S3 Validation utilise la fonctionnalité de table à compartiments d'Amazon Athena. Cela permet à la validation S3 de créer une copie groupée des données de la table cible. Cela signifie que la copie des données de la table est divisée en sous-ensembles correspondant au partitionnement interne de la validation DMS. Les tables à godets Athena ont une limite de 100 000 seaux. Toute table que la validation S3 tente de valider et qui dépasse cette limite échouera à la validation. Le nombre de compartiments que S3 Validation tente de créer est égal au nombre suivant : ``` (#records in the table) / (validation partition size setting) ``` Pour contourner cette limitation, augmentez le paramètre de taille de partition de validation afin que le nombre de compartiments créés par S3 Validation soit inférieur à 100 000. *Pour plus d'informations sur le partitionnement, consultez la section [Partitionnement et découpage dans Athena dans le guide de l'utilisateur](https://docs.aws.amazon.com/athena/latest/ug/ctas-partitioning-and-bucketing.html) d'Amazon Athena.* + Le nom du tableau ne doit pas contenir de caractères spéciaux, à l'exception d'un trait de soulignement. S3 Validation utilise Amazon Athena qui ne prend pas en charge les caractères spéciaux (autres que le trait de soulignement) dans les noms de table. Pour plus d'informations, consultez la rubrique [CREATE TABLE](https://docs.aws.amazon.com/athena/latest/ug/create-table.html) du guide de l'*utilisateur Amazon Athena*. + Lorsque la fonctionnalité de validation AWS DMS des données est utilisée avec une cible Amazon S3 gérée par AWS Lake Formation, le processus de validation échoue. Cela peut entraîner des problèmes de cohérence des données. ## Utilisation de tâches de validation uniquement avec la validation des cibles S3 Une *tâche de validation uniquement* exécute la validation sur les données à migrer sans exécuter la migration. Les tâches de validation uniquement continuent de s'exécuter, même si la tâche de migration s'arrête, ce qui garantit que la fenêtre de validation de l'intervalle de validation à 00h00 UTC AWS DMS ne sera pas manquée. L’utilisation de tâches de validation uniquement avec les points de terminaison cibles Amazon S3 présente les limitations suivantes : + La validation Amazon S3 pour les tâches à chargement complet avec le paramètre Validation uniquement activé est prise en charge, mais fonctionne différemment des tâches à chargement complet et à validation uniquement pour les autres points de terminaison. Pour S3 en tant que cible, une tâche de ce type valide uniquement par rapport aux données de chargement complet dans la cible S3 et ne valide pas par rapport à des données migrées dans le cadre d’une migration CDC. Utilisez cette fonctionnalité uniquement pour valider les données créées par une tâche de chargement complet uniquement. L’utilisation de ce mode pour valider les données d’une cible sur laquelle une tâche CDC active s’exécute ne produira pas une validation efficace. + Les tâches de validation uniquement valident uniquement les modifications effectuées depuis la dernière fenêtre de validation par intervalle (00:00 UTC). Les tâches de validation uniquement ne valident pas les données de chargement complet ni les données de CDC des jours précédents. # AWS DMS resynchronisation des données AWS Database Migration Service (AWS DMS) La resynchronisation des données corrige automatiquement les incohérences identifiées lors de la validation des données entre vos bases de données source et cible. Cette fonctionnalité fonctionne dans le cadre de vos tâches de migration DMS existantes, garantissant que les mises à jour appropriées sont effectuées en fonction de la configuration de vos tâches, des paramètres de connexion, des mappages de tables et des transformations. La fonction de resynchronisation des données fonctionne en lisant les échecs de validation dans une table de contrôle de la base de données cible et en exécutant les opérations de correction appropriées. Lorsqu'une incompatibilité est détectée, les données actuelles sont extraites de la source à l'aide de la clé primaire stockée dans l'enregistrement des défaillances, et elles sont appliquées à la cible tout en respectant les transformations configurées. Pour de plus amples informations, veuillez consulter [`awsdms_validation_failures_v2`table de commande](CHAP_Validating.md#CHAP_DataResync.Troubleshooting.v2table). Le comportement varie en fonction de votre type de migration. Pour les full-load-only tâches, la resynchronisation des données s'exécute une fois le chargement initial et la validation terminés. Pour les tâches impliquant la capture des données de modification (CDC), la resynchronisation des données s'effectue selon un calendrier configuré, interrompant temporairement la réplication et la validation pendant que les correctifs sont appliqués. Pendant les opérations de resynchronisation du CDC : + La réplication et la validation sont temporairement interrompues. + La resynchronisation des données permet de traiter les échecs de validation existants. + Reprise normale de la réplication et de la validation. + Le processus se répète en fonction du planning que vous avez configuré. La resynchronisation des données suit automatiquement l'état de chaque opération de correction et fournit des mesures détaillées via des tableaux statistiques. **Prérequis :** La fonctionnalité de resynchronisation des données nécessite les prérequis suivants : + Vous devez disposer de la version 3.6.1 ou ultérieure du AWS DMS moteur. + Vous devez configurer les paramètres de planification et de durée pour les tâches faisant l'objet d'une réplication continue. Les tâches à chargement complet uniquement ne nécessitent pas ces paramètres. ## Limitations La fonctionnalité de resynchronisation des données présente les limites suivantes : + La resynchronisation des données prend uniquement en charge Oracle et SQL Server en tant que base de données source. + La resynchronisation des données prend en charge PostgreSQL et le moteur compatible Amazon Aurora PostgreSQL en tant que base de données cible. + Toutes les tables de votre base de données source et cible doivent comporter des clés primaires. La validation ne prend pas en charge les tables dépourvues de clé primaire ou de clé unique. Toutes les tables qui ne possèdent pas de clé primaire ou unique valide sont suspendues et aucun échec de validation n'est signalé. + Lors de l'exécution de Full-load-only tâches, la validation des données doit être activée. + La resynchronisation des données ne peut pas être activée pour les tâches de validation uniquement car elles ne répliquent aucune donnée. Vous pouvez activer la resynchronisation sur la tâche de réplication parent en fournissant uniquement la validation. `taskID` Pour plus d'informations, consultez la section [Tâches de validation uniquement](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.ValidationOnly). + Si un `ControlSchema` paramètre est configuré pour la tâche Validation uniquement dans les paramètres de la tâche, la tâche de réplication doit également avoir la même configuration de paramètres pour que la resynchronisation des données puisse détecter les échecs de validation corrects. + Vous devez configurer les paramètres de planification et de durée pour les tâches CDC. + Pendant la fenêtre de resynchronisation, la resynchronisation des données peut avoir un impact sur la latence de réplication dans DMS. [Pour plus d'informations sur le dépannage des validations AWS DMS lors de la resynchronisation des données, consultez la section [Dépannage](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) sous AWS DMS Validation des données.](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html) ## Planification et calendrier Pour les tâches avec CDC, vous devez configurer le moment et la durée de la resynchronisation des données. Cela permet d'éviter tout impact sur vos opérations de réplication normales. Vous spécifiez : + Un calendrier utilisant le format cron pour définir le moment où les opérations de resynchronisation peuvent avoir lieu. + Une durée maximale pour garantir que les opérations de resynchronisation ne se prolongent pas pendant les périodes de pointe d'utilisation. Il est recommandé de planifier les opérations de resynchronisation en dehors des heures de pointe ou pendant une période où les modifications apportées à la base de données source sont minimes, voire nulles. **Note** Le temps planifié inclut l'attente que le flux d'application cible soit vide, car la resynchronisation des données et la réplication normale ne peuvent pas s'exécuter simultanément. ## Cas d’utilisation La fonction de resynchronisation des données permet aux utilisateurs de corriger les incohérences de données entre les systèmes source et cible. Il identifie les enregistrements incompatibles et les synchronise pour maintenir la cohérence des données dans les environnements distribués. Les cas d'utilisation suivants illustrent des scénarios courants dans lesquels la fonctionnalité de resynchronisation des données résout les problèmes de cohérence des données : **Scénario 1 : tâche de chargement complet : exécution de la resynchronisation à l'aide de la même tâche DMS** Dans le cadre de votre tâche de migration à chargement complet DMS existante, vous pouvez effectuer les opérations suivantes : + Activez la validation :`Validation with data migration = true`. + Activez la resynchronisation : `Data resync = true` **Scénario 2 : chargement complet et tâche CDC, CDC uniquement - exécuter la resynchronisation à l'aide de la même tâche DMS** Dans le cadre de votre tâche de migration DMS CDC existante, vous pouvez effectuer les opérations suivantes : + Activez la validation :`Validation with data migration = true`. + Activez la resynchronisation : `Data resync = true` + Spécifiez le calendrier de resynchronisation :. `"ResyncSchedule": "0 0,2,4,6 * * *"` + Spécifiez l'heure de resynchronisation : `MaxResyncTime": 60` **Scénario 3 : chargement complet et tâche CDC ou CDC uniquement pour la réplication et la resynchronisation, en combinaison avec une tâche de validation uniquement** Pour effectuer une opération de validation uniquement dans une autre tâche DMS lors de l'utilisation de la resynchronisation, vous pouvez effectuer les opérations suivantes : + Créez une tâche DMS CDC uniquement pour la validation. **Note** Vous devez noter et spécifier l'ID de cette tâche lors de la resynchronisation des données. + Dans votre tâche CDC principale, désactivez la validation :`Data validation = false`. + Activez la resynchronisation : `Data resync = true` + Spécifiez le calendrier de resynchronisation :. `"ResyncSchedule": "0 0,2,4,6 * * *"` + Spécifiez l'heure de resynchronisation :. `MaxResyncTime": 60` + Spécifiez l'ID de la tâche DMS CDC de validation uniquement. Seul l'ID de tâche de validation est ajouté à la fin de l'ARN. Exemple d'ARN : `arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` et ID de tâche de validation uniquement :`6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`. ## Bonnes pratiques Vous pouvez tirer parti de la fonctionnalité de resynchronisation des données AWS Database Migration Service pour améliorer la durabilité de vos tâches de réplication et garantir la cohérence. Certaines des meilleures pratiques pour utiliser la fonctionnalité de resynchronisation des données sont les suivantes : + Dans le cadre de la resynchronisation des données, les enregistrements présentant des incohérences sont corrigés en les récupérant depuis la source et en les appliquant à la base de données cible. Si la base de données source est mise à jour pendant la fenêtre de resynchronisation, la resynchronisation lit la dernière valeur d'enregistrement et l'applique à la cible. Cela peut entraîner l'échec des événements d'application du CDC et introduire des incohérences temporaires dans la base de données cible. Pour éviter cela, vous devez planifier la fenêtre de resynchronisation en dehors des heures de bureau ou pendant les périodes où les modifications apportées à la base de données source sont nulles ou minimes. + Définissez la fenêtre de resynchronisation pendant les périodes d'activité minimale de la base de données source et dans les limites de votre seuil de latence cible acceptable. De petits intervalles de resynchronisation peuvent entraîner une accumulation d'incohérences de validation non traitées, tandis que de grandes fenêtres peuvent augmenter la latence de réplication lorsque de nombreux échecs de validation se produisent. Surveillez les échecs de validation et les taux de resynchronisation afin de déterminer les fenêtres de resynchronisation optimales pendant les périodes d'inactivité de la source. Voici quelques exemples de configuration des fenêtres de resynchronisation : + Configuration de plusieurs fenêtres courtes : ``` "ResyncSchedule": "0 0,2,4,6 * * *", "MaxResyncTime": 60 ``` + Configuration d'une fenêtre quotidienne unique : ``` "ResyncSchedule": "0 0 * * *", "MaxResyncTime": 360 ``` + Surveillez la latence de réplication dans le DMS pendant les fenêtres de resynchronisation et ajustez le calendrier en conséquence pour atténuer les pics importants. + Vous pouvez consulter les résultats de la resynchronisation via les statistiques des tables ou en interrogeant la `awsdms_validation_failures_v2` table dans la base de données cible. Pour plus d'informations, consultez la section [Surveillance des tâches de réplication à l'aide d'Amazon CloudWatch](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.CloudWatch). + Lorsque la tâche est dans une phase de réplication en cours, évitez de lancer un rechargement pour des tables individuelles pendant la fenêtre de resynchronisation. + Bonnes pratiques pour une tâche de réplication CDC : + Toutes les tables de votre base de données terminent le processus de chargement. + Les incohérences sont identifiées dans le cadre du processus de validation en cours. + Conformément à la fenêtre planifiée de resynchronisation, la tâche de réplication est interrompue pendant une brève période. + La resynchronisation des données résout les problèmes identifiés lors du processus de validation. + Le processus de réplication reprend et se répète conformément au planning. ## Configuration et exemples de resynchronisation des données Configuration des **paramètres de resynchronisation des données** : Vous pouvez configurer la resynchronisation de votre tâche de réplication dans DMS. Vous trouverez ci-dessous un exemple de configuration des paramètres de resynchronisation des données dans votre tâche : ``` "ResyncSettings": { "EnableResync": true, "ResyncSchedule": "0 0,2,4,6 * * *", // Run at 12AM, 2AM, 4AM, and 6AM daily "MaxResyncTime": 60, // Run for maximum of 60 minutes, or 1 hour "ValidationTaskId": "TASK-ID-IF-NEEDED" //Optional, used only if validation is performed as a separate Validation only task } ``` **Exemples de modèles courants de planification de resynchronisation** : + `0 0 * * *`: Courez une fois par jour à minuit. + `0 0,12 * * *`: Courez deux fois par jour à minuit et à midi. + `0 0,2,4,6, * * *`: Fonctionne toutes les deux heures entre minuit et 6 heures du matin. + `0 1 * * 1`: Ouvert chaque semaine le lundi à 1 heure du matin. **Note** Vous devez spécifier un chiffre pour chaque jour, de 0 à 6. Pour plus d'informations, consultez la section [Règles relatives aux expressions Cron](#CHAP_DataResync.cron). **Surveillance des opérations de resynchronisation :** Vous pouvez contrôler l'opération de resynchronisation à l'aide des statistiques des tables. Voici un exemple de sortie : ``` { "TableStatistics": { ... "ValidationFailedRecords": 1000, ... "ResyncRowsAttempted": 1000, "ResyncRowsSucceeded": 995, "ResyncRowsFailed": 5, "ResyncProgress": 99.5, // ratio of ResyncRowsSucceeded/ValidationFailedRecords "ResyncState": "Last resync at: 2024-03-14T06:00:00Z" } } ``` Pour configurer la fonctionnalité de resynchronisation des données dans AWS DMS, vous pouvez consulter les différents paramètres de resynchronisation et leurs paramètres de configuration respectifs. Pour de plus amples informations, veuillez consulter [Paramètres de resynchronisation des données](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md). Pour plus d'informations sur les paramètres de journalisation de la resynchronisation des données, consultez. [Paramètres de la tâche de journalisation](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md) ## Validation et résolution des problèmes **Validation** : Lorsque la validation des données est activée, AWS DMS crée une table des échecs de validation dans votre base de données cible avec la structure suivante : ``` CREATE TABLE awsdms_validation_failures_v2 ( "RESYNC_ID" bigint NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL ); ``` Vous pouvez écrire une requête dans ce tableau pour comprendre les incohérences de données détectées et la manière dont elles sont résolues. Lorsque la validation est activée, AWS DMS crée une table des échecs de validation dans votre base de données cible. En cas de problème, vous pouvez interroger le `awsdms_control.awsdms_validation_failures_v2` tableau pour comprendre les incohérences de données détectées et la manière dont elles sont résolues. Pour plus d'informations, consultez la section [Résolution des problèmes](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) dans [Validation AWS DMS des données](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html). **Flux de travail commun** : Lors de la validation lors de la resynchronisation des données, le flux de travail standard est le suivant : **Tâches à chargement complet uniquement** : 1. Toutes les tables de votre base de données terminent le processus de chargement. 1. Les incohérences sont identifiées dans le cadre du processus de validation en cours. 1. La resynchronisation des données résout les problèmes identifiés lors du processus de validation. 1. Le processus de validation valide la rectification. 1. La tâche de migration est terminée avec succès. **Tâches du CDC** : 1. Toutes les tables de votre base de données terminent le processus de chargement. 1. Les incohérences sont identifiées dans le cadre du processus de validation en cours. 1. Conformément à la fenêtre planifiée de resynchronisation, la tâche de réplication est interrompue pendant une brève période. 1. La resynchronisation des données résout les problèmes identifiés lors du processus de validation. 1. Le processus de réplication reprend et se répète conformément au planning. Toute modification apportée à la tâche, telle que l'arrêt de la tâche de réplication pendant l'opération de resynchronisation ou le rechargement et la revalidation des tables, peut avoir un impact sur le comportement et les résultats de la tâche. Certains des changements de comportement connus sont les suivants : **Lorsque vous arrêtez la tâche de réplication alors que l'opération de resynchronisation est en cours** : + L'opération de resynchronisation ne reprend pas automatiquement. Vous devez le redémarrer à nouveau. + Les futures opérations de resynchronisation ont lieu conformément au calendrier configuré. + Toute correction incomplète est tentée dans la fenêtre de planification de resynchronisation suivante. **Lorsque vous rechargez une table dans votre base de données** : + L'opération de resynchronisation ignore toute table en cours de rechargement. + Les échecs de validation précédents pour une table rechargée sont ignorés. + La nouvelle validation commence une fois l'action de rechargement terminée. **Lorsque vous revalidez une table de votre base de données** : + Toutes les statistiques de votre opération de resynchronisation sont réinitialisées. + Les échecs de validation précédents pour une table revalidée sont ignorés. **Note** Lors de la mise à niveau ou du déplacement d'une tâche vers la version 3.6.1 ou ultérieure de DMS, les défaillances du `awsdms_control.awsdms_validation_failures_v1` tableau ne sont pas resynchronisées. Seuls les échecs du `awsdms_validation_failures_v2` tableau sont resynchronisés. Pour resynchroniser les échecs dans une `awsdms_control.awsdms_validation_failures_v2` table, vous devez recharger la tâche, recharger une ou plusieurs tables de la tâche ou revalider une ou plusieurs tables. Pour plus d'informations, consultez les liens suivants : Pour recharger une tâche, consultez la [référence de `StartReplicationTask` l'API](https://docs.aws.amazon.com/dms/latest/APIReference/API_StartReplicationTask.html). Pour recharger une ou plusieurs tables dans une tâche, consultez la documentation [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html)de *référence des commandes AWS CLI*. Pour revalider une ou plusieurs tables, consultez l'`validate-only`option dans la [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html)section de la documentation de *référence des commandes AWS CLI*. . ## Règles d'expression Cron Pour configurer les opérations de resynchronisation des données lors d'une tâche de réplication, AWS DMS vous pouvez utiliser les règles des expressions cron. Ces règles vous permettent de personnaliser les fenêtres horaires de resynchronisation et de les planifier en fonction des besoins de votre entreprise. Vous pouvez utiliser différents paramètres tels que les minutes, les heures, les jours, les mois et les jours de la semaine. Les règles d'expression cron pour chaque paramètre sont les suivantes : **Procès-verbal** : + Plage de minutes comprise entre 0 et 59. + Vous pouvez utiliser (`-`),`or`/`and`pour spécifier la plage. Maximum de 10 éléments séparés par une virgule (`,`). + **Exemples :** + `2-5`est égal à`2,3,5,5`. + `1-2,3-4,5,7-10`est une plage valide. + `1,2,3,4,5,6,7,8,9,10`est une plage valide. + `1,2,3,4,5,6,7,8,9,10,11`n'est pas une plage valide. L'opération de resynchronisation est ignorée après le dixième élément de la gamme. + Vous pouvez utiliser (`*`). Exemple : `*` égal à`0-59`. + Vous ne pouvez utiliser (`/`) qu'en combinaison avec (`-`) ou (`*`). **Exemples :** + `2-7/2`est égal à`2,4,6`. + `*/15`est égal à`0,15,30,45`. **Heures** : Identique à « **Minutes** », mais la plage valide est comprise entre `0` et`23`. **Jours** : + Identique à « **Minutes** », mais la plage valide est comprise entre `1` et`31`. + L'utilisation de `L` est prise en charge dans la configuration de resynchronisation. Il est interprété comme le dernier jour du mois. Vous ne devez pas l'utiliser en combinaison avec une autre syntaxe. **Mois** : Identique à « **Minutes** », mais la plage valide est comprise entre `1` et`12`. **Jours de la semaine** : + Identique à « **Minutes** », mais la plage valide est comprise entre `0` et`6`. + Vous ne pouvez pas ajouter de valeur de chaîne pour le nom de la semaine.