Comment résoudre les problèmes liés à une tâche AWS DMS qui échoue et qui affiche le message d'erreur « ERROR: canceling statement due to statement timeout » ?

Brève description

Si la base de données PostgreSQL est la source de votre tâche de migration, AWS DMS obtient les données de la table pendant la phase de chargement complet. AWS DMS lit ensuite les journaux d'écriture anticipée (WAL) conservés par le slot de réplication pendant la phase de capture de données modifiées (CDC).

Si la base de données PostgreSQL est la cible, AWS DMS extrait les données de la source et crée des fichiers CSV dans l'instance de réplication. Puis, AWS DMS exécute une commande COPY pour insérer ces enregistrements dans la cible pendant la phase de chargement complet.

Cependant, pendant la phase CDC, AWS DMS exécute les instructions DML exactes à partir des journaux WAL source en mode d'application transactionnelle. Pour le mode d'application par lots, AWS DMS crée également des fichiers CSV pendant la phase CDC. Puis, il exécute une commande COPY pour insérer les modifications nettes dans la cible.

Lorsqu'AWS DMS essaie d'obtenir des données depuis la source ou de placer des données dans la cible, il utilise le paramètre de délai d’attente par défaut de 60 secondes. Si la source ou la cible est très chargée ou si les tables sont verrouillées, AWS DMS ne peut pas terminer l'exécution de ces commandes dans les 60 secondes. La tâche échoue donc avec une erreur indiquant « canceling statement due to statement timeout », et l'une des entrées suivantes s'affiche dans le journal :

Messages :

« ]E: RetCode: SQL_ERROR SqlState: 57014 NativeError: 1 Message: ERROR: canceling statement due to statement timeout; Error while executing the query [1022502] (ar_odbc_stmt.c:2738) »

« ]E: test_decoding_create_replication_slot(...) - Unable to create slot 'lrcyli7hfxcwkair_00016402_8917165c_29f0_4070_97dd_26e78336e01b' (on execute(...) phase) [1022506] (postgres_test_decoding.c:392)) »

Pour résoudre ces erreurs, procédez comme suit :

• Identifiez la cause des longs délais d'exécution des commandes.
• Augmentez la valeur du délai d'attente et vérifiez la valeur du délai d’attente de création du slot.
• Remédiez aux problèmes liés à la création de slots.

Résolution

Identifier la cause des longs délais d'exécution des commandes

Pour trouver la commande qui n'a pas pu être exécutée pendant le délai imparti, consultez le journal de tâches AWS DMS et la section des statistiques de table de la tâche. Vous trouverez également ces informations dans le fichier journal des erreurs de PostgreSQL si le paramètre log_min_error_statement est défini sur ERROR ou sur une gravité inférieure. Après avoir identifié la commande qui a échoué, vous pouvez trouver les noms de tables ayant échoué. Consultez cet exemple de message d'erreur issu du journal des erreurs de PostgreSQL :

ERROR: canceling statement due to statement timeout
STATEMENT: <The statement executed>"

Pour rechercher des verrous sur les tables associées, exécutez cette commande dans la source ou la cible (selon l'emplacement où l'erreur apparaît) :

SELECT blocked_locks.pid AS blocked_pid,
 blocked_activity.usename AS blocked_user,
 blocking_locks.pid AS blocking_pid,
         blocking_activity.usename AS blocking_user,
         blocked_activity.query    AS blocked_statement,
         blocking_activity.query   AS current_statement_in_blocking_process
   FROM  pg_catalog.pg_locks         blocked_locks
    JOIN pg_catalog.pg_stat_activity blocked_activity  ON blocked_activity.pid = blocked_locks.pid
    JOIN pg_catalog.pg_locks         blocking_locks
        ON blocking_locks.locktype = blocked_locks.locktype
        AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
        AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
        AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
        AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
        AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
        AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
        AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
        AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
        AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
        AND blocking_locks.pid != blocked_locks.pid
    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
   WHERE NOT blocked_locks.GRANTED;

Si vous trouvez des PID bloqués, arrêtez ou résiliez le PID bloqué en exécutant cette commande :

SELECT pg_terminate_backend(blocking_pid);

