Sitzungen

Auf dieser Seite wird das erweiterte Konzept von Sitzungen in Cloud Spanner beschrieben, einschließlich Best Practices für Sitzungen beim Erstellen einer Clientbibliothek, mithilfe der REST- oder RPC APIs oder der Google-Clientbibliotheken.

Eine Sitzung stellt einen Kommunikationskanal mit dem Cloud Spanner-Datenbankdienst dar. In einer Sitzung werden Transaktionen ausgeführt, die Daten in einer Cloud Spanner-Datenbank lesen, schreiben oder ändern. Jede Sitzung gilt für eine einzige Datenbank.

Sitzungen können jeweils eine oder mehrere Transaktionen ausführen. Bei der Ausführung mehrerer Transaktionen wird die Sitzung als eine Multiplex-Sitzung bezeichnet. Eigenständige Lesevorgänge, Schreibvorgänge und Abfragen verwenden eine interne Transaktion.

Leistungsvorteile eines Sitzungspools

Das Erstellen einer Sitzung ist teuer. Um zu vermeiden, dass für jeden Datenbankvorgang Leistungskosten anfallen, sollten Kunden einen Sitzungspool führen. Dabei handelt es sich um einen Pool verfügbarer Sitzungen, die sofort verwendet werden können. Der Pool sollte vorhandene Sitzungen speichern und auf Anfrage den entsprechenden Sitzungstyp zurückgeben sowie die Bereinigung nicht verwendeter Sitzungen vornehmen. Ein Beispiel für die Implementierung eines Sitzungspools finden Sie im Quellcode für eine der Cloud Spanner-Clientbibliotheken, z. B. die Go-Clientbibliothek oder die Java-Clientbibliothek.

Sitzungen sind langlebig angelegt. Nachdem eine Sitzung für eine Datenbankoperation verwendet wurde, sollte der Client die Sitzung zur Wiederverwendung an den Pool zurückgeben.

Übersicht über gRPC-Kanäle

gRPC-Kanäle werden vom Cloud Spanner-Client für die Kommunikation verwendet. Ein gRPC-Kanal entspricht in etwa einer TCP-Verbindung. Ein gRPC-Kanal kann bis zu 100 gleichzeitige Anfragen verarbeiten. Das bedeutet, dass eine Anwendung mindestens so viele gRPC-Kanäle benötigt wie die Anzahl der gleichzeitigen Anfragen, die die Anwendung ausführt, geteilt durch 100.

Der Cloud Spanner-Client erstellt beim Erstellen einen Pool von gRPC-Kanälen.

Best Practices für die Verwendung von Google-Clientbibliotheken

Im Folgenden werden Best Practices für die Verwendung der Google Clientbibliotheken für Cloud Spanner beschrieben.

Anzahl der Sitzungen und gRPC-Kanäle in den Pools konfigurieren

Die Clientbibliotheken haben eine Standardanzahl von Sitzungen im Sitzungspool und eine Standardanzahl von gRPC-Kanälen im Kanalpool. Beide Standardwerte sind für die meisten Fälle ausreichend. Im Folgenden sind die Standardwerte für die Mindest- und Höchstanzahl von Sitzungen sowie die Standardanzahl von gRPC-Kanälen für jede Programmiersprache aufgeführt.

C++

MinSessions: 100
MaxSessions: 400
NumChannels: 4

C#

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Go

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Java

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Node.js

Der Node.js-Client unterstützt keine mehreren gRPC-Kanäle. Daher wird empfohlen, mehrere Clients zu erstellen, anstatt die Größe des Sitzungspools für einen einzelnen Client auf mehr als 100 Sitzungen zu erhöhen.

MinSessions: 25
MaxSessions: 100

PHP

Der PHP-Client unterstützt keine konfigurierbare Anzahl von gRPC-Kanälen.

MinSessions: 1
MaxSessions: 500

Python

Python unterstützt vier verschiedene Sitzungspooltypen die Sie zum Verwalten von Sitzungen verwenden können.

Ruby

