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.
Cette section contient des scénarios de réplication spécifiques à PostgreSQL.
Rubriques
Transaction de longue durée sur la source
Lorsque la base de données source contient des transactions de longue durée, telles que des milliers d’insertions dans une seule transaction, les compteurs de transactions et d’événements CDC DMS 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 larestart_lsnvaleur n'est pas mise à jour, il est probable que PostgreSQL ne soit pas en mesure de publier Write Ahead Logs WALs () en raison de transactions actives de longue durée. Pour en savoir plus sur la vuepg_replication_slots, consultez pg_replication_slotsdans la documentation de PostgreSQL 15.4. 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
ageindique 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 la charge de travail de votre source PostgreSQL est élevée, vérifiez les points suivants pour réduire la latence :
-
Vous pouvez rencontrer une latence élevée lorsque vous utilisez le plug-in
test_decodinglors de la migration d’un sous-ensemble de tables de la base de données source avec une valeur élevée de transactions par seconde (TPS). Cela est dû au fait que le plug-intest_decodingenvoie toutes les modifications de base de données à l’instance de réplication, que DMS filtre 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 le débit TPS en utilisant l’une des méthodes suivantes.
Pour les sources Aurora PostgreSQL, utilisez la métrique.
CommitThroughputCloudWatchPour PostgreSQL qui s’exécute sur Amazon RDS ou sur site, utilisez la requête suivante à l’aide d’un client PSQL version 11 ou ultérieure (appuyez sur
enterpendant 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-inpglogical. Contrairement au plug-intest_decoding, le plug-inpglogicalfiltre les modifications du journal d’écriture anticipée (WAL) à la source et envoie uniquement les modifications pertinentes à l’instance de réplication. Pour plus d'informations sur l'utilisation dupglogicalplugin avec AWS DMS, voirConfiguration 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 plug-in test_decoding, le plug-in pglogical génère une sortie au format binaire, ce qui entraîne des modifications du flux WAL (Write Ahead Log) compressé.
Déversez des fichiers dans Aurora PostgreSQL
Dans les versions 13 et supérieures de PostgreSQL, logical_decoding_work_mem le 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 PostgreSQL dans
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, DMS déverse les données de transaction 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 consommation accrue de mémoire de décodage logique par le DMS. Cette augmentation de l'utilisation de la mémoire entraîne la création par DMS de fichiers indésirables 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 WAL logique. 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 que le DMS écrit sur 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. Si le DMS crée 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.
