Recuperação rápida após failover com o gerenciamento de cache do cluster para o Aurora PostgreSQL - Amazon Aurora
Configuração do gerenciamento de cache do clusterMonitorar o cache do bufferSolução de problemas de configuração do CCM

Recuperação rápida após failover com o gerenciamento de cache do cluster para o Aurora PostgreSQL

Para a recuperação rápida da instância de banco de dados do gravador em seus clusters do Aurora PostgreSQL, se houver um failover, use o gerenciamento de cache do cluster para o Amazon Aurora PostgreSQL. O gerenciamento de cache do cluster garante que a performance da aplicação seja mantida se houver um failover.

Em uma situação de failover típica, você pode ver uma degradação de performance temporária, mas grande, depois do failover. Essa degradação ocorre porque quando a instância de banco de dados de failover é iniciada, o cache do buffer está vazio. Um cache vazio também é conhecido como um cache frio. Um cache frio degrada a performance porque a instância de banco de dados precisa ler no disco, que é mais lento, em vez de aproveitar os valores armazenados no cache do buffer.

Com o gerenciamento de cache do cluster, você define uma instância de banco de dados do leitor específica como o destino do failover. O gerenciamento de cache do cluster garante que os dados no cache do leitor designado sejam mantidos sincronizados com os dados no cache da instância de banco de dados do gravador. O cache do leitor designado com valores pré-preenchidos é conhecido como um cache quente. Se ocorrer um failover, o leitor designado usará valores de seu cache quente imediatamente quando for promovido para a nova instância de banco de dados do gravador. Essa abordagem fornece uma performance de recuperação muito melhor à sua aplicação.

O gerenciamento de cache do cluster requer que a instância do leitor designada tenha o mesmo tipo de classe de instância e tamanho (db.r5.2xlarge ou db.r5.xlarge, por exemplo) que o gravador. Tenha isso em mente ao criar seus clusters de banco de dados do Aurora PostgreSQL para que seu cluster possa se recuperar durante um failover. Para obter uma lista de tipos e tamanhos de classe de instância, consulte Especificações de hardware para classes de instância de banco de dados para o Aurora.

nota

Não há suporte ao gerenciamento de cache de cluster para clusters de banco de dados Aurora PostgreSQL que fazem parte de bancos de dados globais do Aurora. É recomendável que nenhuma workload seja executada no leitor de nível 0 designado.

Configuração do gerenciamento de cache do cluster

Para configurar o gerenciamento de cache do cluster, realize os processos a seguir na ordem especificada.

nota

Aguarde pelo menos 1 minuto depois de concluir estas etapas para que o gerenciamento de cache de cluster esteja totalmente operacional.

Habilitar o gerenciamento de cache do cluster

Para habilitar o gerenciamento de cache do cluster, siga as etapas descritas a seguir.

Para habilitar o gerenciamento de cache do cluster

  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, selecione Parameter groups.

  3. Na lista, escolha o grupo de parâmetros para seu cluster de banco de dados Aurora PostgreSQL.

    O cluster de banco de dados deve usar um grupo de parâmetros diferente do padrão, porque não é possível alterar os valores em um grupo de parâmetros padrão.

  4. Em Parameter group actions (Ações do grupo de parâmetros), escolha Edit (Editar).

  5. Defina o valor do parâmetro do cluster apg_ccm_enabled como 1.

  6. Selecione Save changes.

Para habilitar o gerenciamento de cache do cluster para um cluster de banco de dados do Aurora PostgreSQL, use o comando da AWS CLI modify-db-cluster-parameter-group com os seguintes parâmetros obrigatórios:

  • --db-cluster-parameter-group-name

  • --parameters

exemplo

Para Linux, macOS ou Unix:

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my-db-cluster-parameter-group \
    --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

Para Windows:

aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my-db-cluster-parameter-group ^
    --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

Definir a prioridade da camada de promoção para a instância de banco de dados do gravador

Para o gerenciamento de cache do cluster, verifique se a prioridade de promoção é tier-0 para a instância de banco de dados do gravador do cluster de banco de dados do Aurora PostgreSQL. A prioridade da camada de promoção é um valor que especifica a ordem em que um leitor do Aurora é promovido para a instância de banco de dados do leitor depois de uma falha. Os valores válidos são 0 – 15, em que 0 é a primeira prioridade, e 15 é a última prioridade. Para obter mais informações sobre a camada de promoção, consulte Tolerância a falhas para um cluster de banco de dados do Aurora.

Para definir a prioridade da camada de promoção da instância de banco de dados do gravador como tier-0.

  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Databases (Bancos de dados).

  3. Escolha a instância de banco de dados do Writer (Gravador) do cluster de banco de dados Aurora PostgreSQL.

  4. Selecione Modify. A página Modify DB Instance (Modificar instância de banco de dados) é exibida.

  5. No painel Additional configuration (Configuração adicional), escolha a tier-0 (camada-0) para a Failover priority (Prioridade de failover).

  6. Selecione Continue (Continuar) e verifique o resumo de modificações.

  7. Para aplicar as alterações imediatamente depois de salvá-las, escolha Apply immediately (Aplicar imediatamente).

  8. Selecione Modify DB Instance (Modificar instância de banco de dados) para salvar suas alterações.

Para definir a prioridade da camada de promoção como 0 para a instância de banco de dados do gravador usando a AWS CLI, chame o comando modify-db-instance com os seguintes parâmetros obrigatórios:

  • --db-instance-identifier

  • --promotion-tier

  • --apply-immediately

exemplo

Para Linux, macOS ou Unix:

