Il est relativement pratique de mettre à niveau la base de données MongoDB. À moins qu'il n'y ait une mise à jour de version spéciale, il n'est fondamentalement pas nécessaire d'arrêter le service.
1. Si votre structure de données change, le mécanisme sans schéma de MongoDB vous permet de migrer sans migrer
2. Si vous souhaitez utiliser les nouvelles fonctionnalités de la nouvelle version, vous devez vraiment migrer les données. Une manière plus courante consiste à utiliser son mécanisme de réplication. Vous pouvez consulter les notes de version officielles de la version correspondante. Elles indiquent généralement si la réplication peut être utilisée lors des mises à niveau. Si elle ne peut pas être utilisée, cela peut être dû au fait que cette nouvelle version comporte des modifications dans le protocole de réplication. Ensuite, vous devrez peut-être arrêter le service pour effectuer la migration.
3. Avant d'arrêter le service pour la migration, vous pouvez également migrer les données actuelles via mongodump et mongorestore, puis arrêter le service puis migrer les données incrémentielles. Habituellement, le service ne sera pas arrêté trop longtemps.
Non, vous ne pouvez conclure l'accord dans le programme que vous-même.
C'est aussi le plus gros problème avec ce type de base de données orientée document. Nous devons être prudents lors du développement car nous ne pouvons maintenir qu'une seule structure de base de données côté client, au cas où un développeur insère plus ou moins de champs. acceptable pour le serveur.
Ce qui est encore plus pénible, c'est que parfois le client n'est pas unique, nous devons donc conserver la même structure de données sur différents clients, ce qui apporte de gros inconvénients à la mise à niveau de la structure de données. La conception orientée document visait à l’origine à libérer la dépendance aux structures de données, mais elle n’a pas résolu l’arbitraire causé par le manque de conventions sur les structures de données.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Il est relativement pratique de mettre à niveau la base de données MongoDB. À moins qu'il n'y ait une mise à jour de version spéciale, il n'est fondamentalement pas nécessaire d'arrêter le service.
1. Si votre structure de données change, le mécanisme sans schéma de MongoDB vous permet de migrer sans migrer
2. Si vous souhaitez utiliser les nouvelles fonctionnalités de la nouvelle version, vous devez vraiment migrer les données. Une manière plus courante consiste à utiliser son mécanisme de réplication. Vous pouvez consulter les notes de version officielles de la version correspondante. Elles indiquent généralement si la réplication peut être utilisée lors des mises à niveau. Si elle ne peut pas être utilisée, cela peut être dû au fait que cette nouvelle version comporte des modifications dans le protocole de réplication. Ensuite, vous devrez peut-être arrêter le service pour effectuer la migration.
3. Avant d'arrêter le service pour la migration, vous pouvez également migrer les données actuelles via mongodump et mongorestore, puis arrêter le service puis migrer les données incrémentielles. Habituellement, le service ne sera pas arrêté trop longtemps.
Non, vous ne pouvez conclure l'accord dans le programme que vous-même.
C'est aussi le plus gros problème avec ce type de base de données orientée document. Nous devons être prudents lors du développement car nous ne pouvons maintenir qu'une seule structure de base de données côté client, au cas où un développeur insère plus ou moins de champs. acceptable pour le serveur.
Ce qui est encore plus pénible, c'est que parfois le client n'est pas unique, nous devons donc conserver la même structure de données sur différents clients, ce qui apporte de gros inconvénients à la mise à niveau de la structure de données. La conception orientée document visait à l’origine à libérer la dépendance aux structures de données, mais elle n’a pas résolu l’arbitraire causé par le manque de conventions sur les structures de données.