Global Database
- primary cluster in region A
- secondary cluster in region B
Swichover
- 어떤 리전 내에 있는 primary 클러스터가 죽으면 다른 리전에 있는 secondary 클러스터가 primary 으로 승격 → 대신 in-flight replicated 데이터는 유실될 수 있다.
- 클러스터 간 복제를 위해 replication agent/server 가 있다.
- lag 최소화하기 위해 주로 가까운 리전에 secondary 를 만든다.
Write fowarding
- primary 클러스터 내 primary 인스턴스에 쓰기 수행하면 secondary 클러스터 내 primary/replica 까지 데이터 복제를 수행
Fast clones
Export to S3 via clone
- parallel export available
Enhanced binlog
- two phase commit 은 복잡하다 → two phase commit 구조를 개선
pgvector (for postgresql)
- embedding vendor 키워드로 벡터 사용 가능
Aurora serverless
- 애플리케이션 서버가 scale in/out 하는 정도에 따라 Aurora 서버도 scale in/out 한다. (CPU/memory resizing)
- 메모리 리사이징 = buffer pool resizing (기본으로 셋업되는 메모리 비율 : 버퍼 풀 75%, 힙 25% → 버퍼와 힙의 비율을 자동으로 조정)
- 남는 메모리가 있으면 메모리 사용을 자동으로 줄인다.
Blue/Green deployment
- blue → green 클러스터 으로 데이터 복제를 하기 때문에 cutover / rollback 가능?
- cutover 이후에는 현재 next 된 클러스터를 드랍?
- 사용 목적
- DBMS 버전 업데이트
- DDL 포함한 피처 배포
Zero-ETL
- by data streaming from Aurora to Redshift
New Aurora Storage Type
- I/O-optimized
- predictable price
- improved price performance for IO-heavy workload
- apply to cluster unit (클러스터 단위로 적용 가능)
- how it works : optimized reads with tiered cache
- 디비 내 단위시간 당 디스크 IO 횟수를 줄인다. → 캐시 히트율을 높여야 가능.
- 캐시 히트율을 높이려면 파티셔닝을 잘 해야.
- 캐시 히트율을 높이려면 인덱싱을 잘 해야. (힙 트리 구조 내 특정 인덱스 블록을 자주 접근하는 만큼 해당 인덱스에 대한 캐시 히트율이 높아질 것임)
Limitless Database
- scale ≈ managed sharding
- 샤딩을 적용하면 직면하는 과제들
- inconsistency
- DDL 수행 시 샤드 중에 일부가 실패하는 경우
- 동일 쿼리를 수행했으나 샤드 중에 일부가 쿼리 지연으로 인해 다른 결과를 조회하는 경우
- capacity managment
- single database gets bigger → shard 진행 → 샤딩 불균형 발생 → 로드가 많은 샤드는 사양 늘림 (근데 로드 적은 인스턴스들도 같이 늘려야 됨?) → 불필요한 금전적 비용으로 돌아옴
- limitless 는 샤딩에서 발생가능한 문제들을 개선한다.
- 2백만 TPS 보장
- how?
- automated re-sharding (내부적으로 특정 샤드에 데이터가 몰리면 해당 샤드 대상으로 다시 샤딩 진행)
- serverless capacity (트래픽이 많고 적음에 따라 사양을 늘렸다 줄였다)
- consistent DDL/Query/Backup
- 내부적으로 global clock 을 가지고 있음
- cross-shard transaction 의 경우 global clock + 각 샤드의 스냅샷을 사용하여 시간의 지연 없이 consistent read 가능