Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.1k views
in Technique[技术] by (71.8m points)

git - MongoDB backup as text rather than binary for source control

Is it possible to do this?

The reason I ask is that it would seem useful to perform a backup as a pre-commit hook, and include that text-based backup somehow with the code being committed, such that every revision in source control (git) has the necessary backups associated with it.

I realise that it may be possible to get MongoDB to spit out all it's collections as JSON, and back them up that way, but then this would not contain DB and collection metadata.

The central concern is that when branching to make changes to server side code, then reverting that branch, it is easy for us to forget to make the necessary backups that will allow an effective revert (code will no longer match schema). One could claim this is programmer error, but I think there should be some automation in place to ensure that we have a version of the database that is current for every version of the code. This is the problem with schemas that are amorphous during the early days of a project... dynamic schemas being Mongo's main blessing and curse.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

MongoDB stores its data in a BSON (Binary JSON) format so if you are converting to a text-only format you should be aware of potential data type fidelity issues. If you want a consistent backup of your MongoDB database, the recommended format would be the binary output of mongodump. I wouldn't recommend bloating your git repo with binary DB backups, though.

Typically one of the liberating aspects of a database with schema flexibility is not having to worry about schema migrations during development. This does require some consideration on how your application will handle varying schema versions, so having a more controlled approach is fine, too.

Since your main goal is to keep your database schema in sync with code changes, a much better approach would be to investigate schema migration tools. These typically allow you to create upgrade/downgrade code snippets with a defined order of application to a database, and ensure that any changes to the database schema that aren't handled by your application code are captured in the migration scripts.

Some example tools:


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...