Obter estatísticas de serviço de mesa

A Get Table Service Stats operação recupera estatísticas relacionadas com a replicação do serviço Table. Só está disponível no ponto final de localização secundária quando a replicação geo-redundante de acesso de leitura estiver ativada para a conta de armazenamento.

Pedir

O Get Table Service Stats pedido pode ser construído da seguinte forma. HTTPS é recomendado. myaccountSubstitua-o pelo nome da sua conta de armazenamento e note que o -secondary sufixo é necessário:

Método URI do pedido Versão HTTP
GET https://myaccount-secondary.table.core.windows.net/?restype=service&comp=stats HTTP/1.1

Note que o URI deve incluir sempre o corte dianteiro (/) para separar o nome do hospedeiro do caminho e porções de consulta do URI. No caso desta operação, a parte do caminho do URI está vazia.

Parâmetros do URI

Os seguintes parâmetros adicionais podem ser especificados no pedido URI.

Parâmetro Descrição
Timeout Opcional. O timeout parâmetro é expresso em segundos.

Pedido cabeçalhos

A tabela seguinte descreve os cabeçalhos de pedido necessários e opcionais.

Cabeçalho do Pedido Description
Authorization Obrigatório. Especifica o esquema de autorização, nome da conta e assinatura. Para mais informações, consulte Os pedidos autorizados à Azure Armazenamento.
Date or x-ms-date Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para mais informações, consulte Os pedidos autorizados à Azure Armazenamento.
x-ms-version Requerido para todos os pedidos autorizados. Especifica a versão da operação a utilizar para este pedido. Para mais informações, consulte a versão para os serviços Azure Armazenamento.
x-ms-client-request-id Opcional. O cliente gerou valor opaco com um limite de caracteres de 1KB que é gravado nos registos de análise quando Armazenamento Adoção de Registos de Analytics está ativada. A utilização deste cabeçalho é altamente recomendada para correlacionar as atividades do lado do cliente com os pedidos recebidos pelo servidor. Para mais informações consulte Azure Logging: Utilização de Registos para rastrear pedidos de Armazenamento.

Corpo do Pedido

Nenhum.

Resposta

A resposta inclui um código de estado HTTP, um conjunto de cabeçalhos de resposta e um corpo de resposta

Código de Estado

Uma operação bem sucedida devolve o código de estado 200 (OK). Quando chamado para o ponto final de localização secundária que não está ativado para leitura secundária, devolverá o código de estado de Http de 403 com InsufficientAccountPermissions erro.

Cabeçalhos de Resposta

A resposta para esta operação inclui os seguintes cabeçalhos. A resposta também inclui cabeçalhos HTTP padrão adicionais. Todos os cabeçalhos standard estão em conformidade com a especificação do protocolo HTTP/1.1.

Cabeçalho de Resposta Descrição
x-ms-request-id Este cabeçalho identifica exclusivamente o pedido que foi feito e pode ser usado para resolver problemas no pedido. Para obter mais informações, consulte operações de API de resolução de problemas.
x-ms-version Especifica a versão da operação utilizada para a resposta. Para mais informações, consulte a versão para os serviços Azure Armazenamento.
Date Uma data/valor de hora UTC gerado pelo serviço que indica o momento em que a resposta foi iniciada.
x-ms-client-request-id Este cabeçalho pode ser usado para resolver pedidos e respostas correspondentes. O valor deste cabeçalho é igual ao valor do x-ms-client-request-id cabeçalho se estiver presente no pedido e o valor for no máximo 1024 caracteres ASCII visíveis. Se o x-ms-client-request-id cabeçalho não estiver presente no pedido, este cabeçalho não estará presente na resposta.

Corpo de Resposta

O formato do corpo de resposta é o seguinte:

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

A tabela a seguir descreve os elementos do corpo de resposta:

Cabeçalho de Resposta Descrição
Status O estado da localização secundária. Os valores possíveis são:

- live: Indica que a localização secundária está ativa e operacional.
- bootstrap: Indica que a sincronização inicial da localização primária para a localização secundária está em curso. Isto ocorre tipicamente quando a replicação é ativada pela primeira vez.
- indisponível: Indica que a localização secundária está temporariamente indisponível.
LastSyncTime Uma data/valor de hora GMT, para o segundo. Todas as escritas primárias anteriores a este valor estão garantidamente disponíveis para operações de leitura no secundário. As primeiras escritas após este ponto no tempo podem ou não estar disponíveis para leituras.

O valor pode estar vazio se LastSyncTime não estiver disponível. Isto pode acontecer se o estado de replicação for bootstrap ou unavailable .

Embora a geo-replicação esteja continuamente ativada, o LastSyncTime resultado pode refletir um valor em cache do serviço que é atualizado a cada poucos minutos.

Autorização

Só o proprietário da conta pode ligar para esta operação.

Observações

Com a replicação geo-redundante, a Azure Armazenamento mantém os seus dados duráveis em dois locais. Em ambos os locais, a Azure Armazenamento mantém constantemente múltiplas réplicas saudáveis dos seus dados.

O local onde lê, cria, atualiza ou apaga dados é a localização da conta de armazenamento primária. A localização primária existe na região que você escolhe no momento em que você cria uma conta através do portal clássico Azure Management Azure, por exemplo, North Central US. A localização para a qual os seus dados são replicados é a localização secundária. A localização secundária reside numa região que é automaticamente emparelhada geograficamente com a região primária. O acesso apenas à leitura está disponível a partir da localização secundária, se a replicação geo-redundante de acesso de leitura estiver ativada para a sua conta de armazenamento. Para obter mais detalhes sobre a replicação geo-redundante de acesso à leitura, consulte o Azure Armazenamento Team Blog.

Para construir um pedido de operação de leitura contra o ponto final secundário, -secondary apendam-se como um sufixo ao nome da conta no URI que utiliza para ler a partir do armazenamento da mesa. Por exemplo, um URI secundário para a operação Entidades De consulta será semelhante a https://myaccount-secondary.table.core.windows.net/mytable(PartitionKey='<partition-key>',RowKey='<row-key>') .

Pedido e Resposta da Amostra

Segue-se um pedido de amostra para a Get Table Service Stats operação:

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

O pedido é enviado com os seguintes cabeçalhos:

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

O código de estado e os cabeçalhos de resposta são devolvidos da seguinte forma:

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  

A resposta inclui o seguinte corpo XML:

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

Ver também

Operações na Conta (Serviço de Tabela)