MMM ( Multi-Master replication Manager for MySQL )
Multi-Master의 단점을 보완하기 위해서 Manager 장비를 두어 가용성 보장(모니터링)
read/write DB와 read DB로 운영 중 Read/write DB에서 장애 발생 시 Manager DB가 이를 감지하여 vip를 read DB로 이동시키는 구조(Failover)
3rd party 제품으로 운영환경에 맞게 shell script 프로그래밍이 필요
MMM 작동순서
Active Master에 장애 발생시 MMM Manager는 장애를 감지하고 Active Master의 접속을 차단(Virtual IP Down)하고 Passive Master로 서비스의 접속(Virtual IP up)을 넘김
FAIL BACK은 수동으로 진행하는 것이 원칙이나 패치 등으로 인한 정상 종료일 경우 Active Master를 재가동 시켜도 무관함
MMM 장애 처리
# 장점
MySQL Replication이 지원하지 않는 auto Failover를 지원
MMM Manager Server의 관리가 쉬움
MMM Manager는 Virtual IP 관리도 가능
MMM Manager에서 Active Master와 Passive Master 관리가 가능
MySQL의 성능에 영향을 주지 않음
MySQL Storage Engine을 그대로 사용할 수 있음(MySQL cluster는 꼭 NDB를 사용해야 함)
# 단점
MMM Manager 이중화가 불가능
Multi Master로 사용이 가능하나 Multi Master 사용시 데이터 불일치 가능성 있음
Active Master 장애시 데이터 유실 가능성 있음
2. MHA ( Mysql High Availability for MySQL
개요
MySQL 5.6 GTID 지원
MySQL 5.6 Multi-Thread Slave 지원
MySQL 5.6 Binlog checksum 지원
mysqlbinlog streaming host 지원
mysqlbinlog 위치 지원
ping_type=Select / Connect 이외 insert 추가
master_ip_online_change_scrip에 --orig_master_is_new_slave, --orig_master_ssh_user and --new_master_ssh_user option 추가
MHA 구성도
Single master, multiple Slaves
Single master, multiple Slaves (one on remote datacenter)
Single master, multiple Slaves, one candidate master
Three Tier replication
Three Tier replication, multi-master
# 장점
최소한의 Down Time으로 Master의 장애 처리 및 Slave의 새로운 Master로 변경 수행 가능
Master의 장애로 각 노드(Master 및 Slave)의 데이터 불일치가 발생하지 않음
현재 MySQL 서버의 설정을 변경 할 필요가 없음 (MySQL 5.0이상)
서버를 많이 늘릴 필요가 없음 (MySQL Cluster 대비)
스토리지 엔진에 제약을 받지 않음
MySQL 성능에 전혀 제약 사항이 없음
MariaDB Galera Cluster ( = MySQL )
Codership에 의해 개발된 MySQL/MariaDB 이중화 도구로 Synchronous Multi-Master Cluster 소프트웨어로 MySQL Cluster CGE와 달리 별도의 NDB 엔진을 사용하지 않음 (InnoDB 사용)
# 기능
HA 클러스터링 시스템 - Single Point Of Failure을 방지하는 고가용성 솔루션
Active-Active 방식의 멀티마스터 구성
모든 클러스터 노드에 읽기/쓰기 가능
자동으로 신규 노드 추가
클러스터 내 노드 자동 컨트롤
특정 노드 장애 시 자동으로 해당 노드 삭제
Low 레벨의 병렬 복제
기존의 MySQL Client 방식으로 동작 함으로써 어플리케이션에서 사용이 편리함
MySQL 5.1, 5.5 지원
# 장점
노드 간 유실되는 트랜잭션이 없음
마스터 / 슬레이브 간에 데이터 동기화 지연 없음
읽기/쓰기 모두 확장이 가능
클라이언트의 대기시간이 줄어듬 (데이터는 각 로컬 노드는 존재)
VIP 불필요
NDB와 같은 새로운 스토리지 엔진 기술을 배울 필요가 없음
# 단점
신규 노드 추가 시 부하 발생 – 신규 노드 추가 시 모든 데이터를 복사해야 함
데이터 분산이 되지 않는다. – 모든 노드가 동일 데이터를 보유
효과적인 쓰기 확장 솔루션에는 한계 – 서버 간 Group Communication시 트래픽 발생
모든 서버 노드에 동일한 데이터를 유지해야 함 – 저장 공간 낭비
Replication for MSSQL ( MSSQL 복제 )
복제는 한 데이터베이스에서 다른 데이터베이스 데이터와 데이터베이스 개체를 복사 및 배포한 다음 데이터베이스 간에 동기화를 수행하여 일관성을 유지하는 기술
복제된 대상 DB는 온라인 상태를 유지하게 되므로 다른 일련의 역할을 수행할 수 있다.
SQL에서 제공하는 복제 솔루션
트랜잭션 복제 (Transactioin Replication)
데이터 변경에 대한 로그를 읽어 비동기적으로 데이터를 대상 DB에 반영
동일한 데이터가 5회 변경될 경우 마지막 데이터가 아닌 5번의 변경 모두가 대상 DB에 각각 반영
기본적으로 row 단위로 데이터가 반영
다른 복제에 비해 짧은 동기화 시간을 가짐
게시자 또는 구독자가 Oracle 인 경우 사용 가능함
스냅숏 복제 (Snapshot Replication)
지정한 개체의 모든 데이터를 대상 DB에 반영
동기화가 진행되는 동안 구독자의 데이터를 사용할 수 없음
지정한 개체의 사이즈가 큰 경우 동기화에 시간이 오래 걸림
데이터 사이즈가 작고 많은 업데이트가 발생하는 경우 유용함
사용 예시 ) 슈퍼마켓 지점, 본점의 데이터를 매일 새벽 동기화
병합 복제 (Merge Replication)
게시자와 구독자 모두가 데이터 변경을 할 수 있음
동일한 데이터가 5회 변경될 경우 변경 데이터의 마지막 값을 가지고 있다가 동기화 시 마지막 값을 대상 DB에 반영함
트리거를 통하여 변경되는 행의 대해 마지막 변경 값을 시스템 테이블로 관리함
충돌 발생 시 지정한 우선순위에 따라 어떤 값을 반영할지 결정함
사용예시 ) PDA와 PC 간의 데이터 동기화
P2P 복제 (P2P Replication)
모든 노드가 게시와 구독의 역할 모두를 수행함
중간의 1개 노드가 장애 발생시에도 다른 노드를 통하여 데이터 동기화 하여 복제 가용성을 높일 수 있음
양방향 트랜잭션 복제와 유사한 형태로 동작
Mirroring for MSSQL
데이터베이스 가용성을 높이기 위한 소프트웨어 솔루션
데이터베이스 단위로 구현되며 전체 복구 모델을 사용하는 데이터베이스에서만 작동
데이터베이스를 제공하는 주 서버(principal Server)와 장애 조치를 위한 미러서버로 기본 구성을 하며,
운영 모드에 따라 모니터 서버(Witness Server)를 추가하여 장애 발생 시 자동 장애조치(FailOver)를 수행할 수 있다.
Log Shipping for MSSQL ( MSSQL 로그 전달 )
로그 전달을 사용하면 주 서버 데이터베이스에서 별도의 보조 서버에 있는 하나 이상의 보조 데이터베이스로 트랜잭션 로그 백업을 자동으로 보낼 수 있다.
트랜잭션 로그 백업은 각 보조 데이터베이스에 개별적으로 적용된다.
모니터 서버라고 하는 선택적인 세번째 서버는 백업과 복원 작업의 기록 및 상태를 기록하고 예약된 대로 작업이 실행되지 않으면 경고를 발생 시킬 수 있다.
# 로그 전달의 특징
로그 전달 구성은 자동으로 주 서버에서 보조 서버로 장애 조치(Failover)되지 않습니다. 주 데이터베이스를 사용할 수 없을 경우 수동으로 임의의 보조 데이터베이스를 온라인 상태로 전환할 수 있다.
보조 서버의 데이터베이스는 일반적으로 읽기 전용 상태를 유지하지만 복원 작업 진행 시 모든 연결이 끊어지게 된다.
SQL Server 2008 부터는 압축 백업을 이용하여 좀 더 빠르게 로그 전달을 수행할 수 있습니다.
SQL Server 장애 조치 클러스터는 Windows Server 장애 조치 클러스터 위에 구축되어 전체 SQL Server 인스턴스에 고가용성을 제공한다.
SQL Server 장애 조치 클러스터는 네트워크에서 한 대의 컴퓨터처럼 보이지만 현재 노드를 사용할 수 없을 때 노드 간 장애 조치(Failover) 기능을 제공한다. 예를 들어 디스크 이외의 하드웨어 오류, 운영 체제 오류 또는 계획된 운영 체제 업그레이드 작업 중에 다른 노드에서 SQL Server 인스턴스를 구성하여 서비스를 유지할 수 있다. 그러나 장애 조치 클러스터는 디스크 오류에 대한 대비책은 아님
Heartbeat 라인을 통하여 각 노드의 상태를 서로 체크하게 됩니다.
외부에서는 항상 동일한 Virtual IP를 바라보며, 어떤 노드가 Active한지를 알 필요가 없습니다.
공유 스토리지를 사용하기 때문에 데이터 동기화의 비용이 들지 않습니다.
구성 방식에 따라 각 노드를 Active-Passive , Active-Active로 구성할 수 있으며, 최대 16개 노드를 구성할 수 있습니다.
