DBeaver : 원격연결, 로컬연결 setting시 연결 오류 해결법

<원격DB 연결>

AWS Postgresql RDS에 연결한다고 가정하면

server host에 aws 리소스 이름(ARN)

db 이름

db에 설정한 password를 입력.

connection test가 성공적이면 정상연결 된 것.


<원격DB 연결 실패>

연결 실패시,

인코딩 문제가 있는 에러 메세지가 뜨는 경우가 있는데

대부분 에러 메세지 내용은

db를 public으로 설정해놓지 않았거나,

remote db로 들어오는 인바운드 규칙에서 필터링 되어 생기는 연결 실패 문제.


remote db setting에서 vpn 설정, access 설정을 손 봐야한다.



<로컬DB 연결>

remote db가 아니라 local에 db를 생성하여 연결하는 것을 의미한다.

project의 connection에서 각 SQL에 맞는 Port를 알아서 지정해준다. (postgre : 5432)

local host이므로
DBeaver 설치시 입력했던 admin용 password를 입력해야 정상적으로 연결된다. 


<로컬DB 연결실패>

(pgjdbc: autodetected server-encoding to be ISO-8859-1, if the message is not readable, please check database logs and/or host, port, dbname, user, password, pg_hba.conf)


1. pg_hba.conf 파일 수정 

에러가 뜬다면 pg_hba.conf 파일을 열람해본다.

보통 경로는 C:\Program Files\PostgreSQL\12\data이다.


hba = host-based authentication,

conf = configuration의 약자이다.


클라이언트 인증에 쓰이는 파일의 이름은 pg_hba.conf이며

데이터베이스 클러스터의 데이터 디렉토리에 저장되는 환경 설정 파일로 제어된다.

pg_hba.conf 파일은 디렉토리가 initdb에 의해 초기화 될 때 설치된다.


pg_hba.conf는

PostgreSQL에 접속하는 클라이언트에 대한 인증 설정을 설명하는 파일이다.

텍스트 에디터로 해당 설정 중 접근가능 네트워크 설정이 제대로 돼있는지 확인한다.

(.conf 파일의 최하단에 위치함)



- 연결에 사용되는 연결 유형

- 클라이언트 IP 주소 범위(연결 유형에 해당하는 경우)

- 데이터베이스 이름

- 사용자 이름

- 인증 방법

- 연결 타입

- 클라이언트 주소

- 데이터베이스 이름

- 사용자 이름

이 일치하는 첫 번째 레코드는 인증을 수행할 때 사용된다.




- 레코드 하나가 선택되고 인증이 실패한 경우 후속 레코드는 고려되지 않는다.
  (순서를 따져서 인증이 진행된다.)

- 일치하는 레코드가 없으면 액세스가 거부된다.



2. pgAdmin 프로그램에서 로그인 권한 부여

간혹, 로컬 연결이라해도 엉뚱한 계정에 로그인 권한 및 DBA권한이 부여됐을 수도 있다.

Login/Group Roles에 어떤 계정이 있는지 살펴보고

해당 계정의 SQL문을 열람하여 권한이 제대로 부여돼있는지 확인해야한다.

권한이 없는 사용자로 Local DB 연결시에도 위와 같은 연결 오류가 발생한다.


3.서버 그룹에 첫 서버 개설 시 주의사항

'postgres' role이 기본적으로 들어간다.

첫 사용자로 'postgres'이외의 사용자를 설정하는 것이 아니라

'postgres' role 설정 이후에 다른 role들을 설정하는 것.




Dbeaver로 DB작업을 수행하고자 할 때는

Dbeaver


postgresql 드라이버


EDB에서 배포하는 postgresql 패키지(postgresql server, pgadmin 등)


이 필요하다.


대부분 패키지에 딸려서 나오니까

postgresql패키지랑 - dbeaver만 설치해주면 된다. 



댓글

댓글 쓰기

이 블로그의 인기 게시물

실무진 면접 경험으로 정리하는 백엔드 (1) : 에듀 테크 기업 면접

에듀 테크 기술 면접 시간 내어 이력서를 꼼꼼하게 봐주시고 서류상으로는 회사에서 원하는 background라고 생각해주셔서 느낌이 좋았다. 최근 본 면접들 중 가장 깊이있는 질문을 해주셨고 오답과 대안에 대한 설명도 해주셔서 배워갈 수 있었다. 아쉽게도 합격하지 못했지만 좋은 면접 경험이었기 때문에 다음 면접에서 더 견고한 답변을 위해 정리해보았다. 질문&답변&더 나은 답변 일반 질문 이직 사유? 경영상의 이유로 인한 권고사직, 프로덕트 개발과 프로덕트 피벗 과정의 공백기 회사의 이 직군에 지원하면서 뭘 기대하는지? 거의 혼자서 개발을 해왔는데 다른 관점의 의견을 들을 기회가 없었다. 여러 개발자의 의견을 듣고 내 의견에 태클을 걸며 같이 발전하면 좋겠다. 공백기에 뭐하고 있는지 ?  1. django template과 admin, 그리고 오픈소스 wysiwyg를 사용하여 블로깅 서비스 사이드 프로젝트하면서 풀스택 공부중이다. 2. 현업에서 줄곧 이미 구축된 ci/cd를 사용해오고있었는데 직접 구현을 학습하기 위해 github action workflow를 공부하고 있음.  기술&개발 관련 관리형 서비스를 쓰지 않고 aws ec2를 쓴 이유 ? - 비용문제 vpc 어떻게 설정했나? - production region은 모든 ip에 대해서 열고   development region은 사무실 개발 pc와 사무실 기기들의 ip만 접근가능하도록 함 nginx ssl 적용했다고 하는데, 인증서 뭐 사용했나? - 'let's encrypt'사용했는데 생각이 안나서 대답못함. socketio에는 wsgi or asgi? - wsgi vs asgi 차이점에 대해서 답변함. django vs fast api ? - 동기, 비동기 서버 기반과 기타 feature에 대해서 답변함. - django에서 기본 제공되는 템플릿, admin,ORM과 미들웨어들 - fastapi는 기타 기능들을 따로 붙여서 써야한다고 답변, django도 ...
Read more »

