Résolution des problèmes de connexion dans Amazon Redshift - Amazon Redshift
Connexion depuis l’extérieur d’Amazon EC2 et survenue d’un problème de dépassement de délai du pare-feuLa connexion est refusée ou échoueLe client et le pilote sont incompatiblesDes requêtes semblent se bloquer et parfois échouent à atteindre le clusterDéfinition du paramètre de taille d’extraction JDBC

Amazon Redshift ne prendra plus en charge la création de nouvelles fonctions Python définies par l’utilisateur à compter du 1er novembre 2025. Si vous souhaitez utiliser des fonctions Python définies par l’utilisateur, créez-les avant cette date. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement. Pour plus d’informations, consultez le billet de blog .

Résolution des problèmes de connexion dans Amazon Redshift

Si vous rencontrez des problèmes de connexion à votre cluster avec un outil client SQL, vérifiez plusieurs éléments pour cerner le problème. Si vous utilisez des certificats SSL ou serveur, commencez par supprimer cette complexité pendant que vous résolvez le problème de connexion. Ensuite, rajoutez-la lorsque vous avez trouvé une solution. Pour plus d’informations, consultez Configuration des options de sécurité des connexions.

Pour plus d’informations sur les changements de comportement dans les fonctionnalités Amazon Redshift susceptibles d’affecter votre application, consultez Changements de comportement dans Amazon Redshift.

Important

Amazon Redshift a changé la méthode de gestion des certificats SSL. Si vous avez des difficultés à vous connecter avec SSL, il se peut que vous ayez besoin de mettre à jour vos certificats actuels d’autorité de certification racine. Pour plus d'informations, consultez Transition vers les certificats ACM pour les connexions SSL.

La section suivante présente des exemples de messages d’erreur et des solutions possibles aux problèmes de connexion. Etant donné que différents outils clients SQL fournissent différents messages d’erreur, cette liste n’est pas exhaustive, mais constitue un bon point de départ pour la résolution des problèmes.

Connexion depuis l’extérieur d’Amazon EC2 et survenue d’un problème de dépassement de délai du pare-feu

La connexion de votre client à la base de données semble se bloquer ou arriver à expiration lorsque vous exécutez de longues requêtes, par exemple une commande COPY. Dans ce cas, vous pouvez constater que la console Amazon Redshift affiche que la requête est terminée, mais que l’outil client lui-même semble toujours exécuter la requête. Les résultats de la requête peuvent être manquants ou incomplets en fonction selon le moment où la connexion s’est arrêtée.

Solutions possibles

Ce problème se produit lorsque vous vous connectez à Amazon Redshift depuis une machine autre qu’une instance Amazon EC2. Dans ce cas, les connexions inactives sont résiliées par un composant réseau intermédiaire, tel qu’un pare-feu, après une période d’inactivité. Ce comportement est typique lorsque vous vous connectez à partir d’un réseau VPN ou de votre réseau local.

Pour éviter ces délais d’attente, nous vous recommandons d’apporter les modifications suivantes :

Modification des paramètres d’expiration de TCP/IP

Pour modifier les paramètres d’expiration de TCP/IP, configurez-les en fonction du système d’exploitation que vous utilisez pour vous connecter à votre cluster.

  • Linux — Si votre client fonctionne sous Linux, exécutez la commande suivante en tant qu’utilisateur root pour modifier les paramètres de délai d’attente pour la séance en cours : 

    /sbin/sysctl -w net.ipv4.tcp_keepalive_time=200 net.ipv4.tcp_keepalive_intvl=200 net.ipv4.tcp_keepalive_probes=5

    Pour conserver les paramètres, créez ou modifiez le fichier /etc/sysctl.conf avec les valeurs suivantes, puis redémarrez votre système. 

    net.ipv4.tcp_keepalive_time=200
net.ipv4.tcp_keepalive_intvl=200
net.ipv4.tcp_keepalive_probes=5

  • Windows — Si votre client fonctionne sous Windows, modifiez les valeurs des paramètres de registre suivants sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ :

    • KeepAliveTime : 30 000

    • KeepAliveInterval : 1 000

    • TcpMaxDataRetransmissions : 10

    Ces paramètres utilisent le type de données DWORD. S’ils n’existent pas sous le chemin d’accès au registre, vous pouvez créer les paramètres et spécifiez ces valeurs recommandées. Pour plus d’informations sur la modification du registre Windows, reportez-vous à la documentation Windows.

    Une fois ces valeurs définies, redémarrez votre ordinateur pour que les modifications prennent effet.

  • Mac — Si votre client fonctionne sur un Mac, exécutez les commandes suivantes pour modifier les paramètres de délai d’attente pour la séance en cours : 

    sudo sysctl net.inet.tcp.keepintvl=200000
