O que acontece quando removemos o SnapshotIdentifier da nossa configuração do Cloudformation

Question

Quando criamos nossa pilha do Cloudformation, restauramos nosso DBCluster a partir de um instantâneo. Estamos agora no processo de atualizar nossa pilha.

O que a Cloudformation fará com nosso DBCluster se removermos a chave SnapshotIdentifier da nossa configuração? Vamos supor aqui que não estamos usando políticas de pilha.

Os documentos mostre que atualizar esse parâmetro causaria uma substituição. No entanto, não é isso que queremos, e não teríamos certeza do que fazer exatamente para evitar isso.

Obrigado!

    

Answer 1

Essa mudança no atributo DBSnapshotIdentifier resultará, de fato, em uma substituição do AWS :: RDS :: DBInstance.

Nos bastidores, o CloudFormation (CFN) armazena a configuração atual de todos os recursos. Quando você atualiza um recurso, o CFN faz uma chamada de descrição desses recursos e os compara aos valores armazenados.

Somente se os valores realmente mudarem, os recursos serão atualizados. Dito isso, desde que você não atualize a propriedade DBSnapshotIdentifier, o banco de dados não deve ser substituído.

Com o RDS, esse comportamento do CFN pode causar problemas irritantes, especialmente se os pontos de extremidade do RDS forem alterados.

Isso é o que atualmente consideramos boa prática:

1. Estabeleça uma pilha RDS própria, que é separada dos demais. Exporte o terminal RDS como "RDSEndpoint- $ Version". Definir a versão como um parâmetro.
2. Aponte seus aplicativos para o endpoint RDS correto. Usar a exportação da pilha anterior ou usar uma entrada Route53 para isso seria mais fácil.
3. Se você precisar fazer alterações nas instâncias do RDS que causam uma substituição, faça-as em uma nova pilha do RDS, altere $ Version para outra coisa.
4. Quando tudo estiver bem. Altere o endpoint RDS em seus aplicativos (ou altere a entrada Route53, o que melhor lhe convier).

Problemas comuns são:

• Duração da migração de dados entre bancos de dados - se o seu aplicativo não suportar isso, você poderá ter problemas.
• As operações de alteração do RDS são geralmente um pouco lentas. Frequentemente, é mais rápido executar apenas o mysqldump + mysql (no caso do MySQL) em vez de confiar nas instâncias do AWS.
• Perda de credenciais ao alternar para uma nova pilha (você deve ter documentado as credenciais, mas considere isso de qualquer maneira).

Se você está procurando uma solução única para seu problema específico, aqui está um (com possível tempo de inatividade):

1. Leve seu aplicativo para o modo somente leitura ou de manutenção (se o aplicativo não suportar isso, isso pode estar causando o tempo de inatividade).
2. (Manualmente ou com o Instantâneo do RDS) crie um despejo do seu banco de dados.
3. Atualize seu banco de dados com seu novo modelo do CloudFormation
4. Restaurar do seu despejo.
5. Altere seu aplicativo para produção. Se o endpoint mudou, mude também.