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.

Surveillance et résolution des problèmes

Aurora PostgreSQL signale l'activité des requêtes de tables étrangères via CloudWatch Amazon, les fonctions de diagnostic SQL, Database Insights et le journal PostgreSQL, les mêmes outils que vous utilisez déjà pour Aurora PostgreSQL. La surveillance couvre les indicateurs, les événements d'attente et les requêtes de diagnostic liés à l'observation d'une charge de travail ; le dépannage couvre les symptômes courants et explique comment les résoudre.

Contrôle

Cette section décrit les indicateurs, les événements d'attente et les requêtes de diagnostic que vous utilisez pour surveiller votre charge de travail analytique, ainsi que la façon de créer des tableaux de bord à partir de ces indicateurs. Pour des symptômes spécifiques, voirRésolution des problèmes.

Aurora PostgreSQL rend compte de ses activités d'analyse via quatre canaux. Chaque canal répond à une question différente, et la plupart des enquêtes en utilisent plusieurs.

CloudWatch Métriques Amazon

Les CloudWatch métriques Amazon suivantes sont publiées pour Aurora Analytics.

Surveillance des performances du stockage local

Aurora PostgreSQL utilise le stockage local pour le cache de lecture sur disque et pour les fichiers de renvoi de requêtes, tels que les tris et les tables de hachage qui dépassent. query_mem Les statistiques indiquent que cela I/O dépend de la manière dont le stockage local est attaché à la classe d'instance. Vérifiez d'abord votre classe, puis utilisez l'ensemble de mesures correspondant ci-dessous.

Instances avec stockage Amazon EBS uniquement

Les classes telles que db.r8gdb.r7g, et n'db.r7iont pas de stockage d'instance, de sorte que les fichiers de cache de lecture et de déversement partagent le EBS-backed volume Amazon avec le reste de la base de données. Analytical est I/O donc en concurrence avec I/O PostgreSQL normal, et il est indiqué par les métriques de stockage générales plutôt que par un ensemble de métriques spécifiques à Analytics.

Instances avec stockage NVMe local

Des classes telles que db.r8gd et db.r6gd incluent un magasin d'instances NVMe, et Aurora PostgreSQL y place le cache de lecture et les fichiers de déversement plutôt que sur le volume Amazon EBS. Cela permet d'éviter que les I/O analyses soient intégrées au volume de la base de données et de réduire considérablement le temps de latence de lecture du cache. Le périphérique NVMe génère donc ReadIOPS des rapports via son propre ensemble de mesures de stockage éphémères et DiskQueueDepth ne reflète plus les analyses I/O relatives à ces classes. ReadLatency

Mesures Aurora standard pertinentes pour Analytics

Au-delà des mesures spécifiques à l'analyse, les métriques Aurora standard suivantes sont utiles pour surveiller une charge de travail analytique.

SQL-based fonctions de diagnostic

Aurora PostgreSQL SQL-callable fournit des fonctions qu' CloudWatch Amazon ne peut attribuer aux compteurs de rapports : nombre exact d'octets, de spills et de threads pour une requête ou un backend. Commencez par le tableau suivant pour choisir une fonction, puis consultez la référence des fonctions SQL pour ses colonnes.

Toutes les colonnes d'octets indiquent des octets bruts, donc enveloppez-les pg_size_pretty() pour une sortie lisible. Pour la syntaxe, les autorisations et les exemples pratiques de chaque fonction, voirRéférence sur les fonctions SQL.

Exemples de requêtes et de résultats

Pour rechercher les requêtes lues depuis Amazon S3 plutôt que depuis le cache, exécutez la requête suivante.

-- Optional: enable the detailed columns, such as CPU time
SET aurora_analytics.track_detailed_metrics = true;