sudo sysctl net.inet.tcp.keepidle=200000
sudo sysctl net.inet.tcp.keepinit=200000
sudo sysctl net.inet.tcp.always_keepalive=1

    Pour conserver les paramètres, créez ou modifiez le fichier /etc/sysctl.conf avec les valeurs suivantes : 

    net.inet.tcp.keepidle=200000
net.inet.tcp.keepintvl=200000
net.inet.tcp.keepinit=200000
net.inet.tcp.always_keepalive=1

    Redémarrez votre ordinateur, puis exécutez les commandes suivantes pour vérifier que les valeurs sont définies. 

    sysctl net.inet.tcp.keepidle
sysctl net.inet.tcp.keepintvl
sysctl net.inet.tcp.keepinit
sysctl net.inet.tcp.always_keepalive

Modification des paramètres d’expiration de la DSN

Vous pouvez définir un comportement keepalive au niveau de la DSN si vous le souhaitez. Pour cela, vous ajoutez ou vous modifiez les paramètres suivants dans le fichier odbc.ini :

KeepAlivesCount

Nombre de paquets TCP keepalive qui peuvent être perdus avant que la connexion soit considérée comme interrompue.

KeepAlivesIdle

Nombre de secondes d’inactivité avant que le pilote envoie un paquet TCP keepalive.

KeepAlivesInterval

Nombre de secondes entre chaque retransmission de paquet TCP keepalive.

Si ces paramètres n’existent pas ou s’ils ont une valeur égale à 0, le système utilise les paramètres keepalive spécifiés pour TCP/IP afin de déterminer le comportement DSN keepalive. Sous Windows, vous pouvez trouver les paramètres TCP/IP dans le registre dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\. Sous Linux et macOS, les paramètres TCP/IP sont disponibles dans le fichier sysctl.conf.

La connexion est refusée ou échoue

Lorsque votre connexion est refusée ou échoue, vous pouvez recevoir une erreur similaire à l’une des suivantes.

  • « Impossible d’établir une connexion à <endpoint>. »

  • « Impossible de se connecter au serveur : la connexion a expiré. Le serveur s’exécute-t-il sur l’hôte ’<endpoint>’ et accepte-t-il les connexions TCP/IP sur le port ’<port>’ ? »

  • « Connexion refusée. Vérifiez que le nom d’hôte et le port sont corrects et que l’administrateur accepte les connexions TCP/IP. »

Solutions possibles

En général, lorsque vous recevez un message d’erreur indiquant qu’il est impossible d’établir une connexion, cela signifie qu’il y a un problème d’autorisation d’accès au cluster ou que le trafic réseau ne peut pas atteindre le cluster.

Pour vous connecter au cluster depuis un outil client en dehors du réseau sur lequel se trouve le cluster, ajoutez une règle d’entrée au groupe de sécurité du cluster. La configuration de la règle dépend de la création du cluster Amazon Redshift dans un cloud privé virtuel (VPC) :

  • Si vous avez créé le cluster Amazon Redshift dans un cloud privé virtuel (VPC) basé sur Amazon VPC, ajoutez la règle d’entrée au groupe de sécurité du VPC qui spécifie l’adresse CIDR/IP de votre client dans Amazon VPC. Pour plus d’informations sur la configuration des groupes de sécurité du VPC pour votre cluster et les options publiquement accessibles, consultez Ressources Redshift dans un VPC.

  • Si vous avez créé votre cluster Amazon Redshift en dehors d’un VPC, ajoutez l’adresse CIDR/IP de votre client au groupe de sécurité du cluster dans Amazon Redshift. Pour plus d’informations sur la configuration des groupes de sécurité de cluster, consultez Groupes de sécurité Amazon Redshift.

Si vous tentez de vous connecter au cluster à partir d’un outil client qui s’exécute sur une instance Amazon EC2, vous ajoutez également une règle d’entrée. Dans ce cas, ajoutez une règle au groupe de sécurité du cluster. La règle doit spécifier le groupe de sécurité Amazon EC2 associé à l’instance Amazon EC2 de l’outil client.

