http://woowabros.github.io/experience/2018/05/28/billingjul.html
https://ani2life.com/wp/?p=1290
mysqldump가 너무 느려서 뭔가 대안이 없을까 이것저것 뒤지다가 찾은건데요..
그야말로 mysql 백업의 완결판이라고 할만합니다.
sql로 변환해서 백업하는 mysqldump하고는 다르게
그냥 DB 파일 자체를 복사하는 방식의 백업이라서 속도가 비교가 안됩니다.
백업속도도 백업속도지만 사실 복구 속도가 압도적으로 빠른거 같아요.
이렇게 DB 파일 자체를 복사해서 백업하는건 MyISAM 시절에는 많이
쓰였던 것 같은데 InnoDB가 주류가 되면서 거의 이런 식으로는 백업안하는걸로
아는데요..
사실 안정성만 담보된다면 구지 mysqldump를 쓸 필요는 없지요..
그리고 xtrabackup은 그냥 파일복사하는거라던가 mysqldump하곤 틀리게
증분백업이 됩니다.
사실 mysqldump의 불편함을 생각하면 진작에 xtrabackup이 널리 알려져서
쓰이고 있어야 하는거 같은데 검색해보면 별로 얘기가 없더라구요. (한글로 말이죠)
그냥 조용히 아는 사람만 알아서 쓰는건가..
사용법은 진짜 굉장히 쉽습니다.. mysqldump하고 딱 똑같은 수준...
링크한 2번째 글은 배달의민족에서 xtrabackup을 쓴 경험담인데요..
SQL을 압축해서 19GB짜리 DB 정도면 정말 굉장한 사이즈네요..
압축풀면 한 200GB쯤 한다는 얘긴데..
레코드가 몇개나 있을까요? 레코드가 10억개 이상 있을듯..
이런걸 mysqldump로 백업해서 복구한다고 치면.. 살떨리네요.
그리고 첫번째 글에 보면.. 일단 증분백업을 한 다음에 그 증분백업한걸
그냥 전체백업한거에 합치는 식으로 최종 결론을 내고 있는데..
그렇게 할거면 구지 저 글에서 설명하는 것처럼 어렵게 할 필요가
별로 없는거 같습니다.
innobackupex --apply-log <전체백업디렉토리>
이렇게 하면 기존 전체백업에다가 백업시점 이후의 로그를 반영해서
최신으로 만들어내는거 같더라구요.
(모르겠네요 이렇게 하면 안되는 뭔가 다른 이유가 있을지도)
용량이 100GB 가까이 되는 InnoDB 데이터를 매일 mysqldump --opt --single-transaction --no-autocommit --order-by-primary 명령으로 백업 + 압축 + 원격 전송하고 있는 고객사이트가 2군데 있습니다. 전혀 살떨리지 않아요.
이런 장점이 있는 mysqldump을 두고 굳이 다른 툴을 찾아볼 동기부여가 안 되네요. ㅎㅎ 테이블 락이 팍팍 걸리던 MyISAM을 많이 쓰던 시절에 비해 대체 백업툴의 인기가 시들한 이유도 아마 이것 때문인 것 같습니다.