-- Run your queries, then check statistics
SELECT SUBSTR(query, 1, 45) AS query,
       calls,
       pg_size_pretty(analytics_cache_hit_bytes) AS cache_hits,
       pg_size_pretty(analytics_remote_read_bytes) AS s3_reads,
       pg_size_pretty(analytics_total_disk_spill) AS spill,
       round(analytics_total_cpu_time::numeric, 2) AS cpu_ms
FROM aurora_analytics_stat_statements()
WHERE analytics_cache_hit_bytes > 0 OR analytics_remote_read_bytes > 0
ORDER BY analytics_remote_read_bytes DESC;

Interprétez les résultats comme suit.

Pour attribuer de la mémoire, des threads et du spam à un backend, exécutez la requête suivante.

SELECT pid,
       pg_size_pretty(current_memory_usage) AS mem_used,
       active_threads,
       pg_size_pretty(disk_spill_size) AS spill
FROM aurora_analytics_stat_resource_usage()
WHERE current_memory_usage > 0
ORDER BY current_memory_usage DESC;

Joignez la pid colonne pg_stat_activity pour voir quelle requête est exécutée par chaque backend. Utilisez-le lorsque la AuroraAnalyticsMemoryUsage température est élevée et que vous devez savoir quelle session est responsable.

Pour afficher l'activité d'Amazon S3 et du cache à l'échelle de l'instance, exécutez la requête suivante.

SELECT s3_head_request_count,
       s3_get_request_count,
       pg_size_pretty(s3_cache_hit_bytes) AS cache_hit,
       pg_size_pretty(s3_remote_read_bytes) AS s3_read
FROM aurora_analytics_instance_metrics();

Pour vérifier la taille du cache, exécutez la requête suivante.

SELECT pg_size_pretty(aurora_analytics_cache_size()) AS cache_size;

Pour rechercher des requêtes analytiques actives, exécutez la requête suivante.

WITH analytics_tables AS (
    SELECT c.relname
    FROM pg_foreign_table ft
    JOIN pg_class c ON c.oid = ft.ftrelid
    JOIN pg_foreign_server fs ON fs.oid = ft.ftserver
    WHERE fs.srvname = 'aurora_analytics_server'
)
SELECT a.pid, a.usename, a.datname,
       NOW() - a.query_start AS runtime, a.state,
       LEFT(a.query, 100) AS query_preview
FROM pg_stat_activity a
WHERE a.state = 'active'
  AND EXISTS (SELECT 1 FROM analytics_tables t WHERE a.query ILIKE '%' || t.relname || '%')
ORDER BY a.query_start;

Interprétation du nombre de threads actifs

La CloudWatch métrique AuroraAnalyticsActiveThreads Amazon et la active_threads colonne de aurora_analytics_stat_resource_usage() rapport indiquent le nombre de fils de travail d'analyse qui s'exécutent activement au moment de la mesure. Ce nombre est souvent beaucoup plus élevé que le nombre de sessions simultanées, qui est attendu. Le nombre de threads actifs inclut deux types de threads de travail.

Seuls les threads qui travaillent activement sont pris en compte. Un thread inactif en attente de travail n'est pas inclus, de sorte que le nombre augmente et diminue continuellement au fur et à mesure de l'exécution d'une requête.

Comme les deux types de threads sont comptés ensemble, le total peut être bien supérieur au nombre de requêtes simultanées. Une poignée de requêtes lues simultanément depuis Amazon S3 concernant des erreurs de cache peuvent produire plusieurs centaines de threads actifs. C'est normal. Un nombre constamment élevé généré par les I/O threads Amazon S3 indique un faible taux de réussite du cache. Pensez donc à réchauffer ou à dimensionner le cache.

Ces threads de travail sont internes au moteur d'analyse et n'apparaissent pas danspg_stat_activity, qui affiche uniquement vos sessions PostgreSQL. C'est pourquoi un petit nombre de sessions peut entraîner une utilisation élevée du processeur : une seule session peut exécuter des dizaines ou des centaines de threads actifs.