Dans certains cas, vous pouvez avoir une couche entre votre client et le serveur, telle qu’un pare-feu. Dans ce cas, assurez-vous que le pare-feu accepte les connexions entrantes via le port que vous avez configuré pour votre cluster.

Le client et le pilote sont incompatibles

Si votre client et votre pilote sont incompatibles, vous pouvez recevoir un message d’erreur indiquant : « The specified DSN contains an architecture mismatch between the Driver and Application ».

Solutions possibles

Lorsque vous tentez de vous connecter et que vous obtenez une erreur concernant une incompatibilité d’architecture, cela signifie que l’outil client et le pilote ne sont pas compatibles. Cela se produit parce que leur architecture système ne correspond pas. Par exemple, cela peut se produire si vous avez un outil client 32 bits, alors que vous avez installé la version 64 bits du pilote. Les outils clients 64 bits utilisent parfois des pilotes 32 bits, mais vous ne pouvez pas utiliser d’applications 32 bits avec des pilotes 64 bits. Assurez-vous que le pilote et l’outil client utilisent la même version d’architecture système.

Des requêtes semblent se bloquer et parfois échouent à atteindre le cluster

Vous rencontrez un problème pour terminer des requêtes, notamment que les requêtes semblent être en cours d’exécution, mais se bloquent dans l’outil client SQL. Parfois, les requêtes n’apparaissent pas dans le cluster, par exemple dans les tables système ou dans la console Amazon Redshift.

Solutions possibles

Ce problème peut se produire en raison de la perte de paquets. Dans ce cas, il existe une différence dans la taille maximale de l’unité de transmission (MTU) dans le chemin réseau entre deux hôtes IP (Internet Protocol). La taille de la MTU détermine la taille maximale, en octets, d’un paquet pouvant être transféré dans une trame Ethernet sur une connexion réseau. Dans AWS, certains types d’instance Amazon EC2 prennent en charge un MTU de 1500 (trames Ethernet v2) et d’autres types d’instance prennent en charge un MTU de 9001 (trames jumbo TCP/IP).

Pour éviter que des problèmes se produisent en raison de différences de taille de la MTU, nous vous recommandons procéder comme suit :

  • Si votre cluster utilise la plateforme EC2-VPC, configurez le groupe de sécurité Amazon VPC avec une règle ICMP (Internet Control Message Protocol) personnalisée entrante qui renvoie Destination Unreachable. Cette règle indique que l’hôte d’origine utilise la taille de MTU la plus petite sur chemin d’accès réseau. Pour plus d’informations sur cette approche, consultez Configuration des groupes de sécurité pour autoriser le message ICMP « Destination inaccessible ».

  • Si votre cluster utilise la plateforme EC2-Classic ou si vous ne pouvez pas autoriser la règle de trafic entrant ICMP, désactivez les trames jumbo TCP/IP afin que des trames Ethernet v2 soient utilisées. Pour plus d’informations sur cette approche, consultez Configuration de la MTU d’une instance.

Configuration des groupes de sécurité pour autoriser le message ICMP « Destination inaccessible »

En cas de différence de taille de la MTU sur le réseau entre deux hôtes, vérifiez d’abord que vos paramètres réseau n’empêchent pas la détection de la MTU du chemin (PMTUD, path MTU discovery). La PMTUD permet à l’hôte de réception de répondre à l’hôte d’origine avec le message suivant ICMP suivant : Destination Unreachable: fragmentation needed and DF set (ICMP Type 3, Code 4). Ce message indique que l’hôte d’origine utilise la taille de MTU la plus petite sur chemin d’accès réseau pour renvoyer la demande. Sans cette négociation, un rejet de paquet peut se produire, car la demande est trop volumineuse pour l’hôte de réception. Pour plus d’informations sur ce message ICMP, consultez RFC792 sur le site web Internet Engineering Task Force (IETF).

Si vous ne configurez pas explicitement cette règle ICMP entrante pour votre groupe de sécurité Amazon VPC, PMTUD est bloqué. Dans AWS, les groupes de sécurité sont des pare-feu virtuels qui spécifient des règles de trafic entrant et sortant pour une instance. Pour plus d’informations sur le groupe de sécurité de cluster Amazon Redshift, consultez Groupes de sécurité Amazon Redshift. Pour les clusters utilisant la plateforme EC2-VPC, Amazon Redshift utilise les groupes de sécurité VPC pour autoriser ou refuser le trafic vers le cluster. Par défaut, les groupes de sécurité sont verrouillés et refusent tout trafic entrant. Pour plus d’informations sur la définition des règles d’entrée et de sortie pour les instances EC2-Classic ou EC2-VPC, consultez Différences entre les instances EC2-Classic et VPC du Guide de l’utilisateur Amazon EC2.

