Résolution des problèmes de connexion dans Amazon Redshift - Amazon Redshift
Connexion depuis l'extérieur d'Amazon EC2 et problème de délai d'expiration 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

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 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.

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 problème de délai d'expiration 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 \ \ Services \ Tcpip CurrentControlSet \ Parameters \ :

    • KeepAliveTime: 30 000

    • KeepAliveInterval: 1000

    • 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 de 0, le système utilise les paramètres keepalive spécifiés pour les TCP/IP to determine DSN keepalive behavior. On Windows, you can find the TCP/IP paramètres du registre dansHKEY_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 avec<endpoint>. »

  • « Impossible de se connecter au serveur : la connexion a expiré. Le serveur fonctionne-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 EC2 instance Amazon, 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 EC2 de sécurité Amazon associé à l' EC2 instance Amazon 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 : « Le DSN spécifié contient une incompatibilité d'architecture entre le pilote et l'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' EC2 instances Amazon prennent en charge une MTU de 1500 (trames Ethernet v2) tandis que d'autres types d'instances prennent en charge une 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 plate-forme 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 plate-forme EC2 -Classic ou si vous ne pouvez pas autoriser la règle entrante ICMP, désactivez les trames jumbo TCP/IP afin que les 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, rendez-vous RFC792sur le site Web de l'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-feux virtuels qui spécifient des règles pour le trafic entrant et sortant vers 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 plate-forme EC2 -VPC, Amazon Redshift utilise des 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 façon de définir des règles entrantes et sortantes pour les instances EC2 -Classic ou EC2 -VPC, consultez la section Différences entre les instances -Classic EC2 et un VPC dans le 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 par cette règle, consultez la section Path MTU discovery dans le guide de l'utilisateur Amazon EC2 .

Configuration de la MTU d’une instance

Dans certains cas, votre cluster peut utiliser la plateforme EC2 -Classic ou vous ne pouvez pas autoriser la règle ICMP personnalisée pour le trafic entrant. Dans ces cas, nous vous recommandons de régler le MTU à 1500 sur l'interface réseau (NIC) des EC2 instances à 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 tentez de récupérer un ensemble de résultats volumineux via une connexion JDBC, vous risquez de rencontrer une erreur côté client out-of-memory. Pour permettre à votre client de récupérer des ensembles de résultats par lots plutôt que par une seule all-or-nothing extraction, définissez le paramètre de taille de lecture 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 des ensembles de données volumineux, 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.