VERTRIEB: 1-800-867-1380

Statistiken zum Tabellendienst abrufen (REST-API)

Letzte Aktualisierung: April 2015

Der Get Table Service Stats-Vorgang ruft Statistiken zur Replikation für den Tabellendienst ab. Er ist nur über den sekundären Standortendpunkt verfügbar, wenn die georedundante Replikation mit Lesezugriff für das Speicherkonto aktiviert ist.

Die Get Table Service Stats-Anforderung kann wie folgt erstellt werden. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen des Speicherkontos, und beachten Sie, dass das Suffix -secondary erforderlich ist:

 

Methode Anforderungs-URI HTTP-Version

GET

https://myaccount-secondary.table.core.windows.net/?restype=service&comp=stats

HTTP/1.1

Beachten Sie, dass der URI immer einen Schrägstrich (/) enthalten muss, um den Hostnamen vom Pfad- und Abfrageteil des URIs zu trennen. Bei diesem Vorgang ist der Pfadteil des URIs leer.

Im Anforderungs-URI können die folgenden zusätzlichen Parameter angegeben werden.

 

Parameter Beschreibung

Timeout

Optional. Der timeout-Parameter wird in Sekunden angegeben.

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

 

Anforderungsheader Beschreibung

Authorization

Erforderlich. Gibt das Authentifizierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Authentifizierung für die Azure-Speicherdienste.

Date or x-ms-date

Erforderlich. Gibt die Uhrzeit der Anforderung in koordinierter Weltzeit (UTC) an. Weitere Informationen finden Sie unter Authentifizierung für die Azure-Speicherdienste.

x-ms-version

Erforderlich für alle authentifizierten Anforderungen. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für den Blob-Dienst, den Warteschlangendienst und den Tabellendienst in Azure.

x-ms-client-request-id

Optional. Vom Client generierter, nicht transparenter Wert mit einer Zeichenbeschränkung von 1 KB, der bei Aktivierung der Speicheranalyse-Protokollierung in den Analyseprotokollen erfasst wird. Die Verwendung dieses Headers wird dringend empfohlen, um clientseitige Aktivitäten mit den vom Server empfangenen Anforderungen zu korrelieren. Weitere Informationen finden Sie unter Azure-Protokollierung: Verwenden von Protokollen zur Nachverfolgung von Speicheranforderungen.

Die Antwort enthält den HTTP-Statuscode, einen Satz von Antwortheadern und einen Antworttext.

Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben. Beim Aufruf für den sekundären Standortendpunkt, der nicht für sekundäres Lesen aktiviert ist, wird der HTTP-Statuscode 403 mit dem InsufficientAccountPermissions-Fehler zurückgegeben.

Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes der Dienstverwaltung.

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort enthält außerdem weitere HTTP-Standardheader. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

 

Antwortheader

Beschreibung

x-ms-request-id

Dieser Header identifiziert die erfolgte Anforderung eindeutig und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.

x-ms-version

Gibt die Version des für die Antwort verwendeten Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für den Blob-Dienst, den Warteschlangendienst und den Tabellendienst in Azure.

Date

Ein vom Dienst generierter Datums-/Uhrzeitwert in UTC, der angibt, wann die Antwort initiiert wurde.

Der Antworttext weist das folgende Format auf:

<?xml version="1.0" encoding="utf-8"?>
<StorageServiceStats>
  <GeoReplication>      
      <Status>live|bootstrap|unavailable</Status>
      <LastSyncTime>sync-time|<empty></LastSyncTime>
  </GeoReplication>
</StorageServiceStats>

In der folgenden Tabelle werden die Elemente des Antworttexts beschrieben:

 

Antwortheader

Beschreibung

Status

Der Status des sekundären Standorts. Folgende Werte sind möglich:

  • live: Gibt an, dass der sekundäre Standort aktiv und betriebsbereit ist.

  • bootstrap: Gibt an, dass die Erstsynchronisierung vom primären zum sekundären Standort gerade ausgeführt wird. Dies tritt in der Regel bei der erstmaligen Aktivierung der Replikation auf.

  • unavailable: Gibt an, dass der sekundäre Standort vorübergehend nicht verfügbar ist.

