Là sao lưu cơ sở dữ liệu MySQL trong Git là một ý tưởng tốt?

Tôi đang cố gắng cải thiện tình hình sao lưu cho ứng dụng của mình. Tôi có một ứng dụng Django và cơ sở dữ liệu MySQL. Tôi đọc một bài viết đề nghị sao lưu cơ sở dữ liệu trong Git.

Một mặt tôi thích nó, vì nó sẽ giữ một bản sao của dữ liệu và mã đồng bộ.

Nhưng Git được thiết kế cho mã, không phải cho dữ liệu. Vì vậy, nó sẽ thực hiện rất nhiều công việc bổ sung khác với kết xuất MySQL mỗi cam kết, điều này không thực sự cần thiết. Nếu tôi nén tệp trước khi lưu trữ, git vẫn khác các tệp chứ?

(Tệp kết xuất hiện không được nén 100 MB, 5,7 MB khi được giải nén.)

Chỉnh sửa: các định nghĩa lược đồ mã và cơ sở dữ liệu đã có trong Git, đây thực sự là dữ liệu tôi quan tâm về việc sao lưu.

Trước khi bạn mất bất kỳ dữ liệu nào, hãy để tôi thử giới thiệu một viễn cảnh sysadmin cho câu hỏi này.

Chỉ có một lý do để chúng tôi tạo bản sao lưu: để có thể khôi phục khi có sự cố, vì nó luôn luôn như vậy . Như vậy, một hệ thống sao lưu thích hợp có các yêu cầu vượt xa những gì git có thể xử lý một cách hợp lý.

Dưới đây là một số vấn đề tôi có thể thấy trước khi cố gắng sao lưu cơ sở dữ liệu của mình trong git:

• Các kho lưu trữ sẽ phát triển đáng kể với mỗi "bản sao lưu". Vì git lưu trữ toàn bộ các đối tượng (mặc dù đã được nén) và sau đó làm khác chúng sau này (ví dụ như khi bạn chạy git gc) và lưu giữ lịch sử mãi mãi , bạn sẽ có một lượng dữ liệu rất lớn được lưu trữ mà bạn không thực sự cần hoặc thậm chí muốn. Bạn có thể cần phải giới hạn số lượng hoặc thời gian lưu của các bản sao lưu bạn làm để tiết kiệm dung lượng ổ đĩa hoặc vì lý do pháp lý, nhưng rất khó để xóa các bản sửa đổi cũ khỏi repo git mà không có nhiều thiệt hại về tài sản thế chấp.
• Việc khôi phục bị giới hạn ở các điểm mà bạn đã lưu trữ trong kho lưu trữ và vì dữ liệu quá lớn, việc quay lại nhiều hơn một lượng thời gian không đáng kể có thể bị chậm. Một hệ thống dự phòng được thiết kế cho mục đích giới hạn lượng dữ liệu được lưu trữ trong khi có khả năng cung cấp mức độ chi tiết cao hơn và cung cấp khả năng khôi phục nhanh hơn, giảm thời gian chết trong trường hợp xảy ra thảm họa. Các giải pháp sao lưu nhận biết cơ sở dữ liệu ( ví dụ ) cũng có thể cung cấp sao lưu liên tục , đảm bảo rằng không có một giao dịch nào bị mất.
• Các cam kết có khả năng cũng chậm và chậm hơn khi cơ sở dữ liệu phát triển. Hãy nhớ rằng git về cơ bản là một kho lưu trữ dữ liệu khóa-giá trị được ánh xạ vào một hệ thống tệp và do đó phải tuân theo các đặc tính hiệu suất của hệ thống tệp cơ bản. Khoảng thời gian này cuối cùng có thể vượt quá khoảng thời gian sao lưu và tại thời điểm đó, bạn không còn có thể đáp ứng SLA của mình nữa. Các hệ thống sao lưu phù hợp cũng mất nhiều thời gian hơn để sao lưu khi dữ liệu phát triển, nhưng gần như không đáng kể, vì chúng sẽ tự động quản lý kích thước của chúng dựa trên chính sách lưu giữ mà bạn sẽ định cấu hình.