Der Ruby-Client unterstützt keine mehreren gRPC-Kanäle. Daher wird empfohlen, mehrere Clients zu erstellen, anstatt die Größe des Sitzungspools für einen einzelnen Client auf mehr als 100 Sitzungen zu erhöhen.

MinSessions: 10
MaxSessions: 100

Die Anzahl der von Ihrer Anwendung verwendeten Sitzungen entspricht der Anzahl der gleichzeitigen Transaktionen, die Ihre Anwendung ausführt. Sie sollten die Standardeinstellungen für den Sitzungspool nur ändern, wenn Sie erwarten, dass eine einzelne Anwendungsinstanz mehr gleichzeitige Transaktionen ausführt, als der Standard-Sitzungspool verarbeiten kann.

Für Anwendungen mit hoher Nebenläufigkeit wird Folgendes empfohlen:

  1. Legen Sie MinSessions auf die erwartete Anzahl gleichzeitiger Transaktionen fest, die ein einzelner Client ausführt.
  2. Legen Sie MaxSessions auf die maximale Anzahl gleichzeitiger Transaktionen fest, die ein einzelner Client ausführen kann.
  3. Legen Sie MinSessions=MaxSessions fest, wenn sich die erwartete Nebenläufigkeit während der Lebensdauer der Anwendung nicht wesentlich ändert. Dadurch wird verhindert, dass der Sitzungspool skaliert wird. Das Skalieren des Sitzungspools verbraucht auch Ressourcen.
  4. Legen Sie NumChannels auf MaxSessions / 100 fest. Ein gRPC-Kanal kann bis zu 100 Anfragen gleichzeitig verarbeiten. Erhöhen Sie diesen Wert, wenn Sie eine hohe Tail-Latenz (p95/p99-Latenz) beobachten, da dies ein Hinweis auf eine Überlastung des gRPC-Kanals sein kann.

Wenn Sie die Anzahl der aktiven Sitzungen erhöhen, werden zusätzliche Ressourcen im Cloud Spanner-Datenbankdienst und in der Clientbibliothek verwendet. Wenn Sie die Anzahl der Sitzungen über den tatsächlichen Bedarf der Anwendung hinaus erhöhen, kann dies die Leistung Ihres Systems beeinträchtigen.

Sitzungspool vergrößern oder Anzahl der Clients erhöhen

Die Größe des Sitzungspools für eine Anwendung bestimmt, wie viele gleichzeitige Transaktionen eine einzelne Anwendungsinstanz ausführen kann. Es wird nicht empfohlen, die Größe des Sitzungspools über die maximale Nebenläufigkeit hinaus zu erhöhen, die eine einzelne Anwendungsinstanz verarbeiten kann. Wenn die Anwendung einen Anstieg von Anfragen erhält, der die Anzahl der Sitzungen im Pool übersteigt, werden die Anfragen in die Warteschlange gestellt, bis eine Sitzung verfügbar ist.

Die von der Clientbibliothek verbrauchten Ressourcen sind folgende:

  1. Jeder gRPC-Kanal verwendet eine TCP-Verbindung.
  2. Für jeden gRPC-Aufruf ist ein Thread erforderlich. Die maximale Anzahl der von der Clientbibliothek verwendeten Threads entspricht der maximalen Anzahl gleichzeitiger Abfragen, die die Anwendung ausführt. Diese Threads kommen zu allen Threads hinzu, die die Anwendung für ihre eigene Geschäftslogik verwendet.

Es wird nicht empfohlen, die Größe des Sitzungspools über die maximale Anzahl von Threads hinaus zu erhöhen, die eine einzelne Anwendungsinstanz verarbeiten kann. Erhöhen Sie stattdessen die Anzahl der Anwendungsinstanzen.

Anteil der Schreibsitzungen verwalten

Bei einigen Clientbibliotheken reserviert Cloud Spanner einen Teil der Sitzungen für nicht schreibgeschützte Transaktionen. Dies wird als Anteil der Schreibsitzungen bezeichnet. Wenn Ihre Anwendung alle Lesesitzungen genutzt hat, verwendet Spanner die Lese-/Schreibsitzungen, auch für schreibgeschützte Transaktionen. Für nicht schreibgeschützte Sitzungen ist spanner.databases.beginOrRollbackReadWriteTransaction erforderlich. Wenn der Nutzer die spanner.databaseReader IAM-Rolle hat, schlägt der Aufruf fehl und Cloud Spanner gibt die folgende Fehlermeldung zurück:

