Git'teki bir MySQL veritabanını yedeklemek iyi bir fikir midir?

Uygulamam için yedekleme durumunu iyileştirmeye çalışıyorum. Bir Django uygulaması ve MySQL veritabanı var. Git'teki veritabanını yedeklemeyi öneren bir makale okudum.

Bir yandan, verilerin ve kodun bir kopyasını senkronize halde tutacağından hoşuma gitti.

Ancak Git, veriler için değil, kod için tasarlanmıştır. Bu nedenle, MySQL'in dökümü her işlemden farklı kılan ekstra bir iş yapacak, bu da gerçekten gerekli değildir. Saklamadan önce dosyayı sıkıştırırsam, git hala dosyaları farklılaştıracak mı?

(Dökümü dosyası şu anda 100 MB sıkıştırılmamış, bzip edildiğinde 5,7 MB.)

Düzenleme: kod ve veritabanı şeması tanımları Git'te zaten var, bu gerçekten şimdi yedeklemekten endişe duyduğum veri.

Herhangi bir veriyi kaybetmeden önce, bu soruya bir sysadmin bakış açısı sunmaya çalışmama izin verin.

Yedekler oluşturmamızın tek bir nedeni var: bir şeyler ters gittiğinde geri yüklemeyi mümkün kılmak, her zaman olduğu gibi . Bu nedenle, uygun bir yedekleme sistemi, git'in makul olarak üstesinden gelebileceklerin ötesine geçen gereksinimlere sahiptir .

Veritabanınızı git halindeyken yedeklemeye çalışırken öngörebileceğim bazı sorunlar:

• Depo her "yedeklemede" önemli ölçüde büyüyecek. Yana git depolar tüm nesneler sonra (sıkıştırılmış olsa) ve (örneğin çalıştırdığınızda bunları daha sonra fark dosyaları git gc) ve geçmişini tutar sonsuza , size aslında yaramayan hatta istediğiniz depolanan verilerin çok büyük miktarda olacaktır. Disk alanından tasarruf etmek için ya da yasal nedenlerden ötürü yaptığınız yedekleme miktarını ya da saklama süresini sınırlamanız gerekebilir, ancak eski düzeltmeleri çok fazla teminat hasarı olmadan bir git deposundan kaldırmak zordur .
• Geri yükleme, depoda sakladığınız zamanla sınırlıdır ve veriler çok büyük olduğu için, önemsiz bir zamandan daha fazla geriye gitmek yavaş olabilir. Amaç için tasarlanan yedekleme sistemi, potansiyel olarak daha fazla ayrıntı düzeyi sağlarken depolanan veri miktarını sınırlar ve daha hızlı geri yükleme sağlar ve bir felaket durumunda çalışmama süresini azaltır. Veritabanına duyarlı yedekleme çözümleri ( örnek ) aynı zamanda tek bir işlemin kaybolmamasını sağlayarak sürekli yedekleme sağlayabilir .
• Taahhütlerin de yavaş olması ve veritabanı büyüdükçe yavaşlaması muhtemel. Git'in esas olarak bir dosya sistemine eşlenmiş bir anahtar-değer veri deposudur ve bu nedenle temel dosya sisteminin performans özelliklerine tabi olduğunu unutmayın. Bu sürenin sonunda yedekleme aralığını aşması mümkündür ve bu noktada SLA'nızla artık görüşemezsiniz. Doğru yedekleme sistemleri de veriler büyüdükçe yedekleme işleminin daha uzun sürmesini sağlar, ancak neredeyse hiç dramatik değildir, çünkü yapılandırmış olacağınız saklama politikasına dayanarak kendi boyutlarını otomatik olarak yönetirler.

Bir veritabanı dökümü ile yapabileceğiniz bazı ilginç şeyler olduğu gerçeğine rağmen, gitmiş olursanız, genel olarak yedekleri saklamak için tavsiye edemem. Özellikle yedekleme sistemleri yaygın olarak kullanılabildiğinden (ve çoğu açık kaynak kodlu olduğundan) ve verilerinizi güvende tutmak ve olabildiğince çabuk kurtarmayı mümkün kılmak için çok daha iyi çalışır.

İki sentim: Bunun iyi bir fikir olduğunu sanmıyorum. GYTE "zaman içinde farklı noktalarda dosyaları bir dizi depolama enstantane" gibi bir şey yok, bu yüzden olabilir mükemmel böyle bir şey için GIT kullanmak, ama bu demek değildir gerekir . GIT, kaynak kodunu saklamak için tasarlanmıştır, bu nedenle işlevselliklerinin çoğunu kaçırırsınız ve kolaylık sağlamak için çok fazla işlem yaparsınız.

Bunu düşündüğünüzün ana nedeninin "verilerin ve kodun bir kopyasını senkronize tutmak" olduğunu ve bunun kodunuzun 2.0 sürümünün 1.0 sürümünden farklı bir veritabanı şeması gerektirmesinden korktuğunuz anlamına geldiğini varsayalım. . Daha basit bir çözüm, veritabanı şemasını, CREATEifadeler içeren bir SQL komut dosyası kümesi olarak Git deponuzdaki kaynak kod boyunca saklamak olacaktır . Ardından, kurulum prosedürünüzün bir kısmı bu komut dosyalarını önceden kurulmuş bir veritabanı sunucusunda çalıştırmak olacaktır.

Just -d tablolarının asıl içeriğininCREATE kaynak kodunuzun sürümüyle ilgisi yoktur. Yazılımınızı, sürüm 1.0'ı, sunuculara ve farklı şirketler tarafından farklı ekiplerce kullanılan B sunucusuna yüklediğinizi düşünün. Birkaç hafta sonra, şemalar tamamen aynı olsa bile, tabloların içerikleri çok farklı olacaktır.