Le nombre de threads actifs répond à la question « pourquoi le processeur est-il élevé avec seulement quelques sessions ? » , tandis que l'événement d'Extension:AuroraAnalyticsExecuteattente indique le nombre de sessions en attente sur le moteur d'analyse. Pour plus d’informations, consultez Interprétation de l'événement AuroraAnalyticsExecute d'attente.

Surveillance de Xmin Horizon sur les instances de lecteur

Long-running les requêtes analytiques sur les instances de lecteur maintiennent un instantané xmin ouvert, ce qui peut empêcher Autovacuum sur le rédacteur de récupérer des tuples morts. L'exécution de charges de travail analytiques sur un lecteur dédié permet d'isoler cet impact ; pour plus d'informations, consultez. Utilisation d'une instance de lecteur dédiée pour les analyses

statement_timeoutDéfini pour limiter la durée d'exécution d'une seule requête. Comme les autres paramètres PostgreSQL, vous pouvez le définir au niveau de la session, du rôle, de la base de données ou du groupe de paramètres du cluster ; utilisez le niveau le plus bas qui convient. Configurez-le par session pour une seule connexion.

SET statement_timeout = 'XX';

Vous pouvez également le définir par défaut pour le rôle d'analyse.

ALTER ROLE analytics_user SET statement_timeout = 'XX';

Database Insights

Lorsqu'Amazon vous CloudWatch indique que l'instance est sous pression, Database Insights vous indique quelles sessions et quel SQL sont responsables. Les requêtes de table étrangère y apparaissent comme n'importe quelle autre requête PostgreSQL. Vous utilisez donc le même graphique des sessions actives moyennes (AAS), la même liste des requêtes SQL les plus fréquentes et la même répartition des événements d'attente.

Aurora PostgreSQL ajoute un événement d'attente pour les requêtes de table étrangères.

Pour identifier les principales requêtes analytiques, procédez comme suit.

Interprétation de l'événement AuroraAnalyticsExecute d'attente

Lorsqu'une requête fait référence à une table étrangère, le serveur principal de PostgreSQL transmet l'exécution au moteur d'analyse intégré et la bloque jusqu'à ce que le moteur renvoie des résultats. Pendant ce temps, le backend signale l'événement Extension:AuroraAnalyticsExecute d'attente. Dans Database Insights, cela apparaît dans le graphique des sessions actives moyennes (AAS) sous la formeExtension:AuroraAnalyticsExecute. Gardez les points suivants à l'esprit.

Suivi des tendances relatives à la durée des requêtes

Utilisez Database Insights pour savoir si le temps moyen des requêtes est stable ou s'il se dégrade au fil du temps. Une augmentation soudaine peut indiquer ce qui suit.

Logging

Aurora PostgreSQL peut écrire des messages du moteur d'analyse dans le journal des erreurs de PostgreSQL. La journalisation est un outil de diagnostic plutôt qu'un canal de surveillance : elle fournit des informations détaillées sur les opérations individuelles, et non des séries chronologiques sur lesquelles vous pouvez générer des tendances ou des alarmes. Deux paramètres le contrôlent. Définissez-les dans un groupe de paramètres de cluster de base de données pour couvrir l'ensemble de la charge de travail, ou SET au cours d'une seule session pour étendre la sortie à une seule investigation. La portée de la session nécessite SET le rôle. rds_superuser

Les messages sont envoyés dans le journal des erreurs de PostgreSQL. Retrouvez-le de l'une des trois manières suivantes.

Référence des indicateurs clés

Le tableau suivant fournit une référence rapide sur l'état des analyses. Deux lignes dépendent de votre classe d'instance. Vérifiez donc le stockage utilisé par la classe avant de créer des alarmes à partir de ce tableau. Sur les classes NVMe, FreeLocalStorage ne suit pas le volume qui contient le cache de lecture et les fichiers de déversement. Une alarme restera donc silencieuse pendant que le magasin de l'instance est plein.

Résolution des problèmes

