As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Entendendo a política de repetição com o motorista na Amazon QLDB
Importante
Aviso de fim do suporte: os clientes existentes poderão usar a Amazon QLDB até o final do suporte em 31/07/2025. Para obter mais detalhes, consulte Migrar um Amazon QLDB Ledger para o Amazon Aurora Postgre
O QLDB motorista da Amazon usa uma política de repetição para lidar com exceções transitórias ao tentar novamente de forma transparente uma transação com falha. Essas exceções, como CapacityExceededException e RateExceededException, normalmente se corrigem após um período de tempo. Se a transação que falhou com a exceção for repetida após um atraso adequado, é provável que seja bem-sucedida. Isso ajuda a melhorar a estabilidade do aplicativo que usaQLDB.
Tipos de erros que podem ser tentados novamente
O driver repete automaticamente uma transação se e somente se alguma das seguintes exceções ocorrer durante uma operação dentro dessa transação:
-
CapacityExceededException— Retornado quando a solicitação excede a capacidade de processamento do livro contábil.
-
InvalidSessionException— Retornado quando uma sessão não é mais válida ou se a sessão não existe.
-
LimitExceededException— Retornado se um limite de recursos, como o número de sessões ativas, for excedido.
-
OccConflictException— Retornado quando uma transação não pode ser gravada no diário devido a uma falha na fase de verificação do controle otimista de simultaneidade ()OCC.
-
RateExceededException— Retornado quando a taxa de solicitações excede a taxa de transferência permitida.
Política padrão de tentativas
A política de repetição consiste em uma condição de nova tentativa e uma estratégia de recuo. A condição de nova tentativa define quando uma transação deve ser repetida, enquanto a estratégia de recuo define quanto tempo esperar antes de repetir a transação.
Ao criar uma instância do driver, a política de repetição padrão especifica a repetição até quatro vezes e o uso de uma estratégia de recuo exponencial. A estratégia de recuo exponencial usa um atraso mínimo de 10 milissegundos e um atraso máximo de 5000 milissegundos, com jitter igual. Se a transação não puder ser confirmada com sucesso dentro da política de repetição, recomendamos tentar a transação em outro momento.
O conceito por detrás do recuo exponencial é usar esperas progressivamente mais longas entre as novas tentativas para respostas de erro consecutivas. Para obter mais informações, consulte a postagem do AWS blog Exponential Backoff and
