분류 전체보기 (12) 썸네일형 리스트형 percona rds-exporter AWS API throttling issue 1. 배경 현재 재직 중인 회사에서는 오픈소스인 percona 사의 rds-exporter (https://github.com/percona/rds_exporter) 를 이용하여 RDS 의 enhanced monitoring 지표 (OS 지표) 를 수집하고 있다. 하지만 하나의 account + region 에 종속된 instance 가 많아질수록 API throttling 에러가 발생하며 지표 수집에 실패하는 빈도가 잦아졌다. 그래서 해당 이슈에 대한 원인 파악과 함께 대응 방안을 수립하기 시작했다. 2. 기존 방식의 문제점 1) API throttling 이 발생한 원인 rds-exporter 는 CloudWatch Logs 에 속한 Log stream 중 하나인 "RDSOSMetric" 을 Filt.. rds_exporter API Call 비용 이슈(+ Customizing) 1. 배경 Amazon RDS 를 사용하게 되면 mysqld_exporter 를 통해 mysql 에 대한 정보를 가져올 수는 있으나, OS 정보 수집을 위해서는 rds_exporter 를 통해서 가져와야한다. RDS 의 Monitoring Enhanced 를 enable 시켰을 경우 rds_exporter 에서는 대략 인스턴스 당 400~500개의 메트릭을 수집하게 된다. 아주 deep 하게 보면 필요한 지표들도 있겠지만, 대부분은 비용을 소모하면서까지 수집할 필요가 없는 지표들이다. 2. 문제점 1) 쓸모 없는 metric RDS Exporter 가 scrap 하는 지표들은 CloudWatch 에 쌓인 정보들을 scrap 하는 형태이고, amazon manual 을 살펴보면 scrap 할 경우 지표 당.. Grafana 지표 값이 뭉개지는 문제 (+ Customizing) 1. 배경 grafana 는 Source DB (ex. prometheus, influx, etc.. ) 들에 쌓인 데이터를 파싱하여 Visualizaion 해주는 tool 이다. 모니터링 시에 Time Range 에 따라 원하는 Range 의 지표 값들을 볼 수 있다. data 를 가져오는 것은 grafana 를 통해 각 Source DB 에 요청을 하지만, 가져온 data 지표들을 grafana page 에 visualization 을 해주는 것은 웹 브라우저가 하게 된다. 따라서 step 을 짧게 가져가서, time slot 이 너무 많게 되면 웹 브라우저 Client Side 에 과부하를 유발할 수 있다. 그래서 grafana 는 prometheus 등에 data 지표들을 요청할 때 Time Ra.. MySQL FlashBack (5.7 / 8.0) 1. MySQL Flashback 기본적으로 MySQL Community Version 에서는 FlashBack 을 지원하지 않는다. 해당 기능은 MariaDB 10.2.4 이상의 "mysqlbinlog" 바이너리 파일에 탑재된 기능이다. 이는 Binary Log 를 이용하여 FlashBack 을 구현하기때문에, MySQL Community Version 에서도 정상 작동한다. 차후 출시된 MariaDB 의 신규 버전에서는 DDL (DROP, TRUNCATE, ALTER 등) 에 대한 FlashBack 이 지원될 예정이나 현재 버전에서는 지원하지않는다. 또한 이는 MariaDB 에서만 사용될 것이라고 생각된다. MariaDB 10.2.4 Version 이상에서는 Server Parameter 로 "--f.. MySQL Partition Key length 이슈 (in MySQL 5.7) 1. 배경 MySQL 버전 업그레이드를 진행하다가 특정 테이블 생성이 불가능해서 살펴봤었다. 월별 파티션 같은 테이블에서는 파티션 키를 date 관련 타입이 아닌, char 관련 타입으로 가져가는 경우가 있다. 이 때, MySQL 5.7 이전 (MySQL 5.6 이하) 버전에서는 파티션 키의 크기가 파티션 range 의 범위 크기 (ex. '201801' 의 경우 크기는 6) 보다 작아도 파티션 테이블이 만들어 졌다. 그러나 MySQL 5.7 부터는 "ERROR 1654 (HY000): Partition column values of incorrect type" 에러가 발생한다. 2. 테스트 1) MySQL 5.6 > CREATE TABLE `t1` ( `reg_month` varchar(6), `con.. About Me 안녕하세요. 이 글을 보러오시는 분이 계실지는 모르겠지만, 보신다는건 궁금해하신다는 것이라고 생각하니 그래도 소개를 해야겠습니다.(ㅎㅎ) uzi 는 카카오에 다닐 때 사용하던 닉네임입니다. * Kakao (2017.08. ~ 2019. 12.) - MySQL / MongoDB Engineer * Yanolja (2019. 11. ~ 2020. 11.) - MySQL (Aurora) Engineer * Amazon Web Services (2020. 11. ~ 2021. 04.) - Cloud DBs Support Engineer * Yanolja (2021. 04. ~ ) - MySQL (Aurora) Engineer 주로 Trouble Shooting 이나 성능에 관한 분석을 좋아합니다. DB 만 보는.. MongoDB Plan Cache 1. MongoDB Plan Cache 사용 이유 MongoDB 에서 Execution Plan 은 101건의 document 를 반환하는 Plan 을 사용한다. 이 행위를 쿼리가 요청될 때마다, 매번 하는 것은 사실 비효율적인 행위이다. 그래서 MongoDB 에서는 Plan Cache 라는 개념을 사용한다. 이는 MySQL 의 Query Cache 랑은 다른 개념이다. MongoDB 의 Plan Cache 는 Query Shape (쿼리 패턴이라고 이해해도 좋다.) 별 어떤 Execution Plan 을 사용할지 Caching 해두는 공간이다. Plan Cache 가 처음부터 Plan 을 Caching 을 해두는 것은 아니고, 실제 쿼리가 실행 되었을 때 만들어진 Execution Plan 을 캐싱한다.. MongoDB Query Execution Plan 1. MongoDB 에서의 Query Execution Plan MongoDB 의 Optimizer 는 기본적으로 Rule Based 로 동작한다. 하지만 Rule Based 와 Cost Based 의 각 장단점은 명확하기때문에, MongoDB 에서는 Rule Based 를 기본으로 사용하면서 단점을 보완하기위해 추가적인 방법을 이용한다. Execution Plan 을 세울 때, 먼저 Rule Based 로 Execution Plan 을 세우고 실제 해당 Plan 을 실행한다. 그리고 모든 Execution Plan 들 중에 "101건" 의 Document 를 가장 빨리 반환하는 Plan 을 최종적으로 Execution Plan 으로 잡는다. 이 단계에서 선택된 Plan 은 "Winning Plan" ,.. 이전 1 2 다음
