Get Table Service Stats (Abrufen der Tabellendienststatistik)
Der Get Table Service Stats Vorgang ruft Statistiken ab, die sich auf die Replikation für Azure Table Storage beziehen. Sie ist nur auf dem Endpunkt des sekundären Standorts verfügbar, wenn die georedundante Replikation mit Lesezugriff für das Speicherkonto aktiviert ist.
Anforderung
Die Get Table Service Stats-Anforderung kann wie folgt erstellt werden. Es wird empfohlen, HTTPS zu verwenden. Ersetzen Sie myaccount durch den Namen Ihres 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 |
Hinweis
Der URI muss immer einen Schrägstrich (/) enthalten, um den Hostnamen von den Pfad- und Abfrageabschnitten des URI zu trennen. Bei diesem Vorgang ist der Pfadteil des URI leer.
URI-Parameter
Die folgenden zusätzlichen Parameter können für den Anforderungs-URI angegeben werden:
| Parameter | BESCHREIBUNG |
|---|---|
Timeout |
Optional. Der timeout-Parameter wird in Sekunden angegeben. |
Anforderungsheader
Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle beschrieben:
| Anforderungsheader | BESCHREIBUNG |
|---|---|
Authorization |
Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage. |
Date or x-ms-date |
Erforderlich. Gibt die koordinierte Weltzeit (Coordinated Universal Time, UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage. |
x-ms-version |
Erforderlich für alle autorisierten Anforderungen. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste. |
x-ms-client-request-id |
Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der in den Protokollen aufgezeichnet wird, wenn die Protokollierung konfiguriert ist. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter [Überwachen von Azure Table Storage. |
Anforderungstext
Keine.
Antwort
Die Antwort enthält den HTTP-Statuscode, einen Satz von Antwortheadern und einen Antworttext.
Statuscode
Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben. Wenn es auf einem sekundären Standortendpunkt aufgerufen wird, der nicht für einen sekundären Lesevorgang aktiviert ist, wird HTTP-status Code 403 (Unzureichende Kontoberechtigungen) zurückgegeben.
Antwortheader
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 |
Identifiziert eindeutig die Anforderung, die gestellt wurde, und kann zur Problembehandlung für die Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge. |
x-ms-version |
Gibt die Version des Vorgangs an, der für die Antwort verwendet wurde. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste. |
Date |
Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der den Zeitpunkt angibt, zu dem die Antwort initiiert wurde. |
x-ms-client-request-id |
Kann zur Problembehandlung von Anforderungen und deren entsprechenden Antworten verwendet werden. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist und der Wert nicht mehr als 1.024 sichtbare ASCII-Zeichen enthält. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden. |
Antworttext
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>
Die folgende Tabelle erläutert die Elemente des Antworttexts:
| Antwortheader | BESCHREIBUNG |
|---|---|
Status |
Der Status des sekundären Standorts. Mögliche Werte: - live: Gibt an, dass der sekundäre Standort aktiv und betriebsbereit ist. - bootstrap: Gibt an, dass die erste Synchronisierung vom primären Standort zum sekundären Standort ausgeführt wird. Dies tritt normalerweise auf, wenn die Replikation zuerst aktiviert wird. - nicht verfügbar: Gibt an, dass der sekundäre Speicherort vorübergehend nicht verfügbar ist. |
LastSyncTime |
Ein UTC-Datums-/Uhrzeitwert bis zur Sekunde. Alle primären Schreibvorgänge, die diesem Wert vorangehen, sind garantiert für Lesevorgänge beim sekundären Schreibvorgang verfügbar. Primäre Schreibvorgänge nach diesem Zeitpunkt sind möglicherweise für Lesevorgänge verfügbar. Der Wert ist möglicherweise leer, wenn LastSyncTime nicht verfügbar ist. Dies kann passieren, wenn die Replikation status bootstrap ist oder nicht verfügbar ist.Obwohl die Georeplikation kontinuierlich aktiviert ist, spiegelt das LastSyncTime Ergebnis möglicherweise einen zwischengespeicherten Wert aus dem Dienst wider, der alle paar Minuten aktualisiert wird. |
Authorization
Dieser Vorgang kann nur vom Kontobesitzer aufgerufen werden.
Hinweise
Mit georedundanter Replikation verwaltet Azure Storage Ihre Daten dauerhaft an zwei Standorten. An beiden Standorten verwaltet Azure Storage ständig mehrere fehlerfreie Replikate der Daten.
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 klassische Azure-Portal der Azure-Verwaltung (z. B. USA, Norden-Mitte) auswählen.
Als sekundärer Standort wird der Standort bezeichnet, an dem die Daten repliziert werden. Der sekundäre Standort befindet sich in einer Region, die automatisch geografisch mit der primären Region gekoppelt wird. Der schreibgeschützte Zugriff ist über den sekundären Standort verfügbar, wenn die georedundante Replikation mit Lesezugriff für das Speicherkonto aktiviert ist.
Weitere Informationen zur georedundanten Replikation mit Lesezugriff finden Sie unter Datenredundanz.
Um eine Anforderung für einen Lesevorgang für den sekundären Endpunkt zu erstellen, fügen Sie -secondary an den Kontonamen in dem URI an, den Sie zum Lesen aus Dem Tabellenspeicher verwenden. Ein sekundärer URI für den Vorgang Abfrageentitäten ähnelt https://myaccount-secondary.table.core.windows.net/mytable(PartitionKey='<partition-key>',RowKey='<row-key>')beispielsweise .
Beispielanforderung und -antwort
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>