Git에서 MySQL 데이터베이스를 백업하는 것이 좋은 생각입니까?

내 응용 프로그램의 백업 상황을 개선하려고합니다. Django 응용 프로그램과 MySQL 데이터베이스가 있습니다. Git에서 데이터베이스 백업을 제안하는 기사를 읽었습니다.

한편으로는 데이터와 코드의 사본을 동기화하여 유지하기 때문에 마음에 듭니다.

그러나 Git은 데이터가 아닌 코드를 위해 설계되었습니다. 따라서 커밋마다 MySQL 덤프를 비교하는 많은 추가 작업을 수행하므로 실제로는 필요하지 않습니다. 파일을 저장하기 전에 압축해도 git은 여전히 ​​파일을 비교합니까?

(덤프 파일은 압축되지 않은 상태에서 현재 100MB, 압축되지 않은 경우 5.7MB입니다.)

편집 : 코드 및 데이터베이스 스키마 정의는 이미 Git에 있으며 실제로 백업에 관심이있는 데이터입니다.

데이터를 잃기 전에이 질문에 대해 sysadmin 관점을 소개하겠습니다.

일이 잘못되면대로 복원하는 것을 가능하게하기 : 우리는 백업을 만들 단 하나의 이유가 변함없이 뜻. 따라서 적절한 백업 시스템에는 git이 합리적으로 처리 할 수있는 것 이상의 요구 사항 이 있습니다.

다음은 git에서 데이터베이스를 백업하려고 할 때 예상 할 수있는 몇 가지 문제입니다.

• 리포지토리는 모든 "백업"마다 크게 증가합니다. 때문에 자식 매장 전체 오브젝트 후 (압축이기는하지만)하고 (예를 들어, 당신이 실행할 때 나중에 차이점 git gc) , 역사를 유지 영원히 , 당신은 당신이 실제로 필요하지 않은 또는 원하는 저장된 데이터의 매우 큰 금액을해야합니다. 디스크 공간을 절약하기 위해 또는 법적 이유로 백업의 양 또는 보존 기간을 제한해야 할 수도 있지만 , 많은 부수적 손상없이 git repo에서 이전 개정 을 제거하는 것은 어렵 습니다.
• 복원은 저장소에 저장 한 시점으로 제한되며 데이터가 너무 커서 사소한 시간 이상으로 되돌아가는 것이 느려질 수 있습니다. 이를 위해 설계된 백업 시스템은 저장되는 데이터의 양을 제한하면서 더 세분성을 제공 할 수 있으며보다 빠른 복원을 제공하여 재해 발생시 다운 타임을 줄입니다. 데이터베이스 인식 백업 솔루션 ( 예 )은 지속적인 백업을 제공 하여 단일 트랜잭션이 손실되지 않도록합니다.
• 커밋도 느리고 데이터베이스가 커질수록 느려질 수 있습니다. git은 기본적 으로 파일 시스템에 매핑 된 키-값 데이터 저장소 이므로 기본 파일 시스템의 성능 특성에 종속됩니다. 이 시간이 결국 백업 간격을 초과 할 수 있으며이 시점에서 더 이상 SLA를 충족시킬 수 없습니다. 또한 적절한 백업 시스템은 데이터가 증가함에 따라 백업 시간이 오래 걸리지 만 구성 할 보존 정책에 따라 자체 크기를 자동으로 관리하기 때문에 그다지 극적이지는 않습니다.

데이터베이스 덤프를 git에 넣으면 데이터베이스 덤프로 할 수있는 흥미로운 일 이 몇 가지 있다는 사실에도 불구하고 전반적으로 백업을 유지하기 위해 권장 할 수는 없습니다. 특히 백업 시스템은 광범위하게 사용 가능하며 (또한 많은 오픈 소스) 데이터를 안전하게 유지하고 가능한 한 빨리 복구 할 수 있도록 훨씬 잘 작동합니다.

내 두 센트 : 나는 그것이 좋은 생각이라고 생각하지 않습니다. GIT는 "시간에 다른 지점에서 파일 집합의 저장 스냅 샷"와 같은 무언가를, 그래서 당신은 할 수 완벽하게 같은 뭔가를 GIT를 사용하지만, 그건 당신이 의미하지 않는다 해야한다 . GIT는 소스 코드를 저장하도록 설계 되었기 때문에 대부분의 기능이 빠져있을뿐 아니라 약간의 편의를 위해 많은 성능을 거래하게됩니다.

이것에 대해 생각하는 주된 이유는 "데이터와 코드의 사본을 동기화하여 유지하기"때문이며, 이는 코드의 버전 2.0과 버전 1.0과 다른 데이터베이스 스키마가 필요하다는 것을 걱정한다는 것을 의미합니다. . 더 간단한 해결책은 데이터베이스 스키마를 CREATEGit 저장소의 소스 코드 와 함께 명령문 이있는 SQL 스크립트 세트로 저장하는 것 입니다. 그런 다음 설치 절차 중 일부는 이전에 설치된 데이터베이스 서버에서 해당 스크립트를 실행하는 것입니다.