aws rds modify-db-instance \
    --db-instance-identifier writer-db-instance \
    --promotion-tier 0 \
    --apply-immediately

Para Windows:

aws rds modify-db-instance ^
    --db-instance-identifier writer-db-instance ^
    ---promotion-tier 0  ^
    --apply-immediately

Definir a prioridade da camada de promoção para a instância de banco de dados do leitor

É necessário definir somente uma instância de banco de dados de leitor para o gerenciamento de cache do cluster. Para isso, escolha um leitor no cluster do Aurora PostgreSQL que seja da mesma classe e tamanho de instância que a instância de banco de dados do gravador. Por exemplo, se o gravador usar db.r5.xlarge, escolha um leitor que use esse mesmo tipo e tamanho de classe de instância. Depois, defina a prioridade de sua camada de promoção como 0.

A prioridade da camada de promoção é um valor que especifica a ordem em que um leitor do Aurora é promovido para a instância de banco de dados do leitor depois de uma falha. Os valores válidos são 0 – 15, em que 0 é a primeira prioridade, e 15 é a última prioridade.

Para definir a prioridade de promoção da instância de banco de dados do leitor como tier-0

  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Databases (Bancos de dados).

  3. Escolha uma instância de banco de dados do Reader (Leitor) do cluster de banco de dados do Aurora PostgreSQL que seja da mesma classe de instância que a instância de banco de dados do gravador.

  4. Selecione Modify. A página Modify DB Instance (Modificar instância de banco de dados) é exibida.

  5. No painel Additional configuration (Configuração adicional), escolha a tier-0 (camada-0) para a Failover priority (Prioridade de failover).

  6. Selecione Continue (Continuar) e verifique o resumo de modificações.

  7. Para aplicar as alterações imediatamente depois de salvá-las, escolha Apply immediately (Aplicar imediatamente).

  8. Selecione Modify DB Instance (Modificar instância de banco de dados) para salvar suas alterações.

Para definir a prioridade da camada de promoção como 0 para a instância de banco de dados do gravador usando a AWS CLI, chame o comando modify-db-instance com os seguintes parâmetros obrigatórios:

  • --db-instance-identifier

  • --promotion-tier

  • --apply-immediately

exemplo

Para Linux, macOS ou Unix:

aws rds modify-db-instance \
    --db-instance-identifier reader-db-instance \
    --promotion-tier 0 \
    --apply-immediately

Para Windows:

aws rds modify-db-instance ^
    --db-instance-identifier reader-db-instance ^
    ---promotion-tier 0  ^
    --apply-immediately

Monitorar o cache do buffer

Depois de configurar o gerenciamento de cache de cluster, você pode monitorar o estado de sincronização entre o cache de buffer da instância de banco de dados do gravador e o cache de buffer a quente do leitor designado. Para examinar o conteúdo do cache do buffer nas instâncias de banco de dados do gravador e do leitor, use o módulo pg_buffercache do PostgreSQL. Para obter mais informações, consulte a seção Documentação pg_buffercache do PostgreSQL.

Como usar a função aurora_ccm_status

O gerenciamento de cache do cluster também fornece a função aurora_ccm_status. Use a função aurora_ccm_status na instância de banco de dados do gravador para obter as informações a seguir sobre o andamento do aquecimento do cache no leitor designado:

  • buffers_sent_last_minute – quantos buffers foram enviados ao leitor designado no último minuto.

  • buffers_found_last_minute: o número de buffers acessados com frequência que foram identificados durante o último minuto.

  • buffers_sent_last_scan – quantos buffers foram enviados ao leitor designado durante a última verificação completa do cache do buffer.

  • buffers_found_last_scan – quantos buffers foram identificados como acessados com frequência e precisaram ser enviados durante a última verificação completa do cache do buffer. Os buffers que já estão em cache no leitor designado não são enviados.

  • buffers_sent_current_scan – quantos buffers foram enviados até agora durante a verificação atual.

  • buffers_found_current_scan – quantos buffers forma identificados como acessados com frequência na verificação atual.

  • current_scan_progress – quantos buffers foram visitados até agora durante a verificação atual.

O exemplo a seguir mostra como usar a função aurora_ccm_status para converter parte de sua saída em uma taxa quente e em uma porcentagem quente.

SELECT buffers_sent_last_minute*8/60 AS warm_rate_kbps, 
   100*(1.0-buffers_sent_last_scan::float/buffers_found_last_scan) AS warm_percent 
   FROM aurora_ccm_status();

Solução de problemas de configuração do CCM

Ao habilitar o parâmetro de cluster apg_ccm_enabled, o gerenciamento do cache do cluster é ativado automaticamente em nível de instância na instância de banco de dados de gravador e em uma instância de banco de dados de leitor no cluster de banco de dados do Aurora PostgreSQL. As instâncias de gravador e de leitor devem usar o mesmo tipo e tamanho de classe de instância. A prioridade do nível de promoção deles é definida como 0. Outras instâncias de leitor no cluster de banco de dados devem ter um nível de promoção diferente de zero e o gerenciamento do cache do cluster está desabilitado para essas instâncias.

Os motivos a seguir podem causar problemas na configuração e desabilitar o gerenciamento do cache do cluster:

  • Quando não há uma única instância de banco de dados de leitor definida como nível de promoção 0.

  • Quando a instância de banco de dados de leitor não está definida como nível de promoção 0.

  • Quando mais de uma instância de banco de dados de leitor está definida como nível de promoção 0.

  • Quando as instâncias de gravador e uma instância de banco de dados de leitor com nível de promoção 0 não têm o mesmo tamanho de instância.