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á.
# Estratégias de alternância da função do Lambda
Em [Função do Lambda de alternância](rotate-secrets_lambda.md), para segredos de bancos de dados, o Secrets Manager oferece duas estratégias de alternância.
## Estratégia de alternância: usuário único
Essa estratégia atualiza as credenciais de um único usuário em um segredo. Para instâncias do Db2 do Amazon RDS, como os usuários não podem alterar suas próprias senhas, é necessário fornecer credenciais de administrador em outro segredo. **Essa é a estratégia de alternância mais simples, e é apropriada para a maioria dos casos de uso.** Em particular, recomendamos que você use essa estratégia para obter credenciais para usuários únicos (ad hoc) ou interativos.
Quando o segredo é alternado, as conexões de banco de dados abertas não são descartadas. Enquanto a alternância acontece, há um curto período entre a alteração da senha no banco de dados e a atualização do segredo. Durante esse período, há um baixo risco de o banco de dados recusar chamadas que usam as credenciais alternadas. É possível mitigar esse risco com uma [estratégia de nova tentativa apropriada](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/). Após a alternância, as novas conexões usam as novas credenciais.
## Estratégia de alternância: usuários alternados
Essa estratégia atualiza as credenciais de dois usuários em um segredo. Você cria o primeiro usuário e, durante a primeira alternância, a função de alternância o clona para criar o segundo usuário. Toda vez que o segredo é alternado, a função de alternância alterna a senha do usuário que ela atualiza. Como a maioria dos usuários não tem permissão para se clonar, é necessário fornecer as credenciais para um `superuser` em outro segredo. Recomendamos o uso da estratégia de alternância de usuário único quando os usuários clonados em seu banco de dados não tiverem as mesmas permissões que o usuário original, e para credenciais de usuários únicos (ad hoc) ou interativos.
Essa estratégia é apropriada para bancos de dados com modelos de permissão em que uma função possui as tabelas de banco de dados e uma segunda função tem permissão para acessar as tabelas de banco de dados. Ela também é apropriada para aplicações que requerem alta disponibilidade. Se uma aplicação recuperar o segredo durante a alternância, a aplicação ainda obterá um conjunto válido de credenciais. Após a alternância, as credenciais do `user` e do `user_clone` são válidas. Há ainda menos chances de aplicações serem recusadas durante esse tipo de alternância em comparação com a alternância de usuário único. Se o banco de dados estiver hospedado em um farm de servidores em que a alteração de senha demora algum tempo para se propagar para todos os servidores, existe o risco de o banco de dados recusar chamadas que usam as novas credenciais. É possível mitigar esse risco com uma [estratégia de nova tentativa apropriada](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/).
O Secrets Manager cria o usuário clonado com as mesmas permissões do usuário original. Se você alterar as permissões do usuário original após a criação do clone, também deverá alterar as permissões do usuário clonado.
Por exemplo, se você criar um segredo com as credenciais de um usuário do banco de dados, o segredo conterá uma versão com essas credenciais.
**Primeira alternância**: a função de alternância cria um clone do seu usuário com uma senha gerada e essas credenciais se tornam a versão do segredo atual.
**Segunda alternância**: a função de alternância atualiza a senha do usuário original.
**Terceira alternância**: a função de alternância atualiza a senha do usuário clonado.
