공부, 기록

서비스 중 mysql 테이블을 파티셔닝 테이블로 전환이 필요할 때 ONLINE DDL 방식으로 변경이 가능한지 확인해보았다. pt-osc 툴을 사용하여서 가능하며 툴 기능을 추가하여야한다 (해당 기능은 kakao db team 에서 구현) 1. pt-osc 패치 진행 2. pt-osc 로 PK 구성 변경 (--prompt-before-copy 옵션) 3. data copy 전 확인 단계에서 다른 세션으로 new 테이블에 파티셔닝 작업 수행 4. pt-osc로 돌아와 data copy 마저 진행 5. 성능 테스트 6천만건 테이블에 1분 당 3500건 insert (1개 스레드로 350건 입력 + 반복별 0.01초 유휴시간을 주면 분당 약 3500건의 성능이 나옴) ptosc.patch 파일 생성 @@ -8..

Redis Cluster - 주요 개념 및 특징 Redis Cluster : 데이터를 자동으로 여러 Redis 노드에 나누어 저장하며 HA를 지원하는 기술. 과반수의 Master 노드가 죽는 경우 클러스터가 중단 됨. 클러스터는 HA, Sharding을 지원하는 Redis의 운영 방식 중 하나이다 dataset을 Hashslot으로 여러 노드들에 데이터가 매핑될 수 있도록 한다. 각 마스터는 데이터 서버 + 센티널의 역할을 같이 수행한다고 볼 수 있다. Scale-Out 방식 동작 방식 자체적인 바이너리 프로토콜을 통해 node-to-node로 통신을 한다. 각 노드들은 클러스터에 속한 다른 노드들의 정보를 모두 갖고 있는다. 최소 마스터 개수는 3대 이상(MEET 명령어로 3개 이하로도 강제 구성 가능..

레디스 클러스터 구성 테스트 1. 클러스터 구성 테스트 redis 설치 및 conf 파일 수정 cluster-enabled : yes cluster-config-file nodes-6379.conf cluster-node-timeout 3000 cluster-migration-barrier 1 redis -cli --cluster create ip:port ~ 실행 예상 결과 : 4대의 마스터 4대의 슬레이브로 클러스터 자동 구성 실제 결과 : 기존 클러스터로 구성되어 있던 환경이 존재하여 node 에러 발생 → 클러스터 초기화가 필요 → 각 노드에서 CLUSTER RESET HARD 명령어 실행 → 클러스터 재 구성 → 8개의 마스터 서버로 구성 → --cluster-replicas 1 설정 → 4MA..

개요 개발팀에서 특정 SP에서 지연이 발생한다는 내용 전달과 확인 요청을 받음. 통계값을 확인하였을 때 큰 이슈는 없어 보이는 SP 였음. 확인 내용 API CALL 과 동일하게 ANSI 셋팅 이후 진행 (SP의 경우 플랜캐시로 컴파일을 생략하므로 ANSI 셋팅이 다르면 API 호출과는 다른 플랜캐시가 생성되어 정확한 확인이 안될 수 있음) 출력되는 데이터는 0건 메타데이터 관리 테이블을 필터링 하는 과정에서 대부분의 시간이 소요됨. 특이사항 SET STATISTICS IO, TIME 으로 확인한 메타데이터 관리 테이블 및 데이터 처리 내용 실행계획 중 필터 부분의 확인 내용 3. Trace를 통한 확인 내용 (duration, cpu는 show statistics io, time 을 통해 확인한 값과 ..

특정 시점 슬로우 쿼리 증가 현상을 확인개요 : 새벽 01시 슬로우 쿼리 대량 발생분석 다양한 슬로우 쿼리들이 발견됨해당 쿼리들의 reads, cpu 값에 비해 duration이 높아 보임평소 시간대에는 쿼리들이 슬로우 쿼리로 잡히지 않음개발팀을 통해 해당 시간에 API 배치 등 서비스에 특수한 작업은 없는걸로 파악 함특정 계정(A)으로 실행되는 쿼리가 reads, cpu 값이 비교적 높음01시 시점에 다른 시간대에 비해 A 계정 쿼리가 다수 잡힘작업A 계정의 쿼리 분석 및 수정 (BI 데이터를 위한 이관 쿼리로 인덱스 사용할 수 있도록 조건 부분을 조정)결과 : 해당 시점 슬로우 쿼리 수 감소특이사항 : A 계정의 쿼리가 비교적 reads와 cpu가 높으나 서버에 전체..

테이블 스캔 -> read_key, read_first, read_rnd_next 증가 pk 1건 조회 → read_key 증가 index 조회 + 인덱스 컬럼만 read_key, read_next 증가 index 조회 + 다른 컬럼도 read key + read_next 증가 index 스캔 + 인덱스 컬럼만 read_key + read_next 증가 index 스캔 + 다른 컬럼도 read_key + read_next 증가

백업 시간대에 모니터링에 데드락이 확인되어 errorlog 등을 확인하였다. ERRORLOG 내용 NODE 1 PROCESS ID process1b33f7be8c8 (이하 프로세스 A) DELETE FROM msdb.dbo.backupset WHERE backup_set_id IN (SELECT backup_set_id FROM @backup_set_id frame procname=adhoc line=12 stmtstart=714 stmtend=832 sqlhandle=0x0200000077cf362f18334db4e5df45ed12b88dd5ec463b020000000000000000000000000000000000000000 unknown inputbuf DECLARE @num_days_to_reta..

Dump : 논리적 DB 백업 -> CREATE, INSERT 등의 구문으로 백업 및 복원을 하는 방식 데이터 사이즈에 따라 속도 차이가 심하지만 간편하며 어떤 MYSQL 서버에서도 사용이 가능한 장점 Xtrabackup : 물리적 DB 백업으로 파일 시스템 자체를 복사하는 방식이므로 속도가 빠르다 시점복원을 통한 데이터 복원하기 SQL SERVER 에서는 풀백업이 있다는 가정하에 로그 백업을 통하여 시점 복원을 통하여 DB 를 복원하고(STOPAT) (카탈로그 DB명은 별도로 생성) 서비스의 테이블과 복원한 테이블의 데이터를 비교하여 서비스 테이블의 데이터를 복원할 수 있다. MySQL에서는 이러한 장애 상황에서 어떤 방식으로 진행할 수 있을지 체크해보았다. DUMP + BINLOG 를 이용한 복원 1..

CDC : Change Data Capture 는 데이터가 변경 된 경우 이를 저장하는 기능이다. 해당 기능을 이전에 사용했을 때는 깊은 고민없이 사용하였다. 최근 데이터 동기화 방안과 RO 구성에 대한 다양한 방식을 찾다가 CDC 기능을 다시 확인하였고 트리거와 복제 등의 구성과 어떤게 다른점이 있어서 사용을 하는지에 대해 알아보고자 했다. CDC 특징 1. CDC는 데이터 변경의 값을 트랜잭션 로그를 기반으로 하여 추적한다. 2. 원본 테이블에 접근하지 않고 타겟 테이블에 데이터 변경에 대한 기록을 남기기 때문에 서비스에 영향이 적다. 3. 다양한 튜닝을 통하여 CDC의 성능 향상이 가능하다. 4. 원본 테이블에 스키마 변경이 생기면 CDC에 수동으로 반영이 필요하다. (DDL이 미포함이므로) CDC..

SQL Server는 SP마다 일반적인 상황에서 하나의 실행계획을 가지고 사용한다. 다만 특정한 상황에서 SP에 들어오는 파라미터 값에 따라 적절한 실행계획이 나누어지는 상황이 있을 수 있다. 이를 위해 SP에 recompile을 옵션으로 줄 수 있다. 방법 1. SP에 WITH RECOMPILE 을 설정 SP 자체에 전체 실행계획을 매번 새로 작성한다. 즉 실행캐시에 실행계획이 저장되지 않는다. 이는 약간의 CPU 상승을 야기하지만 파라미터에 따른 실행계획이 바뀔 수 있는 경우 적절한 방법이 될 수 있다. 2. 필요한 쿼리에 OPTION (RECOMPILE) 을 설정 SP 자체에 WITH RECOMPILE 옵션을 주는 것과 달리 OPTION이 달린 쿼리 구문에만 실행계획을 재확인 한다. 이러한 상황은 ..