Diagnosticar e solucionar problemas de disponibilidade de SDKs do Azure Cosmos DB em ambientes multirregionais
APLICA-SE A: NoSQL
Este artigo descreve o comportamento da versão mais recente dos SDKs do Azure Cosmos DB quando você vê um problema de conectividade em uma determinada região ou quando ocorre um failover de região.
Todos os SDKs do Azure Cosmos DB oferecem uma opção para personalizar a preferência regional. As seguintes propriedades são usadas em diferentes SDKs:
- A propriedade ConnectionPolicy.PreferredLocationsno SDK do .NET V2.
- As propriedades CosmosClientOptions.ApplicationRegion ou CosmosClientOptions.ApplicationPreferredRegions no SDK do .NET V3.
- O método CosmosClientBuilder.preferredRegions no SDK do Java v4.
- O parâmetro CosmosClient.preferred_locations no SDK do Python.
- O parâmetro CosmosClientOptions.ConnectionPolicy.preferredLocations no SDK do JS.
Quando o SDK é inicializado com uma configuração que especifica a preferência regional, ele primeiro obtém as informações da conta, incluindo as regiões disponíveis no ponto de extremidade global. Em seguida, ele aplica uma interseção da preferência regional configurada e das regiões disponíveis para a conta e usa a ordem de preferência regional para priorizar o resultado.
Se as regiões da configuração de preferência regional não estiverem disponíveis na conta, os valores serão ignorados. Se essas regiões inválidas forem adicionadas posteriormente à conta, o SDK as usará quando elas estiverem classificadas como prioritárias na configuração de preferência.
Tipo de conta | Leituras | Gravações |
---|---|---|
Região única de gravação | Região preferencial classificada como prioritária | Região primária |
Várias regiões de gravação | Região preferencial classificada como prioritária | Região preferencial classificada como prioritária |
Se você não definir uma região preferida, o cliente SDK usa como padrão a região primária:
Tipo de conta | Leituras | Gravações |
---|---|---|
Região única de gravação | Região primária | Região primária |
Várias regiões de gravação | Região primária | Região primária |
Observação
“Região primária” refere-se à primeira região na lista de regiões da conta do Azure Cosmos DB. Se os valores especificados como preferência regional não corresponderem a nenhuma região do Azure existente, eles serão ignorados. Se eles corresponderem a uma região existente, mas a conta não for replicada para ela, o cliente se conectará à próxima região preferida correspondente ou à região primária.
Aviso
A lógica de failover e disponibilidade descrita neste documento pode ser desabilitada na configuração do cliente, o que não é recomendável, a menos que o aplicativo do usuário trate os erros de disponibilidade em si. Isso pode ser feito:
- Definindo a propriedade ConnectionPolicy.EnableEndpointDiscovery no SDK V2 do .NET como false.
- Definindo a propriedade CosmosClientOptions.LimitToEndpoint no SDK do .NET V3 como true.
- Definindo o método CosmosClientBuilder.endpointDiscoveryEnabled no SDK do Java v4 como false.
- Definindo o parâmetro CosmosClient.enable_endpoint_discovery no SDK do Python como false.
- Definindo o parâmetro CosmosClientOptions.ConnectionPolicy.enableEndpointDiscovery no SDK do JS como false.
Em circunstâncias normais, o cliente do SDK se conectará à região preferida (se uma preferência regional estiver definida) ou à região primária (se nenhuma preferência estiver definida) e as operações serão limitadas a essa região, a menos que qualquer um dos cenários a seguir ocorra.
Nesses casos, o cliente que usa o SDK do Azure Cosmos DB expõe logs e inclui as informações de repetição como parte das informações de diagnóstico da operação:
- Na propriedade RequestDiagnosticsString em respostas no SDK do .NET V2.
- Na propriedade Diagnostics em respostas e exceções no SDK do .NET V3.
- O método getDiagnostics () em respostas e exceções no SDK do Java V4.
Ao determinar a próxima região na ordem de preferência, o cliente SDK usará a lista de região da conta, priorizando as regiões preferidas (se houver).
Para obter detalhes abrangentes sobre as garantias de SLA durante esses eventos, consulte os SLAs de disponibilidade.
Removendo uma região da conta
Quando você remove uma região de uma conta do Azure Cosmos DB, qualquer cliente do SDK que usa ativamente a conta detectará a remoção da região através de um código de resposta de back-end. O cliente marca o ponto de extremidade regional como indisponível. O cliente tenta novamente a operação atual e todas as operações futuras são roteadas permanentemente para a próxima região na ordem de preferência. Caso a lista de preferências tenha apenas uma entrada (ou esteja vazia), mas a conta tenha outras regiões disponíveis, ela será roteada para a próxima região na lista da conta.
Adicionando uma região a uma conta
A cada cinco minutos, o cliente do SDK do Azure Cosmos DB lê a configuração da conta e atualiza as regiões conhecidas.
Se você remover uma região e posteriormente adicioná-la de volta à conta, se a região adicionada tiver uma ordem de preferência regional maior na configuração do SDK do que a região conectada atual, o SDK voltará a usar essa região de forma permanente. Depois que a região adicionada for detectada, todas as solicitações futuras serão direcionadas para ela.
Se você configurar o cliente para se conectar preferencialmente a uma região não disponível na conta do Azure Cosmos DB, a região preferencial será ignorada. Se você adicionar essa região posteriormente, o cliente a detectará e será alternado permanentemente para essa região.
Fazer failover da região de gravação em uma única conta de região de gravação
Se você iniciar um failover da região de gravação atual, a próxima solicitação de gravação falhará com uma resposta de back-end conhecida. Quando essa resposta for detectada, o cliente consultará a conta para conhecer a nova região de gravação e prosseguirá para repetir a operação atual e roteará permanentemente todas as operações de gravação futuras para a nova região.
Interrupção regional
Se a conta for uma região única de gravação e a interrupção regional ocorrer durante uma operação de gravação, o comportamento será semelhante a um failover manual. Para solicitações de leitura ou contas de várias regiões de gravação, o comportamento é semelhante à remoção de uma região.
Garantias de consistência da sessão
Ao usar a consistência da sessão, o cliente precisa garantir que ele possa ler suas próprias gravações. Em contas de região única de gravação nas quais a preferência de região de leitura é diferente da região de gravação, pode haver casos em que o usuário emite uma gravação e depois faz uma leitura de uma região local, a região local ainda não recebeu a replicação de dados (restrição à velocidade da luz). Nesses casos, o SDK recebe uma falha específica do serviço na operação de leitura e repete a leitura na região primária para garantir a consistência da sessão. Para contas com várias regiões de gravação, a mesma semântica de sessão se aplica, mas como há várias regiões de gravação disponíveis, as novas tentativas são feitas usando a lista de regiões preferenciais ou a ordem das regiões da conta.
Problemas de conectividade transitórios no protocolo TCP
Quando o cliente do SDK do Azure Cosmos DB está configurado para usar o protocolo TCP para uma determinada solicitação, pode haver situações em que as condições de rede afetem temporariamente a comunicação com um ponto de extremidade específico. Essas condições de rede temporárias podem surgir como tempos limite de TCP e erros de Serviço Indisponível (HTTP 503). O cliente, se possível, tentará novamente a solicitação localmente no mesmo ponto de extremidade por alguns segundos.
Se o usuário tiver configurado uma lista de regiões preferenciais com mais de uma região e o cliente tiver esgotado todas as tentativas locais, ele poderá tentar repetir essa única operação na próxima região da lista de preferências. As operações de gravação só poderão ser repetidas em outra região se a conta do Azure Cosmos DB tiver várias regiões de gravação habilitadas, enquanto as operações de leitura poderão ser repetidas em qualquer região disponível.
Próximas etapas
- Examine os SLAs de disponibilidade.
- Use o SDK do .NET mais recente
- Use o SDK do Java mais recente
- Use o SDK do Python mais recente
- Use o SDK do Node mais recente