Pour plus d’informations sur la procédure pour ajouter des règles aux groupes de sécurité VPC, consultez Groupes de sécurité VPC. Pour plus d’informations sur les paramètres PMTUD spécifiques requis dans cette règle, consultez Détection de la MTU du chemin dans le Guide de l’utilisateur Amazon EC2.

Configuration de la MTU d’une instance

Dans certains cas, votre cluster peut utiliser la plate-forme EC2-Classic ou vous ne pouvez pas autoriser la règle ICMP personnalisée pour le trafic entrant. Dans ces cas, nous vous recommandons d’ajuster le MTU à 1500 sur l’interface réseau (NIC) des instances EC2 à partir desquelles vous vous connectez à votre cluster Amazon Redshift. Cet ajustement désactive les trames jumbo TCP/IP pour s’assurer que les connexions utilisent systématiquement la même taille de paquet. Toutefois, cette option réduit le débit maximal du réseau pour l’instance dans son ensemble, et pas seulement pour les connexions à Amazon Redshift. Pour plus d’informations, consultez les procédures suivantes.

Pour définir la MTU sur un système d’exploitation Microsoft Windows

Si votre client s’exécute sur un système d’exploitation Microsoft Windows, vous pouvez vérifier et définir la valeur de la MTU pour la carte Ethernet à l’aide de la commande netsh.

  1. Exécutez la commande suivante afin de déterminer la valeur actuelle de la MTU : 

    netsh interface ipv4 show subinterfaces

  2. Vérifiez la valeur de la MTU pour la carte Ethernet dans la sortie.

  3. Si la valeur n’est pas 1500, exécutez la commande suivante pour la définir : 

    netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent

    Une fois cette valeur définie, redémarrez votre ordinateur pour que les modifications prennent effet.

Pour définir la MTU sur un système d’exploitation Linux

Si le client s’exécute sur un système d’exploitation Linux, vous pouvez vérifier et définir la valeur de la MTU à l’aide de la commande ip.

  1. Exécutez la commande suivante afin de déterminer la valeur actuelle de la MTU : 

    $ ip link show eth0

  2. Vérifiez la valeur suivant mtu dans la sortie.

  3. Si la valeur n’est pas 1500, exécutez la commande suivante pour la définir : 

    $ sudo ip link set dev eth0 mtu 1500
Pour définir la MTU sur un système d’exploitation Mac

  • Suivez les instructions sur le site de support macOS sur How to change the MTU for troubleshooting purposes. Pour plus d’informations, consultez le site du support.

Définition du paramètre de taille d’extraction JDBC

Par défaut, le pilote JDBC collecte tous les résultats pour une requête à la fois. Par conséquent, lorsque vous essayez de récupérer un jeu de résultats volumineux via une connexion JDBC, il se peut que vous rencontriez une erreur de saturation de la mémoire côté client. Pour autoriser votre client à extraire des jeux de résultats par lots plutôt qu’en une seule extraction basée sur le tout ou rien, définissez le paramètre de taille d’extraction JDBC dans votre application cliente.

Note

La taille de l’extraction n’est pas prise en charge pour ODBC.

Pour obtenir les meilleures performances, définissez la taille de l’extraction sur la valeur la plus élevée qui n’entraîne pas d’erreurs de mémoire. Une valeur d’extraction de taille inférieure entraîne plusieurs opérations du serveur, ce qui prolonge les temps d’exécution. Le serveur réserve des ressources, y compris l’emplacement de requête WLM et la mémoire associée, jusqu’à ce que le client récupère le jeu de résultats complet ou que la requête soit annulée. Lorsque vous ajustez la taille d’extraction de façon appropriée, ces ressources sont libérées plus rapidement, ce qui les rend disponibles pour d’autres requêtes.

Note

Si vous devez extraire de grands jeux de données, nous vous recommandons d’utiliser une instruction UNLOAD pour transférer les données vers Amazon S3. Lorsque vous utilisez UNLOAD, les nœuds de calcul fonctionnent en parallèle afin d’accélérer le transfert des données.

Pour plus d’informations sur la définition du paramètre de taille d’extraction JDBC, consultez Obtention de résultats basés sur un curseur dans la documentation de PostgreSQL.