LastSyncTime

Ein sekundengenauer Datums-/Uhrzeitwert (GMT). Alle primären Schreibvorgänge, die diesem Wert vorausgehen, sind für den sekundären Standort garantiert für Lesevorgänge verfügbar. Es ist möglich, aber nicht gewährleistet, dass primäre Schreibvorgänge, die nach diesem Zeitpunkt erfolgen, für Lesevorgänge verfügbar sind.

Der Wert kann leer sein, wenn LastSyncTime nicht verfügbar ist. Dies kann der Fall sein, wenn der Replikationsstatus bootstrap oder unavailable ist.

Obwohl die geografische Replikation kontinuierlich aktiviert ist, kann das LastSyncTime-Ergebnis einen zwischengespeicherten Wert des Diensts widerspiegeln, der minutenweise aktualisiert wird.

Dieser Vorgang kann nur vom Kontobesitzer aufgerufen werden.

Mit der georedundanten Replikation behält der Azure-Speicher Daten an zwei Standorten permanent bei. An beiden Standorten behält der Azure-Speicher mehrere fehlerfreie Replikate der Daten bei.

Der Standort, an dem Sie Daten lesen, erstellen, aktualisieren oder löschen, ist der primäre Speicherkontostandort. Der primäre Standort befindet sich in der Region, die Sie beim Erstellen eines Kontos über das Azure-Verwaltungsportal auswählen, z. B. USA (Mitte/Norden). Als sekundärer Standort wird der Standort bezeichnet, an dem die Daten repliziert werden. Der sekundäre Standort wird automatisch auf Grundlage des primären Standorts ermittelt und befindet sich in einem zweiten Rechenzentrum in derselben Region wie der primäre Standort. Der schreibgeschützte Zugriff ist über den sekundären Standort verfügbar, wenn die georedundante Replikation mit Lesezugriff für das Speicherkonto aktiviert ist. Ausführlichere Informationen zur georedundanten Replikation mit Lesezugriff finden Sie im Azure-Speicher-Teamblog.

Um eine Anforderung für einen Lesevorgang für den sekundären Endpunkt zu erstellen, fügen Sie -secondary als Suffix an den Speichernamen in dem URI an, den Sie für das Lesen aus dem Tabellenspeicher verwenden. Ein sekundärer URI für den Vorgang Query Entities ähnelt beispielsweise https://myaccount-secondary.table.core.windows.net/mytable(PartitionKey='<partition-key>',RowKey='<row-key>').

Im Folgenden finden Sie eine Beispielanforderung für den Get Table Service Stats-Vorgang:

GET http://myaccount-secondary.table.core.windows.net/?restype=service&comp=stats HTTP/1.1

Die Anforderung wird mit den folgenden Headern gesendet:

x-ms-version: 2013-08-15
x-ms-date: Wed, 23 Oct 2013 22:08:44 GMT
Authorization: SharedKey myaccount:CY1OP3O3jGFpYFbTCBimLn0Xov0vt0khH/E5Gy0fXvg=

Der Statuscode und die Antwortheader werden wie folgt zurückgegeben:

HTTP/1.1 200 OK
Content-Type: application/xml
Date: Wed, 23 Oct 2013 22:08:54 GMT
x-ms-version: 2013-08-15
x-ms-request-id: cb939a31-0cc6-49bb-9fe5-3327691f2a30
Server: Windows-Azure-Table/1.0 Microsoft-HTTPAPI/2.0

Die Antwort enthält den folgenden XML-Text:

<?xml version="1.0" encoding="utf-8"?>
<StorageServiceStats>
  <GeoReplication>
      <Status>live</Status>
      <LastSyncTime> Wed, 23 Oct 2013 22:05:54 GMT</LastSyncTime>      
  </GeoReplication>
</StorageServiceStats>

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2015 Microsoft