yun_dev

kafka로 cdc 구축을 위해 테스트하던 중, max.request.size를 넘었다는 오류가 발생하였다. 해당 오류는 Producer에서 보낼 수 있는 요청 당 최대 메시지 크기를 넘었다는 것이었다. 카프카 공식 문서에서 프로듀서 config에 해당 설정이 있으며 기본적으로 약 1MB로 되어있다. 해당 문제를 해결 위해서는, producer의 max.request.size를 늘려주고, 그에 따라서 kafka broker의 message.max.byte도 살펴보아야 한다. 카프카 공식 문서 max.request.size 정의 The maximum size of a request in bytes. This setting will limit the number of record batches the pro..

현재 진행하고 있는 사이드프로젝트에서 TypeORM QueryBuilder를 사용하여 작업 중에 getRawMany에서 skip, take가 작동하지 않는 상황을 마주했다.🤔 처음에는 쿼리의 문제인 줄 알고 쿼리빌더 결과로 나온 쿼리를 디버깅하다가 문제가 없는 것 같아서 검색하니..! raw data에서는 작동하지 않는다는 사실을 알게 되었다. 그래서 해당 경우에는 limit, offset을 사용해야 한다. 우선은 오류 수정을 위해 limit, offset을 사용했으나, 사실 해당 쿼리가 성능이 좋지 않음을 알고 있어서 페이지네이션 방식을 인덱스를 타도록 커서기반 방식으로 고치는 방향을 고려해야겠다.💪🏻 참고 자료 https://stackoverflow.com/questions/57819937/typeo..

Nosql로 mongoDB를 사용 중이고, mongoose라는 라이브러리를 사용 중인데 다음과 같은 에러를 서버에서 발견했다. (참고: node version - 14.18.0) 해당 오류가 나기 전 후를 살펴보았고, 다음과 같은 상황이라는 것을 알게 됐다. axios를 이용한 http 통신에서 status code 500대의 error난 상황이 발생했고, 이후로 해당 error object 전체를 DB에 저장하는 과정에서 발생하는 상황 error 객체 전체를 넣으려고 하는 부분에서 문제가 있는 것 같아서, error를 stringfy 한 결과를 저장하도록 변경하였다. 변경 후에 해당 오류가 더 이상 발생하지 않았다.🤔 검색을 해보니 나와 같은 상황을 겪은 분의 글도 보았고, axios의 문서도 살펴보았..

Real MySQL 8.0 전면 개정판을 읽으며 정리한 내용입니다. 쿼리 튜닝의 Base는 내가 실행한 쿼리가 어떻게 처리되는지 아는 것이다! ✔️ GROUP BY 처리 버퍼링 방식으로 쿼리를 처리해야 한다. GROUP BY에 대한 결과물을 필터링하기 위해서 HAVING 절을 사용한다. 이때 GROUP BY에 사용된 조건은 인덱스를 사용해서 처리될 수 없으므로, HAVING절 튜닝을 위한 인덱스 생성 등은 필요 X 인덱스 스캔을 이용한 GROUP BY(타이트 인덱스 스캔) 조인의 드라이빙 테이블에 속한 칼럼만을 이용해 그루핑 하는 경우에 GROUP BY 칼럼으로 이미 인덱스가 있는 경우 사용 가능한 방법 루스 인덱스 스캔을 이용한 GROUP BY 단일 테이블에 대해 수행되는 GROUP BY 처리에서만 사..

Real MySQL 8.0 전면 개정판을 읽으며 정리한 내용입니다. 쿼리 튜닝의 Base는 내가 실행한 쿼리가 어떻게 처리되는지 아는 것이다! mysql에서 쿼리는 크게 3단계의 과정으로 실행된다. sql 파싱 mysql 서버가 이해할 수 있는 수준으로 sql 문장을 분리, 이 과정에서 문법 오류 체크 최적화 및 실행 계획 수립 mysql 서버의 옵티마이저가 처리 (테이블을 읽을 순서, 사용할 인덱스 결정 등) 실행 계획을 바탕으로 스토리 엔진에서 데이터 확보 ⚙️ 옵티마이저 ✔️ 옵티마이저란? 쿼리를 최적으로 실행하기 위해서 데이터가 어떻게 분포되어있는지 통계정보를 참조하여, mysql에서는 EXPLAIN이라는 명령으로 쿼리의 실행계획을 확인할 수 있다. ✔️ 옵티마이저의 종류 비용 기반 최적화(Cos..

열심히 A라는 브랜치에서 작업 중이었는데, 오류가 발생하는 등에 이유로 다른 브랜치로 이동해야 하는 경우가 있다.🤭 특히 회사에서 일하면서는 이런 일을 빈번하게 겪었다. 코드리뷰에 대한 답변이 와서 수정이 필요할때, 긴급한 오류를 처리할 때 등등 그럴때마다 아직 미완서인 코드들을 불필요한 커밋을 올리고, checkout 했었다.. 그런 내 이야기를 듣고, 동료분이 stash를 쓰면 되지 않냐고 해서 찾아보고 이걸 왜 이제 알았을까 생각이 들었다..! 커밋하지 않고, 변경사항 저장하기! git stash 간단 정리 git stash : 변경 사항 저장 git stash list : stash한 내역 확인 git stash apply [stash id] : stash한 내역 불러오기(id 미지정시 가장 최근..

처음 개발블로그를 벨로그로 시작했었다. 취업을 하고, 오랫동안 들어가지 않으니 먼지가 폴폴.. 새로운 마음 + 티스토리로 옮기고 싶다는 생각으로 이사 결정! 늘 기록을 해야겠다, 하고 싶다라는 생각은 했었지만 개인 노션에만 정리하고 따로 올리진 못했다😅 2022년 목표로 티스토리에 꾸준히 기록하고 싶다. 화이팅💪🏻