Résolution des problèmes liés aux SQL terminaux Postgre - AWS Service de Migration de Base de Données
Transaction de longue durée sur la sourceCharge de travail élevée sur la sourceDébit réseau élevéDéposez des fichiers dans Aurora Postgre SQL

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.

Résolution des problèmes liés aux SQL terminaux Postgre

Cette section contient des scénarios de réplication spécifiques à PostgreSQL.

Transaction de longue durée sur la source

Lorsque la base de données source contient des transactions de longue durée, telles que quelques milliers d'insertions dans une seule transaction, les compteurs d'DMSCDCévénements et de transactions n'augmentent pas tant que la transaction n'est pas terminée. Ce retard peut entraîner des problèmes de latence que vous pouvez mesurer à l’aide de la métrique CDCLatencyTarget.

Pour examiner les transactions de longue durée, effectuez l’une des opérations suivantes :

  • Utilisez la vue pg_replication_slots. Si la restart_lsn valeur n'est pas mise à jour, il est probable que Postgre ne SQL soit pas en mesure de publier Write Ahead Logs (WALs) en raison de transactions actives de longue durée. Pour plus d'informations sur la pg_replication_slots vue, consultez pg_replication_slots dans la documentation de Postgre 15.4. SQL

  • Utilisez la requête suivante pour renvoyer la liste de toutes les requêtes actives dans la base de données, ainsi que les informations associées : 

    SELECT pid, age(clock_timestamp(), query_start), usename, query 
FROM pg_stat_activity WHERE query != '<IDLE>' 
AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;

    Dans les résultats de la requête, le champ age indique la durée active de chaque requête, que vous pouvez utiliser pour identifier les requêtes de longue durée.

Charge de travail élevée sur la source

Si votre Postgre source SQL a une charge de travail élevée, vérifiez les points suivants pour réduire le temps de latence :

  • Vous pouvez rencontrer une latence élevée lorsque vous utilisez le test_decoding plug-in lors de la migration d'un sous-ensemble de tables de la base de données source avec une valeur de transactions par seconde (TPS) élevée. Cela est dû au fait que le test_decoding plugin envoie toutes les modifications de base de données à l'instance de réplication qui filtre DMS ensuite, en fonction du mappage de table de la tâche. Les événements relatifs aux tables qui ne font pas partie du mappage des tables de la tâche peuvent augmenter la latence source.

  • Vérifiez TPS le débit à l'aide de l'une des méthodes suivantes.

    • Pour les SQL sources Aurora Postgre, utilisez la CommitThroughput CloudWatch métrique.

    • Pour que Postgre SQL fonctionne sur Amazon RDS ou sur site, utilisez la requête suivante à l'aide d'un PSQL client version 11 ou supérieure (appuyez enter pendant la requête pour faire avancer les résultats) :

      SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset
select pg_sleep(60);
SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset
select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";

  • Pour réduire la latence lors de l’utilisation du plug-in test_decoding, envisagez plutôt d’utiliser le plug-in pglogical. Contrairement au test_decoding plugin, le pglogical plugin filtre les modifications apportées par write ahead log (WAL) à la source et envoie uniquement les modifications pertinentes à l'instance de réplication. Pour plus d'informations sur l'utilisation du pglogical plugin avec AWS DMS, consultezConfiguration du plug-in pglogical.

Débit réseau élevé

La réplication peut utiliser beaucoup de bande passante du réseau lorsque vous utilisez le plug-in test_decoding, en particulier lors de transactions à volume élevé. Cela est dû au fait que le plug-in test_decoding traite les modifications et les convertit dans un format lisible par l’homme qui est plus grand que le format binaire d’origine.

Pour améliorer les performances, pensez plutôt à utiliser le plug-in pglogical, qui est un plug-in binaire. Contrairement au test_decoding plugin, le pglogical plugin génère une sortie au format binaire, ce qui entraîne des modifications du flux write ahead log (WAL) compressé.

Déposez des fichiers dans Aurora Postgre SQL

Dans les SQL versions 13 et supérieures de Postgre, le logical_decoding_work_mem paramètre détermine l'allocation de mémoire pour le décodage et le streaming. Pour plus d'informations sur le logical_decoding_work_mem paramètre, consultez la section Consommation de ressources dans Postgre SQL dans la documentation Postgre SQL 13.13.

La réplication logique accumule les modifications pour toutes les transactions en mémoire jusqu'à ce que ces transactions soient validées. Si la quantité de données stockée pour toutes les transactions dépasse la quantité spécifiée par le paramètre de base de donnéeslogical_decoding_work_mem, les données de transaction sont DMS déversées sur le disque afin de libérer de la mémoire pour les nouvelles données de décodage.

Les transactions de longue durée, ou de nombreuses sous-transactions, peuvent entraîner une DMS consommation accrue de mémoire de décodage logique. Cette augmentation de l'utilisation de la mémoire entraîne la DMS création de fichiers déversés sur le disque, ce qui entraîne une latence élevée de la source lors de la réplication.

Pour réduire l'impact d'une augmentation de la charge de travail source, procédez comme suit :

  • Réduisez les transactions de longue durée.

  • Réduisez le nombre de sous-transactions.

  • Évitez d'effectuer des opérations qui génèrent une grande quantité d'enregistrements de journal, telles que la suppression ou la mise à jour d'une table entière en une seule transaction. Effectuez plutôt des opérations par petits lots.

Vous pouvez utiliser les CloudWatch mesures suivantes pour surveiller la charge de travail sur la source :

  • TransactionLogsDiskUsage: le nombre d'octets actuellement occupés par le système logiqueWAL. Cette valeur augmente de façon monotone si les emplacements de réplication logiques ne sont pas en mesure de suivre le rythme des nouvelles écritures ou si des transactions de longue durée empêchent le ramassage des anciens fichiers.

  • ReplicationSlotDiskUsage: quantité d'espace disque actuellement utilisée par les emplacements de réplication logique.

Vous pouvez réduire la latence de la source en ajustant le logical_decoding_work_mem paramètre. La valeur par défaut de ce paramètre est de 64 Mo. Ce paramètre limite la quantité de mémoire utilisée par chaque connexion de réplication en continu logique. Nous recommandons de définir logical_decoding_work_mem une valeur nettement supérieure à la work_mem valeur afin de réduire le nombre de modifications décodées qui sont écrites sur DMS le disque.

Nous vous recommandons de vérifier régulièrement la présence de fichiers déversés, en particulier pendant les périodes de forte activité de migration ou de latence. S'il s'DMSagit de créer un nombre important de fichiers de déversement, cela signifie que le décodage logique ne fonctionne pas efficacement, ce qui peut augmenter le temps de latence. Pour atténuer ce problème, augmentez la valeur du logical_decoding_work_mem paramètre.

Vous pouvez vérifier le dépassement des transactions en cours à l'aide de la aurora_stat_file fonction. Pour plus d'informations, consultez la section Ajustement de la mémoire de travail pour le décodage logique dans le manuel Amazon Relational Database Service Developer Guide.