## ORACLE
| HA (High-Availability) | RAC (Real Application Clusters) | OPS (Oracle Parallel Serve) | |
| 구조 | Active - Standby 구조 | Active - Active 구조 | - 8i 부터는 OPS - 9i 부터는 RAC - RAC ping의 성능저하 문제를 보완하여 등장한게 RAC ※ RAC Ping Instance 1에서 데이터를 변경하고 완료 했을때 그 내용을 Instance 2가 조회한다면 Instance 1의 변경내용은 반드시 스토리지에 저장한 후에 Instance 2로 복사해 오는 작업 |
| 스토리지 구성 | - 각 서버마다 스토리지 존재 | - 하나의 스토리지 | |
| 특징 | - DG(Data Guard) : 운영DB를 백업받는 용도 | - Interconnect(private망) : instance1과 instance2를 연결하는 망 - Cache Fusion : RAC Ping을 보완하는 기능, 디스크를 거치지 않고 바로 Instance로 가져올 수 있는 기능 |
|
| 장점 | - 유지보수 및 구성의 비용적 부담 ↓ | - 유실되는 트랜잭션이 없음 (서비스 연속성 보장) | |
| 단점 | - Active 서버가 죽었을 경우 Standby로 변환시키는 동안 트랜잭션 유실이 발생 - 수시로 동기화가 이루어져야하므로 부하가 발생할 수 있음 - 실시간 데이터 복제를 하며 바이러스 복제가 되어 감염을 전이 시킬 수 있음 |
- 유지보수 및 구성의 비용적 부담 ↑ |
※ SEHA
- 쉽게생각하면 RAC One Node Database 와 비슷한 형태
- 다른점은 RAC ONE Node Database는 짧은 시간동안 인스턴스 두개(active, standby)가 동시에 가동되지만,
SEHA는 하나의 인스턴스가 종료되어야 다른 노드에서 인스턴스가 가동 될 수 있음
## MySQL 이중화 솔루션 종류
1. MySQL Replication
- MySQL 서버 간의 데이터 복제 및 동기화를 제공하는 기능
- 인스턴스를 마스터(Master)와 슬레이브(Slave)로 구분
- Master : read, write | Slave : read
2. MySQL Cluster
- 데이터베이스 서버가 여러 대로 구성되어 있으며, 데이터베이스를 분할하고 복제하여 고가용성을 보장
- 데이터 무결성을 보장
3. Galera Cluster
- Galera Cluster는 MySQL 서버의 동기화 및 복제를 위한 클러스터링 솔루션
- 여러 대의 MySQL 서버가 동일한 데이터를 처리하도록 구성되어 있으며, 모든 노드 간의 데이터 동기화를 자동으로 처리
4. Percona XtraDB Cluster
- 여러 대의 MySQL 서버를 클러스터로 구성하여 데이터를 분할하고 복제하여 고가용성을 보장
- Galera Cluster와 비슷하지만, 몇 가지 고급 기능과 성능 개선을 제공
## MySQL Replication을 이용한 고가용성 및 장애복구 관리도구
| MMM (Multi-Master Replication Manager) | MHA (Master High Availability) | |
| 구조 | Active - Standby 구조 | Active - Active 구조 |
| 스토리지 구성 | 빠른 응답을 요구하는 서비스에 사용 | 정합성이 필요한 서비스에 사용 |
| 특징 | - read/write DB에서 장애가 발생 시 Manager DB가 이를 감지하여 VIP read DB로 이동시키는 구조 | - MasterDB에 장애가 발생하면 MHA Manager는 Master 장비의 VIP를 down - Replication을 진행 후 down 시킨 VIP를 Slave장비에 올려 FailOver를 진행 - MHA Monitor가 Master의 Binary Log와 Slave들의 Relay Log를 확인하여 DB 간의 차이나는 쿼리를 DB에 반영 |
| 장점 | - MySQL Replication이 지원하지 않는 auto FailOver를 지원 - MMM Manager Server의 관리 쉬움(virtual IP, Active Master, Passive Master 관리) - 성능 영향 X |
- 최소한의 다운 타임으로 Master의 장애 처리 및 Slave의 새로운 Master로 변경 수행이 가능 - Master에 장애가 발생하여도 각 노드의 데이터 일치 - 스토리지 엔진에 제약을 받지 않고, MySQL 성능에 전혀 제약사항 X |
| 단점 | - MMM Manager 이중화는 불가능 - Multi Master 사용 시 데이터 불일치 가능성 존재 - Active Master 장애 시 데이터 유실 가능성 존재 |
- failover시에 master로 승격시켜야 하고, bin-log와 relay-log 중에서 차이나는 부분을 각 slave에 반영하여 복제 일관성을 유지시키는 작업을 수행하기 때문에 MMM에 비해서 failover에많은 시간이 소요 (MMM에 비해) |
https://velog.io/@jwpark06/MySQL-%EC%9D%B4%EC%A4%91%ED%99%94-%EC%A7%84%ED%99%94%EA%B8%B0
## MSSQL
Mirroring은 없어질 기능이므로 AlwaysOn으로 변경해야 함.
| Replication | Log shipping | Failover Clustering | AlwaysOn | |
| 오류탐지 | X | X | O | O |
| 특징 | - 주서버 데이터베이스의 데이터를 보조서버로 복사하는 방식 | - 주서버의 로그파일을 보조서버에 일정한 주기로 복사하는 방식 | - 두개의 서버가 하나의 스토리지를 바라보며 스토리지를 기준으로 이중화하는 방식 (오라클 RAC와 비슷) | - Mirroring의 단점을 해결 |
| 장점 | - 필요 테이블, 컬럼 단위로 복사가 가능 - 디스크 장애시 복구 가능 - 구축비용 저렴 |
- 디스크 장애시 복구 가능 - 구축비용 저렴 |
- 오류탐지 - 자동 장애 복구 |
- 오류탐지 - 자동 장애 복구 - 디스크 고장시 복구가능 - 구축비용 저렴 - 공유스토리지 필요 없음 - 보조서버에서도 사용가능하므로 부하분산 효과 |
| 단점 | - 자동 장애조치 기능 X | - 실시간 동기화 불가능 - 자동 장애조치 기능 X |
- 구축비용 비쌈 - 공유 스토리지 장애시 복구 불가 |
- Enterprise 에서만 사용 가능 |
'DBMS' 카테고리의 다른 글
| DBMS별 프로세스 기능 차이 (Oracle, MSSQL, MySQL) (0) | 2023.04.10 |
|---|
