Dépanner les bases de données

Identifier la base de données concernée

Dans le volet Database, vérifiez si le problème touche le développement ou la production. Comparez avec l’environnement qui exécute la requête en échec. Consultez Bases de données de développement et de production. Consultez Replit Status pour voir si un incident correspond. Ne déduisez pas une panne uniquement à partir d’une erreur de connexion.

« The endpoint has been disabled »

Vérifiez s’il existe un problème de facturation en suspens ou une restriction d’utilisation.
Ouvrez le volet Database et sélectionnez l’environnement concerné.
Si Unpause database est disponible, sélectionnez-le, puis réessayez la connexion.
Si le contrôle est absent, vérifiez si un DATABASE_URL configuré manuellement pointe vers une base de données différente de celle affichée dans le volet.

Comparez les paramètres de connexion en privé. N’affichez pas et ne partagez pas la chaîne de connexion complète. Ne supprimez pas une configuration de base de données externe volontaire. Si la réactivation échoue, ou si le contrôle reste absent, contactez le support en indiquant l’environnement, l’erreur et les étapes tentées. Redémarrer à répétition ne remplace pas l’examen d’une base de données suspendue.

Preview se connecte, mais pas l’application publiée

Vérifiez les secrets de production et la configuration de base de données de l’application publiée, surtout après une restauration ou une migration. Les secrets de l’espace de travail seuls ne vérifient pas la connexion de production. Dans Publishing, examinez Adjust settings et les secrets de production. Si votre application utilise à la fois DATABASE_URL et des variables PostgreSQL individuelles, assurez-vous qu’elles désignent la même base de données voulue. Enregistrez et publiez la configuration voulue, puis vérifiez une lecture avant de tester les écritures. Ne copiez jamais d’identifiants de production dans le code frontend ou un dépôt public.

Des tables ou des enregistrements manquent

Vérifiez d’abord quelle base de données l’application lit. Une base de développement vide ou une cible de connexion différente peut ressembler à une perte de données. Vérifiez si une migration récente a modifié les noms de tables ou le schéma. Publier le code de l’application ne prouve pas que les enregistrements de développement ont été copiés en production. N’exécutez pas de réinitialisation, ne supprimez pas de tables et ne copiez pas les données de développement sur la production comme étape de diagnostic.

Objets de base de données non pris en charge

Replit utilise drizzle-kit, l’outil de migration de Drizzle ORM, pour gérer vos bases de données à deux moments :

En développement, Agent met à jour votre fichier de schéma Drizzle et exécute drizzle-kit pour l’appliquer à votre base de données de développement.
Lors de la publication, Replit compare votre base de données de développement avec votre base de données de production et génère le SQL nécessaire pour mettre la production à jour. Il compare les bases de données elles-mêmes, pas votre fichier de schéma.

Drizzle-kit ne gère que ce qu’un schéma Drizzle peut décrire : tables, colonnes, index, contraintes, enums, séquences, vues et politiques de sécurité au niveau des lignes.

Non pris en charge

Ces objets ne font pas partie d’un schéma Drizzle ; drizzle-kit ne peut donc pas les comparer ni les créer en développement, et la publication ne les copie pas en production :

Domaines, types personnalisés créés avec CREATE DOMAIN.
Fonctions, procédures et déclencheurs (triggers).
Autorisations (grants), permissions de table accordées avec GRANT.

Prise en charge limitée : les rôles

Drizzle peut déclarer des rôles, mais leur prise en charge est limitée. Par conséquent, la publication ne crée, ne modifie ni ne supprime actuellement de rôles.

Objets créés avec SQL

Vous pouvez créer manuellement n’importe lequel des objets non pris en charge ci-dessus via la console SQL, et Agent peut aussi exécuter du SQL directement sur votre base de données de développement. Ils fonctionneront en développement et dans Preview, mais les objets non pris en charge ne seront pas copiés en production lors de la publication.

Ce qui se passe lorsqu’un objet n’est pas pris en charge

Si une table, une vue, une valeur par défaut ou une politique dépend de l’un de ces objets, la publication s’arrête à la migration de la base de données avec une erreur telle que :

function my_function(text) does not exist
type "my_domain" does not exist
role "app_user" does not exist

Replit annule la migration échouée, de sorte que votre base de données de production n’est pas modifiée. Les déclencheurs et les autorisations ne provoquent généralement pas d’erreur. La publication réussit, mais votre application publiée peut se comporter différemment de Preview. Par exemple, un déclencheur qui met à jour un horodatage ne s’exécute pas en production. Dans les deux cas, trouvez ce qui manque et appliquez-le à la production, puis publiez à nouveau.

Trouver ce qui manque en production

Agent peut effectuer cette comparaison pour vous, car il dispose d’un accès en lecture seule à votre base de données de production. Consultez le prompt dans Appliquer les objets manquants à la production. Pour vérifier vous-même, exécutez les mêmes requêtes en lecture seule sur les deux bases de données depuis la console SQL, puis comparez les résultats :

