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 JDBC de récupération

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 pour vous connecter à votre cluster à partir d'un outil SQL client, vous pouvez vérifier plusieurs points pour réduire le problème. Si vous utilisez des certificats de serveur SSL ou de serveur, supprimez d'abord cette complexité pendant que vous résolvez le problème de connexion. Ensuite, rajoutez-la lorsque vous avez trouvé une solution. Pour de plus amples informations, veuillez consulter Configuration des options de sécurité des connexions.

Important

Amazon Redshift a changé la façon dont les SSL certificats sont gérés. Si vous rencontrez des difficultés pour vous connecter en utilisantSSL, vous devrez peut-être mettre à jour vos certificats racine de confiance CA actuels. Pour de plus amples informations, veuillez consulter Transition vers des ACM certificats pour les connexions SSL.

La section suivante présente des exemples de messages d’erreur et des solutions possibles aux problèmes de connexion. Étant donné que les différents outils SQL clients fournissent des messages d'erreur différents, cette liste n'est pas exhaustive, mais elle devrait constituer un bon point de départ pour résoudre les 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 expirer lorsque vous exécutez de longues requêtes, telles qu'une COPY commande. 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 AmazonEC2. Dans ce cas, les connexions inactives sont interrompues 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 privé virtuel (VPN) ou de votre réseau local.

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

  • Augmentez les valeurs du système client qui gèrent les délais d'expiration TCP /IP. Apportez ces modifications sur l’ordinateur que vous utilisez pour vous connecter à votre cluster. Le délai d’expiration doit être réglé pour votre client et le réseau. Pour de plus amples informations, veuillez consulter Modifier les paramètres de délai d'expiration TCP /IP.

  • Définissez éventuellement le comportement de keepalive au DSN niveau. Pour de plus amples informations, veuillez consulter Modifier les paramètres DSN du délai d'expiration.

Modifier les paramètres de délai d'expiration TCP /IP

Pour modifier les paramètres de délai d'expiration TCP /IP, configurez les paramètres de délai d'expiration 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 \ \ \ Services SYSTEM CurrentControlSet \ Tcpip \ Parameters \ :

    • KeepAliveTime: 30 000

    • KeepAliveInterval: 1000

    • TcpMaxDataRetransmissions: 10

    Ces paramètres utilisent le type de DWORD données. 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

Modifier les paramètres DSN du délai d'expiration

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

KeepAlivesCount

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

KeepAlivesIdle

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

KeepAlivesInterval

Le nombre de secondes entre chaque TCP retransmission 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 TCP /IP afin de déterminer le comportement de DSN keepalive. Sous Windows, vous pouvez trouver les paramètres TCP /IP dans le registre dansHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\. Sur Linux et macOS, les paramètres TCP /IP se trouvent 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 en acceptant 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 le postmaster 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 des règles dépend de la création ou non 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 AmazonVPC, ajoutez une règle entrante au groupe de VPC sécurité qui spécifie l'CIDRadresse IP du client, dans Amazon. VPC Pour plus d'informations sur la configuration des groupes VPC de sécurité pour votre cluster et sur les options accessibles au public, consultezLes ressources Redshift dans un VPC.

  • Si vous avez créé votre cluster Amazon Redshift en dehors d'unVPC, ajoutez votre adresse CIDR client/IP 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 essayez 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'EC2instance 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 : « L'architecture DSN spécifiée ne correspond pas au 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 lors de l'exécution des requêtes, celles-ci semblant être en cours d'exécution mais bloquées dans l'outil SQL client. 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 MTU taille détermine la taille maximale, en octets, d'un paquet qui peut être transféré dans une trame Ethernet via une connexion réseau. Dans AWS, certains types d'EC2instances Amazon prennent en charge une valeur MTU de 1 500 (trames Ethernet v2), tandis que d'autres types d'instances prennent en charge une MTU valeur de 9001 (trames jumbo TCP /IP).