Veritabanının içeriğini yedeklemek istediğiniz için, size , yedekleme dökümünü, dökümü ait olduğu yazılımın güncel sürümüyle etiketleyen bir yedekleme betiği kullanmanızı öneririm . Komut dosyası GIT deposunda olmalıdır (kaynak kod sürüm dizgisine erişebilsin), ancak dökümlerin kendisi bir sürüm kontrol sistemine ait değildir.

EDIT :

Soruyu motive eden orijinal yazıyı okuduktan sonra , bunu daha da şüpheli bir fikir olarak görüyorum. Kilit nokta, mysqldumpkomutun bir DB'nin mevcut durumunu bir dizi SQL INSERTdeyimine dönüştürmesidir ve GIT bunları yalnızca güncel tablo satırlarını almak için dağıtabilir.

Bu mysqldumpbölüm sağlam, çünkü bu MySQL'in belgelerinde listelenen yedekleme yöntemlerinden biri . GIT kısmı, yazarın , MySQL de dahil olmak üzere çökmelerden kurtulmak için veritabanı sunucularının işlem günlüğü tuttuğunu fark edemediği yerdir . O olduğu bu günlüğünü kullanarak size veritabanı için artımlı yedeklemeler oluşturması gerektiğini, değil GIT. Bu, her şeyden önce, GIT deposunu sonsuzluğa ve ötesine şişirmek yerine, kurtarma işleminden sonra günlükleri döndürebilir veya temizleyebilme avantajına sahiptir ...

Şahsen, yedek dosyaları depolamak için bir kaynak kontrol sürüm sistemi kullanmanın iyi bir fikir olduğunu sanmıyorum, çünkü GIT sürüm kontrolü, veri dosyaları için değil, ikili dosyalar veya bir MySQL yedek döküm dosyası gibi döküm dosyaları için tasarlanmamıştır. Eğer gerçeği olabilir bunu size otomatik olarak gelmez gerektiğini bunu. Dahası, her yeni işlem için yeni bir veritabanı yedeği göz önüne alındığında, deponuz çarpıcı bir şekilde büyüyecek, çok fazla sabit disk alanı kullanacak ve GIT'in performansı etkilenerek yavaş bir kaynak kontrol sistemi ortaya çıkacaktır. Benim için bir yedekleme stratejisi uygulamak ve kodunuzda bir şeyler ters gittiğinde veritabanını geri yüklemeniz gerektiğinde her zaman bir yedekleme dosyası hazır, ancak kaynak kontrol araçları ikili verileri depolamak için yapılmaz.

Bu nedenlerden dolayı, yedekleme dosyalarının 1. gün ve 2. gün için depolanmasında ve ardından iki yedek dosya arasındaki farkları görmede hiçbir yardımcı program göremiyorum. Çok fazladan ve işe yaramaz bir iş gerektirecek. Yeni kod işlerken veritabanı yedeklemelerini depolamak için GIT kullanmak yerine, veritabanı yedeklemelerini tarih ve saate göre ayrılmış ve farklı bir yolda saklayın ve kodunuza etiketleri kullanarak her sürüm için oluşturulan yeni veritabanı yedeklemelerine bazı referanslar ekleyin, Birinin önerdiği gibi.

Veritabanı yedeklemeleri ve GIT hakkındaki son notum: Bir veritabanı yöneticisi, bazı veriler kaybolduğu için bir veritabanını geri yüklemesi gerektiğinde, 1. gün için yedekleme dosyası ile 2. gün için yedekleme dosyası arasındaki farkları kontrol etmesine gerek duymaz, sadece ne olduğunu bilmesi gerekir. Veritabanını herhangi bir hata ve veri kaybı yaşamadan geri yükleyebilecek son arıza dosyası, duruş süresini azaltır. Aslında, bir veritabanı yöneticisinin görevi, sistemin bazı nedenlerden dolayı başarısız olduğu durumlarda en kısa sürede verilerin kurtarılması için kullanılabilir hale getirilmesidir. Veritabanı yedeklemelerini taahhütlerinize bağlı olarak GIT’de saklarsanız, veritabanı yöneticisinin verileri hızlı bir şekilde geri yüklemesine izin vermezsiniz, çünkü yedeklemeleriniz GIT deposunda sakladığınız zamanlarla sınırlıdır ve hizmet dışı kalma süresini azaltır sistemin,

Sonra onun yerine iyi bir yedekleme yazılımı çözüm kullanmak, GIT kullanarak yedeklerini depolamak önermiyoruz (orada bazıları burada daha ayrıntılı bilgiler sağlayacak ve güvenli ve gözünü yapma verilerinizi korumak sağlayacak), veri kurtarma felaket durumunda basit ve hızlı.

İkili verileri Git'te saklamamalısınız - özellikle veritabanı.
Kod değişiklikleri ve veritabanı DML değişiklikleri tamamen farklı şeylerdir.

MySQL ve Oracle, zamanın herhangi bir noktasına geri yüklenmek amacıyla arşiv günlükleri yazabilir. Sadece bu günlükleri güvenli bir yere yedekle, sorun olmaz.

Git'in bu "arşiv kayıtlarını" yedeklemek için kullanması bir anlam ifade etmiyor. Üretim ortamlarındaki arşiv günlükleri oldukça ağırdır ve düzenli olarak tam yedeklemeler yapıldıktan sonra çıkarılmalıdır. Ayrıca onları gitmeye koymak da işe yaramaz - bunlar zaten bir anlamda bir depo.