Alternância e failover com a replicação pglogical

Selecione uma versão da documentação:

Nesta página, você encontra informações sobre como fazer failover e switchover com a replicação pglogical.

Antes de começar

Depois que a replicação pglogical for configurada e houver uma solução viável de alta disponibilidade (HA) e recuperação de desastres (DR), e reconhecendo que a replicação lógica não oferece true e replicação abrangente de todos os objetos de banco de dados, teste essa configuração antes de começar a usá-la.

Para mais informações sobre a extensão pglogical, consulte Sobre o pglogical.

Para informações sobre replicação de dados usando pglogical, consulte Replicar dados entre o AlloyDB para PostgreSQL e o AlloyDB Omni e Replicar dados entre o AlloyDB Omni e outros bancos de dados.

Failover com replicação pglogical

A alternância é um processo controlado usado para trocar as funções entre os bancos de dados do provedor e do assinante. Quando você faz uma alternância, as funções dos dois bancos de dados, provedor e assinante, são invertidas. O provedor se torna o assinante, e o assinante se torna o provedor.

Essa capacidade de failover é importante para upgrades do sistema operacional, do PostgreSQL ou testes de failover.

Para fazer isso em configurações de replicação unidirecional, configure uma nova relação provedor/assinante e remova a antiga.

Criar a nova configuração de provedor/assinante

  1. Impeça que o aplicativo grave no sistema do provedor para evitar mais mudanças no banco de dados e verifique o atraso na replicação para garantir que todas as transações sejam reproduzidas no nó do assinante:

    SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

    Quando todos os campos de atraso mostrarem zero, a replicação estará atualizada e o banco de dados pronto para uma alternância.

    O resultado será assim:

    -[ RECORD 1 ]----+------------------------------