Mặc dù thực tế rõ ràng có một số điều thú vị bạn có thể làm với kết xuất cơ sở dữ liệu nếu bạn đặt nó vào git, nhưng tổng thể tôi không thể đề xuất nó cho mục đích giữ bản sao lưu. Đặc biệt là vì các hệ thống sao lưu có sẵn rộng rãi (và nhiều thậm chí là nguồn mở) và hoạt động tốt hơn nhiều trong việc giữ an toàn cho dữ liệu của bạn và giúp có thể khôi phục nhanh nhất có thể.

Hai xu của tôi: Tôi không nghĩ đó là một ý tưởng tốt. GIT thực hiện một số việc như "lưu trữ ảnh chụp nhanh của một tập hợp các tệp tại các thời điểm khác nhau", vì vậy bạn hoàn toàn có thể sử dụng GIT cho những thứ tương tự, nhưng điều đó không có nghĩa là bạn nên làm . GIT được thiết kế để lưu trữ mã nguồn, do đó bạn sẽ thiếu hầu hết các chức năng của nó và bạn sẽ giao dịch rất nhiều hiệu suất chỉ với một chút thuận tiện.

Hãy để tôi giả sử rằng lý do chính khiến bạn nghĩ về điều này là "giữ một bản sao dữ liệu và mã đồng bộ" và điều này có nghĩa là bạn lo lắng rằng phiên bản 2.0 của mã của bạn cần một lược đồ cơ sở dữ liệu khác với phiên bản 1.0 . Một giải pháp đơn giản hơn là lưu trữ lược đồ cơ sở dữ liệu, dưới dạng một tập lệnh SQL với các CREATEcâu lệnh, dọc theo mã nguồn trong kho Git của bạn. Sau đó, một phần của quy trình cài đặt của bạn sẽ là thực thi các tập lệnh đó trên máy chủ cơ sở dữ liệu đã cài đặt trước đó.

Nội dung thực tế của các CREATEbảng chỉ -d đó không liên quan gì đến phiên bản mã nguồn của bạn. Hãy tưởng tượng bạn cài đặt phần mềm, phiên bản 1.0, trên máy chủ A và trên máy chủ B, được sử dụng trong các công ty khác nhau bởi các nhóm khác nhau. Sau một vài tuần, nội dung của các bảng sẽ rất khác nhau, mặc dù các lược đồ hoàn toàn giống nhau.

Vì bạn muốn sao lưu nội dung của cơ sở dữ liệu, tôi sẽ đề nghị với bạn rằng bạn nên sử dụng tập lệnh sao lưu gắn thẻ kết xuất dự phòng với phiên bản hiện tại của phần mềm mà kết xuất đó thuộc về. Tập lệnh phải nằm trong kho GIT (để nó có quyền truy cập vào chuỗi phiên bản mã nguồn), nhưng bản thân các bản ghi không thuộc hệ thống kiểm soát phiên bản.

CHỈNH SỬA :

Sau khi đọc bài viết gốc thúc đẩy câu hỏi , tôi thấy đây là một ý tưởng thậm chí còn đáng ngờ hơn. Điểm mấu chốt là mysqldumplệnh biến đổi trạng thái hiện tại của DB thành một chuỗi các câu lệnh SQL INSERTvà GIT có thể khác chúng để chỉ nhận các hàng của bảng được cập nhật.

Phần mysqldumpnày là âm thanh, vì đây là một trong những phương thức sao lưu được liệt kê trong tài liệu của MySQL. Phần GIT là nơi tác giả không nhận thấy rằng các máy chủ cơ sở dữ liệu giữ nhật ký giao dịch để phục hồi sau sự cố, bao gồm cả MySQL . Nó đang sử dụng nhật ký này , không phải GIT, mà bạn nên tạo bản sao lưu gia tăng cho cơ sở dữ liệu của mình. Điều này trước tiên và quan trọng nhất, đó là lợi thế mà bạn có thể xoay hoặc xóa các bản ghi sau khi khôi phục, thay vì làm đầy kho lưu trữ GIT thành vô tận và hơn thế nữa ...