generic::permission_denied: Resource %resource% is missing IAM permission:
spanner.databases.beginOrRollbackReadWriteTransaction

Bei Clientbibliotheken, die einen Anteil an Schreibsitzungen haben, können Sie diesen festlegen.

C++

Alle C ++-Sitzungen sind identisch. Es gibt keine schreibgeschützten bzw. nicht schreibgeschützten Sitzungen.

C#

Bei C# gilt standardmäßig ein Anteil an Schreibsitzungen von 0,2. Sie können ihn mit dem Feld `WriteSessionsFraction` von SessionPoolOptions ändern.

Go

Alle Go-Sitzungen sind identisch. Es gibt keine schreibgeschützten bzw. nicht schreibgeschützten Sitzungen.

Java

Alle Java-Sitzungen sind gleich. Es gibt keine schreibgeschützten bzw. nicht schreibgeschützten Sitzungen.

Node.js

Alle Node.js-Sitzungen sind gleich. Es gibt keine schreibgeschützten bzw. nicht schreibgeschützten Sitzungen.

PHP

Alle PHP-Sitzungen sind gleich. Es gibt keine schreibgeschützten bzw. nicht schreibgeschützten Sitzungen.

Python

Python unterstützt vier verschiedene Sitzungspooltypen, die Sie zum Verwalten von schreibgeschützten und nicht schreibgeschützten Sitzungen verwenden können.

Ruby

Der Standardanteil der Schreibsitzungen bei Ruby ist 0,3. Sie können ihn mit der client initialize-Methode ändern.

Best Practices beim Erstellen einer Clientbibliothek oder bei Verwendung von REST/RPC

Im Folgenden werden Best Practices für die Implementierung von Sitzungen in einer Client bibliothek für Cloud Spanner und für die Verwendung von Sitzungen mit der REST API oder der RPC API beschrieben.

Diese Best Practices gelten nur, wenn Sie eine Clientbibliothek entwickeln oder wenn Sie REST/RPC-APIs verwenden. Wenn Sie eine der Google-Client bibliotheken für Cloud Spanner verwenden, lesen Sie den Abschnitt Best Practices für die Verwendung von Google-Clientbibliotheken.

Sitzungspool erstellen und Größe festlegen

Um eine optimale Größe des Sitzungspools für einen Clientprozess festzulegen, geben Sie als untere Grenze die Anzahl der erwarteten gleichzeitigen Transaktionen an und als obere Grenze eine anfängliche Testanzahl (z. B. 100). Wenn die obere Grenze nicht ausreicht, setzen Sie sie herauf. Wenn Sie die Anzahl der aktiven Sitzungen erhöhen, werden zusätzliche Ressourcen im Cloud Spanner-Datenbankdienst verwendet. Wenn Sie also nicht verwendete Sitzungen bereinigen, kann dies die Leistung beeinträchtigen. Für Nutzer, die mit der RPC API arbeiten, empfehlen wir, nicht mehr als 100 Sitzungen pro gRPC-Kanal zu haben.

Gelöschte Sitzungen

Es gibt drei Möglichkeiten, eine Sitzung zu löschen:

  • Ein Client kann eine Sitzung löschen.
  • Der Cloud Spanner-Datenbankdienst kann eine Sitzung löschen, wenn die Sitzung länger als eine Stunde inaktiv ist.
  • Der Cloud Spanner-Datenbankdienst kann eine Sitzung löschen, wenn die Sitzung mehr als 28 Tage alt ist.

Beim Versuch, eine gelöschte Sitzung zu verwenden, wird NOT_FOUND zurückgegeben. Wenn Sie auf diesen Fehler stoßen, erstellen Sie eine neue Sitzung und verwenden diese. Fügen Sie die neue Sitzung dem Pool hinzu und entfernen Sie die gelöschte Sitzung.

Inaktive Sitzung offen halten

