Partager via

Get Table Service Stats

  • Article

L’opération Get Table Service Stats récupère les statistiques liées à la réplication pour stockage Table Azure. Elle est disponible uniquement sur le point de terminaison d’emplacement secondaire lorsque la réplication géoredondante avec accès en lecture est activée pour le compte de stockage.

Requête

La demande Get Table Service Stats peut être construite comme indiqué ci-dessous. Nous vous recommandons d’utiliser HTTPS. Remplacez myaccount par le nom de votre compte de stockage et notez que le suffixe -secondary est requis :

Méthode URI de demande Version HTTP
GET https://myaccount-secondary.table.core.windows.net/?restype=service&comp=stats HTTP/1.1

Notes

L’URI doit toujours inclure une barre oblique (/) pour séparer le nom d’hôte des parties chemin d’accès et requête de l’URI. Dans cette opération, la partie chemin d’accès de l’URI est vide.

Paramètres URI

Les paramètres supplémentaires suivants peuvent être spécifiés sur l’URI de requête :

Paramètre Description
Timeout facultatif. Le paramètre timeout est exprimé en secondes.

En-têtes de requête

Les en-têtes de requête obligatoires et facultatifs sont décrits dans le tableau suivant :

En-tête de requête Description
Authorization Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
Date or x-ms-date Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
x-ms-version Obligatoire pour toutes les demandes autorisées. Spécifie la version de l'opération à utiliser pour cette demande. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
x-ms-client-request-id Optionnel. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes que le serveur reçoit. Pour plus d’informations, consultez [Surveiller le stockage Table Azure.

Corps de la demande

Aucun.

response

La réponse inclut un code d'état HTTP, un ensemble d'en-têtes de réponse et un corps de réponse.

Code d’état

Une opération réussie envoie le code d'état 200 (OK). Lorsqu’il est appelé sur un point de terminaison d’emplacement secondaire qui n’est pas activé pour une lecture secondaire, il retourne le code HTTP status 403 (Autorisations de compte insuffisantes).

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

En-tête de réponse Description
x-ms-request-id Identifie de manière unique la demande qui a été effectuée et peut être utilisée pour résoudre la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
x-ms-version Spécifie la version de l’opération utilisée pour la réponse. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
Date Valeur de date/heure UTC générée par le service, qui indique l’heure à laquelle la réponse a été lancée.
x-ms-client-request-id Peut être utilisé pour résoudre les problèmes liés aux demandes et aux réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id s’il est présent dans la requête et que la valeur ne contient pas plus de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la demande, il ne sera pas présent dans la réponse.

Response body

Le corps de la réponse présente le format suivant :

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

Les éléments du corps de la réponse sont décrits dans le tableau suivant :

En-tête de réponse Description
Status État de l'emplacement secondaire. Les valeurs possibles sont les suivantes :

- live : indique que l’emplacement secondaire est actif et opérationnel.
- bootstrap : indique que la synchronisation initiale de l’emplacement principal vers l’emplacement secondaire est en cours. Cela se produit généralement lorsque la réplication est activée pour la première fois.
- indisponible : indique que l’emplacement secondaire est temporairement indisponible.
LastSyncTime Valeur de date/heure UTC, à la seconde. Toutes les écritures primaires qui précèdent cette valeur sont garanties pour être disponibles pour les opérations de lecture à l’écriture secondaire. Les écritures primaires postérieures à ce point dans le temps peuvent ou non être disponibles pour les lectures.

La valeur peut être vide si LastSyncTime n’est pas disponible. Cela peut se produire si le status de réplication est bootstrap ou non disponible.

Bien que la géoréplication soit activée en continu, le LastSyncTime résultat peut refléter une valeur mise en cache du service qui est actualisée toutes les quelques minutes.

Autorisation

Seul le propriétaire du compte peut appeler cette opération.

Notes

Avec la réplication géoredondante, stockage Azure gère vos données durablement dans deux emplacements. Dans les deux emplacements, Stockage Azure gère en permanence plusieurs réplicas sains des données.

L'emplacement où vous lisez, créez, mettez à jour ou supprimez les données est l'emplacement du compte de stockage principal. L’emplacement principal existe dans la région que vous choisissez lorsque vous créez un compte via le portail Azure Management Azure Classic (par exemple, USA Centre Nord).

L'emplacement dans lequel vos données sont répliquées est l'emplacement secondaire. L’emplacement secondaire réside dans une région qui est automatiquement associée géographiquement à la région primaire. L'accès en lecture seule est disponible à partir de l'emplacement secondaire, si la réplication géographique redondante avec accès en lecture est activée pour votre compte de stockage.

Pour plus d’informations sur la réplication géoredondante avec accès en lecture, consultez Redondance des données.

Pour construire une demande d’opération de lecture sur le point de terminaison secondaire, ajoutez -secondary au nom du compte dans l’URI que vous utilisez pour lire à partir du stockage Table. Par exemple, un URI secondaire pour l’opération Query Entities est similaire à https://myaccount-secondary.table.core.windows.net/mytable(PartitionKey='<partition-key>',RowKey='<row-key>').

Exemple de requête et de réponse

Cet exemple illustre une demande de l'opération Get Table Service Stats :

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

La demande est envoyée avec les en-têtes suivants :

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

Le code d'état et les en-têtes de réponse sont renvoyés comme suit :

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

Cette réponse comprend le corps XML suivant :

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

Voir aussi

Opérations sur le compte (service de table)