-- Functions you created (excludes functions installed by extensions)
SELECT p.proname FROM pg_proc p
WHERE p.pronamespace = 'public'::regnamespace
  AND NOT EXISTS (
    SELECT 1 FROM pg_depend d WHERE d.objid = p.oid AND d.deptype = 'e'
  )
ORDER BY 1;

-- Triggers
SELECT DISTINCT event_object_table, trigger_name
FROM information_schema.triggers
ORDER BY 1, 2;

-- Domains
SELECT typname FROM pg_type
WHERE typtype = 'd' AND typnamespace = 'public'::regnamespace
ORDER BY 1;

-- Roles
SELECT rolname FROM pg_roles
WHERE rolname NOT LIKE 'pg\_%'
ORDER BY 1;

-- Grants to roles other than the one you're connected as
SELECT table_name, grantee, privilege_type
FROM information_schema.role_table_grants
WHERE table_schema = 'public' AND grantee <> current_user
ORDER BY 1, 2, 3;

Tout ce qui apparaît uniquement en développement doit être appliqué à la production. Certains rôles sont créés par Replit et diffèrent entre les deux bases de données ; vous n’avez besoin que des rôles utilisés par les politiques ou les autorisations de votre application.

Appliquer les objets manquants à la production

Avancé : ces étapes exécutent du SQL directement sur votre base de données de production active pour ajouter des objets que la publication ne reprend pas, comme les fonctions, les déclencheurs et les rôles. L’exécution manuelle de SQL est un flux non pris en charge pour lequel nous ne pouvons apporter qu’une aide limitée ; nous le recommandons donc uniquement si vous êtes à l’aise avec SQL.Examinez d’abord vos options dans Récupération des données, et appliquez les changements lorsque votre application a peu de trafic.

Demandez à Agent de comparer vos bases de données et d’écrire un script pour tout ce qui manque. Collez ce prompt dans Agent dans votre projet : Agent peut lire votre base de données de production mais ne peut pas la modifier ; vous exécutez donc le script vous-même dans les étapes suivantes.
Dans l’outil Database, sélectionnez la base de données de production, ouvrez My Data, et activez Enable Editing.
Ouvrez la console SQL et exécutez le script.
Désactivez Enable Editing, puis publiez à nouveau.

La publication ne supprime pas ces objets : ils restent en place pour les publications futures. Conservez le script dans votre projet et réexécutez-le chaque fois que vous ajoutez ou modifiez l’un de ces objets en développement.

Des données ont été supprimées ou écrasées

Arrêtez les écritures évitables sur les données concernées pendant l’évaluation de la récupération. Une restauration peut remplacer des données plus récentes. Préservez l’état actuel et comprenez l’étendue avant de confirmer une action de récupération.

Notez l’environnement concerné, l’heure approximative de la dernière version correcte connue avec son fuseau horaire, et ce qui a changé. Consultez les options de récupération et l’historique disponible affichés pour cette base de données. La conservation et les méthodes de récupération dépendent de la base de données et de la configuration ; ne supposez pas qu’un horodatage plus ancien est récupérable. Utilisez les instructions propres à la base de données dans Récupération de données. Ne supposez pas que la restauration du code de l’application rétablit aussi les données de production. Contactez le support si vous ne parvenez pas à identifier une voie de récupération sûre. La récupération n’est pas garantie, et augmenter la conservation ne peut pas recréer un historique qui n’a pas été conservé.

Des identifiants ont peut-être été exposés

Retirez les valeurs exposées des documents partagés. Pour une base de données de production prise en charge, régénérez ses identifiants dans l’outil Database. Examinez d’abord les conditions d’éligibilité et l’avertissement d’interruption. Mettez à jour les clients externes avec la nouvelle chaîne de connexion. Si l’action n’est pas disponible, contactez le support. Ne supprimez pas la base de données pour effectuer la rotation des identifiants.

Détails à fournir au support

Incluez l’URL du projet, l’environnement, l’erreur nettoyée, l’heure et le fuseau horaire, les migrations ou restaurations récentes et les vérifications déjà effectuées. N’incluez pas d’identifiants de base de données, de chaînes de connexion complètes ni de données clients. Consultez la liste de vérification du support.

​Identifier la base de données concernée

​« The endpoint has been disabled »

​Preview se connecte, mais pas l’application publiée

​Des tables ou des enregistrements manquent

​Objets de base de données non pris en charge

​Non pris en charge

​Prise en charge limitée : les rôles

​Objets créés avec SQL

​Ce qui se passe lorsqu’un objet n’est pas pris en charge

​Trouver ce qui manque en production

​Appliquer les objets manquants à la production

​Des données ont été supprimées ou écrasées

​Des identifiants ont peut-être été exposés

​Détails à fournir au support

Identifier la base de données concernée

« The endpoint has been disabled »

Preview se connecte, mais pas l’application publiée

Des tables ou des enregistrements manquent

Objets de base de données non pris en charge

Non pris en charge

Prise en charge limitée : les rôles

Objets créés avec SQL

Ce qui se passe lorsqu’un objet n’est pas pris en charge

Trouver ce qui manque en production

Appliquer les objets manquants à la production

Des données ont été supprimées ou écrasées

Des identifiants ont peut-être été exposés

Détails à fournir au support