MySQLデータベースをGitでバックアップすることは良い考えですか？
アプリケーションのバックアップ状況を改善しようとしています。 DjangoアプリケーションとMySQLデータベースがあります。Gitでデータベースをバックアップすることを提案する記事を読みました。
データとコードの同期を保つので、一方で気に入っています。
しかし、Gitはデータ用ではなくコード用に設計されています。そのため、MySQLダンプをコミットごとに比較する多くの追加作業が行われますが、これは実際には必要ありません。保存する前にファイルを圧縮した場合でも、gitはファイルを比較できますか？
（現在、ダンプファイルは非圧縮で100MB、bzip圧縮した場合は5.7MBです。）
編集：コードとデータベーススキーマの定義は既にGitにあります。これは、私が現在バックアップすることについて心配しているデータです。
データを失う前に、この質問に対するシステム管理者の視点を紹介します。
バックアップを作成する理由は1つだけです。常にのように、問題が発生したときに復元できるようにするためです。そのため、 適切なバックアップシステムには要件があります gitが合理的に処理できる範囲をはるかに超えています。
以下は、gitでデータベースをバックアップしようとするときに予測できる問題の一部です。
- リポジトリは、すべての「バックアップ」で劇的に増加します。 gitはオブジェクト全体を格納します （圧縮されていますが）、その後 それらを後で差分します（例：
git gc） 、そして履歴を保存します永久に、実際には必要ない、または必要としない非常に大量のデータが保存されます。ディスク容量を節約するため、または法的な理由で、バックアップの量または保持期間を制限する必要があるかもしれませんが、 removeすることは困難ですgit repoからの古いリビジョン 多くの付随的な損傷なし。 - 復元は、リポジトリに保存した特定の時点に限定されます。データが非常に大きいため、ささいな時間よりも前に戻るのに時間がかかる場合があります。目的に合わせて設計されたバックアップシステムは、格納できるデータの量を制限しながら、粒度を高め、より迅速な復元を提供し、災害発生時のダウンタイムを短縮します。データベース対応のバックアップソリューション（ 例 ）は、連続バックアップも提供し、単一のトランザクションが失われないようにします。
- コミットも遅くなる可能性が高く、データベースが大きくなるにつれて遅くなります。 gitは本質的に ファイルシステムにマップされたキーと値のデータストア であるため、基礎となるファイルシステムのパフォーマンス特性の影響を受けることに注意してください。この期間が最終的にバックアップ間隔を超える可能性があり、その時点でSLAを満たすことができなくなります。また、適切なバックアップシステムは、データが増加するにつれてバックアップに時間がかかりますが、設定した保持ポリシーに基づいて独自のサイズを自動的に管理するため、それほど劇的ではありません。
明らかにいくつかの 興味深いもの があるという事実にもかかわらず、それをgitに入れるとデータベースダンプで実行できますが、バックアップを維持する目的で全体的にお勧めすることはできません。特に バックアップシステムは広く利用可能です （そして多くはオープンソースです）であり、データを安全に保ち、可能な限り迅速に回復することを可能にすることではるかにうまく機能します。
私の2セント：それは良い考えではないと思います。 GITは「一連のファイルのスナップショットをさまざまな時点で保存する」などのことを行うので、あなたはcan GITをそのようなものに完全に使用しますが、それはあなたが意味するわけではありませんshould。 GITはソースコードを格納するように設計されているため、その機能のほとんどが失われ、多くのパフォーマンスを少しの便宜のためにトレードすることになります。
これについて考えている主な理由は「データとコードの同期を保つ」ことであり、これはコードのバージョン2.0がバージョン1.0とは異なるデータベーススキーマを必要とすることを心配していることを意味します。より簡単な解決策は、データベーススキーマを、Gitリポジトリのソースコードに沿って、CREATEステートメントを含むSQLスクリプトのセットとして保存することです。次に、インストール手順の一部として、以前にインストールしたデータベースサーバーでこれらのスクリプトを実行します。
CREATE- dテーブルだけの実際のcontentsは、ソースコードのバージョンとは関係ありません。ソフトウェア、バージョン1.0をサーバーAとサーバーBにインストールするとします。これらは、さまざまな会社でさまざまなチームによって使用されています。数週間後、スキーマがまったく同じであっても、テーブルの内容は大きく異なります。
データベースの内容をバックアップしたいので、tagsダンプが属するソフトウェアの現在のバージョンのバックアップダンプを使用するバックアップスクリプトを使用することをお勧めします。スクリプトはGITリポジトリにある必要があります（ソースコードのバージョン文字列にアクセスできるようにするため）が、ダンプ自体はバージョン管理システムに属していません。
[〜＃〜]編集[〜＃〜]：
質問の動機となった元の投稿 を読んだ後、これはさらに疑わしい考えだと思います。重要な点は、mysqldumpコマンドがDBの現在の状態を一連のSQL INSERTステートメントに変換し、GITがそれらを差分して、更新されたテーブル行のみを取得できることです。
MySQLのドキュメントに記載されている バックアップ方法の1つ であるため、mysqldumpの部分は適切です。 GITの部分は、クラッシュから回復するために、データベースサーバーが トランザクションログ を保持していることに著者が気付かないところです MySQLを含む 。データベースの増分バックアップを作成する必要があるのは このログを使用 であり、GITではありません。これには何よりもまず、GITリポジトリを無限大に膨らませるのではなく、回復後にログをローテーションまたはフラッシュできるという利点があります...
個人的には、ソース管理バージョンシステムを使用してバックアップファイルを保存することはお勧めしません。GITバージョン管理は、MySQLバックアップダンプファイルなどのバイナリやダンプファイル用ではなく、データファイル用に設計されているためです。あなたができることができるという事実は、自動的にすべきであるとは限りません。さらに、リポジトリは、新しいコミットごとに新しいデータベースのバックアップを考慮すると、大量のハードディスク領域を使用して劇的に増大し、GITのパフォーマンスが影響を受け、その結果、ソース管理システムが遅くなります。私にとって、バックアップ戦略を実行し、コードに問題が発生したときにデータベースを復元する必要がある場合は、常にバックアップファイルを準備しておくのは問題ありませんが、ソース管理ツールはバイナリデータを格納するように作られていません。
これらの理由により、1日目と2日目のバックアップファイルを保存して、2つのバックアップファイルの違いを確認するユーティリティはありません。多くの余分で無駄な作業が必要になります。新しいコードをコミットするときにGITを使用してデータベースバックアップを保存する代わりに、データベースバックアップを日付と時刻で区切られた別のパスに保存し、タグを使用して、各バージョンに対して作成された新しいデータベースバックアップへの参照をコードに挿入します。誰かがすでに提案したように。
データベースのバックアップとGITに関する私の最後の注意：一部のデータが失われたためにデータベースを復元する必要がある場合、データベース管理者は必要ありません。 1日目のバックアップファイルと2日目のバックアップファイルの違いを確認するには、エラーやデータの損失なしにデータベースを復元し、ダウンタイムを短縮できる最後のバックアップファイルを知る必要があります。実際、データベース管理者の仕事は、システムが何らかの理由で失敗した場合に、できるだけ早くデータをリカバリできるようにすることです。コミットにリンクされたGITにデータベースバックアップを保存する場合、バックアップはGITリポジトリに保存された特定の時点に限定され、ダウンタイムを削減するため、データベース管理者がデータをすばやく復元することはできません。 GITリポジトリのパフォーマンスが大幅に低下し、大量のデータを保存するためです。
次に、GITを使用してバックアップを保存することはお勧めしません。代わりに優れたバックアップソフトウェアソリューションを使用してください（一部の here があります）。これにより、より細かくなり、データを保持できます。安全で安全であり、災害発生時のデータ復旧をシンプルかつ迅速にします。
バイナリデータ、特にデータベースをGitに保存しないでください。
コードの変更とデータベースのDMLの変更はまったく異なります。
MySQLとOracleは、任意の時点に復元する目的でアーカイブログを書き込むことができます。これらのログを安全な場所にバックアップするだけで大丈夫です。
Gitを使用してこれらの「アーカイブログ」をバックアップすることは意味がありません。本番環境のアーカイブログはかなり重いため、定期的なフルバックアップを行った後で削除する必要があります。また、それらをgitに配置しても意味がありません。これらは、ある意味ですでにリポジトリです。