[MASOCON] 데이터정의로 밝힌 삶의 햇볕


백업

  1. 복구
  2. 소산
  3. 글쎄..?

로컬 디스크에서 하면 스케쥴링도 쉽고 간단하다.

늘어나면 백업데이터를 물리적으로 다른 곳으로 옮겨야한다.

즉 별도의 나스로 옮기곤 해야한다.


IDC 마스터, 슬레이브급의 백업.


백업데이터란 자주 쓰이지 않지만, 하루 전 파일도 의미있는 서비스에 필수적인 데이터


매일 같은 나스에 원격 백업해야할까?

복구할 때 반드시 오늘 백업이어야할까?

늘 같은 시간에 백업해야 하나?


매일 다른 나스에 백업해볼까

하루전 백업과 로그로 장애 직전으로 돌릴 수 있다.


최대한 안바쁜 나스에 돌리자


자동화하자

서비스를 고를때

  • 백업 시간 대역에 존재
  • 스케줄이 가장 밀린 순서
  • 어제 백업 데이터 사이즈 순

나스를 고를 때

  • 멀쩡한 녀석 중
  • 임계치를 넘지 않고
  • 동시 백업 수 적고
  • 어제 백업하지 않은 곳

로스리스 어싱크로스 리플리케이션

mysql 슬레이브는 마스터의 커밋 완료된 데이터를 복제한다.

마스터/슬레이브 간 데이터가 틀어질 수 있다.

마스터 장애 시 데이터 유실이 발생할 수 있다.


슬레이브

비동기로 데이터를 로컬에 복제하며, 굳이 서비스에 포함되지 않아도 되는 녀석


서비스는 마스터에서

마스터 슬레이브 갭을 해소시킴


데이터 복제

마스터에서만 서비스하는 상황에서의 피할 수 없는 비동기 데이터 복제


로스리스 리플리케이션

mysql replication - 바이너리 로그를 IO 스레드를 통해 슬레이브의 릴레이 로그로 옮기고 로그로 복제

lossless replication - 샌드와 어크기반


MHA + 로스리스

MHA는 릴레이로그 사용

데이터 유실 없는 높은 가용성 달성 / 30초 이내 페일오버


커밋마다 디스크에 쓰는게 가장 전통적으로 안전한 구성

  • 성능이 디스크의 성능에 좌우된다.

로스리스는 그룹 어딘가에 변경 이력이 존재한다.

1초마다 디스크에 쓰는 방법을 채택

퍼포먼스까지 얻음







© 2017. by isme2n

Powered by aiden