Vérifiez si votre question ou votre problème a déjà été résolu sur l'une des pages suivantes :
- Questions fréquentes
- Problèmes connus
- Messages d'erreur
- Diagnostiquer les problèmes
- Déboguer les problèmes de connexion
Les thèmes traités sur cette page sont les suivants :
- Sauvegarde et récupération
- Clonage
- Connectivité
- Créer des instances
- Flags
- Haute disponibilité
- Importation et exportation
- Serveurs associés
- Logging
- Gérer les instances
- Private Service Connect
- Duplication
Sauvegarde et récupération
| Problème | Dépannage |
|---|---|
| Vous ne pouvez pas voir l'état de l'opération en cours. | Google Cloud Console signale les réussites ou les échecs d'exécution lorsque l'opération est terminée. Il n'est pas conçu pour afficher des avertissements ni d'autres mises à jour.
Exécutez la commande |
| Vous souhaitez savoir qui a initié une opération de sauvegarde à la demande. | L'interface utilisateur n'affiche pas l'utilisateur qui a lancé une opération.
Recherchez les utilisateurs dans les journaux et filtrez-les par texte. Vous devrez peut-être consulter les journaux d'audit pour obtenir des informations personnelles. Les fichiers journaux pertinents incluent :
|
| Une fois qu'une instance est supprimée, vous ne pouvez plus en effectuer de sauvegarde. | Une fois qu'une instance est définitivement supprimée, la récupération de données est impossible. Toutefois, si l'instance est restaurée, ses sauvegardes sont également restaurées. Pour en savoir plus sur la récupération d'une instance supprimée, consultez la section Sauvegardes de récupération. Si vous avez exporté les données, créez une instance puis importez les données pour recréer la base de données. Les données exportées sont écrites dans Cloud Storage, d'où sont lues les données importées. |
| La sauvegarde automatique demeure bloquée pendant de nombreuses heures et ne peut pas être annulée. | Les sauvegardes peuvent prendre beaucoup de temps en fonction de la taille de la base de données.
Si vous devez vraiment annuler l'opération, vous pouvez demander au service client d'effectuer une opération |
| Une opération de restauration peut échouer lorsqu'un ou plusieurs utilisateurs référencés dans le fichier de dump SQL n'existent pas. | Avant de restaurer un fichier de vidage SQL, tous les utilisateurs de la base de données qui possèdent des objets ou disposent d'autorisations sur les objets qu'elle contient doivent exister dans la base de données cible. Si ce n'est pas le cas, l'opération de restauration ne recrée pas les objets avec les autorisations ou la propriété d'origine.
Créez les utilisateurs de la base de données avant d'effectuer une restauration à partir du fichier de vidage SQL. |
| Vous souhaitez augmenter le nombre de jours pendant lesquels vous pouvez conserver les sauvegardes automatiques de sept à 30 jours ou plus. | Vous pouvez configurer le nombre de sauvegardes automatiques à conserver, mais vous ne pouvez pas en conserver moins de sept (valeur par défaut). Les sauvegardes automatiques sont régulièrement supprimées en fonction de la valeur de conservation configurée. Malheureusement, cela signifie que les sauvegardes visibles sont les seules sauvegardes automatiques à partir desquelles vous pourrez effectuer une restauration.
Pour conserver les sauvegardes indéfiniment, vous pouvez créer des sauvegardes à la demande, car elles ne sont pas supprimées de la même manière que les sauvegardes automatiques. Les sauvegardes à la demande sont conservées indéfiniment, c'est-à-dire jusqu'à leur suppression ou la suppression de l'instance à laquelle elles appartiennent. En revanche, comme les sauvegardes de ce type ne sont pas automatiquement supprimées, elles peuvent affecter la facturation. |
| La sauvegarde automatique a échoué et vous n'avez pas reçu de notification par e-mail. | Pour que Cloud SQL vous informe de l'état de la sauvegarde, configurez une alerte basée sur les journaux. |
| Vous ne parvenez pas à restaurer votre instance à l'aide de la commande Transact-SQL RESTORE ou de SQL Server Management Studio (SSMS). |
Cloud SQL ne permet pas de restaurer des instances via SSMS.
Pour restaurer votre instance, exécutez la commande gcloud sql import.
|
Cloner
| Problème | Dépannage |
|---|---|
Échec du clonage : erreur constraints/sql.restrictAuthorizedNetworks. |
L'opération de clonage est bloquée par la configuration Authorized Networks.
Les Authorized Networks sont configurés pour les adresses IP publiques dans la section "Connectivité" de Google Cloud Console, et le clonage n'est pas autorisé pour des raisons de sécurité.
Si possible, supprimez toutes les entrées |
Message d'erreur : Failed to create subnetwork. Couldn't find free
blocks in allocated IP ranges. Please allocate new ranges for this service
provider. Help Token: [help-token-id]. |
Vous essayez d'utiliser la console Google Cloud pour cloner une instance avec une adresse IP privée, mais vous n'avez pas spécifié la plage d'adresses IP allouée que vous souhaitez utiliser et l'instance source n'est pas créée avec la plage spécifiée. Par conséquent, l'instance clonée est créée dans une plage aléatoire. Utilisez |
Connect
| Problème | Dépannage |
|---|---|
Aborted connection. |
Cause possible :
Les applications doivent tolérer les défaillances du réseau et se baser sur les bonnes pratiques telles que le regroupement des connexions et les nouvelles tentatives. La plupart des regroupements de connexions interceptent ces erreurs lorsque cela est possible. Sinon, l'application doit réessayer ou échouer sans occasionner de blocage. Pour effectuer de nouvelles tentatives de connexion, nous vous recommandons les techniques suivantes :
La combinaison de ces techniques permet de réduire les limitations. |
Créer des instances
| Problème | Dépannage |
|---|---|
Message d'erreur : Failed to create subnetwork. Router status is
temporarily unavailable. Please try again later. Help Token:
[token-ID]. |
Essayez de créer à nouveau l'instance Cloud SQL. |
Message d'erreur : Failed to create subnetwork. Required
'compute.projects.get' permission for PROJECT_ID. |
Lorsque vous créez une instance à l'aide d'une adresse IP privée, un compte de service est créé avec le juste-à-temps à l'aide de l'API Service Networking. Si vous avez activé l'API Service Networking récemment, le compte de service peut ne pas être créé et la création de l'instance échoue. Dans ce cas, vous devez attendre que le compte de service se propage dans le système ou l'ajouter manuellement avec les autorisations requises. |
Exporter
| Problème | Dépannage |
|---|---|
HTTP Error 409: Operation failed because another operation was
already in progress. |
Une opération est déjà en attente pour votre instance. Il n'est possible d'exécuter qu'une seule opération à la fois. Envoyez votre requête lorsque l'opération en cours est terminée. |
HTTP Error 403: The service account does not have the required
permissions for the bucket. |
Assurez-vous que le bucket existe et que le compte de service de l'instance Cloud SQL (qui effectue l'exportation) dispose du rôle Storage Object Creator (roles/storage.objectCreator) pour autoriser l'exportation vers le bucket. Consultez la page Rôles IAM pour Cloud Storage. |
| Vous souhaitez automatiser les exportations. | Cloud SQL ne permet pas d'automatiser les exportations.
Vous pouvez créer votre propre système d'exportation automatisé à l'aide de produits Google Cloud tels que Cloud Scheduler, Pub/Sub et Cloud Functions, de manière semblable à cet article sur l'automatisation des sauvegardes. |
Options
| Problème | Dépannage |
|---|---|
| Cloud SQL pour SQL Server ne permet pas de modifier le fuseau horaire d'une instance existante. |
Dans Cloud SQL, SQL Server permet de définir le fuseau horaire d'une nouvelle instance, mais pas d'une instance existante. Dans Cloud SQL pour SQL Server, vous pouvez utiliser la fonction |
Haute disponibilité
| Problème | Dépannage |
|---|---|
| Vous ne trouvez pas les métriques d'un basculement manuel. | Seuls les basculements automatiques sont pris en compte dans les métriques. |
| L'utilisation des ressources d'instance Cloud SQL (processeur et mémoire RAM) arrive bientôt à 100 %, ce qui entraîne l'arrêt de l'instance à haute disponibilité. | La taille de la machine de l'instance est insuffisante pour la charge.
Modifiez l'instance en augmentant la taille de la machine afin d'obtenir plus de processeurs et de mémoire. |
Import
| Problème | Dépannage |
|---|---|
HTTP Error 409: Operation failed because another operation was already in progress. |
Une opération est déjà en attente pour votre instance. Il n'est possible d'exécuter qu'une seule opération à la fois. Envoyez votre requête lorsque l'opération en cours est terminée. |
| L'opération d'importation prend trop de temps. | Un trop grand nombre de connexions actives peut interférer avec les opérations d'importation.
Fermez les opérations inutilisées. Vérifiez l'utilisation du processeur et de la mémoire de votre instance Cloud SQL pour vous assurer que de nombreuses ressources sont disponibles. Le meilleur moyen de s'assurer de la présence d'un nombre maximal de ressources pour l'opération d'importation consiste à redémarrer l'instance avant de lancer l'importation. Un redémarrage :
|
| Une opération d'importation peut échouer lorsqu'un ou plusieurs utilisateurs référencés dans le fichier de dump n'existent pas. | Avant d'importer un fichier de dump, tous les utilisateurs de la base de données qui possèdent des objets ou disposent d'autorisations sur les objets qu'elle contient doivent exister dans la base de données cible. Si ce n'est pas le cas, l'opération d'importation ne parvient pas à recréer les objets en rétablissant les propriétaires ou les autorisations d'origine.
Créez les utilisateurs de la base de données avant de l'importer. |
| Incohérence du LSN | L'ordre d'importation des sauvegardes du journal des transactions est incorrect ou la chaîne du journal des transactions est interrompue. Importez les sauvegardes du journal des transactions dans le même ordre que celui de la table de l'ensemble de sauvegarde. |
| StopAt trop tôt | Cette erreur indique que le premier journal du fichier de journal des transactions se trouve après l'horodatage StopAt. Par exemple, si le premier journal du fichier de journal des transactions est au format 2023-09-01T12:00:00 et que le champ StopAt a la valeur 2023-09-01T11:00:00, Cloud SQL renvoie cette erreur.Assurez-vous d'utiliser le bon code temporel StopAt et le bon fichier de journal des transactions. |
Serveurs associés
| Message d'erreur | Dépannage |
|---|---|
Msg 7411, Level 16, State 1, Line 25
|
L'option DataAccess est désactivée. Exécutez la commande suivante pour activer l'accès aux données :
EXEC sp_serveroption
@server='LINKED_SERVER_NAME',
@optname='data access',
@optvalue='TRUE'
Remplacez LINKED_SERVER_NAME par le nom du serveur associé. |
Access to the remote server is denied because no
login-mapping exists. (Microsoft SQL Server, Error: 7416)
|
Si vous rencontrez ce problème lors de l'établissement d'une connexion chiffrée, vous devez essayer d'une autre manière de fournir l'ID utilisateur lorsque vous accédez au serveur associé. Pour ce faire, exécutez la commande suivante :EXEC master.dbo.sp_addlinkedserver @server = N'LINKED_SERVER_NAME', @srvproduct= N'', @provider= N'SQLNCLI', @datasrc= N'TARGET_SERVER_ID', @provstr= N'Encrypt=yes;TrustServerCertificate=yes;User ID=USER_ID' Remplacez les éléments suivants :
|
Journalisation
| Problème | Dépannage |
|---|---|
| Les journaux d'audit sont introuvables. | Les journaux d'accès aux données ne sont écrits que si l'opération est un appel d'API authentifié qui crée, modifie ou lit des données créées par l'utilisateur, ou si l'opération accède à des fichiers de configuration ou à des métadonnées de ressources. |
| Les informations sur les opérations sont introuvables dans les journaux. | Vous souhaitez obtenir davantage d'informations sur une opération.
Par exemple, un utilisateur a été supprimé, mais vous ne pouvez pas savoir qui est à l'origine de cette opération. Les journaux indiquent que l'opération a commencé, mais ne fournissent pas plus d'informations. Pour obtenir des informations détaillées et des informations permettant d'identifier personnellement l'utilisateur telles que celles-ci, vous devez activer la journalisation d'audit. |
Certains journaux sont filtrés à partir du journal error.log d'une instance Cloud SQL pour SQL Server.
|
Les journaux filtrés incluent les journaux AD sans horodatage, et incluent les éléments suivants : Login failed for user 'x'. Reason: Token-based server access
validation failed with an infrastructure error. Login lacks connect endpoint
permission. [CLIENT: 127.0.0.1]. Ces journaux sont filtrés, car ils peuvent prêter à confusion.
|
| Les fichiers journaux sont difficiles à lire. | Vous préférez afficher les journaux au format JSON ou texte. Pour télécharger les journaux, vous pouvez utiliser la commande gcloud logging read avec les commandes Linux de post-traitement.
Pour télécharger les journaux au format JSON, procédez comme suit :
gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json
Pour télécharger les journaux au format TEXT, procédez comme suit : gcloud logging read \ "resource.type=cloudsql_database \ AND logName=projects/PROJECT_ID \ /logs/cloudsql.googleapis.com%2FLOG_NAME" \ --format json \ --project=PROJECT_ID \ --freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \ | .textPayload' \ --order=asc > downloaded-log.txt |
Gérer les instances
| Problème | Dépannage |
|---|---|
| L'espace de stockage temporaire a entraîné l'augmentation automatique de l'espace de stockage. | L'augmentation automatique de l'espace de stockage est activée.
Le redémarrage supprime les fichiers temporaires sans réduire l'espace de stockage. Seul le service client est en mesure de réinitialiser la taille de l'instance. |
| Les données sont automatiquement supprimées. | Il est probable qu'un script s'exécute quelque part dans votre environnement.
Examinez les journaux au moment de la suppression et vérifiez si un script malveillant est en cours d'exécution à partir d'un tableau de bord ou d'un autre processus automatisé. |
| Impossible de supprimer l'instance. | Le message d'erreur ERROR: (gcloud.sql.instances.delete) HTTP Error
409: The instance or operation is not in an appropriate state to handle the
request s'affiche, ou l'instance affiche INSTANCE_RISKY_FLAG_CONFIG pour l'état d'une option.Voici quelques explications possibles :
|
| L'instance se bloque en raison du volume important des données temporaires. | Le système peut créer plusieurs tables temporaires à la fois, en fonction des requêtes et de la charge.
Malheureusement, vous ne pouvez réduire le fichier L'une des mesures d'atténuation consiste à créer la table temporaire avec |
| Erreur fatale lors de la mise à niveau. | Les journaux peuvent fournir davantage d'informations, mais dans tous les cas, vous devrez peut-être contacter le service client pour forcer la recréation de l'instance. |
| L'instance se bloque au redémarrage après avoir épuisé l'espace disque. | La fonctionnalité d'augmentation automatique de l'espace de stockage n'est pas activée.
Si l'espace de stockage de votre instance est insuffisant et que la fonctionnalité d'augmentation automatique de l'espace de stockage n'est pas activée, l'instance se déconnecte. Pour éviter ce problème, vous pouvez modifier l'instance afin d'activer l'augmentation automatique de l'espace de stockage. |
| Blocage de l'instance principale sur site | Google Cloud ne peut pas vous aider avec des instances qui ne sont pas dans Cloud SQL. |
| Arrêt lent au redémarrage. | Lorsqu'une instance s'arrête, toutes les connexions en attente qui ne se terminent pas au bout de 60 secondes entraînent un arrêt incorrect.
En limitant les connexions à moins de 60 secondes, y compris les connexions à partir de l'invite de commande de base de données, vous pouvez éviter la plupart des arrêts non propres. Si vous laissez ces connexions ouvertes pendant des heures ou plusieurs jours, cela peut entraîner des arrêts incorrects. |
| Impossible de supprimer un utilisateur. | L'utilisateur dispose d'objets dans la base de données qui en dépendent. Vous devez supprimer ces objets ou les réattribuer à un autre utilisateur.
Identifiez les objets qui dépendent de l'utilisateur, puis supprimez-les ou réattribuez-les à un autre utilisateur. Ce fil de discussion sur Stack Exchange explique comment rechercher les objets appartenant à l'utilisateur. |
| Certaines requêtes sont lentes. | Les requêtes peuvent être lentes pour de nombreuses raisons, principalement à cause de certains aspects de la base de données. L'une des raisons pouvant impliquer Cloud SQL est la latence du réseau, lorsque la ressource source (rédacteur ou lecteur) et la ressource de destination (Cloud SQL) se trouvent dans différentes régions.
Reportez-vous aux conseils généraux sur les performances, en particulier. Pour les insertions, mises à jour ou suppressions lentes de bases de données, envisagez les actions suivantes :
Pour réduire la latence, nous vous recommandons de placer les ressources sources et de destination dans la même région. |
| Mémoire insuffisante signalée, mais non reportée dans les graphiques de surveillance. | Une instance peut échouer et signaler Out of memory, mais les graphiques Cloud Monitoring ou Google Cloud Console semblent indiquer qu'il reste encore de la mémoire.
En dehors de votre charge de travail, d'autres facteurs peuvent avoir une incidence sur l'utilisation de la mémoire, tels que le nombre de connexions actives et les processus internes. Ils ne sont pas toujours reflétés dans les graphiques de surveillance. Assurez-vous que l'instance dispose d'une marge suffisante pour prendre en compte votre charge de travail et une utilisation supplémentaire de la mémoire. |
| Récupérer une instance supprimée. | Toutes les données d'une instance, y compris les sauvegardes, sont définitivement perdues lors de sa suppression.
Pour conserver vos données, exportez-les vers Cloud Storage avant de supprimer l'instance. Le rôle d'administrateur Cloud SQL inclut l'autorisation de supprimer l'instance. Pour éviter toute suppression accidentelle, accordez ce rôle uniquement si nécessaire. |
| Vous souhaitez renommer une instance Cloud SQL existante. | Il n'est pas possible de renommer une instance existante.
Il existe d'autres façons d'atteindre cet objectif en créant une instance.
Dans les deux cas, vous pouvez supprimer votre ancienne instance une fois l'opération terminée. Nous vous recommandons d'opter pour le clonage, car il n'a aucune incidence sur les performances et ne nécessite aucune répétition des paramètres de configuration de l'instance (tels que les options, le type de machine, la taille de stockage et la mémoire). |
| Erreur lors de la suppression d'une instance. | Si la protection contre la suppression est activée pour une instance, confirmez que vous souhaitez supprimer cette instance. Ensuite, désactivez la protection contre la suppression avant de supprimer l'instance. |
Private Service Connect
| Problème | Dépannage |
|---|---|
| Le rattachement de service de l'instance n'accepte pas le point de terminaison Private Service Connect. |
|
Réplication
| Problème | Dépannage |
|---|---|
| L'instance répliquée avec accès en lecture n'a pas commencé à se répliquer lors de la création. | Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question. |
| Impossible de créer l'instance dupliquée avec accès en lecture : erreur invalidFlagValue. | L'un des indicateurs de la requête n'est pas valide. Il peut s'agir d'une option que vous avez explicitement définie ou d'une option définie sur une valeur par défaut.
Tout d'abord, vérifiez que la valeur de l'option Si l'option |
| Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue. | Les fichiers journaux indiquent probablement une erreur plus spécifique.
Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question.
Si l'erreur est : |
| Le disque est saturé. | Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée. Modifiez l'instance principale en augmentant la taille du disque. |
| L'instance dupliquée utilise trop de mémoire. | L'instance dupliquée met en cache les opérations de lecture souvent demandées dans une mémoire temporaire, ce qui peut l'amener à utiliser plus de mémoire que l'instance principale.
Redémarrez l'instance dupliquée afin de récupérer l'espace de mémoire temporaire. |
| La duplication s'est arrêtée. | La limite de stockage maximale a été atteinte et l'augmentation automatique de l'espace de stockage n'est pas activée.
Modifiez l'instance pour activer |
| Le délai de duplication est systématiquement long. | La charge d'écriture est trop élevée pour que l'instance dupliquée puisse la traiter. Le délai de duplication s'allonge lorsque le thread SQL d'une instance dupliquée ne parvient pas à suivre le thread d'E/S. Certains types de requêtes ou de charges de travail peuvent allonger le délai de duplication de manière temporaire ou permanente pour un schéma donné. Voici quelques causes typiques affectant le délai de duplication :
Voici quelques solutions possibles :
|
| La création d'une instance dupliquée échoue avec un délai d'expiration. | Les transactions non validées de longue durée sur l'instance principale peuvent entraîner l'échec de la création d'une instance dupliquée avec accès en lecture.
Recréez l'instance dupliquée après avoir arrêté toutes les requêtes en cours d'exécution. |