Cá nhân, tôi không nghĩ nên sử dụng hệ thống phiên bản kiểm soát nguồn để lưu trữ các tệp sao lưu, bởi vì kiểm soát phiên bản GIT được thiết kế cho các tệp dữ liệu, không phải cho các tệp nhị phân hoặc tệp kết xuất như tệp kết xuất sao lưu MySQL. Thực tế là bạn có thể làm điều đó không có nghĩa là tự động mà bạn nên làm điều đó. Hơn nữa, kho lưu trữ của bạn, xem xét sao lưu cơ sở dữ liệu mới cho mỗi lần xác nhận mới, sẽ tăng lên đáng kể, sử dụng nhiều dung lượng ổ cứng và hiệu suất của GIT sẽ bị ảnh hưởng, dẫn đến hệ thống kiểm soát nguồn chậm. Đối với tôi, thật tốt khi thực hiện chiến lược sao lưu và luôn sẵn sàng tệp sao lưu khi bạn cần khôi phục cơ sở dữ liệu khi có lỗi trong mã của bạn, nhưng các công cụ kiểm soát nguồn không được thực hiện để lưu trữ dữ liệu nhị phân.

Vì những lý do này, tôi không thấy bất kỳ tiện ích nào trong việc lưu trữ các tệp sao lưu cho ngày 1 và ngày 2, và sau đó thấy sự khác biệt giữa hai tệp sao lưu. Nó sẽ đòi hỏi rất nhiều công việc phụ và vô ích. Thay vì sử dụng GIT để lưu trữ các bản sao lưu cơ sở dữ liệu khi bạn cam kết mã mới, hãy lưu trữ các bản sao lưu cơ sở dữ liệu theo một đường dẫn khác, được phân tách theo ngày và thời gian và chèn vào mã của bạn một số tham chiếu đến các bản sao lưu cơ sở dữ liệu mới được tạo cho mỗi phiên bản, sử dụng các thẻ, như ai đó đã đề nghị.

Lưu ý cuối cùng của tôi về sao lưu cơ sở dữ liệu và GIT: Quản trị viên cơ sở dữ liệu, khi anh ta cần khôi phục cơ sở dữ liệu vì một số dữ liệu đã bị mất, không cần kiểm tra sự khác biệt giữa tệp sao lưu cho ngày 1 và tệp sao lưu cho ngày 2, anh ta chỉ cần biết đó là gì tập tin sao lưu cuối cùng sẽ cho phép anh ta khôi phục cơ sở dữ liệu, không có bất kỳ lỗi và mất dữ liệu, giảm thời gian chết. Thật vậy, nhiệm vụ của một quản trị viên cơ sở dữ liệu là làm cho dữ liệu có sẵn để phục hồi càng sớm càng tốt, khi hệ thống, vì một số lý do, không thành công. Nếu bạn lưu trữ các bản sao lưu cơ sở dữ liệu trong GIT, được liên kết với các cam kết của bạn, bạn không cho phép người quản trị cơ sở dữ liệu khôi phục dữ liệu một cách nhanh chóng, vì các bản sao lưu của bạn bị giới hạn tại các điểm mà bạn đã lưu trữ trong kho GIT và để giảm thời gian chết của hệ thống,

Sau đó, tôi không khuyên bạn nên lưu trữ các bản sao lưu bằng GIT, thay vào đó sử dụng một giải pháp phần mềm sao lưu tốt (có một số trong số chúng ở đây ), sẽ cung cấp mức độ chi tiết hơn và sẽ cho phép bạn giữ an toàn và bảo mật dữ liệu của mình và làm cho phục hồi dữ liệu đơn giản và nhanh chóng trong trường hợp thảm họa.

Bạn không nên lưu trữ dữ liệu nhị phân trong Git - đặc biệt là cơ sở dữ liệu.
Thay đổi mã và thay đổi DML cơ sở dữ liệu là những thứ hoàn toàn khác nhau.

MySQL và Oracle có thể viết nhật ký lưu trữ cho mục đích được khôi phục đến bất kỳ thời điểm nào. Chỉ cần sao lưu những bản ghi đó đến một nơi an toàn và bạn sẽ ổn thôi.

Để sử dụng Git để sao lưu các "nhật ký lưu trữ" này không có ý nghĩa. Nhật ký lưu trữ trong môi trường sản xuất khá nặng và nên được gỡ bỏ sau khi sao lưu toàn bộ thường xuyên. Ngoài ra, thật vô ích khi đặt chúng trong git - chúng đã là một kho lưu trữ theo một nghĩa nào đó.