Yderligere oplysninger til personer, der kan løbe ind i lignende problemer, når de prøver at oprette forbindelse til RDS eller RedShift:
1) Tjek sikkerhedsgrupper
Bekræft sikkerhedsgruppen for RDS-instansen tillader adgang fra den sikkerhedsgruppe, din kildeserver tilhører (eller dens IP tilføjet direkte, hvis den er ekstern til AWS). Den sikkerhedsgruppe, du bør se på, er den, der er angivet i RDS-forekomstattributterne fra RDS-konsollens brugergrænseflade (kaldet "sikkerhedsgruppe").
BEMÆRK :Databasesikkerhedsgrupper kan være forskellige fra AWS EC2-sikkerhedsgrupper. Hvis din RDS-instans er i klassisk/offentlig EC2, bør du tjekke i afsnittet "databasesikkerhedsgruppe" i RDS-brugergrænsefladen. For VPC-brugere vil sikkerhedsgruppen være en normal VPC-sikkerhedsgruppe (navnet sg-xxx vil blive angivet i RDS-instansens attributter).
2) Bekræft, at DNS ikke er et problem.
Amazon bruger delt DNS, så et DNS-opslag eksternt til AWS vil returnere den offentlige IP, mens et opslag internt i AWS vil returnere en privat IP. Hvis du har mistanke om, at det er et DNS-problem, har du så bekræftet, at forskellige IP-adresser returneres fra forskellige tilgængelighedszoner? Hvis forskellige AZ'er får forskellige IP'er, skal du kontakte AWS support.
3) Bekræft netværksforbindelse ved at etablere en socket-forbindelse.
Værktøjer som tracepath og traceroute vil sandsynligvis ikke hjælpe, da RDS i øjeblikket falder ICMP-trafik.
Test portforbindelsen ved at prøve at etablere en socketforbindelse til RDS-instansen på port 3306 (mysql eller 5432 for postgres). Start med at finde IP-adressen for RDS-instansen og brug enten telnet eller nc (sørg for at bruge den interne/private IP, hvis du opretter forbindelse inde fra AWS):
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a) Hvis dit forbindelsesforsøg ikke lykkes og med det samme mislykkes, er porten sandsynligvis blokeret, eller fjernværten kører ikke en tjeneste på den port. Du skal muligvis bruge AWS-support for at fejlfinde yderligere. Hvis du opretter forbindelse uden for AWS, så prøv først at oprette forbindelse fra en anden instans inde i AWS (da din firewall muligvis blokerer disse forbindelser).
b) Hvis din forbindelse ikke lykkes, og du får en timeout, bliver pakker sandsynligvis droppet/ignoreret af en firewall, eller pakker vender tilbage på en anden netværkssti. Du kan bekræfte dette ved at køre netstat -an | grep SYN (fra en anden ssh-session, mens du venter på, at telnet/nc-kommandoen får timeout).
Forbindelser i SYN-tilstand betyder, at du har sendt en forbindelsesanmodning, men ikke har modtaget noget tilbage (SYN_ACK eller afvis/blokering). Normalt betyder det, at en firewall eller sikkerhedsgruppe ignorerer eller dropper pakker.
Det kan også være et problem med NAT-routing eller flere stier fra flere grænseflader. Kontroller, at du ikke bruger iptables eller en NAT-gateway mellem din vært og RDS-instansen. Hvis du er i en VPC, skal du også sørge for at tillade udgående/udgående trafik fra kildeværten.
c) Hvis din socket-forbindelsestest var vellykket, men du ikke kan oprette forbindelse til en mysql-klient (CLI, workbench, app osv.), skal du tage et kig på outputtet fra netstat for at se, hvilken tilstand forbindelsen er i (erstat x.x.x.x med faktiske IP-adresse for RDS-instansen):
netstat -an | grep x.x.x.x
Hvis du fik oprettet en forbindelse, når du brugte telnet eller NC, men du ser 'SYN'-tilstanden, når du bruger en mysql-klient, løber du muligvis ind i et MTU-problem.
RDS, på det tidspunkt, hvor dette er skrevet, understøtter muligvis ikke ICMP-pakker, der bruges til PMTUD (https:/ /en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ). Dette kan være et problem, hvis du forsøger at få adgang til RDS eller RedShift, der er i en VPC fra en klassisk ec2-instans via ClassicLink. Prøv at sænke MTU'en med følgende, og test derefter igen:
sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
sudo ip link set dev eth0 mtu 1400
Hvis den nederste MTU virkede, skal du sørge for at følge op med AWS kundesupport for at få hjælp og nævne, at du ser et MTU-problem, mens du forsøger at oprette forbindelse til din RDS-instans. Dette kan ske, hvis TCP-pakker er pakket ind med indkapsling til tunneling, hvilket resulterer i en lavere brugbar MTU for pakkedata/nyttelast. Sænkning af MTU'en på kildeserveren gør det muligt for de indpakkede pakker stadig at passe under MTU-grænsen, mens de passerer gennem tunneling-gatewayen.
Hvis det ikke virkede, skal du indstille din MTU tilbage til dets standard og aktivere AWS-support for yderligere fejlfinding.