Solução de problemas de conexão no Amazon Redshift
Se você está com problemas na conexão de uma ferramenta do cliente SQL com o seu cluster, existem várias coisas que pode verificar para reduzir o número de possibilidades para o motivo do problema. Se você estiver usando o SSL ou certificados de servidor, remova essa complexidade antes de tentar solucionar o problema de conexão. Você poderá adicioná-los de volta quando tiver encontrado uma solução. Para obter mais informações, consulte Configurar as opções de segurança para conexões.
Importante
O Amazon Redshift mudou a maneira como os certificados SSL são gerenciados. Se você tiver problemas para se conectar usando o SSL, talvez seja necessário atualizar os certificados CA raiz confiáveis. Para obter mais informações, consulte Transição para certificados ACM das conexões SSL.
A seção a seguir apresenta algumas mensagens de erro de exemplo e possíveis soluções para os problemas de conexão. Como diferentes ferramentas do cliente SQL geram diferentes mensagens de erro, essa não é uma lista completa, mas deve ser um bom ponto de partida para a solução de problemas.
Conectar-se de fora do Amazon EC2 e confrontar-se com um problema de tempo limite do firewall
A conexão do cliente com o banco de dados parece estar travada ou ter expirado por exceder o tempo limite ao executar consultas longas, como um comando de COPY. Nesse caso, você pode observar que o console do Amazon Redshift exibe que a consulta foi concluída, mas a própria ferramenta do cliente ainda parece estar executando a consulta. Os resultados da consulta podem estar ausentes ou incompletos, dependendo de quando a conexão foi interrompida.
Soluções possíveis:
Esse problema ocorre quando você se conecta ao Amazon Redshift de uma máquina que não seja uma instância do Amazon EC2. Nesse caso, as conexões são encerradas por um componente intermediário de rede, como um firewall, após um período de inatividade. Esse é um comportamento típico que ocorre ao fazer logon em uma rede virtual privada (VPN) ou na rede local.
Para evitar essas limitações de tempo, recomendamos as seguintes alterações:
-
Aumente os valores do sistema no cliente que controlam os tempos limite de TCP/IP. Faça essas alterações no computador que está sendo usado para se conectar ao cluster. O período limite deve ser ajustado para o cliente e a rede. Para obter mais informações, consulte Alteração das configurações de tempo limite de TCP/IP.
-
Opcionalmente, defina o comportamento de manutenção de atividade no nível do DSN. Para obter mais informações, consulte Alteração das configurações de tempo limite do DSN.
Alteração das configurações de tempo limite de TCP/IP
Para alterar as configurações de tempo limite de TCP/IP, configure essas definições de acordo com o sistema operacional usado para a conexão com o cluster.
-
Linux - Se o seu cliente estiver executando no Linux, execute o seguinte comando como usuário root para alterar as configurações de tempo limite da sessão atual:
/sbin/sysctl -w net.ipv4.tcp_keepalive_time=200 net.ipv4.tcp_keepalive_intvl=200 net.ipv4.tcp_keepalive_probes=5
Para manter as configurações, crie ou altere o arquivo
/etc/sysctl.conf
com os seguintes valores e, em seguida, reinicialize o sistema.net.ipv4.tcp_keepalive_time=200 net.ipv4.tcp_keepalive_intvl=200 net.ipv4.tcp_keepalive_probes=5
-
Windows - Se o seu cliente for executado no Windows, edite os valores para as seguintes configurações de registro em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\:
-
KeepAliveTime: 30000
-
KeepAliveInterval: 1000
-
TcpMaxDataRetransmissions: 10
Essas configurações usam o tipo de dados DWORD. Se elas não existem no caminho do registro, você pode criar as configurações e especificar esses valores recomendados. Para obter mais informações sobre como editar o registro do Windows, consulte a documentação do Windows.
Após configurar esses valores, reinicie seu computador para que as alterações sejam implementadas.
-
-
Mac - Se o seu cliente estiver sendo executado em um Mac, execute os seguintes comandos para alterar as configurações de tempo limite da sessão atual:
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
Para manter as configurações, crie ou altere o arquivo
/etc/sysctl.conf
com os seguintes valores:net.inet.tcp.keepidle=200000 net.inet.tcp.keepintvl=200000 net.inet.tcp.keepinit=200000 net.inet.tcp.always_keepalive=1
Reinicie seu computador e, em seguida, execute os seguintes comandos para verificar se os valores estão definidos.
sysctl net.inet.tcp.keepidle sysctl net.inet.tcp.keepintvl sysctl net.inet.tcp.keepinit sysctl net.inet.tcp.always_keepalive
Alteração das configurações de tempo limite do DSN
Você pode definir o comportamento de manutenção de atividade no nível do DSN, se desejar. Para isso, adicione ou modifique os seguintes parâmetros no arquivo odbc.ini:
- KeepAlivesCount
-
O número de pacotes de keepalive de TCP que podem ser perdidos antes que a conexão seja considerada interrompida.
- KeepAlivesIdle
-
O número de segundos de inatividade antes que o driver envie um pacote de manutenções de atividade de TCP.
- KeepAlivesInterval
-
O número de segundos entre cada retransmissão de keepalive de TCP.
Se esses parâmetros não existem, ou se estão com o valor 0, o sistema usa os parâmetros de manutenção de atividade especificados para TCP/IP a fim de determinar o comportamento de manutenção de atividade do DSN. No Windows, os parâmetros de TCP/IP podem ser encontrados no registro em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
. No Linux e no macOS, os parâmetros de TCP/IP podem ser encontrados no arquivo sysctl.conf.
A conexão é recusada ou falha
Quando sua conexão for recusada ou falhar, você poderá receber um erro semelhante a um dos seguintes:
-
"Falha ao estabelecer uma conexão com
<endpoint>
." -
“Não foi possível conectar-se ao servidor: a conexão expirou por exceder o tempo limite. O servidor está sendo executado no host
'<endpoint>'
e aceitando as conexões TCP/IP na porta'<port>'
?" -
"A conexão foi recusada. Certifique-se de que o nome do host e da porta estão corretos e o postmaster está aceitando conexões de TCP/IP.”
Soluções possíveis:
Geralmente, quando você recebe uma mensagem de erro indicando que não foi possível estabelecer uma conexão, o problema é relacionado à permissão de acesso ao cluster ou ao tráfego de rede que está chegando ao cluster.
Para se conectar ao cluster de uma ferramenta de cliente fora da rede em que o cluster está, adicione uma regra de entrada ao grupo de segurança do cluster. A configuração da regra depende da criação do cluster do Amazon Redshift em uma nuvem privada virtual (VPC):
-
Se você criou o cluster do Amazon Redshift em uma nuvem privada virtual (VPC) com base no Amazon VPC, adicione uma regra de entrada ao grupo de segurança da VPC no endereço CIDR/IP no Amazon VPC. Para obter mais informações sobre a configuração de grupos de segurança da VPC para o cluster e opções acessíveis ao público geral, consulte Recursos do Redshift em uma VPC.
-
Se você criou seu cluster do Amazon Redshift fora de um VPC, adicione o endereço CIDR/endereço IP ao grupo de segurança do cluster no Amazon Redshift. Para obter mais informações sobre a configuração de grupos de segurança de clusters, consulte Grupos de segurança do Amazon Redshift.
Se você tentar se conectar ao cluster de uma ferramenta cliente que executa uma instância do Amazon EC2, deverá também adicionar uma regra de entrada. Nesse caso, adicione uma regra ao grupo de segurança do cluster. A regra deve especificar o grupo de segurança do Amazon EC2 associado à instância do Amazon EC2 da ferramenta cliente.
Em alguns casos, pode haver uma camada entre o cliente e o servidor, como um firewall. Nesses casos, verifique se o firewall aceita conexões de entrada pela porta que foi configurada para o cluster.
O cliente e o driver são incompatíveis
Se o cliente e o driver forem incompatíveis, você poderá receber o seguinte erro: “O DSN especificado contém uma incompatibilidade de arquitetura entre o driver e a aplicação”.
Soluções possíveis:
Quando você recebe uma mensagem de erro de incompatibilidade de arquiteturas ao tentar estabelecer uma conexão, isso significa que a ferramenta do cliente e o driver são incompatíveis. Isso ocorre porque as arquiteturas de sistema não correspondem. Por exemplo, isso pode ocorrer se você tiver uma ferramenta do cliente de 32 bits mas instalou uma versão do driver para 64 bits. Em algumas ocasiões, as ferramentas do cliente de 64 bits podem usar drivers de 32 bits, mas não é possível usar aplicativos de 32 bits com drivers de 64 bits. Certifique-se de que o driver e a ferramenta do cliente estão usando a mesma versão de arquitetura de sistema.
As consultas parecem travar e, às vezes, não se comunicam com o cluster
Você está tendo um problema com a conclusão das consultas, onde as consultas parecem estar em execução mas travam na ferramenta do cliente SQL. Às vezes, as consultas não aparecem no cluster, como nas tabelas do sistema ou no console do Amazon Redshift.
Soluções possíveis:
Esse problema pode ocorrer devido à perda de pacotes. Nesse caso, há uma diferença no tamanho da unidade de transmissão máxima (MTU) no caminho da rede entre dois hosts de IP (Internet Protocol). O tamanho de MTU determina o tamanho máximo, em bytes, de um pacote que pode ser transferido em um quadro Ethernet através de uma conexão de rede. Na AWS, alguns tipos de instância do Amazon EC2 oferecem suporte a um MTU de 1500 (frames Ethernet v2) e outros tipos de instância oferecem suporte a um MTU de 9001 (frames jumbo TCP/IP).
Para evitar problemas que podem ocorrer com as diferenças de tamanho de MTU, recomendamos a execução de uma das ações a seguir:
-
Se o seu cluster usa a plataforma EC2-VPC, configure o grupo de segurança Amazon VPC com uma regra de entrada personalizada de protocolo de mensagem de controle da Internet (ICMP) que retorna
Destination Unreachable
. Assim, a mensagem instrui o host de origem a usar o menor tamanho de MTU no caminho de rede. Para obter mais detalhes sobre essa abordagem, consulte Configuração de grupos de segurança para permitir o "destino inacessível" do ICMP. -
Se o cluster usa a plataforma EC2-Classic, ou se você não pode permitir a regra de entrada do ICMP, desabilite os quadros jumbo de TCP/IP para que os quadros de Ethernet v2 sejam usados. Para obter mais detalhes sobre essa abordagem, consulte Configuração da MTU de uma instância.
Configuração de grupos de segurança para permitir o "destino inacessível" do ICMP
Quando há alguma diferença no tamanho de MTU da rede entre dois hosts, em primeiro lugar certifique-se de que suas configurações de rede não estão obstruindo a descoberta de MTU do caminho (PMTUD). A PMTUD permite que o host de recepção responda ao host de origem com a seguinte mensagem de ICMP: Destination Unreachable: fragmentation
needed and DF set (ICMP Type 3, Code 4)
. Essa mensagem instrui o host de origem a usar o menor tamanho de MTU no caminho de rede para enviar novamente a solicitação. Sem essa negociação, a perda de pacotes pode ocorrer porque a solicitação é muito grande para o host aceitar. Para obter mais informações sobre a mensagem do ICMP, acesse RFC792
Se você não configurar explicitamente esta regra de entrada ICMP para seu grupo de segurança do Amazon VPC, PMTUD será bloqueado. Na AWS, grupos de segurança são firewalls virtuais que especificam regras para o tráfego de entrada e saída de uma instância. Para obter informações sobre o grupo de segurança de cluster do Amazon Redshift, consulte Grupos de segurança do Amazon Redshift. Para clusters que usam a plataforma EC2-VPC, o Amazon Redshift usa grupos de segurança da VPC para permitir ou negar o tráfego para o cluster. Por padrão, os grupos de segurança são bloqueados e negam todo o tráfego de entrada. Consulte informações sobre como definir regras de entrada e saída para instâncias EC2-Classic ou EC2-VPC em Differences between instances in EC2-Classic and a VPC no Guia do usuário do Amazon EC2.
Para obter mais informações sobre como adicionar regras aos grupos de segurança da VPC, consulte Grupos de segurança da VPC. Consulte mais informações sobre as configurações específicas de PMTUD exigidas nessa regra em Path MTU Discovery no Guia do usuário do Amazon EC2.
Configuração da MTU de uma instância
Em alguns casos, o cluster pode usar a plataforma EC2-Classic ou você não pode permitir a regra ICMP personalizada para tráfego de entrada. Nesses casos, é recomendado que você ajuste o MTU para 1500 na interface de rede (NIC) das instâncias do EC2 a partir das quais você se conecta ao cluster do Amazon Redshift. Esse ajuste desabilita os quadros enormes de TCP/IP para garantir que as conexões usem consistentemente o mesmo tamanho de pacote. No entanto, essa opção reduz totalmente o throughput máximo da rede para a instância, não apenas para conexões com o Amazon Redshift. Para obter mais informações, consulte os procedimentos a seguir.
Para definir a MTU em um sistema operacional Microsoft Windows
Se o cliente é executado em um sistema operacional Microsoft Windows, você pode revisar e definir o valor da MTU para o adaptador de Ethernet usando o comando netsh
.
-
Execute o comando a seguir para determinar o valor atual da MTU:
netsh interface ipv4 show subinterfaces
-
Revise o valor
MTU
para o adaptadorEthernet
na saída. -
Se o valor não for
1500
, execute o seguinte comando para defini-lo:netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent
Após configurar esse valor, reinicie seu computador para que as alterações sejam implementadas.
Para definir a MTU em um sistema operacional Linux
Se o cliente é executado em um sistema operacional Linux, você pode revisar e definir o valor da MTU usando o comando ip
.
-
Execute o comando a seguir para determinar o valor atual da MTU:
$ ip link show eth0
-
Revise o valor da
mtu
na saída. -
Se o valor não for
1500
, execute o seguinte comando para defini-lo:$ sudo ip link set dev eth0 mtu 1500
Para definir a MTU em um sistema operacional Mac
-
Siga as instruções no site de suporte do macOS sobre
How to change the MTU for troubleshooting purposes
. Para obter mais informações, pesquise o site de suporte.
Como configurar o parâmetro JDBC para o tamanho da busca
Por padrão, o driver JDBC coleta todos os resultados de uma consulta ao mesmo tempo. Como resultado, quando você tenta recuperar um grande conjunto de resultados por meio de uma conexão JDBC, pode encontrar um erro de falta de memória por parte do cliente. Para habilitar seu cliente para recuperar conjuntos de resultados em lotes em vez de em uma única busca tudo ou nada, configure o parâmetro JDBC para o tamanho de busca em seu aplicativo cliente.
nota
O tamanho de busca não é compatível com ODBC.
Para obter uma melhor performance, defina o tamanho de busca como o maior valor que não resulte em erros de falta de memória. Um valor menor de tamanho de busca resulta em mais viagens do servidor, o que prolonga os tempos de execução. O servidor reserva recursos, incluindo a vaga de consulta WLM e memória associada, até que o cliente recupere todo o conjunto de resultados ou até que a consulta seja cancelada. Quando você ajusta o tamanho de busca adequadamente, esses recursos são liberados mais rapidamente, disponibilizando-os para outras consultas.
nota
Se você precisar extrair grandes conjuntos de dados, recomendamos o uso de uma instrução UNLOAD para transferir os dados ao Amazon S3. Quando você usa UNLOAD, os nós de computação funcionam em paralelo para acelerar a transferência de dados.
Para obter mais informações sobre a configuração do parâmetro JDBC para o tamanho de busca, acesse Obtenção de resultados com base em um cursor