doc-locale/fr-fr/integration/clickhouse.md
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
ClickHouse est un système de gestion de bases de données orienté colonnes et open-source. Il peut filtrer, agréger et interroger efficacement de grands ensembles de données.
GitLab utilise ClickHouse comme magasin de données secondaire pour activer des fonctionnalités d'analytique avancées telles que GitLab Duo, les tendances SDLC et CI Analytics. GitLab ne stocke dans ClickHouse que les données nécessaires à ces fonctionnalités.
Nous vous recommandons d'utiliser ClickHouse Cloud pour connecter ClickHouse à GitLab.
Vous pouvez également apporter votre propre instance ClickHouse. Pour plus d'informations, consultez les recommandations ClickHouse pour GitLab Self-Managed.
Une fois ClickHouse configuré, vous pouvez utiliser les fonctionnalités d'analytique suivantes :
| Fonctionnalité | Description |
|---|---|
| Tableau de bord de la flotte de runners | Affiche les métriques d'utilisation des runners et les temps d'attente des jobs. Permet l'export de fichiers CSV contenant le nombre de jobs et les minutes de runner exécutées par type de runner et statut de job pour chaque projet. |
| Analytique des contributions | Fournit des analyses des contributions des membres du groupe (événements push, tickets, merge requests) au fil du temps. ClickHouse réduit le risque de problèmes de délai d'expiration pour les instances volumineuses. |
| GitLab Duo et les tendances SDLC | Mesure l'impact de GitLab Duo sur les performances du développement logiciel. Suit les métriques de développement (fréquence de déploiement, délai d'exécution, taux d'échec des changements, temps de restauration) ainsi que les indicateurs spécifiques à l'IA (adoption des sièges GitLab Duo, taux d'acceptation des suggestions de code et utilisation de GitLab Duo Chat). |
| API GraphQL pour les métriques IA | Fournit un accès programmatique aux données de tendances GitLab Duo et SDLC via les endpoints AiMetrics, AiUserMetrics et AiUsageData. Permet l'export de métriques pré-agrégées et de données d'événements brutes pour l'intégration avec des outils de BI et des analyses personnalisées. |
La version de ClickHouse prise en charge varie selon votre version de GitLab :
dictGet), consultez le snippet.ClickHouse Cloud est toujours compatible avec la dernière release stable de GitLab.
[!warning] Si vous utilisez ClickHouse 25.12, notez qu'il a introduit une modification incompatible avec les versions antérieures dans
ALTER MODIFY COLUMN. Cela interrompt le processus de migration pour l'intégration GitLab ClickHouse dans les versions antérieures à 18.8. Une mise à niveau de GitLab vers la version 18.8+ est requise.
Choisissez votre type de déploiement en fonction de vos exigences opérationnelles :
Après avoir configuré votre instance ClickHouse :
Prérequis :
Pour configurer ClickHouse Cloud :
8443 pour les connexions HTTPS utilisées par GitLab, ou 9440 pour le TCP natif avec TLS utilisé par clickhouse-client)[!note] ClickHouse Cloud gère automatiquement les mises à niveau de version et les correctifs de sécurité. Les clients Enterprise Edition (EE) peuvent planifier les mises à niveau pour contrôler leur moment et éviter les interruptions de service inattendues pendant les heures ouvrables. Pour plus d'informations, consultez mettre à niveau ClickHouse.
Après avoir créé votre service ClickHouse Cloud, créez la base de données et l'utilisateur GitLab.
Prérequis :
[!warning] Pour ClickHouse avec GitLab Self-Managed, vous êtes responsable de la planification et de l'exécution des mises à niveau de version, des correctifs de sécurité et des sauvegardes. Pour plus d'informations, consultez Mettre à niveau ClickHouse.
Pour une configuration multi-nœuds à haute disponibilité (HA), GitLab prend en charge le moteur de table Replicated dans ClickHouse.
Prérequis :
remote_servers.clustershardreplicaLors de la configuration de la base de données pour la HA, vous devez exécuter les instructions avec la clause ON CLUSTER.
Pour plus d'informations, consultez la documentation du moteur de base de données Replicated de ClickHouse.
L'application GitLab communique avec le cluster ClickHouse via l'interface HTTP/HTTPS. Pour les déploiements HA, utilisez un proxy HTTP ou un répartiteur de charge pour distribuer les requêtes entre les nœuds du cluster ClickHouse.
Options de répartiteur de charge recommandées :
Exemple de configuration chproxy de base :
server:
http:
listen_addr: ":8080"
clusters:
- name: "clickhouse_cluster"
nodes: [
"http://ch-node1:8123",
"http://ch-node2:8123",
"http://ch-node3:8123"
]
users:
- name: "gitlab"
password: "your_secure_password"
to_cluster: "clickhouse_cluster"
to_user: "gitlab"
Lorsque vous utilisez un répartiteur de charge, configurez GitLab pour qu'il se connecte à l'URL du répartiteur de charge plutôt qu'aux nœuds ClickHouse individuels.
Pour plus d'informations, consultez la documentation chproxy.
Après avoir configuré votre instance ClickHouse pour GitLab Self-Managed, créez la base de données et l'utilisateur GitLab.
Avant de configurer la base de données, vérifiez que ClickHouse est installé et accessible :
Vérifiez que ClickHouse est en cours d'exécution :
clickhouse-client --query "SELECT version()"
Si ClickHouse est en cours d'exécution, le numéro de version s'affiche (par exemple, 24.3.1.12).
Vérifiez que vous pouvez vous connecter avec des identifiants :
clickhouse-client --host your-clickhouse-host --port 9440 --secure --user default --password 'your-password'
[!note] Si vous n'avez pas encore configuré TLS, utilisez le port
9000sans l'indicateur--securepour les tests initiaux.
Pour créer les objets de base de données et d'utilisateur nécessaires :
clickhouse-client.PASSWORD_HERE par le mot de passe généré.{{< tabs >}}
{{< tab title="Nœud unique ou ClickHouse Cloud" >}}
CREATE DATABASE gitlab_clickhouse_main_production;
CREATE USER gitlab IDENTIFIED WITH sha256_password BY 'PASSWORD_HERE';
CREATE ROLE gitlab_app;
GRANT SELECT, INSERT, ALTER, CREATE, UPDATE, DROP, TRUNCATE, OPTIMIZE, dictGet ON gitlab_clickhouse_main_production.* TO gitlab_app;
GRANT SELECT ON information_schema.* TO gitlab_app;
GRANT gitlab_app TO gitlab;
{{< /tab >}}
{{< tab title="ClickHouse HA pour GitLab Self-Managed" >}}
Remplacez CLUSTER_NAME_HERE par le nom de votre cluster :
CREATE DATABASE gitlab_clickhouse_main_production ON CLUSTER CLUSTER_NAME_HERE ENGINE = Replicated('/clickhouse/databases/{cluster}/gitlab_clickhouse_main_production', '{shard}', '{replica}');
CREATE USER gitlab IDENTIFIED WITH sha256_password BY 'PASSWORD_HERE' ON CLUSTER CLUSTER_NAME_HERE;
CREATE ROLE gitlab_app ON CLUSTER CLUSTER_NAME_HERE;
GRANT SELECT, INSERT, ALTER, CREATE, UPDATE, DROP, TRUNCATE, OPTIMIZE, dictGet ON gitlab_clickhouse_main_production.* TO gitlab_app ON CLUSTER CLUSTER_NAME_HERE;
GRANT SELECT ON information_schema.* TO gitlab_app ON CLUSTER CLUSTER_NAME_HERE;
GRANT gitlab_app TO gitlab ON CLUSTER CLUSTER_NAME_HERE;
{{< /tab >}}
{{< /tabs >}}
{{< tabs >}}
{{< tab title="Package Linux" >}}
Pour fournir à GitLab les identifiants ClickHouse :
Modifiez /etc/gitlab/gitlab.rb :
gitlab_rails['clickhouse_databases']['main']['database'] = 'gitlab_clickhouse_main_production'
gitlab_rails['clickhouse_databases']['main']['url'] = 'https://your-clickhouse-host:port'
gitlab_rails['clickhouse_databases']['main']['username'] = 'gitlab'
gitlab_rails['clickhouse_databases']['main']['password'] = 'PASSWORD_HERE' # replace with the actual password
Remplacez l'URL par :
https://your-service.clickhouse.cloud:8443https://your-clickhouse-host:8443https://your-load-balancer:8080 (ou l'URL de votre répartiteur de charge)Enregistrez le fichier et reconfigurez GitLab :
sudo gitlab-ctl reconfigure
{{< /tab >}}
{{< tab title="Chart Helm (Kubernetes)" >}}
Enregistrez le mot de passe ClickHouse en tant que secret Kubernetes :
kubectl create secret generic gitlab-clickhouse-password --from-literal="main_password=PASSWORD_HERE"
Exportez les valeurs Helm :
helm get values gitlab > gitlab_values.yaml
Modifiez gitlab_values.yaml :
global:
clickhouse:
enabled: true
main:
username: gitlab
password:
secret: gitlab-clickhouse-password
key: main_password
database: gitlab_clickhouse_main_production
url: 'https://your-clickhouse-host:port'
Remplacez l'URL par :
https://your-service.clickhouse.cloud:8443https://your-clickhouse-host:8443https://your-load-balancer:8080 (ou l'URL de votre répartiteur de charge)Enregistrez le fichier et appliquez les nouvelles valeurs :
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
{{< /tab >}}
{{< /tabs >}}
[!note] Pour les déploiements en production, configurez TLS/SSL sur votre instance ClickHouse et utilisez des URL
https://. Pour les installations GitLab Self-Managed, consultez la documentation Sécurité réseau.
Pour vérifier que votre connexion est correctement configurée :
Connectez-vous à la console Rails.
Exécutez la commande suivante :
ClickHouse::Client.select('SELECT 1', :main)
En cas de succès, la commande retourne [{"1"=>1}].
Si la connexion échoue, vérifiez :
[!note] Cette étape est obligatoire. Si vous la sautez, les tableaux de bord Analytics n'affichent pas de données et affichent une erreur « Failed to fetch data ».
{{< tabs >}}
{{< tab title="Package Linux" >}}
Pour créer les objets de base de données requis, exécutez :
sudo gitlab-rake gitlab:clickhouse:migrate
{{< /tab >}}
{{< tab title="Chart Helm (Kubernetes)" >}}
Les migrations sont exécutées automatiquement avec le chart GitLab-Migrations.
Vous pouvez également exécuter les migrations en lançant la commande suivante dans le pod Toolbox :
gitlab-rake gitlab:clickhouse:migrate
{{< /tab >}}
{{< /tabs >}}
Une fois votre instance GitLab connectée à ClickHouse, vous pouvez activer les fonctionnalités qui utilisent ClickHouse :
Prérequis :
Pour activer ClickHouse pour Analytics :
Pour désactiver ClickHouse pour Analytics :
Prérequis :
Pour désactiver :
[!note] La désactivation de ClickHouse pour Analytics empêche GitLab d'interroger ClickHouse, mais ne supprime aucune donnée de votre instance ClickHouse. Les fonctionnalités d'analytique qui dépendent de ClickHouse se replieront sur des sources de données alternatives ou deviendront indisponibles.
ClickHouse Cloud gère automatiquement les mises à niveau de version et les correctifs de sécurité. Aucune intervention manuelle n'est requise.
Pour des informations sur la planification des mises à niveau et les fenêtres de maintenance, consultez les mises à niveau de ClickHouse Cloud.
[!note] ClickHouse Cloud vous notifie à l'avance des mises à niveau à venir. Consultez le journal des modifications de ClickHouse Cloud pour rester informé des nouvelles fonctionnalités et des changements.
Pour ClickHouse avec GitLab Self-Managed, vous êtes responsable de la planification et de l'exécution des mises à niveau de version.
Prérequis :
Avant la mise à niveau :
Pour mettre à niveau ClickHouse :
[!warning] Assurez-vous toujours que la version de ClickHouse reste compatible avec votre version de GitLab. Des versions incompatibles peuvent provoquer la mise en pause de l'indexation et l'échec de fonctionnalités. Pour plus d'informations, consultez les versions de ClickHouse prises en charge
Pour les procédures de mise à niveau détaillées, consultez la documentation ClickHouse sur les mises à jour.
Prérequis :
Pour vérifier le statut des migrations ClickHouse :
Vous pouvez également vérifier les migrations en attente à l'aide de la console Rails :
# Sign in to Rails console
# Run this to check migrations
ClickHouse::MigrationSupport::Migrator.new(:main).pending_migrations
Si une migration ClickHouse échoue :
Consultez les journaux pour obtenir les détails de l'erreur. Les erreurs liées à ClickHouse sont enregistrées dans les journaux de l'application GitLab.
Résolvez le problème sous-jacent (par exemple, mémoire insuffisante, problèmes de connectivité).
Relancez la migration :
# For installations that use the Linux package
sudo gitlab-rake gitlab:clickhouse:migrate
# For self-compiled installations
bundle exec rake gitlab:clickhouse:migrate RAILS_ENV=production
[!note] Les migrations sont conçues pour être idempotentes et peuvent être relancées en toute sécurité. Si une migration échoue en cours d'exécution, la relancer la reprend là où elle s'est arrêtée ou ignore les étapes déjà effectuées.
GitLab fournit plusieurs tâches Rake pour gérer votre base de données ClickHouse.
Les tâches Rake suivantes sont disponibles :
| Tâche | Description |
|---|---|
sudo gitlab-rake gitlab:clickhouse:migrate | Exécute toutes les migrations ClickHouse en attente pour créer ou mettre à jour le schéma de base de données. |
sudo gitlab-rake gitlab:clickhouse:drop | Supprime toutes les bases de données ClickHouse. À utiliser avec une extrême prudence car cela supprime toutes les données. |
sudo gitlab-rake gitlab:clickhouse:create | Crée les bases de données ClickHouse si elles n'existent pas. |
sudo gitlab-rake gitlab:clickhouse:setup | Crée les bases de données et exécute toutes les migrations. Équivaut à l'exécution des tâches create et migrate. |
sudo gitlab-rake gitlab:clickhouse:schema:dump | Exporte le schéma de base de données actuel dans un fichier à des fins de sauvegarde ou de contrôle de version. |
sudo gitlab-rake gitlab:clickhouse:schema:load | Charge le schéma de base de données depuis un fichier de dump. |
[!note] Pour les installations compilées depuis les sources, utilisez
bundle exec rakeà la place desudo gitlab-rakeet ajoutezRAILS_ENV=productionà la fin de la commande.
Pour vérifier que votre connexion ClickHouse fonctionne :
# For installations that use the Linux package
sudo gitlab-rake gitlab:clickhouse:info
# For self-compiled installations
bundle exec rake gitlab:clickhouse:info RAILS_ENV=production
Cette tâche affiche des informations de débogage sur la connexion et la configuration ClickHouse.
Pour exécuter toutes les migrations en attente :
# For installations that use the Linux package
sudo gitlab-rake gitlab:clickhouse:migrate
# For self-compiled installations
bundle exec rake gitlab:clickhouse:migrate RAILS_ENV=production
[!warning] Cela supprime toutes les données de votre base de données ClickHouse. À utiliser uniquement en développement ou lors du dépannage.
Pour supprimer et recréer la base de données :
# For installations that use the Linux package
sudo gitlab-rake gitlab:clickhouse:drop
sudo gitlab-rake gitlab:clickhouse:setup
# For self-compiled installations
bundle exec rake gitlab:clickhouse:drop RAILS_ENV=production
bundle exec rake gitlab:clickhouse:setup RAILS_ENV=production
Vous pouvez utiliser des variables d'environnement pour contrôler le comportement des tâches Rake :
| Variable d'environnement | Type de données | Description |
|---|---|---|
VERBOSE | Booléen | Définissez sur true pour afficher une sortie détaillée pendant les migrations. Exemple : VERBOSE=true sudo gitlab-rake gitlab:clickhouse:migrate |
[!note] Pour le dimensionnement des ressources et les recommandations de déploiement en fonction du nombre d'utilisateurs, consultez la configuration requise.
Pour des informations sur l'architecture de ClickHouse et l'optimisation des performances, consultez la documentation ClickHouse sur l'architecture.
Vous devez effectuer une sauvegarde complète avant de mettre à niveau l'application GitLab. Les données ClickHouse ne sont pas incluses dans les outils de sauvegarde GitLab.
La stratégie de sauvegarde et de restauration dépend du choix de déploiement.
ClickHouse Cloud gère automatiquement :
Aucune configuration supplémentaire n'est nécessaire.
Pour plus d'informations, consultez les sauvegardes ClickHouse Cloud.
Si vous gérez votre propre instance ClickHouse, vous devez effectuer des sauvegardes régulières pour garantir la sécurité des données :
metrics ou logs) vers un bucket de stockage d'objets, par exemple AWS S3.Cela duplique les données pour chaque sauvegarde complète, mais représente l'approche la plus simple pour restaurer les données.
Vous pouvez également utiliser clickhouse-backup. Il s'agit d'un outil tiers qui offre des fonctionnalités similaires avec des fonctions supplémentaires telles que la planification et la gestion du stockage distant.
Pour garantir la stabilité de l'intégration GitLab, vous devez surveiller l'état et les performances de votre cluster ClickHouse.
ClickHouse Cloud fournit une intégration Prometheus native qui expose les métriques via un endpoint d'API sécurisé.
Après avoir généré les identifiants d'API, vous pouvez configurer des collecteurs pour récupérer les métriques de ClickHouse Cloud. Par exemple, un déploiement Prometheus.
ClickHouse peut exposer des métriques au format Prometheus. Pour activer cela :
Configurez la section prometheus dans votre config.xml pour exposer les métriques sur un port dédié (la valeur par défaut est 9363).
<prometheus>
<endpoint>/metrics</endpoint>
<port>9363</port>
<metrics>true</metrics>
<events>true</events>
<asynchronous_metrics>true</asynchronous_metrics>
</prometheus>
Configurez Prometheus ou un serveur compatible similaire pour récupérer http://<clickhouse-host>:9363/metrics.
Vous devez configurer des alertes pour les métriques suivantes afin de détecter les problèmes susceptibles d'affecter les fonctionnalités GitLab :
| Nom de la métrique | Description | Seuil d'alerte (recommandation) |
|---|---|---|
ClickHouse_Metrics_Query | Nombre de requêtes en cours d'exécution. Une hausse soudaine peut indiquer un goulot d'étranglement des performances. | Déviation de la baseline (par exemple > 100) |
ClickHouseProfileEvents_FailedSelectQuery | Nombre de requêtes SELECT ayant échoué | Déviation de la baseline (par exemple > 50) |
ClickHouseProfileEvents_FailedInsertQuery | Nombre de requêtes INSERT ayant échoué | Déviation de la baseline (par exemple > 10) |
ClickHouse_AsyncMetrics_ReadonlyReplica | Indique si un réplica est passé en mode lecture seule (souvent en raison d'une perte de connexion à ZooKeeper). | > 0 (prendre des mesures immédiates) |
ClickHouse_ProfileEvents_NetworkErrors | Erreurs réseau (réinitialisations/délais d'expiration de connexion). Des erreurs fréquentes peuvent provoquer l'échec des jobs d'arrière-plan GitLab. | Taux > 0 |
Si ClickHouse est disponible derrière un répartiteur de charge, vous pouvez utiliser l'endpoint HTTP /ping pour vérifier la disponibilité. La réponse attendue est Ok avec le code HTTP 200.
Pour garantir la sécurité de vos données et l'auditabilité, appliquez les pratiques de sécurité suivantes.
Chiffrement TLS : configurez les serveurs ClickHouse pour utiliser le chiffrement TLS afin de valider les connexions.
Lors de la configuration de l'URL de connexion dans GitLab, vous devez utiliser le protocole https:// (par exemple, https://clickhouse.example.com:8443) pour le spécifier.
Listes d'autorisation IP : limitez l'accès au port ClickHouse (par défaut 8443 ou 9440) aux seuls nœuds de l'application GitLab et aux autres réseaux autorisés.
L'application GitLab ne tient pas de journal d'audit distinct pour les requêtes ClickHouse individuelles. Pour satisfaire des exigences spécifiques concernant l'accès aux données (qui a interrogé quoi et quand), vous pouvez activer la journalisation côté ClickHouse.
Dans ClickHouse Cloud, la journalisation des requêtes est activée par défaut. Vous pouvez accéder à ces journaux en interrogeant la table system.query_log.
Pour les instances auto-gérées, assurez-vous que le paramètre de configuration query_log est activé dans la configuration de votre serveur :
Vérifiez que la section query_log existe dans votre config.xml ou users.xml :
<query_log>
<database>system</database>
<table>query_log</table>
<partition_by>toYYYYMM(event_date)</partition_by>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<ttl>event_date + INTERVAL 30 DAY</ttl> <!-- Keep only 30 days -->
</query_log>
Une fois activé, toutes les requêtes exécutées sont enregistrées dans la table system.query_log, permettant une piste d'audit.
La configuration système recommandée varie en fonction du nombre d'utilisateurs.
| Utilisateurs | Recommandation principale | Instance AWS ARM comparable | Instance GCP ARM comparable | Instance Azure ARM comparable | Type de déploiement |
|---|---|---|---|---|---|
| 1 000 | ClickHouse Cloud Basic | - | - | - | Géré |
| 2 000 | ClickHouse Cloud Basic | m8g.xlarge | c4a-standard-4 | Standard_D4ps_v6 | Géré ou nœud unique |
| 3 000 | ClickHouse Cloud Scale | m8g.2xlarge | c4a-standard-8 | Standard_D8ps_v6 | Géré ou nœud unique |
| 5 000 | ClickHouse Cloud Scale | m8g.4xlarge | c4a-standard-16 | Standard_D16ps_v6 | Géré ou nœud unique |
| 10 000 | ClickHouse Cloud Scale | m8g.4xlarge | c4a-standard-16 | Standard_D16ps_v6 | Géré ou nœud unique/HA |
| 25 000 | ClickHouse pour GitLab Self-Managed ou ClickHouse Cloud Scale | m8g.8xlarge ou 3×m8g.4xlarge | c4a-standard-32 ou 3×c4a-standard-16 | Standard_D32ps_v6 ou 3xStandard_D16ps_v6 | Géré ou nœud unique/HA |
| 50 000 | ClickHouse pour GitLab Self-Managed en haute disponibilité (HA) ou ClickHouse Cloud Scale | 3×m8g.4xlarge | 3×c4a-standard-16 | 3xStandard_D16ps_v6 | Géré ou cluster HA |
Recommandation : ClickHouse Cloud Basic offrant une bonne rentabilité sans complexité opérationnelle.
Recommandation : ClickHouse Cloud Basic offrant le meilleur rapport qualité-prix sans complexité opérationnelle.
Recommandation alternative pour le déploiement ClickHouse sur GitLab Self-Managed :
Recommandation : ClickHouse Cloud Scale
Recommandation alternative pour le déploiement ClickHouse sur GitLab Self-Managed :
[!note] Les déploiements HA ne sont pas rentables à cette échelle.
Recommandation : ClickHouse Cloud Scale
Recommandation alternative pour le déploiement ClickHouse sur GitLab Self-Managed :
Recommandation : ClickHouse Cloud Scale
Recommandation alternative pour le déploiement ClickHouse sur GitLab Self-Managed :
Recommandation : ClickHouse Cloud Scale ou ClickHouse pour GitLab Self-Managed. Les deux options sont économiquement viables à cette échelle.
Recommandations pour le déploiement ClickHouse sur GitLab Self-Managed :
Nœud unique :
Déploiement HA :
Stockage : 400 Go par nœud avec un niveau de performances élevé.
Recommandation : ClickHouse pour GitLab Self-Managed HA ou ClickHouse Cloud Scale. L'option auto-gérée est légèrement plus rentable à cette échelle.
Recommandations pour le déploiement ClickHouse sur GitLab Self-Managed :
Nœud unique :
Déploiement HA (recommandé) :
Stockage : 1 000 Go par nœud avec un niveau de performances élevé.
La configuration HA devient rentable uniquement à partir de 10 000 utilisateurs.
MergeTree est un moteur de table dans ClickHouse conçu pour des taux d'ingestion de données élevés et de grands volumes de données. Il s'agit du moteur de stockage principal de ClickHouse, offrant des fonctionnalités telles que le stockage en colonnes, le partitionnement personnalisé, les index primaires épars et la prise en charge des fusions de données en arrière-plan.[!warning] Sur GitLab 18.0.0 et versions antérieures, l'exécution des migrations du schéma de base de données pour ClickHouse peut échouer pour ClickHouse 24.x et 25.x avec le message d'erreur suivant :
plaintextCode: 344. DB::Exception: Projection is fully supported in ReplacingMergeTree with deduplicate_merge_projection_mode = throw. Use 'drop' or 'rebuild' option of deduplicate_merge_projection_modeSans l'exécution de toutes les migrations, l'intégration ClickHouse ne fonctionnera pas.
Pour contourner ce problème et exécuter les migrations :
Connectez-vous à la console Rails.
Exécutez la commande suivante :
ClickHouse::Client.execute("INSERT INTO schema_migrations (version) VALUES ('20231114142100'), ('20240115162101')", :main)
Migrez à nouveau la base de données :
sudo gitlab-rake gitlab:clickhouse:migrate
Cette fois, la migration de la base de données devrait se terminer avec succès.
À partir de GitLab 18.8, GitLab commence à utiliser les dictionnaires ClickHouse pour la dénormalisation des données. Les instructions GRANT antérieures à 18.8 n'accordaient pas à l'utilisateur gitlab la permission d'interroger les dictionnaires, une étape de modification manuelle est donc nécessaire :
clickhouse-client.PASSWORD_HERE par le mot de passe généré.{{< tabs >}}
{{< tab title="Nœud unique ou ClickHouse Cloud" >}}
GRANT dictGet ON gitlab_clickhouse_main_production.* TO gitlab_app;
{{< /tab >}}
{{< tab title="ClickHouse HA pour GitLab Self-Managed" >}}
Remplacez CLUSTER_NAME_HERE par le nom de votre cluster :
GRANT dictGet ON gitlab_clickhouse_main_production.* TO gitlab_app ON CLUSTER CLUSTER_NAME_HERE;
{{< /tab >}}
{{< /tabs >}}
Sans l'octroi de cette permission, la migration ClickHouse (CreateNamespaceTraversalPathsDict) échouera avec l'erreur suivante :
DB::Exception: gitlab: Not enough privileges.
Après avoir accordé la permission, la migration peut être relancée en toute sécurité (idéalement, attendez 1 à 2 heures que le verrou de migration distribué soit libéré).
Dans GitLab 18.5 et versions antérieures, des données en double pouvaient être insérées dans les tables ClickHouse (telles que ci_finished_pipelines et ci_finished_builds) lorsque les workers Sidekiq relançaient des requêtes après des délais d'expiration réseau. Ce problème entraînait l'affichage de métriques agrégées incorrectes dans les tableaux de bord d'analytique par les vues matérialisées, y compris le tableau de bord de la flotte de runners.
Ce problème a été corrigé dans GitLab 18.9 et reporté dans les versions 18.6, 18.7 et 18.8. Pour résoudre ce problème, mettez à niveau vers GitLab 18.6 ou une version ultérieure.
Si vous disposez de données en double existantes, un correctif pour reconstruire les vues matérialisées affectées est prévu pour GitLab 18.10 dans le ticket 586319. Pour obtenir de l'aide, contactez le support GitLab.