Apakah mencadangkan database MySQL di Git adalah ide yang bagus?

Saya mencoba memperbaiki situasi cadangan untuk aplikasi saya. Saya memiliki aplikasi Django dan database MySQL. Saya membaca sebuah artikel yang menyarankan membuat cadangan database di Git.

Di satu sisi saya suka, karena akan menyimpan salinan data dan kode dalam sinkronisasi.

Tapi Git dirancang untuk kode, bukan untuk data. Dengan demikian akan melakukan banyak pekerjaan tambahan untuk membedakan setiap dump MySQL, yang sebenarnya tidak perlu. Jika saya mengkompres file sebelum menyimpannya, apakah git masih akan membuat file berbeda?

(File dump saat ini 100MB tidak terkompresi, 5,7MB saat di-bzip.)

Sunting: definisi skema dan basis data skema sudah ada di Git, ini benar-benar data yang saya khawatirkan untuk mencadangkan sekarang.

Sebelum Anda kehilangan data apa pun, izinkan saya mencoba memperkenalkan perspektif sysadmin untuk pertanyaan ini.

Hanya ada satu alasan kami membuat cadangan: untuk memungkinkan pengembalian ketika terjadi kesalahan, seperti yang selalu terjadi . Dengan demikian, sistem cadangan yang tepat memiliki persyaratan yang jauh melampaui apa yang bisa ditangani oleh git secara wajar.

Berikut adalah beberapa masalah yang dapat saya ramalkan dengan mencoba membuat cadangan database Anda di git:

• Repositori akan tumbuh secara dramatis dengan setiap "cadangan". Karena git menyimpan seluruh objek (walaupun dikompresi) dan kemudian membedanya nanti (misalnya ketika Anda menjalankan git gc) , dan menyimpan sejarah selamanya , Anda akan memiliki sejumlah besar data yang disimpan yang sebenarnya tidak Anda butuhkan atau bahkan inginkan. Anda mungkin perlu membatasi jumlah atau periode penyimpanan cadangan yang Anda lakukan untuk menghemat ruang disk atau karena alasan hukum, tetapi sulit untuk menghapus revisi lama dari repo git tanpa banyak kerusakan jaminan.
• Pemulihan terbatas pada titik waktu yang Anda simpan di repositori, dan karena datanya sangat besar, kembali lebih dari jumlah waktu yang sepele mungkin lambat. Sistem cadangan yang dirancang untuk tujuan membatasi jumlah data yang disimpan sekaligus berpotensi memberikan rincian lebih besar, dan memberikan pemulihan lebih cepat, mengurangi waktu henti jika terjadi bencana. Solusi pencadangan sadar-database ( contoh ) juga dapat menyediakan pencadangan berkelanjutan , memastikan tidak ada satu transaksi pun yang hilang.
• Komit juga cenderung lambat, dan semakin lambat seiring bertambahnya basis data. Ingat bahwa git pada dasarnya adalah penyimpanan data bernilai-kunci yang dipetakan ke sistem file , dan karenanya tunduk pada karakteristik kinerja sistem file yang mendasarinya. Dimungkinkan untuk jangka waktu ini untuk akhirnya melebihi interval cadangan, dan pada saat itu Anda tidak lagi dapat memenuhi SLA Anda. Sistem pencadangan yang tepat juga membutuhkan waktu lebih lama untuk pencadangan saat data tumbuh, tetapi tidak secara dramatis, karena mereka akan secara otomatis mengelola ukurannya sendiri berdasarkan kebijakan penyimpanan yang akan Anda konfigurasi.

Terlepas dari kenyataan bahwa ternyata ada beberapa hal menarik yang dapat Anda lakukan dengan dump basis data jika Anda memasukkannya ke git, secara keseluruhan saya tidak dapat merekomendasikannya untuk tujuan menyimpan cadangan. Terutama karena sistem cadangan tersedia secara luas (dan banyak yang bahkan open source) dan bekerja jauh lebih baik dalam menjaga data Anda aman dan memungkinkan untuk pulih secepat mungkin.

Dua sen saya: Saya pikir itu bukan ide yang baik. GIT melakukan sesuatu seperti "menyimpan snapshot dari set file pada waktu yang berbeda", sehingga Anda dapat menggunakan GIT dengan sempurna untuk hal seperti itu, tetapi itu tidak berarti Anda harus melakukannya . GIT dirancang untuk menyimpan kode sumber, sehingga Anda akan kehilangan sebagian besar fungsinya, dan Anda akan memperdagangkan banyak kinerja hanya dengan sedikit kenyamanan.

Biarkan saya berasumsi bahwa alasan utama mengapa Anda berpikir tentang ini adalah untuk "menyimpan salinan data dan kode dalam sinkronisasi", dan bahwa ini berarti Anda khawatir bahwa versi 2.0 dari kode Anda memerlukan skema basis data yang berbeda dari versi 1.0 . Solusi yang lebih sederhana adalah dengan menyimpan skema database, sebagai satu set skrip SQL dengan CREATEpernyataan, di sepanjang kode sumber di repositori Git Anda. Kemudian, bagian dari prosedur instalasi Anda adalah untuk mengeksekusi skrip-skrip itu pada server database yang diinstal sebelumnya.

