일단 그냥 아무거나 다 적음
Mysql 설명임
Amazon RDS!!
Aurora가 궁금했는데.. rds 중심이래
클러스터 구조...
DB 클러스터와 Storage 클러스터로 나누어진다.
primary 있어야하고, read replica 추가...
다중 가용영역... 세개 AZ 6개 복제본
DB클러스터 복제사본
Aurora 더 높은 성능, 확장성 등
Read replica를 추가할 때 기존 read replica를 먼저 올리고 증분으로 올림...
그래서 백업이 설정되어있어야 read replica를 추가할 수 있는 듯.
RDS 스토리지 크기에 따른 IOPS가 다르다. 높아질 수록 커짐
기준 점은 400GB로 이하, 이상을 구분해서 성능의 차이가 좀 있다.(400GB이상은 4개 디스크)
community edition과 대응
스토리지 : 최대 64TB
오로라는 community edtion에서 별도 커스터마이징 됨
++ 동일한 ebs를 써서, 데이터 동기화가 굉장...아니 같음
- survivable cache
- fast insert
- parallel query
- 엔진 사용의 제한(innoDB)
- 일부 내부 아키텍쳐의 차이
mysql 버전 3개로 나누어짐 X, Y, Z
Z버전 업그레이드 는 마이너
(기능, 호환 X --> 보안 자잘한 업그레이드 등등)
X혹은 Y는 메이저 버전 업그레이드
InnoDB 엔진(추가 공부해보자)
64TB인것도 innoDB라 그렇대
MyISAM - > 256GB
과거에 많이 쓰였으나 지금은 Inno가 대세임
- redo log 처리는 Aurora에서 존재하지 않는다.
- change buffer 도 Aurora에서 사용하지 않는다.
- Aurora는 무조건 InnoDB를 사용한다.
InnoDB
-- 장점
- Crash Safe
- 전용 캐시 공간 존재(InnoDB Buffer Pool: 서버의 75% 까지 잡도록 허용, mysql도 마찬가지임)
- 관계 무결성 지원 <- 당연한 것 같지만 InnoDB라서 되는거래
- 내부 체크섬 메커니즘
- 체인지 버퍼링
- Adaptive hash index(사용량이 겁나 많으면 이점이 된다네)
- Compression (IO 작게 가져가고 뭐... 압축하면 그렇겠지)
- Monitoring Feature (다양한 모니터링 기능 사용 가능하다.)
Tablespace는 RDS에서 지원하고 있지 않음
Undo Log
어떻게 마지막 변경을 취소할 지에 대한 내용을 담고 있는 로그
언두로그세그먼트 + 롤백 세그먼트
MVCC Multi version cuncurrency control
Row의 일관된 읽기 및 잠금 없는 읽기를 보장하기 위한 개념
select에 부하를 줄 수 있고, 안좋은 점도 많다. 트랜젝션에서 이점이 없으면 fuzzy한다. (삭제하는 것을 fuzzy라고 부른다...?)
CheckPoint
더티페이지를 플러시하는 과정
Sharp Checkpoint는 퍼포먼스와 IO에 영향을 미침
DML 의 사용이 많은 환경이라면, 성능을 위해 InnoDB로그의 사용량을 늘려주는 것을 고려할 수 있음.
RDS 마이그레이션 모범사례(추천 / 마이그레이션 할때만 좀 적용해줘라)
- Automated Backup을 비활성화
-> 바이너리 로그를 함께 사용하게되는데 IO에 부담이 2배가 되어 migration하는 동안만 좀 꺼라 - 마이그레이션시에 Single-AZ를 사용
- 큰 스토리지와 큰 인스턴스 클래스를 사용
- 데이터 로딩시 Primary Key 순서에 맞춰 로드 (mysqldump 이용시에는 --order-by-primary-key 사용)
- 외래키 체크 비활성화
- 큰 트랜잭션으로 데이터 입력(--extended-insert 사용)
- 바이너리 로깅이 활성화되어 있다면, binlog_format 값을 row가 아닌 다른 값으로 변경 (Automated Backup이 활성화 되어있다 = 바이너리 로깅 활성화)
Restore From S3 사용시
- 백업이 호환되어야 s3 통한 복원 사용가능
- 압축 파일 만들 때, 여러 파일로 쪼개라
- 복원된 데이터베이스의 최대크기는 지원되는 최대 데이터 베이스 크기에서 백업 크기를 뺀 값 (64TB - XX)
버전 업그레이드시 참고사항
- DB 엔진 업그레이드의 경우, 일반 업그레이드와 다르게 multi-AZ 환경에서도 함께 업그레이드가 이루어지기 때문에, 별도의 다운타임 감소가 없음
- 업그레이드간 Downtime 감소를 위한 방법으로는 Blue-Green Deployment를 사용가능
- 마이너 버전 자동 업그레이드는, 최신 버전이 릴리즈 이후 바로 적용이 아니라 보안, 버그 등 고려해 자동 업그레이드 대상일 경우에만!
- 자동 업그레이드를 해지한다고, OS 업그레이드는 피할 수 없다.
major 버전 업그레이드
- 메이저는 호환성 때문에 자동으로 진행 X
- 신규 버전 인스턴스의 경우. 오래된 세대 인스턴스는 지원하지 않을 수 있다.
- 테스트 권장
- Datetime/time/timestamp가 포함되어있는 경우 'ALTER TABLE <table_name> FORCE;' 명령어를 통해 데이터 타입 컨버전 가능
RDS -> Aurora
- 스냅샷, 읽기 전용 복제본을 통한 마이그레이션 가능
- Aurora 에서 지원하지 않는 테이블은 제거가 필요하다.
(InnoDB가 아닌 엔진을 사용하는 테이블, 지원하지 않는 Row Format을 사용하는 테이블)
MySQL Replication
- RDS Mysql은 기본적으로 crash safe replication이 활성화
+ 병렬 복제
- slave_parallel_workers
- slave_parallel_type
- slave_preserve_commit_order
- binlog_group_commit_sync_delay
- binlog_transaction_dependency_tracking
- transaction_write_set_extraction
Read Replica 한계
- 멀티 소스 리플리케이션 불가
- 그룹 리플리케이션 불가
- 비동기식 (semi sync는 지원 X)
Trouble Shooting
Resource Overhead
- High latency
- Low Throughput
- Not available instance state(storage-full)
- Storage Throttling
▶ IOPS, throughput
▶ GP2
- BustBalance < 1TB
- Up to 3000 IOPS
- Throughput up to 4000 MB/s
▶ IO1 (헤비 트랜잭션이 빈번하면 IO1을 추천 함)
- Provisioned IOPS
- Throughput up to 1000 MB/s
▶ ReadThroughput + WriteThroughput, ReadIOPS + WriteIOPS
▶ Low free storage
- temporary object
- 비정상 인입
Autoscaling은 긴급 조치일 뿐. 알람을 사용해서 temp로 인해 storage가 차게 된다면 빠르게 조치해주자.
(늘어나면 줄지 않고, Autoscaling 쿨타임도 존재한다.)
Aurora는 사용한 스토리지 만큼 용량을 내므로,(늘려놓고 사용하는게 아님/필요할 때 마다 숫자만 올라감) Autoscaling이 필요하지 않으며, temp가 막 늘어나면 비용이 늘어날거임.
: 최근 버전은 리사이즈 기능이 있어서 사용량이 줄어들면 자동으로 줄어듬! 이전버전은...?
Performance Issue
갑자기 확 쳐서 알람조차 발생하지 않게되면, 그냥 자동 재시작
High CPU
- 쿼리 load
- Enhanced Monitoring
▶ LoadAverageMinute
▶ User(%) or Nice(%)- Performance Insights
- Lock
- Long running queries
Low memory (VM마다 사양이 다른데, 같은 설정을 가져갈 경우 문제 발생할 수 있음)
- Buffer pool setting
- Memory-related parameters
▶ sort_buffer_size, join_buffer_size, tmp_table_size... - Performance Schema (Mysql에서는 메모리에 올라감)
- Long running query
- OOM
▶ Review memory-related parameters - CloudWatch metric: FreeableMemory (캐시 버퍼 모두 포함이므로 상세하게 구분하여 쳐다볼 것)
High Replica lag
- Insufficient instance class or storage
▶ Bigger or same instance class on replica - Long running queries
- Binlog_format = ROW
으 이거 3년차 정도 DBA 교육이었따.
내 레벨이 아니어따.
쪼오오끔은 이해했지만, 난이도가 굉장히 높아따.
이대로 괜찮을까...