Cette section décrit les symptômes spécifiques, leurs causes et la façon de les résoudre. Pour les métriques, les événements d'attente et les requêtes de diagnostic utilisés pour surveiller une charge de travail, consultezContrôle.

Problèmes d'installation et de configuration

Les problèmes d'installation et de configuration courants sont les suivants.

Extension non disponible

Symptôme : CREATE EXTENSION aurora_analytics échec avec l'erreur suivante.

ERROR:  extension "aurora_analytics" is not available

Causes et solutions : Cette erreur signifie que vous exécutez une version d'Aurora PostgreSQL qui ne prend pas en charge l'extension. aurora_analytics Pour utiliser cette fonctionnalité, effectuez une mise à niveau vers Aurora PostgreSQL 17.11 ou version ultérieure, ou vers la version 18.6 ou supérieure. Utilisez le tableau suivant pour identifier la cause et la résoudre.

Pour effectuer un diagnostic, exécutez les requêtes suivantes. La seconde ne renvoie aucune ligne sur une version non prise en charge.

SELECT version();

SELECT * FROM pg_available_extensions WHERE name = 'aurora_analytics';

Fonctionnalité non activée

Symptôme : Une requête portant sur une table étrangère échoue avec l'erreur suivante. Cela est distinct de l'erreur d'indisponibilité de l'extension : l'extension est installée avec succès, mais les requêtes sont rejetées car la fonctionnalité est désactivée au niveau du cluster de base de données.

ERROR:  aurora_analytics is not enabled
HINT:  Set aurora_analytics.enabled to true in the parameter group and retry the query.

Cause : aurora_analytics.enabled est défini suroff.

Solution : définissez sur on dans aurora_analytics.enabled le groupe de paramètres de votre cluster de base de données. En tant que paramètre dynamique, la modification est appliquée immédiatement sans redémarrage.

Pour diagnostiquer, exécutez la requête suivante.

SHOW aurora_analytics.enabled;

Autorisation refusée pour créer une extension

Symptôme : La création de l'extension échoue avec l'erreur suivante.

ERROR:  permission denied to create extension "aurora_analytics"

Solution : Pour créer l'extension, vous devez avoir le rds_superuser rôle ou être un utilisateur à qui le rds_extension rôle a été attribué et qui a délégué cette extension. Être propriétaire de la base de données n'est pas suffisant. Accordez le rds_superuser rôle et réessayez.

GRANT rds_superuser TO your_user;
CREATE EXTENSION aurora_analytics;

Sinon, pour permettre à un non-superutilisateur de créer l'extension, accordez le rds_extension rôle et déléguez cette extension spécifique. Exécutez ce qui suit en tant querds_superuser.

GRANT rds_extension TO your_user;
ALTER USER your_user SET rds.allowed_delegated_extensions = 'aurora_analytics';

La rds_extension subvention à elle seule n'est pas suffisante. Sans entrée aurora_analyticsrds.allowed_delegated_extensions, CREATE EXTENSION échoue avec « Cette extension n'est pas spécifiée dans \" rds.allowed_delegated_extensions \ "». Pour plus d'informations, consultez Utilisation de la prise en charge déléguée des extensions Amazon RDS pour PostgreSQL.

Le rôle IAM n'est pas actif

Symptôme : les requêtes de tables étrangères échouent avec des erreurs de refus d'accès, ou le statut du rôle s'affiche Pending au lieu deActive.

Diagnostic : exécutez la commande suivante pour vérifier l'état de l'association de rôles.

aws rds describe-db-clusters \
  --db-cluster-identifier <cluster-id> \
  --query "DBClusters[0].AssociatedRoles"

Solution : Utilisez le tableau suivant pour agir sur le statut.

Amazon S3 et erreurs d'accès aux données

Les erreurs courantes liées à Amazon S3 et à l'accès aux données sont répertoriées ci-dessous.

Accès refusé lors de la lecture d'Amazon S3

Symptôme : Une requête de table étrangère échoue avec l'erreur suivante.