Isi sebenarnya dari CREATEtabel -d itu tidak ada hubungannya dengan versi kode sumber Anda. Bayangkan Anda menginstal perangkat lunak Anda, versi 1.0, di server A dan di server B, yang digunakan di berbagai perusahaan oleh tim yang berbeda. Setelah beberapa minggu, isi tabel akan sangat berbeda, meskipun skema persis sama.

Karena Anda ingin mencadangkan konten database, saya sarankan kepada Anda agar Anda menggunakan skrip cadangan yang menandai dump cadangan dengan versi perangkat lunak saat ini yang dimiliki oleh dump tersebut. Script harus dalam repositori GIT (sehingga memiliki akses ke string versi kode sumber), tetapi kesedihan itu sendiri tidak termasuk dalam sistem kontrol versi.

EDIT :

Setelah membaca posting asli yang memotivasi pertanyaan , saya menemukan ini ide yang lebih meragukan. Poin kuncinya adalah bahwa mysqldumpperintah mengubah keadaan saat ini dari DB menjadi serangkaian INSERTpernyataan SQL , dan GIT dapat mengubah mereka untuk mendapatkan hanya baris tabel yang diperbarui.

Bagian mysqldumpini masuk akal, karena ini adalah salah satu metode cadangan yang tercantum dalam dokumentasi MySQL. Bagian GIT adalah tempat penulis gagal memperhatikan bahwa server basis data menyimpan log transaksi untuk pulih dari kerusakan, termasuk MySQL . Hal ini menggunakan log ini , tidak GIT, bahwa Anda harus membuat backup inkremental untuk database Anda. Ini memiliki, pertama dan terpenting, keuntungan bahwa Anda dapat memutar atau menyiram log setelah pemulihan, alih-alih membengkak repositori GIT hingga tak terbatas dan di luar ...

Secara pribadi, saya tidak berpikir itu ide yang baik untuk menggunakan sistem versi kontrol sumber untuk menyimpan file cadangan, karena kontrol versi GIT dirancang untuk file data, bukan untuk biner atau file dump seperti file dump cadangan MySQL. Fakta bahwa Anda dapat melakukannya bukan berarti secara otomatis Anda harus melakukannya. Selain itu, repositori Anda, mempertimbangkan cadangan basis data baru untuk setiap komit baru, akan tumbuh secara dramatis, menggunakan banyak ruang hard disk dan kinerja GIT akan terpengaruh, yang mengakibatkan sistem kontrol sumber lambat. Bagi saya tidak apa-apa untuk menjalankan strategi cadangan dan selalu menyiapkan file cadangan ketika Anda perlu mengembalikan database ketika ada sesuatu dalam kode Anda yang salah, tetapi alat kontrol sumber tidak dibuat untuk menyimpan data biner.

Untuk alasan ini, saya tidak melihat utilitas apa pun dalam menyimpan file cadangan untuk hari 1 dan untuk hari 2, dan kemudian melihat perbedaan antara dua file cadangan. Ini akan membutuhkan banyak pekerjaan ekstra dan tidak berguna. Alih-alih menggunakan GIT untuk menyimpan cadangan basis data saat Anda melakukan kode baru, simpan cadangan basis data di jalur yang berbeda, dipisahkan oleh tanggal dan waktu, dan masukkan kode Anda beberapa referensi ke cadangan basis data baru yang dibuat untuk setiap versi, menggunakan tag, sebagai seseorang yang sudah disarankan.

Catatan terakhir saya tentang backup database dan GIT: Seorang administrator database, ketika dia perlu mengembalikan database karena beberapa data telah hilang, tidak perlu memeriksa perbedaan antara file cadangan untuk hari 1 dan file cadangan untuk hari 2, dia hanya perlu tahu mana yang merupakan file cadangan terakhir yang akan memungkinkannya untuk memulihkan database, tanpa kesalahan dan kehilangan data, mengurangi waktu henti. Memang, tugas administrator database adalah membuat data tersedia untuk pemulihan sesegera mungkin, ketika sistem, karena alasan tertentu, gagal. Jika Anda menyimpan cadangan basis data di GIT, yang ditautkan dengan komit Anda, Anda tidak mengizinkan administrator basis data untuk memulihkan data dengan cepat, karena cadangan Anda terbatas pada titik waktu Anda disimpan dalam repositori GIT, dan untuk mengurangi waktu henti. dari sistem,

Kemudian, saya tidak merekomendasikan untuk menyimpan cadangan menggunakan GIT, sebagai gantinya gunakan solusi perangkat lunak cadangan yang baik (ada beberapa di sini ), yang akan memberikan lebih banyak rincian dan akan memungkinkan Anda untuk menjaga data Anda aman dan aman, dan membuat Anda pemulihan data sederhana dan cepat jika terjadi bencana.

Anda seharusnya tidak menyimpan data biner di Git - terutama basis data.
Perubahan kode dan perubahan DML basis data adalah hal yang sangat berbeda.

MySQL dan Oracle dapat menulis log arsip untuk tujuan dipulihkan ke titik waktu mana pun. Hanya cadangan log tersebut ke tempat yang aman dan Anda akan baik-baik saja.

Untuk menggunakan Git untuk mencadangkan "arsip log" ini tidak masuk akal. Log arsip di lingkungan produksi agak berat dan harus dihapus setelah melakukan pencadangan penuh secara teratur. Juga tidak ada gunanya untuk menempatkan mereka di git - mereka sudah menjadi repositori dalam arti tertentu.