application_name | test_sub_1
state            | streaming
sync_state       | async
client_addr      | 10.45.0.80
client_hostname  | 
sent_lag         | 0
receiving_lag    | 0
replay_lag       | 0
total_lag        | 0
reply_delay      | 00:00:26.203433

  2. Converter o banco de dados de assinantes em um banco de dados de provedores:

    1. Interrompa a assinatura do assinante atual.
    2. Adicione o conjunto de réplicas, se necessário.
    3. Adicione as tabelas necessárias ao conjunto de replicação.
    4. Crie uma nova assinatura de assinante no novo banco de dados de assinantes.
    5. Redirecione os aplicativos para o novo provedor.

  3. Interrompa a assinatura no banco de dados de assinantes atual, que se torna o novo provedor:

    SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);

  4. (Opcional) Crie um conjunto de replicação que corresponda à definição do banco de dados do provedor original. Isso não é necessário se você estiver usando os conjuntos de replicação padrão:

    SELECT pglogical.create_replication_set(REPLICATION_SET_NAME);

  5. Adicione tabelas a esse conjunto de replicação:

    SELECT pglogical.replication_set_add_table(REPLICATION_SET_NAME, TABLE_NAME);

    Substitua:

    • REPLICATION_SET_NAME: o nome do conjunto de réplicas.
    • TABLE_NAME: o nome da tabela de um proprietário do esquema. Por exemplo, ARRAY['public'].`

  6. No novo banco de dados de assinantes, que antes era o banco de dados do provedor, crie a nova assinatura com a opção synchronize_data definida como false para evitar o carregamento inicial da tabela:

    SELECT pglogical.create_subscription (
           subscription_name := '<subscription name>',
           replication_sets := array['default'],
           synchronize_data := false,
           provider_dsn := 'host=<hostname or IP> port=5432 
           dbname=<db name> user=pglogical_replication password=<password>');

  7. Verifique se a assinatura está funcionando no nó do provedor:

    SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

  8. Se a replicação estiver funcionando, mude as strings de conexão do aplicativo para usar o novo banco de dados do provedor e reinicie as camadas do aplicativo.

Se você mudar os dados no nó do provedor antigo depois que o assinante for interrompido, essas mudanças não serão replicadas, o que resultará em perda de dados. Se houver mudanças não replicadas nos dados do banco de dados do provedor original ou se o provedor original, que é o novo assinante, não estiver em um estado consistente com o novo banco de dados do provedor, que é o assinante antigo, será necessário criar o novo banco de dados do assinante do zero.

Remover o provedor e a assinatura antigos

Se você quiser a replicação unidirecional, remova a configuração antiga de provedor/assinante.

  1. Remova a assinatura antiga no novo provedor:

    SELECT pglogical.drop_subscription('<subscription name>')

  2. Remova o conjunto de replicação no novo assinante ou remova todas as tabelas do conjunto de replicação:

    SELECT pglogical.drop_replication_set('<replication set name>')

    SELECT pglogical.replication_set_remove_table('<replication set name>','<table name>')

Replicação bidirecional

Para fazer a troca sem inatividade ou garantir que nenhum dado seja perdido devido a mudanças não planejadas, use a replicação bidirecional. Ao implementar a replicação bidirecional, considere a resolução de conflitos, a menos que haja controles rigorosos para impedir o acesso de gravação aos dois nós ao mesmo tempo.

É possível configurar a resolução de conflitos usando as seguintes configurações de pglogical.conflict_resolution:

  • error: o assinante para quando um conflito é detectado.
  • apply_remote: sempre aplique as mudanças recebidas, independente dos dados no banco de dados do assinante. Esta é a configuração padrão.
  • keep_local: sempre ignore os dados conflitantes recebidos e descarte a mudança conflitante.
  • last_update_wins: a versão dos dados com o carimbo de data/hora do commit mais recente é a que é confirmada
  • first_update_wins: a versão dos dados com o carimbo de data/hora mais antigo é a que é confirmada.

Para configurar a replicação bidirecional, configure o provedor e o assinante para que a replicação aconteça nos dois sentidos. O assinante original também se torna um provedor com o mesmo conjunto de replicação do provedor original. Consulte Criar uma tabela e adicioná-la ao conjunto de replicação padrão no banco de dados do provedor do AlloyDB para PostgreSQL para criar um conjunto de replicação que duplica o conjunto original no banco de dados do provedor inicial.

No provedor original, adicione um novo assinante. Consulte Criar um nó e uma assinatura no banco de dados assinante do AlloyDB Omni para criar um novo assinante e garantir que o parâmetro synchronize_data do comando pglogical.create_subscription esteja definido como false. Isso evita a cópia inicial da tabela de dados.

Failover com replicação pglogical

O failover ocorre quando o banco de dados do provedor fica indisponível por qualquer motivo, e você precisa mudar o aplicativo para usar o banco de dados do assinante.

Para evitar que dados duplicados sejam aplicados por engano ao banco de dados de assinantes de failover, desative a assinatura. Isso garante que as mudanças de um provedor restaurado não sejam aplicadas por engano quando o provedor ficar disponível novamente.

  1. Parar o subscriber, test_sub_1:

    SELECT pglogical.alter_subscription_disable(`test_sub_1`);

  2. Verifique se o status está definido como disabled:

    SELECT pglogical.show_subscription_status('test_sub_1');

    O resultado será assim:

    show_subscription_status                                                                           
----------------------------------------------------------------------------
(test_sub1,disabled,subscriber,"host=10.45.0.108 port=5432 dbname=my_test_db user=pglogical_replication",subscriber,{failover_set},{all})

  3. Confira a palavra-chave desativada na saída de status.

  4. Crie uma nova configuração de provedor/assinante para manter a alta disponibilidade e a capacidade de recuperação de desastres.

  5. Crie um novo conjunto de replicação com todas as tabelas que foram replicadas originalmente para que um novo assinante seja criado quando o banco de dados do provedor antigo for recuperado e convertido em um novo assinante ou um novo assinante seja criado.

  6. Configurar o assinante.

  7. Configure esse banco de dados como o novo assinante se for possível recuperar o banco de dados do provedor antigo até o momento da falha. Use as mesmas etapas para criar uma assinatura e defina o parâmetro synchronize_data do comando pglogical.create_subscription como false para evitar a cópia inicial da tabela.

  8. Remova a configuração antiga do provedor no nó recuperado para evitar o acúmulo de arquivos WAL.

  9. Se você estiver usando o banco de dados do provedor antigo, descarte o conjunto de replicação completo ou remova todas as tabelas do conjunto de replicação uma por uma:

    SELECT pglogical.drop_replication_set('<replication set name>')

    SELECT pglogical.replication_set_remove_table('<replication set name>','<table name>')

  10. Mude o aplicativo para gravar no novo nó.

A seguir