1. 문제 상황지난 포스팅에 이어 이번에도 운영 환경 모니터링 중 발생했던 에러와 해결과정을 다룰 예정이다. 이번엔 사용 중인 postgresSQL에 접근하는 쿼리 실행 중에 다음과 같은 에러가 간혈적으로 발생하였다. org.apache.ibatis.exceptions.exceptions.PersistenceException:Cause: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection;nested exception is org.apache.commons.dbcp.SQLNestedException:Cannot get a connection, pool error Timeout waiting for ..

1. 문제 상황최근 개발하던 시스템의 오픈을 앞두면서 운영 로그를 어느 때보다 신경 써서 모니터링하고 있다. 그전까진 나를 비롯한 팀원들 그리고 소수의 공사 인원들만 접근해서 별다른 특이사항이 없었지만, 근래에 각 지사 인원의 시스템 교육 기간이 시작되고 이용자가 늘어나자 개발 단계에서 발생하지 않았던 에러들이 하나 둘 발생하기 시작했다. 오늘은 그중 해결하면서 가장 애먹었던 에러를 해결하는 과정을 기록하고자 한다. 현재 우리 시스템은 한 대의 WAS 컨테이너에서 postgres 1대, oracle 2대의 데이터베이스 서버를 혼용하여 사용 중인데, WAS 컨테이너에서 오라클 DB에 접근하는 쿼리를 실행하던 중 간혈적으로 ORA-01555: snapshot too old 에러가 발생하는 것을 확인할 수 ..

0. SQL과 친해지기 위한 과정실무를 시작하고 여러가지를 배울 수 있었지만, 그 중 가장 많이 도움이 된 것은 sql을 다룰 수 있게 된 것이라고 생각한다. 한창 취업을 준비하던 당시에는 JPA나 QueryDSL에 익숙해진 나머지, 간단한 join이 들어간 쿼리 정도만 이해하고 작성할 수 있었는데, 프로젝트에 투입되고 보니 MyBatis를 비롯한 생 sql을 다룰 일이 많았었다. 특히, mybatis 쿼리의 경우 100줄은 가볍게 넘기는 복잡한 쿼리들이 많아 익숙해지기 위한 시간이 필요했고 이에 적응하게 되었다. 또한, 실행 계획을 통해 성능이 떨어지는 쿼리를 분석하고 개선하는 경험도 할 수 있었다. 지나치게 느린 쿼리를 분석해보면 인덱스를 제대로 타지 않거나 정렬 과정에서 디스크에 접근하는 경우들이 ..

1. 구체화된 뷰Materialized View(이하 mv로 표기)는 이름 그대로 구체화된 뷰를 뜻한다. view가 가상 테이블로서 조회 요청이 들어오면 기본 테이블에서 실시간으로 데이터를 계산하여 데이터를 반환한다면, mv는 쿼리의 결과를 물리적 테이블로 저장해놓고 조회 요청이 들어오면 즉시 결과를 반환한다. view와는 다르게 물리적으로 저장된 상태이기 때문에 인덱스를 설정할 수 있고, 이로 인해 성능적인 면에서 이득을 볼 수 있다. 하지만 실시간으로 변경되는 데이터가 필요하다면, 새 result set 구성을 위해 refresh를 해야만 한다. 2. 실무에서의 MV 활용처음 mv의 존재를 알게 된 것은 현재 회사에 입사하고 시스템을 익히기 시작한 무렵이었다. mv에 대해 실습을 하기에 앞서,..

HTTP(Hypertext Transfer Protocol)는 웹에서 데이터를 주고받는 서버-클라이언트 모델의 프로토콜이다. 여기서 데이터란 본래 HTML 문서와 같은 HyperText를 칭하였지만, 현재는 이미지, 오디오, 비디오 등 다양한 형태의 데이터를 전송할 수 있다. 오늘은 이 HTTP의 발전 과정을 살펴보고자 한다. 1. HTTP/0.9 (1991)문서화된 최초의 HTTP 버전은 0.9이다. 상태 코드, 헤더가 존재하지 않았으며, 지원되는 메소드 또한 GET뿐이었다. 그리고 HTTP의 이름에 걸맞게 HTML 파일만 전송 가능하였다. HTTP의 초기 버전답게 가장 단순한 형태를 갖고 있다. 2. HTTP/1.0 (1996)이어서 등장한 HTTP/1.0은 인터넷 인프라가 빠르게 변화하면서 더 다..

지난 포스팅에 이어 오늘은 리플리케이션 실습을 진행해보기로 한다.1. Replication with Docker간단한 실습을 위해 docker를 통해 replication을 구성해보기로 한다. docker-compose.yml다음과 같이 master 노드 1개와 slave 노드 2개로 구성한다.services: mysql-master: image: mysql:8.0 container_name: mysql-master restart: always environment: MYSQL_ROOT_PASSWORD: 1234 MYSQL_DATABASE: test MYSQL_USER: user MYSQL_PASSWORD: 1234 ports: ..

1. ReplicationDB 리플리케이션은 데이터베이스에서 데이터의 복제본을 생성하여 여러 위치에 저장하는 과정을 의미한다. 많은 DBMS에서 이러한 리플리케이션을 지원하며, 일반적으로 서버 사이에 master-slave 관계를 설정하고 데이터 원본은 master에, 사본은 slave에 저장하는 방식이다. 이때, 쓰기 연산은 마스터 서버에서만 지원하고, 슬레이브 서버는 읽기 연산만을 지원하게 된다. 쓰기 연산이란 데이터의 상태를 변경하는 Insert, Update, Delete를 칭하며 이들은 마스터 서버에게만 전달된다. 대부분의 애플리케이션은 쓰기 연산보다 읽기 연산의 비중이 훨씬 높으므로 일반적으로 슬레이브의 수를 더 많이 두게 된다. 장점리플리케이션의 장점은 다음과 같이 정리할 수 있다.1..

분산 환경에서 똑같은 ID로 데이터를 저장하면 무슨 일이 발생할까?데이터에 접근할 때마다 노드에서 다른 결과를 받거나 업데이트 시에 충돌이 일어나는 등 여러 곤란한 문제가 생길 것이다. 따라서 여러 데이터베이스를 사용하는 샤딩 환경에선 해당 데이터의 ID가 유일성을 가진다는 것을 보장해야 한다. 1. 샤딩스피어 중복 ID 테스트이전 포스팅에서 다뤘던 샤딩스피어에선 중복ID로 데이터를 저장하면 어떻게 처리될까?? 다음과 같이 ID 생성 전략을 쓰지 않고 임의의 ID 값으로 Order를 저장해보도록 하겠다.@Transactionalpublic Order createOrder() { Order order = new Order(); order.setOrderId(12405L); return order..