Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- Spring Boot
- NestJS
- maven
- Spring
- 서브라임 텍스트
- loadcomplete
- PostgreSQL
- Windows 10
- BRIN
- OGM
- exit code = -805306369
- springboot
- PG-Strom
- Maven Project
- HTML Code
- tortoise SVN
- Next.js
- Spring Cloud
- MariaDB
- typeorm
- orioledb
- Can't load AMD 64-bit .dll on a IA 32-bit platform
- tomcat
- Eclipse
- graph database
- STS
- HTML Special Entity
- NextJs
- Java
- JSP
Archives
- Today
- Total
Undergoing
Multi Master Replication 기본 개요 본문
- 정의
- 여러 대의 Master Node로 구성된 HA 환경
- SMR(Single Master Replication)과의 차이점(출처 : EDB)
- SMR
- 테이블 행에 대한 변경(삽입, 업데이트 및 삭제)은 지정된 기본 데이터베이스에서 발생할 수 있고, 이 변경은 하나 이상의 보조 데이터베이스의 테이블에 복제됨
- 보조 데이터베이스의 복제된 테이블은 지정된 기본 데이터베이스에서 변경을 허용하지 않음
- MMR
- 두 개 이상의 데이터베이스가 지정되어 동일한 테이블 정의와 초기 행 집합이 있는 테이블이 생성
- 테이블 행에 대한 변경(삽입, 업데이트 및 삭제)은 모든 데이터베이스에서 허용됨
- 데이터베이스의 테이블 행에 대한 변경은 다른 모든 데이터베이스의 대응 테이블에 복제됨
- SMR
- 구성 환경
- Master-Standby의 종속 구조가 아닌, 모두가 Master의 권한을 지님
- 각 노드 별 개별 쓰기 가능
- 현 마스터에서 업데이트 발생 시 다른 모든 마스터 노드에 비동기적으로 전파되어 업데이트, 일관성 유지
- 각 마스터는 선택적으로 Read Replica를 생성하여 전체 수신 읽기를 확장, 하위 클러스터를 형성할 수 있음
- MMR의 필요성
- 부하 공유
- 일반적으로는 마스터에 부하가 걸리기 마련이나, 다중 마스터 구조를 통해 부하 분산이 가능
- 사본 유지 관리
- DB 버전의 최신화
- 분할 관리의 용이성
- 부하 공유
- 고려 사항
- 비동기이기 때문에, 다른 마스터에 반영되는 시간이 소요됨. ACID를 보장할 수 없을 수도 있음
- 특정 마스터 노드에서 발생하는 모든 업데이트에 대해 다른 마스터 노드에 전송 시 시간이 많이 걸릴 수 있음(네트워크 대역폭 의존도 높음. 네트워크 성능 저하 가능성 생김)
- 동일한 엔티티에 대해 여러 마스터에서 동시에 업데이트 되는 경우 충돌이 발생할 수 있음.
'개발 > DB' 카테고리의 다른 글
Overview of PostgreSQL Internals(PG14 기준) (1) | 2024.07.19 |
---|---|
MySQL Group Replication (1) | 2024.07.16 |
Aurora Replication (0) | 2024.07.13 |
OrioleDB (0) | 2024.07.12 |
PostGraphile (0) | 2024.07.11 |