doc-locale/fr-fr/administration/troubleshooting/postgresql.md
{{< details >}}
{{< /details >}}
Cette page contient des informations sur PostgreSQL utilisées par l'équipe Support de GitLab lors du dépannage. GitLab rend ces informations publiques afin que tout le monde puisse bénéficier des connaissances collectées par l'équipe Support.
[!warning] Certaines procédures documentées ici peuvent endommager votre instance GitLab. Utilisez-les à vos propres risques.
Si vous êtes sur un niveau payant et que vous ne savez pas comment utiliser ces commandes, contactez le Support pour obtenir de l'aide sur les problèmes que vous rencontrez.
{{< tabs >}}
{{< tab title="Linux package (Omnibus)" >}}
Recommandé pour :
sudo gitlab-psql
Sur une instance à nœud unique, ou un nœud web ou Sidekiq, vous pouvez également utiliser la console de base de données Rails, mais son initialisation prend plus de temps :
sudo gitlab-rails dbconsole --database main
{{< /tab >}}
{{< tab title="Docker" >}}
docker exec -it <container-id> gitlab-psql
{{< /tab >}}
{{< tab title="Self-compiled (source)" >}}
Utilisez la commande psql qui fait partie de votre installation PostgreSQL.
sudo -u git -H psql -d gitlabhq_production
{{< /tab >}}
{{< tab title="Helm chart (Kubernetes)" >}}
gitlab-rails dbconsole dans le pod toolbox.
[!note] Pour les déploiements cloud natifs utilisant des services PostgreSQL gérés (tels qu'AWS RDS), vous ne pouvez pas modifier directement le fichier de configuration de la base de données. À la place, configurez les paramètres PostgreSQL via le groupe de paramètres ou l'interface de configuration de votre service cloud.
{{< /tab >}}
{{< /tabs >}}
Pour quitter la console, tapez : quit.
Cette section contient des liens vers des informations disponibles ailleurs dans la documentation GitLab.
gitlab-ctl patroni check-leader et les erreurs PgBouncer.Références :
ERROR: deadlock detected
Trois délais d'expiration applicables sont identifiés dans le ticket #30528 ; nos paramètres recommandés sont les suivants :
deadlock_timeout = 5s
statement_timeout = 15s
idle_in_transaction_session_timeout = 60s
Citation du ticket #30528 :
<!-- vale gitlab_base.FutureTense = NO --><!-- vale gitlab_base.FutureTense = YES -->« Si un interblocage se produit et que nous le résolvons en abandonnant la transaction après une courte période, les mécanismes de nouvelle tentative dont nous disposons déjà feront que le travail bloqué sera réessayé, et il est peu probable que nous subissions plusieurs interblocages consécutifs. »
[!note] Au sein du Support, notre approche générale pour reconfigurer les délais d'expiration (s'applique également à la pile HTTP) est qu'il est acceptable de le faire temporairement comme solution de contournement. Si cela rend GitLab utilisable pour le client, cela permet de gagner du temps pour comprendre le problème plus complètement, implémenter un correctif rapide ou apporter un autre changement qui traite la cause première. En général, les délais d'expiration devraient être remis à des valeurs par défaut raisonnables une fois la cause première résolue.
Dans ce cas, les conseils que nous avions du développement étaient de supprimer deadlock_timeout ou statement_timeout, mais de laisser le troisième paramètre à 60 secondes. La définition de idle_in_transaction protège la base de données contre les sessions potentiellement bloquées pendant des jours. Vous trouverez plus de discussion dans le ticket relatif à l'introduction de ce délai d'expiration sur GitLab.com.
Valeurs par défaut PostgreSQL :
statement_timeout = 0 (jamais)idle_in_transaction_session_timeout = 0 (jamais)Les commentaires du ticket #30528 indiquent que ces deux valeurs devraient être définies à au moins quelques minutes pour toutes les installations du package Linux (afin qu'elles ne restent pas bloquées indéfiniment). Cependant, 15 s pour statement_timeout est très court et n'est efficace que si l'infrastructure sous-jacente est très performante.
Consultez les paramètres actuels avec :
sudo gitlab-rails runner "c = ApplicationRecord.connection ; puts c.execute('SHOW statement_timeout').to_a ;
puts c.execute('SHOW deadlock_timeout').to_a ;
puts c.execute('SHOW idle_in_transaction_session_timeout').to_a ;"
La réponse peut prendre un peu de temps.
{"statement_timeout"=>"1min"}
{"deadlock_timeout"=>"0"}
{"idle_in_transaction_session_timeout"=>"1min"}
Ces paramètres peuvent être mis à jour dans /etc/gitlab/gitlab.rb avec :
postgresql['deadlock_timeout'] = '5s'
postgresql['statement_timeout'] = '15s'
postgresql['idle_in_transaction_session_timeout'] = '60s'
Une fois enregistré, reconfigurez GitLab pour que les modifications prennent effet.
[!note] Il s'agit de paramètres du package Linux. Si une base de données externe, telle qu'une installation PostgreSQL d'un client ou Amazon RDS, est utilisée, ces valeurs ne sont pas définies et devraient être configurées en externe.
[!warning] Les conseils suivants ne s'appliquent pas si PgBouncer est activé, car le délai d'expiration modifié pourrait affecter plus de transactions que prévu.
Dans certaines situations, il peut être souhaitable de définir un délai d'expiration des instructions différent sans avoir à reconfigurer GitLab, ce qui dans ce cas redémarrerait Puma et Sidekiq.
Par exemple, une sauvegarde peut échouer avec les erreurs suivantes dans la sortie de la commande de sauvegarde car le délai d'expiration des instructions était trop court :
pg_dump: error: Error message from server: server closed the connection unexpectedly
Vous pouvez également voir des erreurs dans les journaux PostgreSQL :
canceling statement due to statement timeout
Pour modifier temporairement le délai d'expiration des instructions :
Ouvrez /var/opt/gitlab/gitlab-rails/etc/database.yml dans un éditeur
Définissez la valeur de statement_timeout sur 0, ce qui définit un délai d'expiration des instructions illimité.
Confirmez dans une nouvelle session de console Rails que cette valeur est utilisée :
sudo gitlab-rails runner "ActiveRecord::Base.connection_db_config[:variables]"
Effectuez l'action pour laquelle vous avez besoin d'un délai d'expiration différent (par exemple la sauvegarde ou la commande Rails).
Annulez la modification dans /var/opt/gitlab/gitlab-rails/etc/database.yml.
Pour les déploiements cloud natifs utilisant des services PostgreSQL gérés (tels qu'AWS RDS, Azure Database pour PostgreSQL ou Google Cloud SQL), vous ne pouvez pas modifier directement le fichier de configuration de la base de données. À la place, configurez le paramètre statement_timeout via le groupe de paramètres ou l'interface de configuration de votre service cloud :
statement_timeout sur 0 (illimité).statement_timeout sur 0.statement_timeout sur 0.Après avoir apporté des modifications au groupe de paramètres ou à la configuration, vous devrez peut-être redémarrer l'instance de base de données pour que les modifications prennent effet. Consultez la documentation de votre fournisseur cloud pour obtenir des instructions spécifiques.
Dans certaines situations, vous pouvez vouloir observer la progression d'une opération CREATE INDEX ou REINDEX. Par exemple, vous pouvez le faire pour confirmer si l'opération CREATE INDEX ou REINDEX est active, ou pour vérifier dans quelle phase se trouve l'opération.
Prérequis :
Pour observer une opération CREATE INDEX ou REINDEX :
pg_stat_progress_create_index intégrée.Par exemple, depuis une session de console de base de données, exécutez la commande suivante :
SELECT * FROM pg_stat_progress_create_index \watch 0.2
Pour en savoir plus sur la production d'une sortie conviviale et l'écriture de données dans des fichiers journaux, consultez cet extrait.
Si vous rencontrez les erreurs suivantes, vérifiez si max_connections est suffisamment élevé pour garantir des connexions stables.
connection to server at "xxx.xxx.xxx.xxx", port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
psql: error: connection to server on socket "/var/opt/gitlab/postgresql/.s.PGSQL.5432" failed:
FATAL: sorry, too many clients already
Pour ajuster max_connections, consultez la configuration de plusieurs connexions à la base de données.
Cette erreur signifie probablement que autovacuum ne parvient pas à terminer son exécution :
ERROR: database is not accepting commands to avoid wraparound data loss in database "gitlabhq_production"
Ou
ERROR: failed to re-find parent key in index "XXX" for deletion target page XXX
Pour résoudre l'erreur, exécutez VACUUM manuellement :
Arrêtez GitLab avec la commande gitlab-ctl stop.
Placez la base de données en mode mono-utilisateur avec la commande :
/opt/gitlab/embedded/bin/postgres --single -D /var/opt/gitlab/postgresql/data gitlabhq_production
Dans l'invite backend>, exécutez VACUUM;. Cette commande peut prendre plusieurs minutes.
Attendez la fin de la commande, puis appuyez sur <kbd>Contrôle</kbd> + <kbd>D</kbd> pour quitter.
Démarrez GitLab avec la commande gitlab-ctl start.
Consultez les prérequis de base de données et examinez et installez la liste des extensions requises.
production/sidekiq {#serialization-errors-in-the-productionsidekiq-log}Si vous recevez des erreurs comme cet exemple dans votre journal production/sidekiq, renseignez-vous sur la définition de default_transaction_isolation sur read committed pour résoudre le problème :
ActiveRecord::StatementInvalid PG::TRSerializationFailure: ERROR: could not serialize access due to concurrent update
Si vous recevez des erreurs comme cet exemple, renseignez-vous sur la résolution des erreurs de slot de réplication PostgreSQL HA :
pg_basebackup: could not create temporary replication slot "pg_basebackup_12345": ERROR: all replication slots are in use
HINT: Free one or increase max_replication_slots.
Si vous recevez des erreurs comme cet exemple, renseignez-vous sur la résolution des erreurs de réplication Geo :
ERROR: replication slots can only be used if max_replication_slots > 0
FATAL: could not start WAL streaming: ERROR: replication slot "geo_secondary_my_domain_com" does not exist
Command exceeded allowed execution time
PANIC: could not write to file 'pg_xlog/xlogtemp.123': No space left on device
Lors du dépannage de problèmes avec Geo, vous devriez :
pg_dump et psql {#mismatch-in-pg_dump-and-psql-versions}Si vous recevez des erreurs comme cet exemple, renseignez-vous sur la façon de sauvegarder et restaurer une base de données PostgreSQL non packagée :
Dumping PostgreSQL database gitlabhq_production ... pg_dump: error: server version: 13.3; pg_dump version: 14.2
pg_dump: error: aborting because of server version mismatch
btree_gist n'est pas dans la liste d'autorisation {#extension-btree_gist-is-not-allow-listed}Le déploiement de PostgreSQL sur Azure Database pour PostgreSQL - Flexible Server peut entraîner cette erreur :
extension "btree_gist" is not allow-listed for "azure_pg_admin" users in Azure Database for PostgreSQL
Pour résoudre cette erreur, ajoutez l'extension à la liste d'autorisation avant l'installation.