Descrever a replicação e a decodificação lógica

Concluído

O parâmetro wal_level permite que você defina quantas informações devem ser gravadas no log. Há duas opções: LOGICAL ou REPLICA. REPLICA é o padrão. Esse parâmetro é definido quando o servidor é iniciado.

Alta disponibilidade

A alta disponibilidade é um serviço de Banco de Dados do Azure para PostgreSQL que fornece um servidor em espera pronto para assumir se houver uma falha no servidor dinâmico. A alta disponibilidade no servidor flexível do Banco de Dados do Azure para PostgreSQL usa a replicação para atualizar automaticamente o servidor em espera com alterações de dados.

Quando você configura a alta disponibilidade para o servidor flexível do Banco de Dados do Azure para PostgreSQL, o servidor primário é colocado em uma zona de disponibilidade e um servidor em espera é criado em uma zona de disponibilidade diferente. Os dados são replicados do servidor primário para o servidor em espera usando a replicação de streaming do PostgreSQL no modo síncrono.

Cada zona de disponibilidade consiste em um ou mais data centers. As zonas de disponibilidade têm as próprias fontes de alimentação, sistemas de resfriamento, infraestrutura de rede e outros, tornando-as independentes umas das outras. Três cópias de arquivos de dados e arquivos WAL (log de gravação antecipada) são armazenadas no armazenamento com redundância local em cada zona de disponibilidade, fornecendo isolamento físico entre servidores primários e em espera. Se uma zona de disponibilidade falhar, os outros dois provavelmente continuarão funcionando. As zonas de disponibilidade dentro de uma região são conectadas por redes de fibra rápidas com latência de ida e volta inferior a dois milissegundos.

Observação

Nem todas as regiões têm zonas de disponibilidade.

Com a alta disponibilidade, os dados são duplicados o tempo todo em que o banco de dados está em uso, fornecendo uma cópia atualizada do original. Se houver uma falha, a réplica poderá ser usada no lugar do original. A replicação tem um servidor primário e um servidor em espera. O servidor primário envia arquivos de log WAL para o servidor em espera, que recebe os arquivos de log WAL.

O servidor em espera retorna ao servidor primário com informações como o último log de gravação que ele escreveu e a última posição liberada para o disco, etc. Para definir a frequência mínima para o receptor WAL enviar um relatório de volta, defina o parâmetro wal_receiver_status_interval. O parâmetro max_replication_slots define o número máximo de slots de replicação aos quais o servidor dá suporte. Quando wal_level é definido como REPLICA, max_replication_slotsdeve ser pelo menos um. No entanto, o intervalo de valores permitido é entre 0 e 262.143.

O parâmetro max_wal_senders define o número máximo de processos de remetente de WAL.

Os servidores primários e em espera são monitorados e as ações apropriadas são executadas para resolver problemas, incluindo disparar um failover para o servidor em espera. A seguir, lista os status de alta disponibilidade com redundância de zona:

• Inicializando – o processo de criação de um servidor em espera está em andamento.
• Replicando – a replicação de dados está em estado estável e íntegro.
• Íntegro – o servidor em espera está sendo atualizado pelo primário.
• Fazendo Failover – o servidor de banco de dados está em processo de failover para o servidor em espera.
• Removendo Em Espera – o processo de exclusão do servidor em espera está em andamento.
• Não Habilitado – a alta disponibilidade com redundância de zona não está habilitada.

Você pode adicionar alta disponibilidade a um servidor de banco de dados existente. Se você estiver habilitando ou desabilitando a alta disponibilidade em um servidor ativo, execute a operação quando houver pouca atividade.

No Portal do Azure:

1. Navegue até o servidor Banco de Dados do Azure para PostgreSQL.
2. Na seção Visão geral, selecione sua Configuração atual. A seção Computação + Armazenamento é exibida.
3. Em Alta disponibilidade, marque a caixa de seleção Alta Disponibilidade (com redundância de zona) para habilitar a alta disponibilidade. A Alta disponibilidade não é compatível com a camada Com capacidade de intermitência.

É importante observar que a alta disponibilidade é uma opção de recuperação de desastre. Você não pode usar o servidor em espera para nenhuma outra finalidade, como permitir o acesso a bancos de dados somente leitura. No entanto, você pode configurar a replicação entre dois servidores do Banco de Dados do Azure para PostgreSQL usando um modelo de publicador e assinante. Essa configuração mantém dois servidores com dados sendo replicados entre eles. Em seguida, você tem acesso total ao servidor assinante e pode usar os bancos de dados para qualquer finalidade. Você pratica essa configuração no exercício no final deste módulo.

Decodificação lógica

A decodificação lógica também usa dados enviados para o log write-ahead. Como o nome sugere, ele decodifica as entradas no log write-ahead para torná-las compreensíveis. Todas as alterações INSERT, UPDATE e DELETE estão disponíveis para decodificação lógica.

A decodificação lógica pode ser usada para auditoria, análise ou qualquer outro motivo pelo qual você possa estar interessado em saber o que mudou e quando ela foi alterada.

A decodificação lógica extrai alterações de todas as tabelas no banco de dados. Ela é diferente da replicação, pois não pode enviar essas alterações para outras instâncias do PostgreSQL. Em vez disso, uma extensão do PostgreSQL fornece um plug-in de saída para transmitir as alterações.

A decodificação lógica permite que o conteúdo do log write-ahead seja decodificado em um formato fácil de entender, que pode ser interpretado sem conhecimento da estrutura do banco de dados. O Banco de Dados do Azure para PostgreSQL dá suporte à decodificação lógica e ao plug-in wal2json, que é instalado nos servidores do Banco de Dados do Azure para PostgreSQL.

Outras extensões podem ser usadas, como a extensão pglogical, que permite a replicação lógica de streaming.

Para usar a decodificação lógica, em Parâmetros de servidor, defina:

• wal_level para LOGICAL
• max_replication_slots = 10
• max_wal_senders = 10

O servidor precisa ser reiniciado depois que essas alterações forem feitas.

Para usar a extensão pglogical do portal do Azure:

1. Navegue até o servidor Banco de Dados do Azure para PostgreSQL.
2. Selecione Parâmetros do servidor e pesquise por shared_preload_libraries. Na caixa suspensa, selecione pglogical.
3. Pesquise por azure.extensions. Na caixa suspensa, selecione pglogical.
4. Para aplicar as alterações, reinicie o servidor.

Você também precisa conceder permissões de usuário administrador para replicação:

ALTER ROLE <adminname> WITH REPLICATION;

Para obter mais informações, consulte a documentação online da documentação da extensão pglogical.

A decodificação lógica gera alterações de dados como um fluxo chamado de slot de replicação lógica.

1. Cada slot tem um plug-in de saída, que você pode definir.
2. Cada slot fornece alterações de apenas um banco de dados, mas um banco de dados pode ter vários slots.
3. Cada alteração de dados normalmente é emitida uma vez por slot.
4. Se o PostgreSQL for reiniciado, um slot poderá emitir novamente as alterações, que o cliente precisa manipular.
5. Os slots precisam ser monitorados. Os slots não armazenados se mantêm em todos os arquivos WAL para essas alterações não controladas. Essa situação pode levar ao armazenamento completo ou à quebra de ID da transação.