It is relatively convenient to upgrade the MongoDB database. Unless there is a special version update, there is basically no need to stop the service.
1. If your data structure changes, MongoDB’s Schema-free mechanism allows you to avoid migration
2. If you want to use the new features in the new version, you really have to migrate the data. A more common way is through its Replication mechanism. You can take a look at the official release notes of the corresponding version. It usually states whether Replication can be used during upgrades. If it cannot be used, it may be because this new version has changes in the Replicastion protocol. Then you may have to stop the service to do the migration.
3. Before stopping the service for migration, you can also migrate the current data through mongodump and mongorestore, then stop the service and then migrate the incremental data. Usually the service will not be stopped for too long.
No, you can only make the agreement in the program yourself.
This is also the biggest problem with this type of document-oriented database. We have to be careful when developing it, because we can only maintain one database structure on the client side, in case a developer inserts more or less fields. , the server is acceptable.
What’s even more distressing is that sometimes the client is not unique, so we have to maintain the same data structure on different clients, which brings great inconvenience to the upgrade of the data structure. Document-oriented design was originally intended to liberate the dependence on data structures, but it did not solve the arbitrariness caused by the lack of data structure conventions.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
It is relatively convenient to upgrade the MongoDB database. Unless there is a special version update, there is basically no need to stop the service.
1. If your data structure changes, MongoDB’s Schema-free mechanism allows you to avoid migration
2. If you want to use the new features in the new version, you really have to migrate the data. A more common way is through its Replication mechanism. You can take a look at the official release notes of the corresponding version. It usually states whether Replication can be used during upgrades. If it cannot be used, it may be because this new version has changes in the Replicastion protocol. Then you may have to stop the service to do the migration.
3. Before stopping the service for migration, you can also migrate the current data through mongodump and mongorestore, then stop the service and then migrate the incremental data. Usually the service will not be stopped for too long.
No, you can only make the agreement in the program yourself.
This is also the biggest problem with this type of document-oriented database. We have to be careful when developing it, because we can only maintain one database structure on the client side, in case a developer inserts more or less fields. , the server is acceptable.
What’s even more distressing is that sometimes the client is not unique, so we have to maintain the same data structure on different clients, which brings great inconvenience to the upgrade of the data structure. Document-oriented design was originally intended to liberate the dependence on data structures, but it did not solve the arbitrariness caused by the lack of data structure conventions.