Der Cloud Spanner-Datenbankdienst behält sich das Recht vor, eine nicht verwendete Sitzung zu löschen. Wenn Sie eine inaktive Sitzung unbedingt offen halten müssen, wenn z. B. eine signifikante Erhöhung der Datenbanknutzung in naher Zukunft erwartet wird, können Sie verhindern, dass die Sitzung gelöscht wird. Führen Sie einen kostengünstigen Vorgang wie das Ausführen der SQL-Abfrage SELECT 1 durch, um die Sitzung aktiv zu halten. Wenn Sie über eine inaktive Sitzung verfügen, die nicht in naher Zukunft verwendet werden soll, erlauben Sie, dass sie von Cloud Spanner gelöscht wird. Erstellen Sie eine neue Sitzung, wenn das nächste Mal eine Sitzung benötigt wird.

Ein Szenario, in dem Sitzungen offen gehalten werden, ist der Umgang mit regulärer Spitzennachfrage der Datenbank. Wenn eine starke Datenbanknutzung täglich von 9:00 Uhr bis 18:00 Uhr stattfindet, sollten Sie während dieser Zeit einige inaktive Sitzungen offen halten, da diese wahrscheinlich zu Spitzenzeiten erforderlich sind. Nach 18:00 Uhr kann Cloud Spanner inaktive Sitzungen wieder löschen. Erstellen Sie jeden Tag vor 9:00 Uhr einige neue Sitzungen, damit sie für die erwartete Nachfrage bereitstehen.

Ein anderes Szenario wäre, dass Sie eine Anwendung haben, die Cloud Spanner verwendet, aber den Verbindungsaufwand dabei vermeiden muss. Sie können eine Gruppe von Sitzungen offen halten, um den Verbindungsaufwand zu vermeiden.

Sitzungsdetails vom Clientbibliotheksbenutzer ausblenden

Wenn Sie eine Clientbibliothek erstellen, sollten Sie dem Clientbibliotheksbenutzer keine Sitzungen anzeigen. Stellen Sie die Möglichkeit für den Client bereit, Datenbankaufrufe ohne den Aufwand der Erstellung und Verwaltung von Sitzungen durchzuführen. Ein Beispiel für eine Clientbibliothek, in der die Sitzungsdetails vor dem Clientbibliotheksbenutzer ausgeblendet werden, finden Sie in der Cloud Spanner-Clientbibliothek für Java.

Fehler bei Schreibtransaktionen bearbeiten, die nicht idempotent sind

Schreibtransaktionen ohne Wiederholungsschutz können Mutationen mehr als einmal anwenden. Wenn eine Mutation nicht idempotent ist, kann eine Mutation, die mehrmals angewendet wird, zu einem Fehler führen. Beispiel: Eine Einfügung (Insert) kann den Fehler ALREADY_EXISTS verursachen, obwohl die Zeile vor dem Schreibversuch nicht vorhanden war. Dies kann auftreten, wenn der Back-End-Server die Mutation festgeschrieben hat, dies aber dem Client nicht mitteilen konnte. In diesem Fall könnte die Mutation wiederholt werden, was aber zu dem Fehler ALREADY_EXISTS führen würde.

Im Folgenden sind einige Möglichkeiten aufgelistet, wie Sie mit diesem Szenario bei der Bereitstellung Ihrer eigenen Clientbibliothek oder bei der Verwendung der REST API verfahren können:

  • Strukturieren Sie Ihre Schreibvorgänge so, dass sie idempotent sind.
  • Verwenden Sie Schreibvorgänge mit Wiederholungsschutz.
  • Implementieren Sie eine Methode mit der Logik "upsert": einfügen, wenn neu, oder aktualisieren, wenn bereits vorhanden.
  • Bearbeiten Sie den Fehler für den Client.

Für stabile Verbindungen sorgen