노마드코더 개발자북클럽 Clean code TIL 6 : 6장. 객체와 자료구조

      오늘 TIL 3줄 요약 구현을 감추려면 추상화가 필요하다. 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉽다. 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다. 모듈은 자신이 조작하는 객체의 속사정을 몰라야한다. -> 특히 기차 충돌 코드를 피하라. TIL (Today I Learned) 날짜 2025. 06.01 오늘 읽은 범위 5장. 형식 맞추기 기억하고 싶은 내용을 써보세요. 도형 클래스는 간단한 자료구조로, 도형 동작 방식은 Geometry 클래스에서 구현한다. 객체라면 내부 구조를 감춰야 한다. 정확히는, 1. 동작을 공개하고  2. 자료를 숨겨라. 함수나 타입을 보호할지 공개할지에 대한 확신이 부족할 때 잡종 구조가 생긴다.  DTO = 자료 전달 객체 db, 통신을 위한 소켓에서 받은 메시지의 구문을 분석하여 db의 raw data를 애플리케이션의 객체로 변환할 때 유용. 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 새로운 동작을 추가하는 유연성이 필요하다면, 자료구조와 절차적인 코드가 더 적합하다. 활성 레코드는 자료로 취급하며 비즈니스 규칙를 담고 내부자료(높은 확률로 활성 레코드 인스턴스)를 숨기는 객체는 따로 생성한다. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 잡종 구조 !! 내가 최근에 구현한 클래스 인 것 같다. 다시 리팩토링 할 까? 한 때는 이론적인 책이구나라고 생각했는데, 이 챕터를 읽고 생각이 바뀌었다. 아주 좋은 실례를 다루고 있어서 고개를 끄덕이면서 읽게 되었다. 특히, 활성 레코드의 취급에 대한 부분이 명쾌했다. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.   #노개북   #노마드코더   #개발자북클럽  
Read more »

백엔드 개발자가 Djnago fullstack 사이드 프로젝트를하며 ( html, css, vanillaJS 그리고 JS프레임워크 )

서론 웹 개발 환경에서 FE 개발자와 BE 개발자는 상대의 업무를 서로 이해하게된다면  좀 더 총괄적인 서비스의 흐름과 병목지점을 파악할 수 있다. 때문에 이 둘의 협업 과정은 자연스럽게 Full-stack을 지향하고 있는 과정이라고 생각한다. 24년 12월부터 Django fullstack 사이드 프로젝트를 시작했다. 본론 시행착오 python django 코드 뿐 아니라 html + css + js도 함께 커버하기에 작업에 상당한 context switch가 있었다. 머릿속에 그린 것을 도식화나 문서화하지 않고 무작정 뛰어들었기 때문에  디자인 중인 화면을 확인할 곳이 없었다는 흠이 있었다. 특히 wireframe, 화면설계서가 없으니까  백엔드 작업시 하나의 기능을 완성하기 전까지 제대로 빌드가 되지 않기 때문에  dribble이라는 디자인 사이트를 많이 참고했다. 중복 작업과 반복 작업 중복, 반복 작업 django template language에서 상속을 지원하기 때문에 베이스 템플릿을 상속받아서 페이지를 제작할 수 있다. 템플릿에서 내부에서 여러번 쓰이는 컴포넌트가 불편하다면 공통 컴포넌트를 만들어주면된다. 그러나 컴포넌트를 FE 프레임워크 레벨 정도로 관리하기는 쉽지 않다. 공통 컴포넌트를 관리하려면 프레임워크의 틀을 따라가야하는데 이 시점이 프론트엔드 프레임워크 선정을 할 타이밍이라고 생각한다. JS로 모든 것을 control한다는 것의 간결함 FE UI 프레임워크에서는 html로 작성한 class, id 명을 js에서 검색하여 따르기보다 js로 직접 동적으로 문서 객체를 생성한다. 참조하기도 간편하고 관리하기도 쉽다. js는 bom(부분적으로)과 dom을 컨트롤 할 수 있다. 결론 결국 아주 간결한 landing page 외에는 JS 기반 프레임워크를 사용해야한다. 나는 왜 바로 FE 프레임워크로 뛰어들지 않았나? 더 깊고 가파른 학습을 위해 컴퓨터공학이나 소프트웨어학과의 교육 커리큘럼도 그렇고 프레임워크 이...
Read more »