Étant donné que les lignes mortes, ou « tuples », peuvent augmenter la durée de SÉLECTION, vérifiez la présence d'un grand nombre de lignes mortes dans les tables source en exécutant cette commande :

select * from pg_stat_user_tables where relname= 'table_name';

Vérifiez si la table cible défaillante utilise des clés primaires ou des index uniques. Si la table n’utilise pas de clé primaire ni d'index unique, une analyse complète de la table est effectuée lors de l'exécution de toute instruction UPDATE. Cette analyse de table peut prendre beaucoup de temps.

Augmenter la valeur du délai d'attente

AWS DMS utilise l'attribut de connexion supplémentaire executeTimeout à la fois sur les points de terminaison source et cible. La valeur par défaut pour executeTimeout est de 60 secondes. Par conséquent, AWS DMS expire si l'exécution d'une requête prend plus de 60 secondes.

Si l'erreur apparaît dans Source_Unload ou Source_Capture, définissez la valeur du délai d'attente pour executeTimeout dans la source. Si l'erreur apparaît dans Target_Load ou Target_Apply, définissez la valeur du délai d'expiration pour executeTimeout dans la cible. Augmentez le réglage de la valeur du délai d'attente en procédant comme suit :

1.    Ouvrez la console AWS DMS.

2.    Choisissez Points de terminaison dans le volet de navigation.

3.    Choisissez le point de terminaison PostgreSQL.

4.    Choisissez Actions, puis sélectionnez Modifier.

5.    Développez la section Paramètres spécifiques au point de terminaison.

6.    Dans le champ Attributs de connexion supplémentaires, saisissez cette valeur :

executeTimeout=3600;

7.    Choisissez Enregistrer.

8.    Dans le volet Points de terminaison, choisissez le nom de votre point de terminaison PostgreSQL.

9. Dans la section Connexions , le statut du point de terminaison passe de Test en cours à Réussi.

Vous pouvez augmenter (en millisecondes) le paramètre statement_timeout dans l'instance de base de données PostgreSQL. La valeur par défaut est 0, ce qui désactive les délais d'attente pour toutes les requêtes. Vous pouvez également augmenter le paramètre lock_timeout. La valeur par défaut est 0, ce qui désactive les délais d'attente pour les verrous.

Résoudre les problèmes liés à la création de slots

Si le délai d’attente s'est produit lors de la création du slot de réplication dans la base de données PostgreSQL, des entrées de journal similaires aux suivantes s'affichent :

Messages

« ]E: test_decoding_create_replication_slot(...) - Unable to create slot 'lrcyli7hfxcwkair_00016402_8917165c_29f0_4070_97dd_26e78336e01b' (on execute(...) phase) [1022506] (postgres_test_decoding.c:392) »

Vous pouvez augmenter ce délai en configurant le paramètre TransactionConsistencyTimeout dans la section Paramètres de tâche. La valeur par défaut est de 600 secondes.

PostgreSQL ne peut pas créer le slot de réplication s'il existe des verrous actifs dans les tables utilisateur de la base de données. Vérifiez la présence de verrous en exécutant cette commande :

select * from pg_locks;

Puis, pour vérifier si l'erreur a été résolue, exécutez cette commande pour créer manuellement le slot de réplication dans la base de données PostgreSQL source :

select  xlog_position FROM pg_create_logical_replication_slot('<Slot name as per
    the task log>', 'test_decoding');

Si la commande ne parvient toujours pas à créer le slot, vous devrez peut-être utiliser un DBA PostgreSQL pour identifier le goulot d'étranglement et configurer votre base de données. Si la commande aboutit, supprimez le slot que vous venez de créer à titre de test :

select pg_drop_replication_slot(‘<slot name>');

Enfin, redémarrez votre tâche de migration.

Informations connexes

Documentation PostgreSQL pour les paramètres de connexion client par défaut

Attributs de connexion supplémentaires lors de l'utilisation de PostgreSQL en tant que cible pour AWS DMS

Attributs de connexion supplémentaires lors de l'utilisation de PostgreSQL en tant que source DMS

Utilisation d'une base de données PostgreSQL en tant que source AWS DMS