ERROR:  [Aurora Analytics] HTTP 403 Forbidden

Causes et solutions : Vérifiez les points suivants.

Diagnostic : exécutez la requête suivante pour inspecter les options de la table étrangère.

SELECT ft.ftrelid::regclass, ftoptions
FROM pg_foreign_table ft
WHERE ft.ftrelid::regclass::text = 'ft_orders';

AWS Glue délai d'expiration ou erreur de connexion

Symptôme : une requête échoue avec l'erreur suivante.

ERROR:  [Aurora Analytics] Glue GetTable API failed: curlCode: 28, Timeout was reached; Connection timed out after 301 milliseconds

Cause : aucun point de terminaison d'interface AWS Glue VPC n'existe ou un groupe de sécurité bloque le port TCP 443.

Pour résoudre ce problème : Procédez comme suit.

AWS Glue table introuvable

Symptôme : une requête échoue avec l'erreur suivante.

ERROR:  [Aurora Analytics] Glue GetTable API failed: EntityNotFoundException: Database not found: <name>

-- or

ERROR:  [Aurora Analytics] Glue GetTable API failed: EntityNotFoundException: Table not found: <name>

Causes et solutions : utilisez le tableau suivant pour identifier la cause et la résoudre.

Diagnostic : exécutez la commande suivante.

aws glue get-table \
  --database-name <db> \
  --name <table> \
  --region <region>

Mauvais format spécifié

Symptôme : une requête échoue avec l'erreur suivante.

ERROR:  [Aurora Analytics] failed to fetch column information...
HINT:  If the S3 location contains Parquet files, verify the foreign table was created with format 'parquet' instead of 'iceberg'.

Solution : recréez le tableau étranger avec le format correct.

DROP FOREIGN TABLE ft_my_table;

CREATE FOREIGN TABLE ft_my_table ()
SERVER aurora_analytics_server
OPTIONS (
    location 's3://my-bucket/data/',
    format 'parquet',
    region 'us-east-1'
);

Échec de résolution DNS

Symptôme : une requête échoue avec l'erreur suivante.

ERROR:  [Aurora Analytics] Glue GetTable API failed: curlCode: 6, Could not resolve host: glue.<region>.amazonaws.com

Cause : Mauvaise région dans l' AWS Glue ARN, ou le point de terminaison VPC n'est pas disponible dans cette région.

Solution : Procédez comme suit.

Problèmes de performances des requêtes

Les problèmes de performance des requêtes les plus courants sont les suivants.

Les requêtes sont lentes

Symptôme : les requêtes prennent plus de temps que prévu.

Causes et solutions : utilisez le tableau suivant pour déterminer pourquoi les requêtes sont lentes et comment y répondre.

Requêtes utiles : pour vérifier si les requêtes sont traitées depuis le cache ou depuis Amazon S3, et si elles se répètent, exécutez la requête suivante.

SET aurora_analytics.track_detailed_metrics = true;
-- Run your query, then check per-query stats
SELECT query, analytics_cache_hit_bytes, analytics_remote_read_bytes, analytics_total_disk_spill
FROM aurora_analytics_stat_statements()
ORDER BY analytics_remote_read_bytes DESC;

Si cette valeur analytics_remote_read_bytes est élevée par rapport àanalytics_cache_hit_bytes, le cache est froid ou l'ensemble de travail dépasse la capacité du cache.

Pour vérifier le nombre de sessions d'analyse actives, exécutez la requête suivante.

SELECT COUNT(*) FROM pg_stat_activity a
WHERE a.state = 'active'
  AND EXISTS (
      SELECT 1 FROM pg_foreign_table ft
      JOIN pg_class c ON c.oid = ft.ftrelid
      JOIN pg_foreign_server fs ON fs.oid = ft.ftserver
      WHERE fs.srvname = 'aurora_analytics_server'
        AND a.query ILIKE '%' || c.relname || '%'
  );

Erreurs de mémoire insuffisante

