백업

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

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

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

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

---

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

---

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

---

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

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

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

---

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

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

---

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

---

자동화하자

서비스를 고를때

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

나스를 고를 때

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

---

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

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

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

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

---

슬레이브

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

---

서비스는 마스터에서

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

---

데이터 복제

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

---

로스리스 리플리케이션

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

lossless replication - 샌드와 어크기반

---

MHA + 로스리스

MHA는 릴레이로그 사용

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

---

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

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

---

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

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

퍼포먼스까지 얻음

---

---

2023년 새해에는 성장하고 함께하고 싶다면?

Pre A 단계 이상의 스타트업 C 레벨들이 모여서 커뮤니티를 만들었습니다. 같이 스터디하고 친해질 일잘러를 찾습니다.