Für eine optimale Leistung sollte die Verbindung, die Sie zum Hosten einer Sitzung verwenden, stabil sein. Wenn sich die Hostingverbindung für eine Sitzung ändert, bricht Cloud Spanner möglicherweise die aktive Transaktion in der Sitzung ab. Dies führt während der Aktualisierung der Sitzungsmetadaten zu einer geringfügigen Mehrbelastung Ihrer Datenbank. Wenn sich einige Verbindungen gelegentlich ändern, ist das kein Problem, aber Sie sollten Situationen vermeiden, in denen sich eine große Anzahl von Verbindungen gleichzeitig ändert. Falls Sie einen Proxy zwischen dem Client und Cloud Spanner einsetzen, sollten Sie bei jeder Sitzung für eine stabile Verbindung sorgen.

Aktive Sitzungen überwachen

Mit dem Befehl ListSessions können Sie aktive Sitzungen in Ihrer Datenbank über die Befehlszeile, mit der REST API oder mit der RPC API überwachen. ListSessions zeigt die aktiven Sitzungen für eine bestimmte Datenbank an. Dies ist sinnvoll, wenn Sie die Ursache für ein Sitzungsleck finden möchten. Ein Sitzungsleck ist ein Vorfall, bei dem Sitzungen erstellt, aber nicht zur Wiederverwendung an einen Sitzungspool zurückgegeben werden.

Mit ListSessions können Sie Metadaten zu Ihren aktiven Sitzungen abrufen, z. B. wann eine Sitzung erstellt und wann eine Sitzung zuletzt verwendet wurde. Die Analyse dieser Daten weist Sie bei der Fehlersuche in die richtige Richtung. Wenn die approximate_last_use_time für die meisten aktiven Sitzungen schon länger zurückliegt, deutet dies eventuell darauf hin, dass Sitzungen von Ihrer Anwendung nicht ordnungsgemäß wiederverwendet werden. Weitere Informationen zum Feld approximate_last_use_time finden Sie in der RPC API Referenz.

Weitere Informationen zur Verwendung von ListSessions finden Sie in der REST API-Referenz, der RPC API-Referenz oder der Referenz zum gcloud Befehlszeilentool.

Automatische Bereinigung von Sitzungslecks

Wenn Sie alle Sitzungen in Ihrem Sitzungspool verwenden, wartet jede neue Transaktion, bis eine Sitzung an den Pool zurückgegeben wird. Wenn Sitzungen erstellt, aber nicht zur Wiederverwendung an den Sitzungspool zurückgegeben werden, wird dies als Sitzungsleck bezeichnet. Bei einem Sitzungsleck bleiben Transaktionen, die auf eine offene Sitzung warten, unbegrenzt hängen und blockieren die Anwendung. Sitzungslecks werden häufig durch problematische Transaktionen verursacht, die extrem lange ausgeführt werden und nicht festgeschrieben werden.

Sie können Ihren Sitzungspool so einrichten, dass diese inaktiven Transaktionen automatisch aufgelöst werden. Wenn Sie Ihre Clientbibliothek so konfigurieren, dass inaktive Transaktionen automatisch aufgelöst werden, werden problematische Transaktionen erkannt, die ein Sitzungsleck verursachen können. Sie werden aus dem Sitzungspool entfernt und durch eine neue Sitzung ersetzt.

Das Logging kann auch dabei helfen, diese problematischen Transaktionen zu identifizieren. Wenn das Logging aktiviert ist, werden Warnlogs standardmäßig freigegeben, wenn mehr als 95% Ihres Sitzungspools verwendet werden. Wenn Ihre Sitzungsauslastung über 95 % liegt, müssen Sie entweder die maximale Anzahl der zulässigen Sitzungen in Ihrem Sitzungspool erhöhen oder es liegt möglicherweise ein Sitzungsleck vor. Warnlogs enthalten Stacktraces von Transaktionen, die länger als erwartet ausgeführt werden, und können dabei helfen, die Ursache für eine hohe Auslastung des Sitzungspools zu ermitteln. Warnlogs werden je nach Konfiguration des Log-Exporters gepusht.

Clientbibliothek so konfigurieren, dass inaktive Transaktionen automatisch aufgelöst werden

Sie können die Clientbibliothek so konfigurieren, dass Warnlogs gesendet und inaktive Transaktionen automatisch aufgelöst werden, oder die Clientbibliothek so konfigurieren, dass nur Warnlogs empfangen werden.

Java

