[트러블슈팅] Communications link failure, Spring Boot 배포 시 DB 연결 URL이 바뀌지 않는 문제 해결

 

 

7월에 EC2로 배포했었던 나의 소중한 프로젝트...

청구서를 보고 눈물을 머금으며 관련 인스턴스를 싹 지웠었다

근데 이제 다시 실사용자를 받아볼 때가 되어서 이제서야 또 배포를 하게 되었다.

 

그래서 차근차근 하고 있었다. 

rds로 mysql 다시 배포하고, 그 이후에 ec2로 스프링부트 배포하고

별 문제 없이 마지막 단계까지 왔는데 스프링부트 jar 파일 실행할 때마다 이런 오류가 발생했다.

 

2025-10-27T17:55:43.036Z ERROR 2319 --- [           main] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Exception during pool initialization.

com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure

The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
        at com.mysql.cj.jdbc.exceptions.SQLError.createCommunicationsException(SQLError.java:175) ~[mysql-connector-j-8.1.0.jar!/:8.1.0]
        at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:64) ~[mysql-connector-j-8.1.0.jar!/:8.1.0]
        at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:819) ~[mysql-connector-j-8.1.0.jar!/:8.1.0]
        at com.mysql.cj.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:440) ~[mysql-connector-j-8.1.0.jar!/:8.1.0]
        at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:239) ~[mysql-connector-j-8.1.0.jar!/:8.1.0]
        at com.mysql.cj.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:188) ~[mysql-connector-j-8.1.0.jar!/:8.1.0]

 

 

이렇게 기다란 오류가 생성되고 결국에는 서버가 실행이 되긴 했다.

근데 그래도 데이터베이스 연결이 안 되면 무소용이기에... 이걸 해결해야만 했는데

환경변수 지정을 안 해줬나 해서 nano로 bash파일에 넣어두기도 하고 했는데 여전히 안 됐다. 

 

그래서!! 보안그룹이 문제인가 하고 똑같은 걸 몇 번을 수정했다.

 

그래서 우분투 서버 내에 mysql client를 깔아서 여기서 주소로 잘 접속이 되는지 봤다. (잘 된다면 보안그룹에는 문제가 없는 것일테니까) 

sudo apt install mysql-client 로 mysql을 깔고

 

mysql -h 엔드포인트주소 -u 사용자이름 -p 하고 패스워드 입력했더니

연결이 잘 되더래요

그럼 보안그룹 문제도 아닌 거잖아요...

 

 

근데 오류 로그에서 발견한 문제점이 있었다

오류 로그에 뜬 데이터베이스 url (엔드포인트) 와 지금 내 데이터베이스 엔드포인트가 달랐다

 

Caused by: java.net.UnknownHostException: ecostep-db.cruikuqa2yrq.ap-northeast-2.rds.amazonaws.com: Name or service not known

스프링부트 로그에 뜬 오류 중에서 이곳...

현재 데이터베이스는 database-1027로 시작하는데 
얘는 ecostep-db로 시작한다

 

이걸 어디서 많이 봤나 했더니 내가 7월에 배포했었던 rds 엔드포인트 이름이었다. . . 

결국... 스프링부트 jar 파일이 수정 전의 jar 파일로 들어가고 있던 것이었음을 발견했다

 

 

문제를 확실히 하기 위해서 

 jar xf ecoStep-1.0-SNAPSHOT.jar BOOT-INF/classes/application.yml
cat BOOT-INF/classes/application.yml

라는 명령어를 사용했다. (지피티의 도움을 받음) 

 

이 명령어들이 뭐냐면..

 

1) jar xf ecoStep-1.0-SNAPSHOT.jar BOOT-INF/classes/application.yml

JAR 파일(일종의 zip 파일) 안에서 BOOT-INF/classes/application.yml 이 파일만 꺼낸다 (xf 의미: x = extract f = file)

 

2) cat BOOT-INF/classes/application.yml

방금 꺼내온 파일의 내용을 터미널에 출력해서 확인한다 (cat = 파일 내용 보기)

 

 

명령어를 사용해보니 진짜 이 jar 파일 내의 application.yml은 예전 url을 담고 있었다.

그렇다면 왜 아무리 파일을 다시 clean build하고 scp로 덮어씌워도 예전 파일이 실행됐던 걸까...

보통 gradlew clean build를 하면 이전의 파일 설정 내용을 없애고 다시 빌드를 해줘서 이렇게 겹치지 않는데 (지금이 세 번째 배포인데 두 번째 배포 때는 안 이랬다) 지금 Gradle에서 jar 관련 캐시가 꼬여 있는 것 같다 

 

 

그래서 프로젝트의 jar를 빌드할 때,

gradlew clean build 대신 gradlew bootJar을 써서 해결했다. 

 

 

둘의 차이점은... 

gradlew clean build: 프로젝트의 모든 기본 빌드 작업 수행

gradlew bootJar: 실행 가능한 JAR 파일 생성 작업만 수행

 

gradle 시스템이 application.yml 파일의 변경사항을 감지 못하고 있다가 

bootJar을 단독으로 명시해서 그제서야 다시 jar 파일을 빌드할 수 있었던 것 같다... 

 

 

그리고 다시 scp 하고 실행해보니 잘 됐다... ㅎㅎ