doc-locale/fr-fr/administration/geo/replication/object_storage.md
{{< details >}}
{{< /details >}}
{{< history >}}
geo_object_storage_verification. Activé par défaut.{{< /history >}}
Geo peut être utilisé en combinaison avec le stockage d'objets (AWS S3 ou tout autre stockage d'objets compatible).
Les sites Secondaire peuvent utiliser l'un des éléments suivants :
La méthode de stockage (locale ou stockage d'objets) des fichiers est enregistrée dans la base de données, et la base de données est répliquée du site Geo principal vers le site Geo secondaire.
Lors de l'accès à un objet chargé, nous obtenons sa méthode de stockage (locale ou stockage d'objets) à partir de la base de données. Le site Geo secondaire doit donc correspondre à la méthode de stockage du site Geo principal.
Par conséquent, si le site Geo principal utilise le stockage d'objets, le site Geo secondaire doit également l'utiliser.
Pour que :
En savoir plus sur l'utilisation du stockage d'objets avec GitLab.
Geo vérifie les fichiers stockés dans le stockage d'objets pour garantir l'intégrité des données entre les sites principal et secondaires.
[!warning] La désactivation de la vérification du stockage d'objets n'est pas recommandée. Lorsque vous désactivez le
geo_object_storage_verification, GitLab supprime de façon asynchrone tous les enregistrements d'état de vérification existants.
Lorsque le geo_object_storage_verification est désactivé :
Geo::VerificationBatchWorker) peuvent toujours apparaître dans les journaux Sidekiq, mais la vérification n'a pas lieu.{{< history >}}
{{< /history >}}
[!warning] En cas de problèmes, évitez de supprimer manuellement des fichiers individuels, car cela peut entraîner des incohérences de données.
Les sites Secondaire peuvent répliquer les fichiers stockés par le site principal, qu'ils soient stockés sur le système de fichiers local ou dans le stockage d'objets.
Pour activer la réplication GitLab :
Pour LFS, suivez la documentation pour configurer le stockage d'objets LFS.
Pour les artefacts de job CI, il existe une documentation similaire pour configurer le stockage d'objets pour les artefacts de job.
Pour les chargements des utilisateurs, il existe une documentation similaire pour configurer le stockage d'objets pour les chargements.
Si vous souhaitez migrer les fichiers du site principal vers le stockage d'objets, vous pouvez configurer le site secondaire de plusieurs façons :
Si le paramètre Autoriser ce site secondaire à répliquer le contenu sur le stockage d'objets est désactivé et que vous avez migré tous vos fichiers du stockage local vers le stockage d'objets, de nombreuses barres de progression dans Admin > Geo > Sites affichent Rien à synchroniser.
[!warning] Pour éviter toute perte de données, vous ne devez activer le paramètre Autoriser ce site secondaire à répliquer le contenu sur le stockage d'objets que si vous utilisez des stockages d'objets distincts pour les sites principal et secondaire.
GitLab ne prend pas en charge le cas où les deux conditions suivantes sont réunies :
Des incohérences de données peuvent survenir lors de la migration du stockage local vers le stockage d'objets, comme décrit plus en détail dans la section de dépannage du stockage d'objets.
Lorsque vous utilisez Amazon S3, vous pouvez utiliser la réplication inter-régions (CRR) pour disposer d'une réplication automatique entre le bucket utilisé par le site principal et le bucket utilisé par les sites secondaire.
Si vous utilisez Google Cloud Storage, envisagez d'utiliser le stockage multi-régional. Vous pouvez également utiliser le Storage Transfer Service, bien que celui-ci ne prenne en charge que la synchronisation quotidienne.
Pour une synchronisation manuelle ou planifiée par cron, voir :