Verwenden Sie setWarnAndCloseIfInactiveTransactions, um Warnlogs zu empfangen und inaktive Transaktionen zu entfernen.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnAndCloseIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

Verwenden Sie setWarnIfInactiveTransactions, um nur Warnlogs zu empfangen.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

Go

Verwenden Sie SessionPoolConfig mit InactiveTransactionRemovalOptions, um Warnlogs zu empfangen und inaktive Transaktionen zu entfernen.

 client, err := spanner.NewClientWithConfig(
     ctx, database, spanner.ClientConfig{SessionPoolConfig: spanner.SessionPoolConfig{
         InactiveTransactionRemovalOptions: spanner.InactiveTransactionRemovalOptions{
         ActionOnInactiveTransaction: spanner.WarnAndClose,
         }
     }},
 )
 if err != nil {
     return err
 }
 defer client.Close()

Verwenden Sie customLogger, um nur Warnlogs zu empfangen.

 customLogger := log.New(os.Stdout, "spanner-client: ", log.Lshortfile)
 // Create a logger instance using the golang log package
 cfg := spanner.ClientConfig{
         Logger: customLogger,
     }
 client, err := spanner.NewClientWithConfig(ctx, db, cfg)

Multiplex-Sitzungen

Mit Multiplex-Sitzungen können Sie eine große Anzahl gleichzeitiger Anfragen in einer einzelnen Sitzung erstellen. Eine Multiplex-Sitzung ist eine Kennung, die Sie für mehrere gRPC-Kanäle verwenden. Es werden keine zusätzlichen Engpässe eingeführt. Multiplex-Sitzungen haben folgende Vorteile:

  • Reduzierter Verbrauch von Back-End-Ressourcen aufgrund eines einfacheren Protokolls für die Sitzungsverwaltung. So werden beispielsweise Aktivitäten zur Sitzungsverwaltung vermieden, die mit der Verwaltung des Sitzungsinhabers und der Garbage Collection verbunden sind.
  • Langlebige Sitzung, für die im Leerlauf keine Keep-Alive-Anfragen erforderlich sind.

Multiplex-Sitzungen werden in den folgenden Fällen unterstützt:

  • Die Clientbibliotheken C++, Go, Java, Node.js, PHP, Python und Ruby Clientbibliotheken.

  • Cloud Spanner-Ökosystemtools, die von den genannten Clientbibliotheken abhängen, z. B. PGAdapter, JDBC, Hibernate, database/sql-Treiber, dbAPI-Treiber und GORM.

  • Cloud Spanner-Ökosystemtools, die von den Java- und Go-Clientbibliotheken abhängen, z. B. PGAdapter, JDBC, Hibernate, database/sql-Treiber und GORM. Mit OpenTelemetry-Messwerten können Sie sehen, wie der Traffic zwischen dem vorhandenen Sitzungspool und der Multiplex-Sitzung aufgeteilt wird. OpenTelemetry hat einen Messwertfilter, is_multiplexed, der Multiplex-Sitzungen anzeigt, wenn er auf true gesetzt ist.

Multiplex-Sitzungen werden für alle Arten von Transaktionen unterstützt.

Clientbibliotheken rotieren Multiplex-Sitzungen alle 7 Tage, um zu verhindern, dass Transaktionen in veralteten Sitzungen gesendet werden.

Multiplex-Sitzungen sind in einigen Clientbibliotheken standardmäßig aktiviert. Für andere müssen Sie Umgebungsvariablen verwenden, um sie zu aktivieren. Weitere Informationen finden Sie unter Multiplex-Sitzungen aktivieren.

Hinweise

Wenn Sie entweder einen leeren Lese- oder Schreibtransaktionskörper oder eine Transaktion festschreiben möchten, bei der jede Abfrage oder DML-Anweisung fehlgeschlagen ist, gibt es bei Multiplex-Sitzungen einige Szenarien zu berücksichtigen. Für Multiplex-Sitzungen müssen Sie in jede Commit-Anfrage ein vom Server generiertes Pre-Commit-Token einfügen. Bei Transaktionen, die Abfragen oder DML enthalten, muss mindestens eine vorherige erfolgreiche Abfrage- oder DML-Transaktion vorhanden sein, damit der Server ein gültiges Token an die Clientbibliothek zurücksenden kann. Wenn keine erfolgreichen Abfragen oder DML-Transaktionen vorhanden sind, fügt die Clientbibliothek vor einem Commit implizit SELECT 1 hinzu.

