Início / dba / Perguntas / 209281
Accepted
tuk
Asked: 2018-06-12 02:30:18 +0800 CST

Patroni: Como lidar com uma réplica que foi desconectada do primário por muito tempo?

  • 772

Digamos que estou usando replicação de streaming assíncrona com a configuração abaixo em um cluster de 3 nós com Postgres 10.4 e Patroni 1.4.4

    bootstrap:
      dcs:
        ttl: 30
        loop_wait: 10
        retry_timeout: 10
        maximum_lag_on_failover: 1048576
        postgresql:
          use_pg_rewind: true
          use_slots: true
          parameters:
            max_wal_senders: 10
            wal_keep_segments: 100
            max_replication_slots: 10

Vamos supor que um dos nós de réplica de repente perca sua conexão com o primário por um longo tempo.

  1. Nesse caso, acho que o tamanho do WAL no primário continuará crescendo, pois não está sendo consumido pelo slot de replicação da réplica desconectada. Portanto, existe alguma configuração na configuração do patroni que removerá a réplica e removerá seu slot de replicação se for desconectado do primário por x tempo de duração?
  2. Qual é a maneira recomendada de lidar com este caso?
postgresql replication

2 respostas

  1. Best Answer

    Suponho que você esteja monitorando a integridade do cluster de banco de dados, portanto, uma réplica ausente apareceria muito em breve. Além disso, é uma obrigação monitorar o espaço em disco (ficar sem ele pode levá-lo a uma situação que não é muito fácil de resolver), então isso também pegaria isso (mais tarde ou mais cedo, geralmente).

    Depois de descobrir que você tem uma réplica que caiu, você deve investigar por que isso aconteceu e corrigi-la - ou remover completamente o host do Patroni. Se estiver sob pressão de espaço em disco, remova o slot de replicação para liberar espaço WAL. Em uma configuração de nuvem, muitas vezes simplesmente encerrar o host resolverá tudo isso trazendo um novo host. De qualquer forma, uma vez que você tenha um host em funcionamento, talvez seja necessário reinicializar o nó Patroni.

    Por outro lado, temo que atualmente não haja mecanismo para cercar réplicas que não parecem voltar (seja qualquer implementação real de remover o slot de replicação para algo mais complexo do que isso).

    • 2

  2. Slots de replicação enchendo o disco?

    Mesmo se você especificar use_slotsna configuração do Patroni, o slot será removido automaticamente se a réplica não renovar sua chave de membro no DCS (distributed consenso store). Por padrão, isso significa que um slot para uma réplica desaparecida será descartado após 30 segundos (isso corresponde à ttlconfiguração, que indica por quanto tempo as chaves do líder e do membro permanecerão no DCS) https://github.com/zalando/patroni/issues /1105

    Portanto, a menos que você mesmo configure os slots (com o recurso de slot de replicação permanente do Patroni, embora eu não recomende), sua réplica pode ficar para trás infinitamente. Isso significa que não há como a réplica recuperar o atraso, porque o primário já reciclou parte do WAL que seria necessário para recuperar o atraso.

    Como evitar ficar infinitamente para trás

    A maneira fácil de lidar com esse cenário é definir wal_keep_segments alto o suficiente para cobrir seus tempos de inatividade habituais (partições de rede, manutenção de hardware etc.).

    A maneira recomendada de lidar com isso é implementar o arquivamento centralizado do WAL, por exemplo, com pgBackRest, para que a réplica atrasada possa recuperar o WAL ausente do arquivo.

    Como se recuperar de ficar infinitamente para trás

    Se sua réplica ficar muito atrasada e o primário já tiver reciclado parte do WAL que seria necessário para recuperar o atraso, e você não tiver um arquivo WAL, a réplica precisará ser recriada. Isso é feito muito facilmente executando

    patronictl -c /path/to/your/patroni.yaml reinit clustername membername

    Dependendo do create_replica_methodsque você definiu, um backup será usado para "reimaginar" a réplica. Por padrão, isso é feito através do pg_basebackup.

    • 2

relate perguntas