이러한 -d 테이블 의 실제 내용 은 CREATE소스 코드 버전과 관련이 없습니다. 다른 팀에서 서로 다른 회사에서 사용하는 서버 A와 서버 B에 소프트웨어 버전 1.0을 설치한다고 가정하십시오. 몇 주 후에는 스키마가 완전히 동일하더라도 테이블의 내용이 매우 다릅니다.

데이터베이스의 내용을 백업하고자하므로 덤프에 속하는 소프트웨어의 현재 버전으로 백업 덤프에 태그를 지정 하는 백업 스크립트를 사용하는 것이 좋습니다 . 스크립트는 소스 코드 버전 문자열에 액세스 할 수 있도록 GIT 저장소에 있어야하지만 덤프 자체는 버전 제어 시스템에 속하지 않습니다.

편집 :

질문에 동기를 부여한 원래 게시물을 읽은 후에 는 더 모호한 아이디어를 발견했습니다. 요점은 mysqldump명령이 DB의 현재 상태를 일련의 SQL INSERT문으로 변환하고 GIT가이를 업데이트하여 테이블 행만 가져올 수 있다는 것입니다.

mysqldump이 때문에 일부는 소리 백업 방법 중 하나 의 MySQL의 설명서에 적혀. GIT 부분은 저자가 데이터베이스 서버 가 MySQL을 포함한 충돌로부터 복구하기 위해 트랜잭션 로그 를 유지한다는 것을 알지 못하는 곳 입니다. 되는 이 로그를 사용 하면 데이터베이스에 대한 증분 백업을 생성해야한다고,하지 GIT를. 이것은 무엇보다도 GIT 리포지토리를 무한대 이상으로 늘리지 않고 복구 후 로그를 회전하거나 플러시 할 수 있다는 이점이 있습니다 ...

개인적으로, GIT 버전 제어는 바이너리 또는 MySQL 백업 덤프 파일과 같은 덤프 파일이 아닌 데이터 파일을 위해 설계 되었기 때문에 소스 제어 버전 시스템을 사용하여 백업 파일을 저장하는 것은 좋은 생각이 아닙니다. 그렇게 할 수 있다고해서 자동으로 해야 한다는 의미는 아닙니다 . 또한, 새로운 커밋마다 새로운 데이터베이스 백업을 고려한 리포지토리는 많은 하드 디스크 공간을 사용하여 크게 증가하고 GIT 성능에 영향을 미쳐 소스 제어 시스템이 느려집니다. 나에게 백업 전략을 실행하고 코드의 무언가가 잘못되었을 때 데이터베이스를 복원해야 할 때 항상 백업 파일을 준비하는 것이 좋습니다.하지만 소스 제어 도구는 바이너리 데이터를 저장하지 않습니다.

이러한 이유로 1 일과 2 일의 백업 파일을 저장 한 다음 두 백업 파일의 차이점을 확인할 수있는 유틸리티가 없습니다. 많은 여분의 쓸모없는 작업이 필요합니다. 새 코드를 커밋 할 때 GIT를 사용하여 데이터베이스 백업을 저장하는 대신 데이터베이스 백업을 다른 경로에 날짜 및 시간으로 구분하여 저장하고 태그를 사용하여 각 버전에 대해 생성 된 새 데이터베이스 백업에 대한 참조를 코드에 삽입하십시오. 누군가 이미 제안했듯이.

데이터베이스 백업 및 GIT에 대한 마지막 참고 사항: 데이터베이스 관리자는 일부 데이터가 손실되어 데이터베이스를 복원해야 할 때 1 일 백업 파일과 2 일 백업 파일의 차이점을 확인할 필요가 없습니다. 오류 및 데이터 손실없이 데이터베이스를 복원하여 가동 중지 시간을 줄일 수있는 마지막 백업 파일. 실제로 데이터베이스 관리자의 임무는 시스템이 어떤 이유로 장애가 발생할 경우 가능한 빨리 데이터를 복구 할 수 있도록하는 것입니다. 커밋에 연결된 GIT에 데이터베이스 백업을 저장하면 백업이 GIT 리포지토리에 저장된 특정 시점으로 제한되어 다운 타임을 줄이기 때문에 데이터베이스 관리자가 데이터를 빠르게 복원 할 수 없습니다. 시스템의

그럼, 대신 좋은 백업 소프트웨어 솔루션을 사용, GIT를 사용하여 백업을 저장하지 않는 것이 좋습니다 (거기에 그들 중 일부는 여기에 더 세분화를 제공하고 안전하고, 당신을 데이터를 보존 할 수 있도록하는) 재난 발생시 간단하고 빠른 데이터 복구.

바이너리 데이터베이스, 특히 데이터베이스에 바이너리 데이터를 저장해서는 안됩니다.
코드 변경과 데이터베이스 DML 변경은 완전히 다릅니다.

MySQL과 Oracle은 특정 시점으로 복원 할 목적으로 아카이브 로그를 작성할 수 있습니다. 해당 로그를 안전한 곳에 백업하면 괜찮을 것입니다.

Git을 사용하여 이러한 "아카이브 로그"를 백업하는 것은 의미가 없습니다. 프로덕션 환경의 아카이브 로그는 다소 무거 우므로 정기적으로 전체 백업을 수행 한 후에 제거해야합니다. 또한 자식을 git에 넣는 것은 쓸모가 없습니다-그것들은 이미 어떤 의미에서 저장소입니다.