Wenn eine Lese- oder Schreibtransaktion in einer Multiplex-Sitzung nur Mutationen enthält und eine der Mutationen für eine Tabelle oder eine Spalte gilt, die nicht im Schema vorhanden ist, kann der Client anstelle eines NOT_FOUND-Fehlers einen INVALID_ARGUMENT-Fehler zurückgeben.

Multiplex-Sitzungen aktivieren

Multiplex-Sitzungen sind in den folgenden Clientbibliotheken standardmäßig aktiviert:

  • C++ in Version 2.41.0 und höher.
  • Go in Version 1.85.0 und höher.
  • Java in Version 6.98.0 und höher.
  • Node.js in Version 8.3.0 und höher.
  • PHP in Version 2.0.0 und höher.
  • Python in Version 3.57.0 und höher.
  • Ruby in Version 2.30.0 und höher.

Wenn Sie Multiplex-Sitzungen in früheren Versionen der Node.js-, Java- und Go-Clientbibliotheken verwenden möchten, müssen Sie zuerst eine Umgebungsvariable festlegen, um sie zu aktivieren.

Setzen Sie die Umgebungsvariable GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS auf TRUE, um Multiplex-Sitzungen zu aktivieren. Mit diesem Flag wird auch die Unterstützung für Multiplex-Sitzungen für ReadOnly-Transaktionen aktiviert.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS=TRUE

Setzen Sie die Umgebungsvariable GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_PARTITIONED_OPS auf TRUE, um die Unterstützung für partitionierte Vorgänge für Multiplex-Sitzungen zu aktivieren.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_PARTITIONED_OPS=TRUE

Setzen Sie die Umgebungsvariable GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_FOR_RW auf TRUE, um die Unterstützung für nicht schreibgeschützte Transaktionen für Multiplex-Sitzungen zu aktivieren.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_FOR_RW=True

Sie müssen GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS auf TRUE setzen, um eine Transaktion in einer Multiplex-Sitzung zu unterstützen.

Traffic für reguläre und Multiplex-Sitzungen ansehen

OpenTelemetry hat den Filter is_multiplexed, um den Traffic für Multiplex-Sitzungen anzuzeigen. Setzen Sie diesen Filter auf true to view multiplexed sessions andfalse`, um reguläre Sitzungen anzuzeigen.

  1. Richten Sie OpenTelemetry für Cloud Spanner ein. Folgen Sie dazu der Anleitung im Abschnitt OpenTelemetry für Cloud Spanner Vorbereitung .

  2. Rufen Sie den Metrics Explorer auf.

    Zum Metrics Explorer

  3. Filtern Sie im Drop-down-Menü Messwert nach generic.

  4. Klicken Sie auf Allgemeine Aufgabe und rufen Sie Cloud Spanner > Spanner/num_acquired_sessions auf.

  5. Wählen Sie im Feld Filter eine der folgenden Optionen aus:

    a. is_multiplexed = false , um reguläre Sitzungen anzuzeigen. b. is_multiplexed = true, um Multiplex-Sitzungen anzuzeigen.

    Die folgende Abbildung zeigt die Option Filter mit ausgewählten Multiplex-Sitzungen.

Weitere Informationen zur Verwendung von OpenTelemetry mit Cloud Spanner finden Sie unter OpenTelemetry nutzen, um die Beobachtbarkeit von Cloud Spanner zu demokratisieren und Latenz in einer Cloud Spanner-Komponente mit OpenTelemetry untersuchen.

Opentelemetry-Dashboard mit dem Filter „is-multiplexed“

Fehlerbehebung

Zu den häufigsten sitzungsbezogenen Fehlern, die in Ihrer Anwendung auftreten können, gehören:

  • Session not found
  • RESOURCE_EXHAUSTED

Weitere Informationen finden Sie unter Sitzungsfehler.