Po opublikowaniu tego problemu, podczas pracy, zdałem sobie sprawę, że nie jestem nawet w stanie pingować do serwera EC2 lub telnet do niego. Więc coś podstawowego musiało być nie tak. W końcu przyjaciel pomógł mi rozwiązać problem. Jak się spodziewałem, problem był bardzo specyficzny dla EC2.
Szczegóły są następujące:
Kiedy tworzymy instancję EC2, otrzymujemy zewnętrzny adres IP podobny do:ec2-XX-XXX-XXX-XX.ap-southeast-1.compute.amazonaws.com
Podczas ustawiania uprawnień w mysql nadawałem uprawnienia do powyższego adresu IP, tj.:
GRANT ALL PRIVILEGES on . to [email protected]'ec2-XX-XXX-XXX-XX.ap-southeast1.compute.amazonaws.com' IDENTIFIED BY 'password';
To nie działa, gdy próbujesz komunikować się z instancją EC2 z innej lokalnej instancji EC2. W tym celu musisz podać „wewnętrzny adres ip” instancji EC2, który można znaleźć za pomocą polecenia ip:
ip a:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 12:31:41:02:58:47 brd ff:ff:ff:ff:ff:ff
inet **XX.XX.XX.XXX/23** brd YY.YYY.YY.YYY scope global eth0
inet6 fe80::1031:41ff:fe02:5847/64 scope link
valid_lft forever preferred_lft forever
Aby wszystko działało poprawnie, musisz przyznać uprawnienia do adresu IP -- „XX.XXX.XX.XXX/23” i powinno działać. Podobnie, podczas łączenia się z bazą danych „mysql”, nazwa hosta podana w poleceniu mysql powinna być również „wewnętrznym adresem ip” hosta instancji EC2.