Symptôme : deux erreurs partagent la même ERROR ligne mais diffèrent dans le mode HINT opératoireDETAIL. Dans le premier cas, la requête a besoin de plus de mémoire.

ERROR:  [Aurora Analytics] Out of Memory Error: Failed to allocate memory for query execution.
HINT:  Possible solution: Increasing the query mem (SET aurora_analytics.query_mem='...GB')

Dans le second cas, l'instance de base de données est soumise à une pression de mémoire à l'échelle de l'instance.

ERROR:  [Aurora Analytics] Out of Memory Error: Failed to allocate memory for query execution.
DETAIL:  Transaction cancelled due to insufficient memory

Cause : Distinguez les deux cas par la ligne qui les accompagne.

Confirmez la cause à l'aide de métriques : Vérifiez les points suivants.

Pour résoudre ce problème : choisissez le chemin qui correspond au message. Si l'erreur est associée à un HINT (mémoire de requête trop faible), procédez comme suit.

Si l'erreur entraîne une DETAIL (pression sur la mémoire de l'instance), procédez comme suit.

Stockage insuffisant en raison d'une fuite de requêtes

Symptôme : une requête échoue avec l'erreur suivante.

ERROR:  [Aurora Analytics] could not write to temporary file: No space left on device

Cause : lorsque les résultats intermédiaires d'une requête sont supérieursquery_mem, le moteur transfère les données vers un stockage local temporaire. Si plusieurs requêtes simultanées se répandent simultanément, ou si une seule requête déverse un très gros volume de données, le stockage local peut être épuisé. query_memest un budget par requête plutôt qu'un pool à l'échelle de l'instance, ce qui signifie que chaque requête simultanée peut générer son propre débordement et que les fichiers sortants partagent le stockage local avec le cache de lecture. Ensemble, c'est la raison pour laquelle la simultanéité, plutôt qu'une seule requête volumineuse, est le déclencheur habituel de l'épuisement.

Diagnostic : surveillez sur Amazon AuroraAnalyticsDiskSpillSize le volume CloudWatch de déversements à l'échelle de l'instance, puis attribuez-le à un backend.

SELECT pid,
       pg_size_pretty(disk_spill_size) AS spill,
       pg_size_pretty(current_memory_usage) AS mem_used,
       active_threads
FROM aurora_analytics_stat_resource_usage()
WHERE disk_spill_size > 0
ORDER BY disk_spill_size DESC;

Pour résoudre ce problème : Procédez comme suit.

Problèmes liés aux tables étrangères

Les problèmes courants liés aux tables étrangères sont les suivants.

Incompatibilité du schéma

Symptôme : une requête échoue avec l'erreur suivante ou renvoie des types de données incorrects.

ERROR:  column "column_name" does not exist

Causes : les définitions des colonnes ne correspondent pas au schéma Parquet ou Iceberg réel, ou le schéma source a été modifié après la création de la table étrangère.

Pour résoudre ce problème : si la table étrangère existe déjà et que seules ses définitions de colonnes sont dérivées de la source, actualisez-la sur place avecaurora_analytics_refresh_foreign_table, ce qui permet de réconcilier les définitions de colonne sans supprimer ni recréer la table (en préservant les autorisations et les objets dépendants). Pour la syntaxe complète et les autorisations, voirRéférence sur les fonctions SQL. L'apply_changesargument est obligatoire : pass false pour prévisualiser les modifications sans modifier le tableau, ou true pour les appliquer. Faites d'abord un essai à sec, puis appliquez.

-- Preview the schema changes
SELECT aurora_analytics_refresh_foreign_table('ft_my_table', false);
-- Apply them
SELECT aurora_analytics_refresh_foreign_table('ft_my_table', true);

Vous pouvez également recréer la table étrangère avec une inférence de schéma.

