Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite werden einige der nutzerseitig gesteuerten Konfigurationen beschrieben, die dazu führen können, dass ein Ausfall einer Spanner-Instanz vom Spanner-SLA (Service Level Agreement) ausgeschlossen wird. Das SLA schließt Ausfälle aus, die „durch Faktoren verursacht wurden, die außerhalb der Kontrolle von Google liegen“. Außerdem finden Sie dort Richtlinien, wie Sie diese Konfigurationen vermeiden können.
Spanner verwaltet viele Aspekte von Datenbankvorgängen, z. B. das Aufteilen und Neuausgleichen von Daten, die Replikation, das Failover sowie alle Hardware- und Softwareupdates. Viele dieser Verhaltensweisen lassen sich mit integrierten Einstellungen und Administrator-APIs konfigurieren. Ihre Arbeitslasten hängen neben Spanner auch von anderen Komponenten ab, z. B. von Ihren Anwendungen und Ihrem Netzwerk.
Diese vom Kunden gesteuerten Konfigurationen können das Risiko von Instanzausfällen in Abhängigkeit von der Datenbanklast und anderen Konfigurationsparametern erhöhen.
Wenn Ihre Instanz fehlerhaft wird und Google feststellt, dass die Instanz die auf dieser Seite beschriebenen Betriebsbeschränkungen nicht einhält, wird eine daraus resultierende Ausfallzeit möglicherweise nicht durch das Spanner-SLA abgedeckt (bzw. nicht darauf angerechnet).
Konfigurationen, die vom Spanner-SLA ausgeschlossen sind
Die folgenden Konfigurationen sind vom Spanner-SLA ausgeschlossen:
Wenn Ihre Instanz so konfiguriert und verwendet wird, dass die Arbeitslast die Instanz überlastet, ist sie nicht durch das SLA abgedeckt.
Ausfallzeiten von Instanzen, die auf Ihre freiwilligen Handlungen oder Unterlassungen zurückzuführen sind, sind nicht durch die SLA abgedeckt.
Wenn Sie die Spanner API oder andere Google Cloud APIs deaktivieren, die zum Erstellen einer Verbindung zu Spanner erforderlich sind, fällt dies nicht unter die SLA.
Die Nichtverfügbarkeit der Spanner API aufgrund Ihrer Netzwerkkonfiguration, z. B. Proxy- und Firewallregeln, ist nicht durch die SLA abgedeckt.
Die Nichtverfügbarkeit von Anwendungen aufgrund veralteter oder falsch konfigurierter Clients ist nicht durch die SLA abgedeckt. Prüfen Sie insbesondere, ob Sie aktuelle Clientversionen mit unterstützten Abhängigkeiten verwenden. Java-Anwendungen sollten beispielsweise die BOM (Bill of Materials) von Google mit einem Paketmanager wie Gradle oder Maven verwenden.
Wir empfehlen Ihnen, Benachrichtigungen und Monitoring mit Cloud Monitoring einzurichten.
Zu vermeidende Konfigurationen
Damit das Spanner-SLA abgedeckt ist, müssen Sie die folgenden Konfigurationen vermeiden:
CPU-Überlastung: Wenn die CPU-Auslastung konstant hoch ist, hat Ihre Instanz nicht die richtige Größe für Ihre Arbeitslast und ist möglicherweise nicht vom SLA abgedeckt. Die Empfehlungen zur CPU-Auslastung von Spanner bieten Spielraum für ein Failover-Ereignis, bei dem die verbleibenden Rechenressourcen dazu beitragen, den Traffic von nicht verfügbaren Teilen der Instanz zu bewältigen. Sie können die CPU-Auslastungsmesswerte von Spanner verwenden, um die CPU-Auslastung zu überwachen.
Vollständiger Speicherplatz: In Spanner wird Ihnen nur der von Ihnen genutzte Speicherplatz in Rechnung gestellt. Jeder Knoten oder jede Recheneinheit hat jedoch ein Limit für die Menge an Speicherplatz, die er verwalten kann. Wenn Ihre Instanz nicht die richtige Größe für den adressierbaren Speicher pro Knoten hat, ist sie möglicherweise nicht durch das SLA abgedeckt. Mit den Messwerten zur Speicherauslastung von Spanner können Sie die Speicherauslastung überwachen.
Kontingentlimit:Knotenressourcen sind durch Kontingente pro Nutzer begrenzt.
Wenn Sie Kontingenterhöhungen nicht im Voraus beantragen, kann es zu einer Überlastung der Computeressourcen kommen, die möglicherweise nicht durch die SLA abgedeckt ist. Anfragen zur Kontingenterhöhung, die eine Genehmigung von Google erfordern, werden in der Regel innerhalb eines Tages bearbeitet.
Nicht bereitgestellte Sitzungen: Spanner-Clients verwenden gRPC-Channels für die Kommunikation mit Google Cloud -Endpunkten für Abfragen und Verwaltung. Wenn Ihre Clientumgebungen nicht genügend Kanäle für das Anfragevolumen einer Arbeitslast bieten, kann es bei Ihren Anwendungen zu einer hohen Latenz und einem niedrigen Anfragedurchsatz kommen, die möglicherweise nicht durch die SLA abgedeckt sind.
Überlastung der Verbindung:Viele Spanner-APIs können bei einem vorübergehenden Fehler, z. B. einem Transaktions-Deadlock in einer Abfrage, einem Netzwerkproblem oder Ratenbeschränkungen für administrative APIs, sicher wiederholt werden. Zu aggressive Wiederholungsversuche können bestehende Verbindungen überlasten und zu Ressourcenmangel oder zusätzlichem Drosseln führen. Die erhöhte Latenz oder der reduzierte Durchsatz sind möglicherweise nicht durch das SLA abgedeckt. Weitere Informationen finden Sie unter Client-Zeitüberschreitungen und ‑Wiederholungsversuche verwalten.
Überlastung von Festplattenlaufwerken (HDD): Mit mehrstufigem Speicher können Sie Ihre Spanner-Daten auf einer Mischung aus Solid-State-Laufwerken (SSDs) und Festplattenlaufwerken (HDDs) speichern. Wenn die Festplattenauslastung auf HDD-Speicher 100 % erreicht, tritt in Ihrer Spanner-Instanz eine deutlich erhöhte Latenz auf. Dies ist möglicherweise nicht durch das SLA abgedeckt. Mit den Messwerten für den mehrstufigen Speicher von Spanner können Sie die Festplattenauslastung überwachen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-17 (UTC)."],[],[],null,["# Spanner operational guidelines\n\nThis page describes some of the user-controlled configurations that can cause an\noutage for a Spanner instance to be excluded from the\nSpanner Service Level Agreement (SLA), which excludes outages\n\"caused by factors outside of Google's reasonable control\". It also provides\nguidelines on how to avoid these configurations.\n\nSpanner manages many aspects of database operations, such as\nsplitting and rebalancing data, replication, failover, and all hardware and\nsoftware updates. You can configure many of these behaviors with built-in\nsettings and administrative APIs. Your workloads also depend on other components\nin addition to Spanner, such as your applications and network.\nThese customer-controlled configurations may increase the risk of instance\ndowntime, depending on your database load and other configuration parameters.\n\nIf your instance becomes unhealthy, and if Google determines that the instance\nis out of compliance with the operational limits described on this page, then\nany resulting downtime may not be covered by (or does not count against) the\nSpanner SLA.\n| **Note:** You're responsible for monitoring your Spanner instances and verifying that they are correctly sized and configured for the type of workloads that you're running.\n\nConfigurations excluded from the Spanner SLA\n--------------------------------------------\n\nThe following configurations are excluded from the Spanner SLA:\n\n- If your instance is configured and used in a way that causes the workload to overload the instance, then it isn't covered by the SLA.\n- Downtime of instances that results from your voluntary actions or inactions isn't covered by the SLA\n- If you disable the [Spanner API](/spanner/docs/getting-started/set-up#set_up_a_project) or other Google Cloud APIs that are required to create and connect to Spanner, then it isn't covered by the SLA.\n- Unavailability of the Spanner API that is the result of your network configuration, such as proxy and firewall rules, isn't covered by the SLA.\n- Application unavailability due to out-of-date or misconfigured [clients](/spanner/docs/reference/libraries) isn't covered by the SLA. In particular, verify that you are using recent client versions with supported dependencies. For example, Java applications should use [Google's BOM](/java/docs/bom) (bill of materials) with a package manager, such as Gradle or Maven.\n\nWe recommend that you set up alerts and monitoring using\n[Cloud Monitoring](/spanner/docs/monitoring-cloud).\n\n### Configurations to avoid\n\nTo maintain Spanner SLA coverage, you must avoid the following\nconfigurations:\n\n- **CPU overload** : If your CPU utilization is consistently high, then your instance isn't properly sized for your workload, and the instance might not be covered by the SLA. Spanner [CPU utilization recommendations](/spanner/docs/compute-capacity#change-compute-capacity) provide overhead for a failover event, where the remaining compute resources help to accommodate traffic from unavailable parts of the instance. You can use Spanner [CPU utilization metrics](/spanner/docs/cpu-utilization) to monitor CPU utilization.\n- **Full storage** : Spanner bills you only for the storage that you use. However, each node, or unit of compute, has a [limit](/spanner/quotas#database-limits) for the amount of storage it can manage. If your instance isn't properly sized for the addressable storage per node, then the instance might not be covered by the SLA. You can use Spanner [storage utilization metrics](/spanner/docs/storage-utilization) to monitor storage utilization.\n- **Quota limit:** Node resources are limited by per-user [quotas](/spanner/quotas). Failure to request quota increases in advance might result in compute resource overload, which might not be covered by the SLA. Quota increase requests that require approval from Google are typically fulfilled within one day.\n- **Under provisioned sessions** : Spanner clients use [gRPC channels](/spanner/docs/sessions#configure_the_number_of_sessions_and_grpc_channels_in_the_pools) to communicate with Google Cloud endpoints for queries and administration. If your client environments don't provide enough channels to support the request volume of a workload, your applications might experience high latency and low request throughput that might not be covered by the SLA.\n- **Connection overload:** Many Spanner APIs can be safely retried in the event of a transient failure, such as a transaction deadlock in a query, a network issue, or rate limits for administrative APIs. Overly aggressive retries might overwhelm existing connections, causing resource exhaustion or additional throttling. The increased latency or reduced throughput might not be covered by the SLA. For more information, see [managing client timeouts and retries](/spanner/docs/custom-timeout-and-retry).\n- **Hard disk drive (HDD) overload:** [Tiered storage](/spanner/docs/tiered-storage) lets you store your Spanner data on a mix of solid-state drives (SSD) and hard disk drives (HDD). If your disk load on HDD storage reaches 100%, your Spanner instance experiences significantly increased latency and might not be covered by the SLA. You can use Spanner [tiered storage metrics](/spanner/docs/monitoring-console#tiered_storage_charts_and_metrics) to monitor disk load.\n\nWhat's next\n-----------\n\n- Learn [best practices for improving Spanner performance and availability using the launch checklist](/spanner/docs/launch-checklist)."]]
