私は Node + Mongo にかなり慣れていないので、新しいコミットを行うたびにデータベースをバックアップできる方法があるかどうかを確認しようとしています。これは可能ですか？mongodump を使用してバックアップする方法は知っていますが、サーバーにプッシュするたびにこれを行う必要は避けたいと思います。データ ディレクトリのアイデアがうまくいかない場合、ノード サーバー リポジトリにバックアップし、実行するたびにプッシュを実行するスクリプトを作成することは可能でしょうか?
私はオンラインで git と mongo に関連するものを見つけることができなかったので、私はこれを間違って見ている/何かを理解していない可能性があると思います。どんな助けでも大歓迎です！ありがとう！
コミットごとにアクションをトリガーしたい場合は、実行可能なスクリプトを呼び出すことができる「フック」gitの概念があります。
たとえば、必要に応じてコミットが成功する前または後に (シェル スクリプトにラップされた) バックアップを実行するpre-commitまたはpost-commitフックを追加できます。mongodump
具体的には、github リポジトリに mongo データ ディレクトリを含めることはできますか?
MongoDB の実行中はデータ ファイルが排他的アクセスのためにロックされるため、Git リポジトリにデータ ディレクトリを含めません。実行中のインスタンスが使用するファイルをコピーするmongodと、「バックアップ」が破損したり使用できなくなったりする場合があります。
バイナリ データ ファイルは、(MongoDB 2.6 のように) 圧縮されていないバイナリ形式であり、事前に割り当てられた/未使用のストレージが含まれているため、リポジトリが大幅に肥大化します。完全なデータのバックアップをバージョン管理に保存したい場合は、バージョン管理にチェックインする前に、結果の出力ディレクトリを zip または tar+gzip でバックアップおよび圧縮します。mongodump
コミットごとに完全なデータベース バックアップを作成すると、多くの時間とディスク容量が消費される可能性があります。コミットごとにデータベースのバックアップを作成するための懸念/要件に応じて、考慮すべき代替アプローチがいくつかあります。
不正なコミットによるデータの削除または変更が懸念される場合は、遅延セカンダリを使用した MongoDB レプリカ セットの展開により、データの古いビューを利用できる状態に保つことができます (たとえば、2 時間遅延)。これは完全なバックアップ戦略に取って代わるものではありませんが、開発ワークフローをより機敏に保ちながら、不正なコミットでデータを回復する手段を提供するのに役立つ可能性があります。
(完全なデータベースではなく) データまたは特定の必要なデータの構造の変更に関心がある場合は、移行フレームワーク (例: mongo-migrate) を使用できます。明示的な「移行スクリプト」を使用してデータの構造を変更すると、データと構造が特定のチェックアウトに対してコードが期待するものと一致することを確認できます (関連する .migrate スクリプトがコード コミットに含まれます)。これは、開発チームと一緒に作業していて、全員が同様のデータを持っていることを確認したい場合にも役立ちます (完全なダンプをチェックインする必要はありません)。
@vmr が述べたように、MMS (MongoDB Management Service) などのバックアップ サービスを使用して、定期的にバックアップを取ることができます。MMS バックアップのクラウド バージョンは、過去 24 時間以内の特定の時点に復元できます。