doc-locale/fr-fr/administration/geo/replication/upgrading_the_geo_sites.md
{{< details >}}
{{< /details >}}
[!warning] Lisez attentivement ces sections avant de mettre à jour vos sites Geo. Ne pas suivre les étapes de mise à niveau spécifiques à la version peut entraîner des interruptions de service imprévues. Si vous avez des questions spécifiques, contactez le support. Une mise à niveau majeure de la version de base de données nécessite de réinitialiser la réplication PostgreSQL vers les sites Geo secondaires. Cela s'applique aux bases de données packagées sous Linux et aux bases de données gérées en externe. Cela peut entraîner une interruption de service plus longue que prévu.
La mise à niveau des sites Geo implique d'effectuer :
[!note] Ces étapes générales de mise à niveau nécessitent une interruption de service dans une configuration multi-nœuds. Si vous souhaitez éviter les interruptions de service, envisagez d'utiliser les mises à niveau sans interruption de service.
Pour mettre à niveau les sites Geo lors de la sortie d'une nouvelle version de GitLab, mettez à niveau le site principal et tous les sites secondaire :
Facultatif. Suspendez la réplication sur chaque site secondaire pour protéger la capacité de reprise après sinistre (DR) des sites secondaire. Suspendez la réplication lorsque votre priorité est de préserver un point de contrôle DR propre lors d'une fenêtre de mise à niveau à risque élevé. Ne suspendez pas la réplication si votre priorité est de maintenir le site secondaire à jour et de servir le trafic en lecture normalement pendant la mise à niveau, en particulier dans une approche sans interruption de service.
Connectez-vous en SSH à chaque nœud du site principal.
Effectuez des tests sur le site principal, en particulier si vous avez suspendu la réplication à l'étape 1 pour protéger la DR. Pour plus d'informations sur les tests post-mise à niveau, consultez Exécuter les vérifications de l'état de la mise à niveau.
Assurez-vous que les secrets du fichier /etc/gitlab/gitlab-secrets.json du site principal et du site secondaire sont identiques. Le fichier doit être identique sur tous les nœuds d'un site.
Connectez-vous en SSH à chaque nœud des sites secondaire.
Si vous avez suspendu la réplication à l'étape 1, reprenez la réplication sur chaque site secondaire. Ensuite, redémarrez Puma et Sidekiq sur chaque site secondaire. Cela permet de s'assurer qu'ils sont initialisés par rapport au nouveau schéma de base de données qui est maintenant répliqué depuis le site principal précédemment mis à niveau.
sudo gitlab-ctl restart sidekiq
sudo gitlab-ctl restart puma
Testez les sites principal et secondaire, et vérifiez la version sur chacun d'eux.
Maintenant que le processus de mise à niveau est terminé, vous pouvez vérifier que tout fonctionne correctement :
Exécutez la tâche Geo Rake sur un nœud d'application pour les sites principal et secondaire. Tout devrait être vert :
sudo gitlab-rake gitlab:geo:check
Vérifiez le tableau de bord Geo du site principal pour détecter d'éventuelles erreurs.
Testez la réplication des données en poussant du code vers le site principal et vérifiez s'il est reçu par les sites secondaire.
Si vous rencontrez des problèmes, consultez le guide de dépannage Geo.