Prüfen Sie, ob Ihre Frage oder das Problem bereits auf einer der folgenden Seiten beantwortet wurde:
Folgende Themen werden auf dieser Seite behandelt:
- Sicherung und Wiederherstellung
- Klonen
- Verbindung
- Instanzen erstellen
- Flags
- Hochverfügbarkeit
- Import und Export
- Verknüpfte Server
- Logging
- Instanzen verwalten
- Private Service Connect
- Replikation
Sicherung und Wiederherstellung
| Problem | Fehlerbehebung |
|---|---|
| Der Status des aktuellen Vorgangs wird nicht angezeigt. | Die Google Cloud Console meldet erfolgreiche oder fehlgeschlagene Vorgänge nur, wenn diese abgeschlossen sind. Es werden keine Warnungen oder andere Updates angezeigt.
Führen Sie den
Befehl |
| Sie möchten wissen, wer einen On-Demand-Sicherungsvorgang ausgelöst hat. | Auf der Benutzeroberfläche wird nicht der Nutzer angezeigt, der einen Vorgang gestartet hat.
Suchen Sie in den Logs und filtern Sie nach Text, um den Nutzer zu finden. Möglicherweise müssen Sie Audit-Logs für private Informationen verwenden. Zu den relevanten Logdateien gehören:
|
| Nach dem Löschen einer Instanz können Sie keine Sicherung mehr davon erstellen. | Nachdem eine Instanz dauerhaft gelöscht wurde, ist keine Datenwiederherstellung mehr möglich. Wenn die Instanz jedoch wiederhergestellt wird, werden auch ihre Sicherungen wiederhergestellt. Weitere Informationen zum Wiederherstellen einer gelöschten Instanz finden Sie unter Wiederherstellungssicherungen. Wenn Sie einen Exportvorgang durchgeführt haben, können Sie eine neue Instanz erstellen und dann mit einem Importvorgang die Datenbank neu erstellen. Exporte werden in Cloud Storage geschrieben und Importe werden von dort gelesen. |
| Eine automatische Sicherung bleibt viele Stunden hängen und kann nicht abgebrochen werden. | Sicherungen können je nach Datenbankgröße sehr lange dauern.
Wenn Sie den Vorgang wirklich abbrechen müssen, können Sie den Kundensupport bitten, einen Neustart der Instanz zu erzwingen ( |
| Ein Wiederherstellungsvorgang kann fehlschlagen, wenn ein oder mehrere Nutzer, auf die in der SQL-Dumpdatei verwiesen wird, nicht vorhanden sind. | Vor dem Wiederherstellen eines SQL-Dumps müssen alle Datenbanknutzer, die Inhaber von Objekten in der Dumpdatenbank sind oder Berechtigungen dafür haben, in der Zieldatenbank vorhanden sein. Andernfalls kann der Wiederherstellungsvorgang die Objekte nicht mit den ursprünglichen Eigentumsrechten oder Berechtigungen neu erstellen.
Erstellen Sie die Datenbanknutzer, bevor Sie den SQL-Dump wiederherstellen. |
| Sie möchten die Anzahl der Tage für die Aufbewahrung automatischer Sicherungen von sieben auf 30 Tage oder länger erhöhen. | Sie können die Anzahl der automatischen Sicherungen konfigurieren, die beibehalten werden sollen, aber nicht weniger als den Standardwert (sieben) beibehalten. Automatische Sicherungen werden basierend auf dem konfigurierten Aufbewahrungswert regelmäßig entfernt. Leider bedeutet dies, dass die jeweils aktuell sichtbaren Sicherungen die einzigen automatischen Sicherungen sind, aus denen Sie wiederherstellen können.
Wenn Sie Sicherungen unbegrenzt aufbewahren möchten, können Sie eine On-Demand-Sicherung erstellen, da diese nicht auf dieselbe Weise wie automatische Sicherungen gelöscht wird. On-Demand-Sicherungen werden für unbegrenzte Zeit aufbewahrt. Das heißt, sie bleiben so lange erhalten, bis sie gelöscht werden, oder bis die Instanz gelöscht wird, zu der sie gehören. Da diese Art der Sicherung nicht automatisch gelöscht wird, kann sich dies auf die Abrechnung auswirken. |
| Eine automatische Sicherung ist fehlgeschlagen und Sie haben keine E-Mail-Benachrichtigung erhalten. | Wenn Sie von Cloud SQL über den Status der Sicherung benachrichtigt werden möchten, konfigurieren Sie eine logbasierte Benachrichtigung. |
| Sie können Ihre Instanz nicht mit dem Transact-SQL-RESTORE-Befehl oder dem SQL Server Management Studio (SSMS) wiederherstellen. |
Cloud SQL unterstützt keine Wiederherstellung von Instanzen über SSMS.
Führen Sie den Befehl
gcloud sql import aus, um Ihre Instanz wiederherzustellen.
|
Klonen
| Problem | Fehlerbehebung |
|---|---|
Der Klonvorgang schlägt mit dem Fehler constraints/sql.restrictAuthorizedNetworks fehl. |
Der Klonvorgang wird durch die Authorized Networks-Konfiguration blockiert.
Authorized Networks sind für öffentliche IP-Adressen im Bereich „Verbindung“ der Google Cloud Console konfiguriert und das Klonen ist aufgrund von Sicherheitsaspekten nicht zulässig.
Entfernen Sie nach Möglichkeit alle |
Fehlermeldung: 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]. |
Sie versuchen, die Google Cloud Console zu verwenden, um eine Instanz mit einer privaten IP-Adresse zu klonen, aber Sie haben den zugewiesenen IP-Bereich, den Sie verwenden möchten, nicht angegeben, und die Quellinstanz wird nicht mit dem angegebenen Bereich erstellt. Dadurch wird die geklonte Instanz in einem zufälligen Bereich erstellt. Klonen Sie mit |
Verbinden
| Problem | Fehlerbehebung |
|---|---|
Aborted connection. |
Mögliche Ursache:
Anwendungen sollten Netzwerkfehler tolerieren und gemäß den Best Practices mit Verbindungs-Pooling und Wiederholungsversuchen arbeiten. Die meisten Verbindungs-Pooler erfassen diese Fehler nach Möglichkeit. Andernfalls muss die Anwendung einen Wiederholungsversuch ausführen oder ordnungsgemäß fehlschlagen. Für einen erneuten Verbindungsversuch empfehlen wir die folgenden Methoden:
Durch die Kombination dieser Methoden wird die Drosselung reduziert. |
Instanzen erstellen
| Problem | Fehlerbehebung |
|---|---|
Fehlermeldung: Failed to create subnetwork. Router status is
temporarily unavailable. Please try again later. Help Token:
[token-ID]. |
Versuchen Sie noch einmal, die Cloud SQL-Instanz zu erstellen. |
Fehlermeldung: Failed to create subnetwork. Required
'compute.projects.get' permission for PROJECT_ID. |
Wenn Sie eine Instanz mithilfe einer privaten IP-Adresse erstellen, wird mit der Service Networking API zur richtigen Zeit ein Dienstkonto erstellt. Wenn Sie die Service Networking API erst vor Kurzem aktiviert haben, wird das Dienstkonto möglicherweise nicht erstellt und die Instanzerstellung schlägt fehl. In diesem Fall müssen Sie warten, bis das Dienstkonto im gesamten System verteilt wurde, oder es manuell mit den erforderlichen Berechtigungen hinzufügen. |
Exportieren
| Problem | Fehlerbehebung |
|---|---|
HTTP Error 409: Operation failed because another operation was
already in progress. |
Für Ihre Instanz steht bereits ein Vorgang aus. Es ist jeweils nur ein Vorgang zulässig. Senden Sie Ihre Anfrage, nachdem der aktuelle Vorgang abgeschlossen ist. |
HTTP Error 403: The service account does not have the required
permissions for the bucket. |
Prüfen Sie, ob der Bucket vorhanden ist und das Dienstkonto für die Cloud SQL-Instanz (die den Export durchführt) die Rolle Storage Object Creator (roles/storage.objectCreator) hat, um den Export in den Bucket zu ermöglichen. Siehe IAM-Rollen für Cloud Storage. |
| Sie möchten Exporte automatisieren. | Cloud SQL bietet keine Möglichkeit, Exporte zu automatisieren.
Sie können Ihr eigenes automatisiertes Exportsystem mit Google Cloud-Produkten wie Cloud Scheduler, Pub/Sub und Cloud Functions erstellen, ähnlich wie in diesem Artikel zur Automatisierung von Sicherungen. |
Flags
| Problem | Fehlerbehebung |
|---|---|
| Sie möchten die Zeitzone für eine Cloud SQL-Instanz ändern. |
Informationen zum Aktualisieren der Zeitzone einer Instanz finden Sie unter Instanzeinstellungen. In Cloud SQL for SQL Server können Sie die Funktion |
Hochverfügbarkeit
| Problem | Fehlerbehebung |
|---|---|
| Sie können die Messwerte für ein manuelles Failover nicht finden. | Nur automatische Failovers werden in den Messwerten aufgenommen. |
| Cloud SQL-Instanzressourcen (CPU und RAM) sind zu fast 100 % ausgelastet, wodurch die Hochverfügbarkeitsinstanz abstürzt. | Die Rechnerkapazitäten der Instanz reichen für die Arbeitslast nicht aus.
Bearbeiten Sie die Instanz, um ein Upgrade auf einen Rechner mit höherer Kapazität durchzuführen, sodass mehr CPUs und Speicherplatz verfügbar sind. |
Importieren
| Problem | Fehlerbehebung |
|---|---|
HTTP Error 409: Operation failed because another operation was already in progress. |
Für Ihre Instanz steht bereits ein Vorgang aus. Es ist jeweils nur ein Vorgang zulässig. Senden Sie Ihre Anfrage, nachdem der aktuelle Vorgang abgeschlossen ist. |
| Der Importvorgang dauert zu lange. | Zu viele aktive Verbindungen können Importvorgänge beeinträchtigen.
Schließen Sie nicht verwendete Vorgänge. Prüfen Sie die CPU- und Arbeitsspeichernutzung Ihrer Cloud SQL-Instanz, um dafür zu sorgen, dass genügend Ressourcen verfügbar sind. Die beste Methode, um maximale Ressourcen für den Import zu gewährleisten, ist ein Neustart der Instanz vor Beginn des Vorgangs. Ein Neustart
|
| Ein Importvorgang kann fehlschlagen, wenn ein oder mehrere Nutzer, auf die in der Dumpdatei verwiesen wird, nicht vorhanden sind. | Vor dem Importieren einer Dumpdatei müssen alle Datenbanknutzer, die Inhaber von Objekten sind oder Berechtigungen für Objekte in der Dumpdatenbank erhalten haben, in der Zieldatenbank vorhanden sein. Andernfalls kann der Importvorgang die Objekte nicht mit den ursprünglichen Eigentumsrechten oder Berechtigungen neu erstellen.
Erstellen Sie die Datenbanknutzer vor dem Import. |
| LSN stimmt nicht überein | Die Reihenfolge des Imports der Transaktionslog-Backups ist falsch oder die Transaktionslogkette ist fehlerhaft. Importieren Sie die Transaktionslog-Backups in der Reihenfolge, die Sie in der Tabelle der Sicherungssätze vorfinden. |
| StopAt zu früh | Dieser Fehler gibt an, dass das erste Protokoll in der Transaktionsprotokolldatei nach dem Zeitstempel StopAt liegt. Beispiel: Wenn das erste Log in der Transaktionslogdatei auf 2023-09-01T12:00:00 gesetzt ist und das StopAt-Feld den Wert 2023-09-01T11:00:00 hat, gibt Cloud SQL diesen Fehler zurück.Achten Sie darauf, dass Sie den richtigen StopAt-Zeitstempel und die richtige Transaktionsprotokolldatei verwenden. |
Verknüpfte Server
| Fehlermeldung | Fehlerbehebung |
|---|---|
Msg 7411, Level 16, State 1, Line 25
|
Die Option DataAccess ist deaktiviert. Führen Sie den folgenden Befehl aus, um den Datenzugriff zu aktivieren:EXEC sp_serveroption @server='LINKED_SERVER_NAME', @optname='data access', @optvalue='TRUE' Ersetzen Sie LINKED_SERVER_NAME durch den Namen des verknüpften Servers. |
Access to the remote server is denied because no
login-mapping exists. (Microsoft SQL Server, Error: 7416)
|
Wenn dieses Problem bei der Herstellung einer verschlüsselten Verbindung auftritt, müssen Sie eine andere Methode angeben, um die Nutzer-ID beim Zugriff auf den verknüpften Server anzugeben. Führen Sie hierzu den folgenden Befehl aus:
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' Ersetzen Sie Folgendes:
|
Logging
| Problem | Fehlerbehebung |
|---|---|
| Audit-Logs wurden nicht gefunden. | Logs zum Datenzugriff werden nur geschrieben, wenn der Vorgang ein authentifizierter, nutzergesteuerter API-Aufruf ist, der von Nutzern erstellte Daten erstellt, ändert oder liest, oder wenn der Vorgang auf Konfigurationsdateien oder Metadaten von Ressourcen zugreift. |
| Vorgangsinformationen wurden nicht in Logs gefunden. | Sie möchten weitere Informationen zu einem Vorgang erhalten.
Beispiel: Ein Nutzer wurde gelöscht, aber Sie können nicht sehen, wer ihn gelöscht hat. Die Logs zeigen den gestarteten Vorgang an, enthalten jedoch keine weiteren Informationen. Für die Erfassung detaillierter und personenidentifizierbarer Informationen wie diesen müssen Sie Audit-Logging aktivieren. |
Einige Logs werden aus dem Log error.log einer Cloud SQL for SQL Server-Instanz gefiltert.
|
Gefilterte Logs inkludieren AD-Logs ohne Zeitstempel und umfassen: 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]. Diese Logs werden gefiltert, da sie möglicherweise zu Verwirrung führen.
|
| Logdateien sind schwer zu lesen. | Sie können die Logs alternativ im JSON- oder Textformat aufrufen. Sie können zum Herunterladen der Logs den Befehl gcloud logging read zusammen mit Linux-Nachbearbeitungsbefehlen verwenden.
So laden Sie die Logs im JSON-Format herunter: 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 So laden Sie die Logs als TEXT herunter: 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 |
Instanzen verwalten
| Problem | Fehlerbehebung |
|---|---|
| Automatischer Speicher wurde durch temporären Speicher erhöht. | Der automatische Speicher ist aktiviert.
Durch den Neustart werden die temporären Dateien gelöscht, der Speicherplatz wird jedoch nicht reduziert. Nur der Kundensupport kann die Instanzgröße zurücksetzen. |
| Daten werden automatisch gelöscht. | Höchstwahrscheinlich wird irgendwo in Ihrer Umgebung ein Skript ausgeführt.
Sehen Sie in den Logs zur Zeit des Löschvorgangs nach, ob ein schädliches Skript über ein Dashboard oder einen anderen automatisierten Prozess ausgeführt wird. |
| Instanz kann nicht gelöscht werden. | Sie sehen möglicherweise die Fehlermeldung ERROR: (gcloud.sql.instances.delete) HTTP Error
409: The instance or operation is not in an appropriate state to handle the
request oder die Instanz hat möglicherweise den Flag-Status INSTANCE_RISKY_FLAG_CONFIG.Im Folgenden sind einige mögliche Erklärungen aufgeführt:
|
| Instanz bleibt aufgrund großer temporärer Datenmengen hängen. | Abhängig von den Abfragen und der Auslastung kann das System viele temporäre Tabellen gleichzeitig erstellen.
Sie können die Eine Möglichkeit, das Problem zu beheben, besteht darin, die temporäre Tabelle mit |
| Schwerwiegender Fehler beim Upgrade. | Die Logs enthalten zwar möglicherweise weitere Informationen, aber wahrscheinlich benötigen Sie Hilfe vom Kundensupport, um die Neuerstellung der Instanz zu erzwingen. |
| Instanz bleibt beim Neustart hängen, nachdem der Speicherplatz ausgeschöpft ist. | Die automatische Speichererweiterung ist nicht aktiviert.
Wenn der Speicherplatz Ihrer Instanz aufgebraucht ist und die automatische Speichererweiterung nicht aktiviert ist, wird die Instanz offline geschaltet. Dies können Sie vermeiden, wenn Sie die Instanz bearbeiten und die automatische Speichererweiterung aktivieren. |
| Die lokale primäre Instanz bleibt hängen | Google Cloud bietet für Instanzen, die nicht in Cloud SQL enthalten sind, keine Unterstützung. |
| Langsames Herunterfahren beim Neustart. | Beim Herunterfahren einer Instanz können alle ausstehenden Verbindungen, die nicht innerhalb von 60 Sekunden beendet werden, ein nicht ordnungsgemäßes Herunterfahren verursachen.
Wenn Sie Verbindungen von weniger als 60 Sekunden verwenden, kann in den meisten Fällen das nicht ordnungsgemäße Herunterfahren vermieden werden. Dies gilt auch für Verbindungen, die über die Eingabeaufforderung der Datenbank hergestellt werden. Wenn Sie diese Verbindungen mehrere Stunden oder Tage geöffnet lassen, kann dies das Herunterfahren beeinträchtigen. |
| Nutzer kann nicht gelöscht werden. | Der Nutzer ist wahrscheinlich Inhaber von Objekten in der Datenbank, die davon abhängig sind. Sie müssen diese Objekte löschen oder einem anderen Nutzer zuweisen.
Finden Sie heraus, welche Objekte vom Nutzer abhängig sind, löschen Sie diese Objekte oder weisen Sie sie einem anderen Nutzer zu. In diesem Thread zu Stack Exchange wird besprochen, wie Sie die Objekte finden, deren Inhaber der Nutzer ist. |
| Bestimmte Abfragen werden langsam ausgeführt. | Abfragen können aus vielen Gründen langsam sein, hauptsächlich aufgrund bestimmter Aspekte der Datenbank. Ein Grund, der sich auf Cloud SQL auswirken kann, ist die Netzwerklatenz, wenn sich die Quellressource (Autor oder Leser) und die Zielressource (Cloud SQL) in verschiedenen Regionen befinden.
Lesen Sie insbesondere die Informationen unter Allgemeine Leistungstipps. Wenn Datenbankeinträge, Aktualisierungen oder Löschvorgänge sehr langsam sind, probieren Sie Folgendes:
Für eine möglichst geringe Latenz sollten sich die Quell- und Zielressourcen in derselben Region befinden. |
| Es wird angegeben, dass nicht genügend Arbeitsspeicher vorhanden ist, aber in Monitoring-Diagrammen wird dies nicht angezeigt. | Eine Instanz kann fehlschlagen und Out of memory melden, aber in den Google Cloud Console- oder Cloud Monitoring-Diagrammen wird angezeigt, dass noch Arbeitsspeicher vorhanden ist.
Neben der Arbeitslast gibt es weitere Faktoren, die sich auf die Speichernutzung auswirken können, z. B. die Anzahl der aktiven Verbindungen und internen Overhead-Prozesse. Diese werden nicht immer in den Monitoring-Diagrammen widergespiegelt. Die Instanz muss genügend Kapazität für die Arbeitslast und zusätzlichen Overhead haben. |
| Gelöschte Instanz wiederherstellen | Alle Daten einer Instanz, einschließlich Sicherungen, werden beim Löschen der Instanz dauerhaft entfernt.
Wenn Sie die Daten beibehalten möchten, exportieren Sie diese in Cloud Storage, bevor Sie eine Instanz löschen. Die Rolle "Cloud SQL-Administrator" enthält die Berechtigung zum Löschen der Instanz. Gewähren Sie diese Rolle nur, wenn nötig, um ein versehentliches Löschen zu vermeiden. |
| Sie möchten eine vorhandene Cloud SQL-Instanz umbenennen. | Das Umbenennen einer vorhandenen Instanz wird nicht unterstützt.
Es gibt noch andere Möglichkeiten, das Ziel zu erreichen, indem eine neue Instanz erstellt wird.
In beiden Fällen können Sie Ihre alte Instanz löschen, nachdem der Vorgang abgeschlossen wurde. Es wird empfohlen, das Klonen zu verwenden, da dies keine Beeinträchtigung der Leistung nach sich zieht und Sie die Einstellungen der Instanzkonfiguration zu Flags, Maschinentyp, Speichergröße und Arbeitsspeicher nicht noch einmal festlegen müssen. |
| Fehler beim Löschen einer Instanz. | Wenn der Löschschutz für eine Instanz aktiviert ist, bestätigen Sie Ihre Pläne, die Instanz zu löschen. Deaktivieren Sie dann den Löschschutz, bevor Sie die Instanz löschen. |
Private Service Connect
| Problem | Fehlerbehebung |
|---|---|
| Der Dienstanhang der Instanz akzeptiert den Private Service Connect-Endpunkt nicht. |
|
Replikation
| Problem | Fehlerbehebung |
|---|---|
| Beim Erstellen hat das Lesereplikat nicht repliziert. | Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler. Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden. |
| Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler | Eines der Flags in der Anfrage ist ungültig. Dies kann ein Flag sein, das Sie explizit angegeben haben, oder ein Flag, für das ein Standardwert festgelegt wurde.
Prüfen Sie als Erstes, ob der Wert des Flags Wenn das Flag |
| Lesereplikat kann nicht erstellt werden – unbekannter Fehler. | Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler.
Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.
Lautet der Fehler |
| Laufwerk ist voll. | Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden. Bearbeiten Sie die primäre Instanz, um sie auf ein größeres Laufwerk zu aktualisieren. |
| Die Replikatinstanz verwendet zu viel Arbeitsspeicher. | Das Replikat verwendet temporären Speicher zum Speichern häufig angeforderter Lesevorgänge im Cache, was dazu führen kann, dass es mehr Speicher als die primäre Instanz verwendet.
Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben. |
| Replikation gestoppt. | Das maximale Speicherlimit wurde erreicht und die automatische Speichererweiterung ist nicht aktiviert.
Bearbeiten Sie die Instanz, um |
| Replikationsverzögerung ist durchgehend hoch. | Die Schreiblast ist für das Replikat zu hoch. Die Replikationsverzögerung tritt auf, wenn der SQL-Thread auf einem Replikat nicht mit dem E/A-Thread Schritt halten kann. Einige Arten von Abfragen oder Arbeitslasten können vorübergehend oder dauerhaft zu einer hohen Replikationsverzögerung für ein bestimmtes Schema führen. Typische Ursachen für Replikationsverzögerungen sind:
Hier einige mögliche Lösungen:
|
| Die Replikaterstellung schlägt bei Zeitüberschreitung fehl. | Langlaufende Transaktionen ohne Commit auf der primären Instanz können dazu führen, dass die Lesereplikaterstellung fehlschlägt.
Erstellen Sie das Replikat neu, nachdem alle laufenden Abfragen beendet sind. |