DROP FOREIGN TABLE ft_my_table;
CREATE FOREIGN TABLE ft_my_table ()
SERVER aurora_analytics_server
OPTIONS (location 's3://...', format 'parquet', region 'us-east-1');
-- Check inferred schema
\d ft_my_table

Erreur de type de colonne non prise en charge

Symptôme : La création d'une table étrangère échoue avec l'erreur suivante.

ERROR:  unsupported data type for column "complex_column"

Solution : activez l'option d'ignorer les colonnes non prises en charge, puis recréez la table étrangère. Les colonnes non prises en charge sont ignorées.

SET aurora_analytics.skip_unsupported_columns = true;
-- Recreate the table, unsupported columns are skipped
DROP FOREIGN TABLE ft_my_table;
CREATE FOREIGN TABLE ft_my_table ()
SERVER aurora_analytics_server
OPTIONS (location 's3://...', format 'parquet', region 'us-east-1');

Problèmes de connexion et de session

Les problèmes de connexion et de session les plus courants sont les suivants.

Long-running requêtes bloquant d'autres travaux

Symptôme : quelques requêtes analytiques consomment la plupart des ressources de l'instance, ce qui ralentit les performances. Sur Amazon CloudWatch, cela se traduit par un pic soutenu CPUUtilization associé à un AuroraAnalyticsActiveThreads nombre élevé, même si seules quelques sessions sont actives. Ces sessions indiquent l'événement Extension:AuroraAnalyticsExecute d'attente dans le graphique des sessions actives moyennes (AAS). Quelques sessions peuvent entraîner une charge CPU élevée car chaque requête analytique s'exécute sur de nombreux threads de travail ; voirInterprétation du nombre de threads actifs.

Diagnostic : exécutez la requête suivante pour rechercher les requêtes analytiques de longue durée.

WITH analytics_tables AS (
    SELECT c.relname
    FROM pg_foreign_table ft
    JOIN pg_class c ON c.oid = ft.ftrelid
    JOIN pg_foreign_server fs ON fs.oid = ft.ftserver
    WHERE fs.srvname = 'aurora_analytics_server'
)
SELECT a.pid, a.usename, a.datname,
       NOW() - a.query_start AS runtime, a.state,
       LEFT(a.query, 100) AS query_preview
FROM pg_stat_activity a
WHERE a.state = 'active'
  AND EXISTS (SELECT 1 FROM analytics_tables t WHERE a.query ILIKE '%' || t.relname || '%')
ORDER BY a.query_start;

Solution : définissez un environnement statement_timeout d'exécution des requêtes limité pour les utilisateurs analytiques.

ALTER USER analyst SET statement_timeout = '30min';

Pour arrêter une requête déjà en cours d'exécution, annulez ou arrêtez son backend.

SELECT pg_cancel_backend(<pid>);     -- cancel the query
SELECT pg_terminate_backend(<pid>);  -- terminate the session

Tempêtes de connexion

Symptôme : DatabaseConnections des pics soudains et des requêtes ralentissent ou échouent.

Solution : implémentez le regroupement des connexions (par exemple, Amazon RDS Proxy) pour gérer les connexions analytiques et définissez les statement_timeout valeurs appropriées pour empêcher les requêtes intempestives.

Basculement et basculement globaux des bases de données

Les problèmes suivants sont courants après un basculement ou un basculement de base de données globale.

Cross-Region Latence d'Amazon S3 après le passage au numérique

Symptôme : après le basculement ou le basculement d'une base de données globale, les requêtes analytiques ralentissent.

Cause : les tables étrangères pointent toujours vers des compartiments Amazon S3 situés dans la région d'origine, de sorte que le nouveau fichier principal indique Cross-region.

Confirmez la cause à l'aide de métriques : le niveau élevé AuroraAnalyticsRemoteRead et AuroraAnalyticsS3GetRequest après le passage au numérique, en particulier lorsque les requêtes qui étaient auparavant envoyées depuis le cache affichent désormais des lectures à distance soutenues, indique que le nouveau serveur principal extrait des données depuis la région d'origine plutôt que localement. On s'attend à ce que AuroraAnalyticsCacheHitRatio le nouveau serveur principal soit épuisé jusqu'à ce que son cache se réchauffe.

