ssuperjun 님의 블로그

[고도화 아이디어]장애 발생 직후 스크립트 1차 실행(원인 분석 및 휘발성 상태 정보 보존 목적) -> 2차 실행(정상화 이후) [기존 문제점]기존의 journalctl 및 db 로그 수집 방식은 장애 발생 당시의 db 상태 정보를 수집하지 못함이로 인해 기존 스크립트는 디스크 full, cpu 병목, too many connections, 복제 지연 등의 상황을 커버하지 못함 [목적]이 아이디어를 적용하면, 디스크 full, cpu 병목, too many connections, 복제 지연 등의 런타임 통계 정보를 수집해 더 많은 장애 상황에 대한 타임라인을 작성할 수 있음2차 실행 시, 1차 실행 때 수집했던 db 상태 정보를 활용해 더 고도화된(풍성한 정보의) 타임라인을 산출할 수 있음실용적인가?=>..

마스터에서 레플리카(슬레이브)의 ip주소나 hostname을 알아낼 수 있는지 재확인기존에는 레플리카의 UUID 38자리밖에 알아내지 못했음 ca801에서/home1/irteam/mysql/base/bin/mysql \ -S /home1/irteam/mysql/run/mysql.sock \ -u root -p'nhn!@#하나둘셋' \ -e "SHOW SLAVE HOSTS;" 혹은 -e "SHOW REPLICA HOSTS;"=> UUID밖에 알아내지 못함 재시도/home1/irteam/mysql/base/bin/mysql \ -S /home1/irteam/mysql/run/mysql.sock \ -u root -p'nhn!@#하나둘셋' \ -e "SELECT HOST FROM inform..

클러스터드 인덱스와 논클러스터드 인덱스를 비교하는 테스트 쿼리 수행기존 테스트: https://ssuperjun.tistory.com/59피드백: 가설 설정과 테스트 방향성은 좋지만, 논클러스터드 인덱스 테이블을 설계할 때 pk를 id로 설정하는 바람에 결과가 모두 유효하지 않게 됨 재실험 진행결론: MySQL InnoDB 엔진에선 완전한 의미의 논클러스터드 인덱스 구현은 불가능=> 논클러스터드 인덱스는 실제 row를 찾을 때 이중 탐색 구조(1. secondary index 탐색 -> 2. PK 얻음 -> 3. PK로 clustered index 재탐색) 때문 따라서 클러스터드 인덱스 vs 논클러스터드 인덱스 성능을 비교하는 대신id를 pk로 하는 클러스터드 인덱스 vs uuid(랜덤값)를 pk로 하고..

문제레플리카의 디스크 Full 장애(MySQL 9번 장애)를 일으킨 뒤 8분 후에 복구를 시도하면, '레플리카의 디스크 Full'에 대한 타임라인이 정리되지 않고, 복구 이후의 '복제 연결 단절' 타임라인만 정리됨 예시+T0 [Replica_Disk_Full] - fault1+T600 [RELAY_DISK_FULL] - 10분마다 반복-> 대략 30분 후 복구 진행+T2400 [CONN_LOST] - fault2: I/O 스레드 연결 끊김+T2400 [REPL_START]- I/O 스레드 재연결- 이후 12분 간 장애(fault) 없음=> 장애 묶음의 시작점을 fault1(+T0)로 봐야 하지만, fault2(+T2400)로 보는 문제 발생현재 로직은 120초(gap) 기준으로 conn_lost를 새 묶..

1장: 마이크로서비스 아키텍처와 레디스 모놀리틱 아키텍처 vs 마이크로서비스 아키텍처모놀리틱 아키텍처에서는 모든 데이터를 하나의 DB에서 관리하고자 해 중앙 집약저인 RDBMS를 표준으로 삼음MSA에서는 각 서비스가 독립적으로 동작비즈니스 특성과 데이터의 형태를 고려해 RDBMS or NoSQL 중 하나를 선택하는 것이 중요NoSQL의 특징: 실시간 응답, 확장성(scale-out), 고가용성(복제, 샤딩 등), 클라우드 네이티브(클라우드 제공 업체의 DBaaS 이용 가능), 단순성(데이터 저장소를 간단하게 사용, 서비스별 적합한 데이터 모델 적용), 유연성(폭발적으로 증가한 데이터를 저장)NoSQL 데이터 저장소 유형: 그래프, 칼럼(column 단위로 데이터 저장), 문서(스키마 유연), 키-값 유형..

프로젝트 기간: 3주(실제 소요 기간 11일)역할: 프로젝트 기획, Redis 및 MySQL 장애 연출, 장애 수집-분석 스크립트 작성, 최종 산출물을 사내 메신저에 등록협업 사항: 프로젝트 기획, input 및 output 선정 시 은빈 인턴님과 협업해 결정[1]프로젝트 제목: 장애 이력 자동 작성 도구[2]목적DB 담당자가 장애 알림을 받으면, 원활한 서비스를 위해 DB 정상화를 최우선으로 진행추후 장애 이력 보고 시 장애 이력을 시간 순서대로 정리해 놓은 타임라인이 필요 한 장애가 발생했을 때 장애 이력 보고에 들어갈 항목: 23가지(장애 관리팀 & 장애 담당자) => 이 '장애 이력 자동 작성 도구'가 없다면, 장애가 발생한 DB의 로그를 일일이 확인해 타임라인을 정리해야 함[3]실행 환경배경: ..