Pour éviter les problèmes liés aux différences de MTU taille, nous vous recommandons d'effectuer l'une des opérations suivantes :

  • Si votre cluster utilise la VPC plate-forme EC2 -, configurez le groupe VPC de sécurité Amazon avec une règle de message de contrôle Internet (ICMP) personnalisée entrante qui renvoieDestination Unreachable. La règle indique donc à l'hôte d'origine d'utiliser la MTU taille la plus faible le long du chemin réseau. Pour plus d’informations sur cette approche, consultez Configuration des groupes de sécurité pour autoriser la ICMP « destination inaccessible ».

  • Si votre cluster utilise la plate-forme EC2 -Classic ou si vous ne pouvez pas autoriser la règle ICMP entrante, 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 MTU d'une instance.

Configuration des groupes de sécurité pour autoriser la ICMP « destination inaccessible »

En cas de différence de MTU taille du réseau entre deux hôtes, assurez-vous d'abord que vos paramètres réseau ne bloquent pas la MTU découverte du chemin (PMTUD). PMTUDpermet à l'hôte récepteur de répondre à l'hôte d'origine avec le ICMP message suivant :Destination Unreachable: fragmentation needed and DF set (ICMP Type 3, Code 4). Ce message indique à l'hôte d'origine d'utiliser la MTU taille la plus petite sur le chemin 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 ICMP message, 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 VPC sécurité Amazon, elle PMTUD est bloquée. 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 VPC plate-forme EC2 -, Amazon Redshift utilise des groupes VPC de sécurité 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 VPC instances EC2 -Classic ou EC2 -, consultez la section Différences entre les instances dans EC2 -Classic et a dans le guide de VPC l'utilisateur Amazon. EC2

Pour plus d'informations sur l'ajout de règles aux groupes VPC de sécurité, consultezVPCgroupes de sécurité. Pour plus d'informations sur PMTUD les paramètres spécifiques requis par cette règle, consultez la section Path MTU discovery dans le guide de EC2 l'utilisateur Amazon.

Configuration MTU d'une instance

Dans certains cas, votre cluster peut utiliser la plateforme EC2 -Classic ou vous ne pouvez pas autoriser la ICMP règle personnalisée pour le trafic entrant. Dans ces cas, nous vous recommandons d'ajuster la valeur MTU à 1500 sur l'interface réseau (NIC) des EC2 instances à partir desquelles vous vous connectez à votre cluster Amazon Redshift. Ce réglage désactive les trames jumbo TCP /IP pour garantir que les connexions utilisent toujours 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 configurer MTU sur un système d'exploitation Microsoft Windows

Si votre client fonctionne sous un système d'exploitation Microsoft Windows, vous pouvez vérifier et définir la MTU valeur de l'adaptateur Ethernet à l'aide de la netsh commande.

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

    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.

À configurer MTU sur un système d'exploitation Linux

Si votre client fonctionne sous un système d'exploitation Linux, vous pouvez vérifier et définir la MTU valeur à l'aide de la ip commande.

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

    $ 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
À configurer 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 JDBC de récupération

Par défaut, le JDBC pilote collecte tous les résultats d'une requête en une seule fois. Par conséquent, lorsque vous tentez de récupérer un ensemble de résultats volumineux via une JDBC connexion, vous pouvez rencontrer une erreur côté client out-of-memory. Pour permettre à votre client de récupérer des ensembles de résultats par lots au lieu d'une seule all-or-nothing extraction, définissez le paramètre de taille de JDBC récupération dans votre application cliente.

Note

La taille de récupération n'est pas prise en charge pourODBC.

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 le slot de WLM requête et la mémoire associée, jusqu'à ce que le client récupère l'ensemble des résultats 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 UNLOADinstruction pour transférer les données vers Amazon S3. Lorsque vous l'utilisezUNLOAD, les nœuds de calcul fonctionnent en parallèle pour accélérer le transfert de données.

Pour plus d'informations sur la définition du paramètre de JDBC taille de récupération, consultez la section Obtenir des résultats en fonction d'un curseur dans la documentation PostgreSQL.