doc-locale/fr-fr/administration/geo/disaster_recovery/bring_primary_back.md
{{< details >}}
{{< /details >}}
Après un basculement, il est possible de réintroduire le site principal rétrogradé en tant que nouveau site secondaire ou de restaurer votre site principal d'origine. Ce processus comprend deux étapes :
[!warning]
Si vous avez des doutes concernant la cohérence des données sur ce site, vous devriez le configurer depuis zéro.
Le site principal rétrogradé est considéré comme un serveur GitLab autonome qui n'est plus synchronisé avec Geo.
Assurez-vous que toute configuration résiduelle en tant qu'ancien site principal est supprimée avant de le rajouter en tant que nouveau site secondaire.
Étant donné que l'ancien site principal n'est pas synchronisé avec le site principal actuel, la première étape consiste à mettre à jour l'ancien site principal. Notez que la suppression des données stockées sur disque telles que les dépôts et les téléversements n'est pas rejouée lors de la resynchronisation de l'ancien site principal, ce qui peut entraîner une augmentation de l'utilisation du disque. Vous pouvez également configurer une nouvelle instance GitLab secondaire pour éviter cela.
Pour mettre à jour l'ancien site principal :
Connectez-vous via SSH à l'ancien site principal qui a pris du retard.
Supprimez /etc/gitlab/gitlab-cluster.json s'il existe. (Qu'est-ce que le fichier gitlab-cluster.json ?)
Si le site à rajouter en tant que site secondaire a été promu avec la commande gitlab-ctl geo promote, il peut contenir /etc/gitlab/gitlab-cluster.json. Par exemple, lors de l'exécution de gitlab-ctl reconfigure, vous pouvez remarquer une sortie du type :
The 'geo_primary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'true' and overrides the setting in the /etc/gitlab/gitlab.rb
Dans ce cas, /etc/gitlab/gitlab-cluster.json doit être supprimé de chaque nœud Sidekiq, PostgreSQL, Gitaly et Rails du site (en cas de configuration multi-nœuds), afin de faire de /etc/gitlab/gitlab.rb l'unique source de vérité.
Assurez-vous que tous les services sont en cours d'exécution :
sudo gitlab-ctl start
[!note]
- Si vous avez désactivé le site principal de façon permanente, vous devez annuler ces étapes maintenant. Pour les distributions avec systemd, telles que Debian/Ubuntu/CentOS7+, vous devez exécuter
sudo systemctl enable gitlab-runsvdir. Pour les distributions sans systemd, telles que CentOS 6, vous devez installer l'instance GitLab depuis zéro et la configurer en tant que site secondaire en suivant les instructions de configuration. Dans ce cas, vous n'avez pas besoin de suivre l'étape suivante.- Si vous avez modifié les enregistrements DNS pour ce site lors de la procédure de reprise après sinistre, vous devrez peut-être bloquer toutes les écritures vers ce site pendant cette procédure.
Configurer Geo. Dans ce cas, le site secondaire fait référence à l'ancien site principal.
Si PgBouncer était activé sur le site current secondary (lorsqu'il était un site principal), désactivez-le en modifiant /etc/gitlab/gitlab.rb et en exécutant sudo gitlab-ctl reconfigure.
Vous pouvez ensuite configurer la réplication de base de données sur le site secondaire.
Initialisez le schéma de base de données de suivi Geo sur le site secondaire réintroduit.
gitlab-ctl replicate-geo-database réplique uniquement la base de données principale gitlabhq_production. La base de données de suivi Geo (gitlabhq_geo_production) est locale au site secondaire et est normalement migrée par sudo gitlab-ctl reconfigure via geo_secondary['auto_migrate']. Si auto_migrate est désactivé, si la base de données de suivi est externe, ou si elle était vide lors de la dernière exécution de reconfigure, le curseur de journal Geo se bloque et tous les types de synchronisation restent à 0 %.
Dans ces cas, sur un nœud Rails ou Sidekiq du site secondaire :
Exécutez les migrations de base de données de suivi manuellement.
Redémarrez le curseur de journal Geo afin qu'il prenne en compte le nouveau schéma :
sudo gitlab-ctl restart geo-logcursor
Vérifiez que la base de données de suivi est correctement configurée avant de continuer :
# Confirm the tracking database has tables
sudo gitlab-geo-psql -d gitlabhq_geo_production -c "\dt"
# Confirm all tracking database migrations are applied
sudo gitlab-rake db:migrate:status:geo | grep -w down
# Run the full Geo check
sudo gitlab-rake gitlab:geo:check
La commande db:migrate:status:geo ne doit retourner aucune migration down, et gitlab:geo:check doit indiquer GitLab Geo tracking database is correctly configured ... yes dans sa sortie.
Configurez l'audience JWT pour OpenBao. Si vous avez activé GitLab Secrets Manager et que les sites principal et secondaire ne partagent pas la même audience JWT, définissez jwt_audience sur l'URL OpenBao du nouveau site principal dans les valeurs Helm du site secondaire rajouté :
global:
openbao:
enabled: true
url: https://openbao.old-primary.example.com:8200
jwt_audience: https://openbao.promoted.example.com:8200
Si vous avez perdu votre site principal d'origine, suivez les instructions de configuration pour configurer un nouveau site secondaire.
Lorsque la réplication initiale est terminée et que le site principal et le site secondaire sont étroitement synchronisés, vous pouvez effectuer un basculement planifié.
Si votre objectif est d'avoir à nouveau deux sites, vous devez également remettre votre site secondaire en ligne en répétant la première étape (configurer l'ancien site principal en tant que site secondaire) pour le site secondaire.
S'il y a plus d'un site secondaire, les sites restants peuvent être remis en ligne maintenant. Pour chacun des sites restants, lancez le processus de réplication avec le site principal.
Lorsqu'un site secondaire est ajouté, s'il contient des données qui auraient autrement été synchronisées depuis le site principal, Geo évite de re-transférer ces données.
git fetch, qui ne transfère que les références manquantes.Cas d'utilisation :
{{< history >}}
geo_skip_download_if_exists. Désactivé par défaut.geo_skip_download_if_exists supprimé.{{< /history >}}
Lorsque vous ajoutez un site secondaire qui contient déjà des données de blobs, le site Geo secondaire évite de re-transférer ces données. Cela s'applique aux éléments suivants :
Si la copie du site secondaire est effectivement corrompue, la vérification en arrière-plan finira par échouer et le blob sera resynchronisé.
Les blobs ne seront ignorés de cette manière que s'ils n'ont pas d'enregistrement de registre correspondant dans la base de données de suivi Geo. Les conditions sont strictes car la resynchronisation est presque toujours intentionnelle, et nous ne pouvons pas risquer d'ignorer par erreur un transfert.