Ces indicateurs de volume ne permettent pas à eux seuls de distinguer les lectures interrégionales d'un réchauffement local du cache froid, car les deux augmentent le volume de lecture à distance juste après un basculement. La latence des requêtes Amazon S3 est ce qui les distingue : un pic de latence par requête indique des lectures entre régions, tandis qu'un cache froid local se réchauffe à une latence normale. Aurora PostgreSQL n'émet pas de métrique de latence de lecture à distance. Pour la mesurer, activez Amazon S3 Request Metrics sur le bucket et TotalRequestLatency surveillez (moyenne et p99) dans l'espace de noms Amazon. AWS/S3 CloudWatch Les métriques de demande Amazon S3 ne sont pas activées par défaut.

Pour résoudre ce problème : Procédez comme suit.

Association de rôles IAM manquante dans la région secondaire

Symptôme : les requêtes échouent avec l'erreur suivante.

ERROR:  credential to access AWS service is unavailable
HINT:  Please attach IAM role with proper permission policy to this cluster with the feature name "AuroraAnalytics".

Cause : Le rôle IAM n'a jamais été associé au cluster de cette région.

Solution : associez le rôle IAM au nom de la fonctionnalitéAuroraAnalytics, puis attendez que son statut devienne Active le même.

Le rôle IAM ne dispose d'aucune autorisation dans la région secondaire

Symptôme : pour Parquet dans Amazon S3, les requêtes échouent avec l'erreur suivante.

ERROR:  [Aurora Analytics] Executor Error: ... HTTP 403 Forbidden
        AccessDenied: User: arn:aws:sts::<account>:assumed-role/AuroraAnalyticsRole/...
        is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::<bucket>/<key>"

Pour Iceberg through AWS Glue, les requêtes échouent avec l'erreur suivante.

ERROR:  [Aurora Analytics] Glue GetTable API failed: User: ... is not authorized to perform:
        glue:GetTable on resource: arn:aws:glue:<region>:<account>:catalog

Cause : Le rôle est associé, mais sa politique ne dispose pas des autorisations requises.

Solution : attachez une politique qui autorise les actions requises. L'erreur indique le nom exact de l'action et de la ressource qui ont été refusées.

Aucun chemin réseau vers Amazon S3 ou AWS Glue dans la région secondaire

Symptôme : pour Amazon S3, les requêtes échouent avec l'erreur suivante.

ERROR:  [Aurora Analytics] Executor Error: ... Timeout was reached error for HTTP HEAD to
        'https://<bucket>.s3.<region>.amazonaws.com/<key>'

Car AWS Glue les requêtes échouent avec l'erreur suivante.

ERROR:  [Aurora Analytics] Glue GetTable API failed: curlCode: 28,
        Timeout was reached; Details: Connection timed out after 300 milliseconds

Cause : Il n'y a aucun point de terminaison VPC ni chemin NAT dans le VPC de cette région.

Solution : créez un point de terminaison de passerelle Amazon S3, un point de terminaison d' AWS Glue interface et un point de terminaison d'interface AWS STS.

Activation de la journalisation détaillée

Pour les problèmes transitoires ou difficiles à reproduire, activez temporairement la journalisation détaillée.

-- As rds_superuser
SET aurora_analytics.enable_logging = true;
SET aurora_analytics.logging_level = 'DEBUG1';

-- Reproduce the issue
SELECT * FROM ft_problematic_table WHERE ...;

-- Reset logging level after investigation
RESET aurora_analytics.logging_level;
RESET aurora_analytics.enable_logging;

Les messages de diagnostic du moteur d'analyse sont écrits dans le journal des erreurs de PostgreSQL. Pour la référence des paramètres et les trois méthodes de récupération du journal, consultezLogging.