VENDAS: 1-800-867-1389

Obter status do serviço Tabela

Atualizado: abril de 2014

A operação Get Table Service Stats recupera as estatísticas relacionadas à replicação para o serviço Tabela. Ela está disponível apenas no ponto de extremidade de local secundário quando a replicação georredundante de acesso de leitura está habilitada para a conta de armazenamento.

A solicitação Get Table Service Stats pode ser criada da seguinte maneira. HTTPS é recomendado. Substitua myaccount pelo nome da sua conta de armazenamento. Note que o sufixo -secondary é necessário:

 

Método URI de solicitação Versão de HTTP

GET

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

HTTP/1.1

Observe que o URI sempre deve incluir a barra (/) para separar o nome do host do caminho e as partes de consulta do URI. No caso dessa operação, a parte do caminho do URI fica vazia.

Os seguintes parâmetros adicionais podem ser especificados no URI de solicitação.

 

Parâmetro Descrição

Timeout

Opcional. O parâmetro timeout é expresso em segundos.

A tabela a seguir descreve os cabeçalhos de solicitação obrigatórios e opcionais.

 

Cabeçalho de solicitação Descrição

Authorization

Obrigatória. Especifica o esquema de autenticação, o nome da conta e a assinatura. Para obter mais informações, consulte Autenticação para os Serviços de Armazenamento do Windows Azure.

Date or x-ms-date

Obrigatória. Especifica o Tempo Universal Coordenado (UTC) para a solicitação. Para obter mais informações, consulte Autenticação para os Serviços de Armazenamento do Windows Azure.

x-ms-version

Obrigatório para todas as solicitações autenticadas. Especifica a versão da operação a ser usada para esta solicitação. Para obter mais informações, consulte Controle de versão dos serviços Arquivo, Blob, Fila e Tabela no Windows Azure.

x-ms-client-request-id

Opcional. Valor opaco gerado pelo cliente com limite de caractere de 1KB que será registrado nos logs de análise quando Sobre o registro em log da Análise de Armazenamento for habilitado. O uso deste cabeçalho é altamente recomendável para correlacionar atividades do lado do cliente com solicitações recebidas pelo servidor. Para obter mais informações, consulte Log do Windows Azure: Usando logs para rastrear solicitações de armazenamento.

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

Uma operação bem-sucedida retorna o código de status 200 (OK). Quando a chamada ocorrer no ponto de extremidade do local secundário, que não está habilitado para a leitura secundária, isso retornará um código de status Http 403 com erro InsufficientAccountPermissions.

Para obter informações sobre códigos de status, consulte Status e códigos de erro de gerenciamento de serviços.

A resposta para esta operação inclui os cabeçalhos a seguir. A resposta também inclui cabeçalhos padrão HTTP adicionais. Todos os cabeçalhos padrão obedecem à especificação de protocolo HTTP/1.1.

 

Cabeçalho de resposta

Descrição

x-ms-request-id

Esse cabeçalho identifica a solicitação que foi feita de forma exclusiva e pode ser usado para solucionar problemas na solicitação. Para obter mais informações, consulte Solucionando problemas de operações de API.

x-ms-version

Especifica a versão da operação usada para a resposta. Para obter mais informações, consulte Controle de versão dos serviços Blob, Fila e Tabela no Windows Azure.

Date

Um valor de data/hora UTC gerado pelo serviço que indica a hora em que a resposta foi iniciada.

Formato do corpo da resposta:

<?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 da resposta:

 

Cabeçalho de resposta

Descrição

Status

O status do local secundário. Os possíveis valores são:

  • live: indica que o local secundário está ativo e operacional.

  • bootstrap: indica que a sincronização inicial do local primário no local secundário está em andamento. Isso normalmente ocorre quando a replicação é habilitada pela primeira vez.

  • indisponível: indica que o local secundário está temporariamente indisponível.

LastSyncTime

Um valor de data/hora GMT, para o segundo. Todas as gravações primárias anteriores a esse valor estão certamente disponíveis para operações de leitura no local secundário. Gravações primárias após esse momento determinado podem ou não estar disponíveis para leituras.

O valor pode estar vazio se LastSyncTime não está disponível. Isso pode ocorrer se o status de replicação é bootstrap ou unavailable.

Embora a georreplicação esteja continuamente ativada, o resultado LastSyncTime pode refletir um valor armazenado em cache do serviço que é atualizado a cada intervalo de minutos.

Somente o proprietário da conta pode chamar essa operação.

Com a replicação georredundante, o Armazenamento do Windows Azure mantém seus dados duráveis em dois locais. Em ambos os locais, o Armazenamento do Windows Azure mantém constantemente várias réplicas íntegras de seus dados.

O local onde você lê, cria, atualiza ou exclui dados é o local da conta de armazenamento principal. O local principal existe na região que você escolhe quando cria uma conta por meio do Portal de Gerenciamento do Windows Azure; por exemplo, Centro-Norte dos Estados Unidos. O local no qual seus dados são replicados é o local secundário. O local secundário é determinado automaticamente com base no local principal; ele está em um segundo data center que reside na mesma região que o local principal. O acesso somente leitura está disponível no local secundário se a replicação georredundante de acesso de leitura está habilitada para sua conta de armazenamento. Para obter mais detalhes sobre a replicação georredundante de acesso de leitura, consulte o Blog da Equipe de Armazenamento do Windows Azure.

Para construir uma solicitação para uma operação de leitura no ponto de extremidade secundário, acrescente -secondary como um sufixo ao nome da conta no URI que você usa para ler do armazenamento da tabela. 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>').

Esta é uma solicitação de exemplo para a operação Get Table Service Stats:

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

A solicitação é enviada 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=

Os cabeçalhos de código de status e de resposta são retornados 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>

Consulte também

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft