Como a replicação de streaming funciona para diferentes versões do RDS para PostgreSQL - Amazon Relational Database Service

Como a replicação de streaming funciona para diferentes versões do RDS para PostgreSQL

Conforme discutido em Configuração de réplica de leitura com o PostgreSQL, o RDS para PostgreSQL usa o protocolo de replicação de streaming nativo do PostgreSQL para enviar dados de WAL da instância de banco de dados de origem. Ele envia dados de WAL de origem para as réplicas de leitura na região e entre regiões. Com a versão 9.4, o PostgreSQL introduziu slots de replicação física como um mecanismo de suporte para o processo de replicação.

Um slot de replicação física impede que uma instância de banco de dados de origem remova dados de WAL antes que sejam consumidos por todas as réplicas de leitura. Cada réplica de leitura possui seu próprio slot físico na instância de banco de dados de origem. O slot monitora o WAL mais antigo (por número de sequência lógica, LSN) que pode ser necessário para a réplica. Depois que todos os slots e conexões de banco de dados progrediram além de um determinado WAL (LSN), esse LSN se torna um candidato para remoção no próximo ponto de verificação.

O Amazon RDS usa o Amazon S3 para arquivar dados de WAL. Para réplicas de leitura na região, é possível usar esses dados arquivados para recuperar a réplica de leitura quando necessário. Um exemplo de quando isso pode ser necessário é se a conexão entre o banco de dados de origem e a réplica de leitura for interrompida por qualquer motivo.

Na tabela a seguir, é possível encontrar um resumo das diferenças entre as versões do PostgreSQL e os mecanismos de suporte para réplicas de leitura na região e entre regiões usados pelo RDS para PostgreSQL.

Versão Na região Entre regiões
PostgreSQL 14.1 e versões posteriores
  • Slots de replicação

  • Arquivo do Amazon S3

  • Slots de replicação

PostgreSQL 13 e versões anteriores
  • Arquivo do Amazon S3

  • Slots de replicação

Para obter mais informações, consulte Monitoração e ajuste do processo de replicação.

Noções básicas dos parâmetros que controlam a replicação do PostgreSQL

Os parâmetros a seguir afetam o processo de replicação e determinam como as réplicas de leitura permanecem atualizadas com a instância de banco de dados de origem:

max_wal_senders

O parâmetro max_wal_senders especifica o número máximo de conexões com as quais a instância de banco de dados de origem é compatível ao mesmo tempo por meio do protocolo de replicação de streaming.

O valor padrão varia para versões do RDS para PostgreSQL:

  • Para as versões 13, 14 e 15, o valor padrão é 20.

  • Para as versões 16 e posteriores, o valor padrão é 35.

Esse parâmetro deve ser definido como um número um pouco maior que o número real de réplicas de leitura. Se esse parâmetro for definido muito baixo para o número de réplicas de leitura, a replicação será interrompida.

Para obter mais informações, consulte max_wal_senders na documentação do PostgreSQL.

nota

max_wal_senders é um parâmetro estático que requer a reinicialização da instância de banco de dados para que as alterações sejam aplicadas.

wal_keep_segments

O parâmetro wal_keep_segments especifica o número de arquivos de log de gravação antecipada (WAL) que a instância de banco de dados de origem mantém no diretório pg_wal. A configuração padrão é 32.

Se wal_keep_segments não estiver definido como um valor grande o suficiente para sua implantação, uma réplica de leitura poderá ficar tão distante que interromperá a replicação de streaming. Se isso acontecer, o Amazon RDS gerará um erro de replicação e iniciará a recuperação na réplica de leitura. Ele faz isso reproduzindo os dados de WAL arquivados da instância de banco de dados de origem no Amazon S3. Este processo de recuperação continua até que a réplica de leitura tenha alcançado o suficiente para continuar com a replicação de streaming. É possível ver esse processo em ação, conforme capturado pelo log do PostgreSQL em Exemplo: como uma réplica de leitura se recupera de interrupções de replicação.

nota

No PostgreSQL versão 13, o parâmetro wal_keep_segments é chamado de wal_keep_size. Ele atende ao mesmo propósito que wal_keep_segments, mas seu valor padrão é em megabytes (MB) (2048 MB) em vez do número de arquivos. Para obter mais informações, consulte wal_keep_segments e wal_keep_size na documentação do PostgreSQL.

max_slot_wal_keep_size

O parâmetro max_slot_wal_keep_size controla a quantidade de dados de WAL que a instância de banco de dados do RDS para PostgreSQL retém no diretório pg_wal para atender a slots. Esse parâmetro é usado para configurações que usam slots de replicação. O valor padrão desse parâmetro é -1, o que significa que não há limite para a quantidade de dados de WAL mantidos na instância de banco de dados de origem. Para obter informações sobre como monitorar os slots de replicação, consulte Monitorar os slots de replicação da instância de banco de dados do RDS para PostgreSQL.

Para obter mais informações sobre esse parâmetro, consulte max_slot_wal_keep_size na documentação do PostgreSQL.

Quando a transmissão que fornece dados de WAL a uma réplica de leitura é interrompida, o PostgreSQL muda para o modo de recuperação. Ele restaura a réplica de leitura usando os dados de WAL arquivados no Amazon S3 ou usando dados de WAL associados ao slot de replicação. Quando esse processo é concluído, o PostgreSQL restabelece a replicação de streaming.

Exemplo: como uma réplica de leitura se recupera de interrupções de replicação

No exemplo a seguir, você encontra os detalhes do log que demonstram o processo de recuperação de uma réplica de leitura. O exemplo é de uma instância de banco de dados do RDS para PostgreSQL que executa o PostgreSQL versão 12.9 na mesma Região da AWS que o banco de dados de origem, portanto, os slots de replicação não são usados. O processo de recuperação é o mesmo para outras instâncias de banco de dados do RDS para PostgreSQL que executam PostgreSQL anterior à versão 14.1 com réplicas de leitura na região.

Quando a réplica de leitura perde contato com a instância de banco de dados de origem, o Amazon RDS registra o problema no log como mensagem FATAL: could not receive data from WAL stream, junto com ERROR: requested WAL segment ... has already been removed. Conforme mostrado na linha em negrito, o Amazon RDS recupera a réplica reproduzindo um arquivo de WAL arquivado.

2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  switched WAL source from archive to stream after failure 2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1 2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000001A000000D3 has already been removed 2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0 2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3 2014-11-07 19:01:16 UTC::@:[23180]:LOG:  restored log file "000000010000001A000000D3" from archive

Quando o Amazon RDS reproduz arquivos de WAL arquivados suficientes na réplica para recuperar o atraso, o streaming para a réplica de leitura pode começar novamente. Quando o streaming é retomado, o Amazon RDS grava uma entrada no arquivo de log, semelhante à mostrada a seguir.

2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1

Definir os parâmetros que controlam a memória compartilhada

Os parâmetros que você define determinam o tamanho da memória compartilhada para rastrear IDs de transações, bloqueios e transações preparadas. A estrutura de memória compartilhada de uma instância em espera deve ser igual ou maior que a de uma instância primária. Isso garante que a primeira não fique sem memória compartilhada durante a recuperação. Se os valores dos parâmetros na réplica forem menores que os valores dos parâmetros na primária, o Amazon RDS ajustará automaticamente os parâmetros da réplica e reiniciará o mecanismo.

Os parâmetros afetados são:

  • max_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

Para evitar que o RDS reinicialize réplicas em decorrência de memória insuficiente, recomendamos aplicar as alterações de parâmetro como uma reinicialização contínua de cada réplica. Você deve aplicar as seguintes regras ao definir os parâmetros:

  • Aumentar os valores dos parâmetros:

    • Você deve sempre aumentar primeiro os valores dos parâmetros de todas as réplicas de leitura e realizar uma reinicialização contínua de todas as réplicas. Em seguida, aplique as alterações de parâmetro na instância primária e reinicialize.

  • Diminuir os valores dos parâmetros:

    • Primeiro, você deve diminuir os valores dos parâmetros da instância primária e realizar uma reinicialização. Em seguida, aplique as alterações de parâmetro a todas as réplicas de leitura correspondentes e execute uma reinicialização contínua.