성능이슈로 db 정기 백업에 관해서
본문
예를 들어 1년에 1백만 row 가 추가 되는 table 있습니다
그래서 1년에 한번 db를 백업할 계획을 세웁니다
1. 이때, 사용자가 1년 이전 data 를 요구할 때,
자동으로 조건절을 이용해 백업 db 를 select 하는 쿼리를 만드는 것이 좋은가요?
2. 아니면 사용자 ui 에 1년 이내 data 버튼, 1년 이전 data 버튼 따로 만들어서
사용자가 백업 db 의 data 를 요구할 때 성능이 느릴 수 있음을 인지시키는 것이 좋을까요?
3. 현업에서 db 백업은 일정 주기가 지나면 자동으로 백업이 되도록 완전자동화 되어 있나요?
아니면 db 관리자가 스케쥴에 따라 수동으로 (예를 들면 서버점검 시간에?) 하는 것이 관행인가요?
4. h/w 성능, table 칼럼 수 등 여러 변수가 있을 수 있겠지만
db 백업할 정도의 db 사이즈는 어느 정도인가요?
답변 4
성능이슈로 백업을할경우
mysqldump를 사용하시는게 좋고
필요에따라 바로 확인하시는게 아니라면
보관용으로 .tar + gzip으로 적용해서 압축해서 시간을 관리하는 형태로 백업하시는게 좋습니다.
시점별로 스냅샷식으로 보관하는게 백업의 의미가 있을테니까요
테이블 복제형태는 실시간백업보다는 미러링의 의미가 큽니다.
백업할때는 db사이즈가 중요한게 아니라.
저장소의 크기가 중요하죠
DB가 너무 많이 방대해서 백업이 어려운상황에 도달했을때는
데이타 정제를 해서 보관데이타와 사용데이타로 나누어야 하는데
그건 전문DBA의 도움을 받으시는게 상책입니다.
DB의 여러가지 마이그레이션 / 튜닝들이 필요하거든요
복구를 생각한다면 데이타 전체 백업하는게 맞습니다.
뭐는 지우고 뭐는 남기고 하는 작업이 더 번거롭고, 행여 데이타가 손실되면 전체 복구를 하는게 복구 시간을 줄일수 있습니다. 디스크도 요즘 비싸지도 않구요.
한 200기가정도는 그냥 풀로 백업해도 됩니다.
테라급이상의 데이타도 바이너리 증분하는 형태로 백업할겁니다..
나열된 항목들 모두 정해진 답이 없습니다.
운영쪽에서 정책을 어떻게 잡느냐에 따라 각각 다른 형태가 됩니다.
