Descrever a replicação e a decodificação lógica
O parâmetro wal_level permite definir quantas informações devem ser gravadas no log. Existem duas opções: LOGICAL ou REPLICA. REPLICA é o padrão. Este parâmetro é definido quando o servidor é iniciado.
Elevada disponibilidade
Alta disponibilidade é um serviço do Banco de Dados do Azure para PostgreSQL, que fornece um servidor em espera pronto para assumir o controle se houver uma falha em seu servidor ativo. A alta disponibilidade no Banco de Dados do Azure para servidor flexível 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 Banco de Dados do Azure para servidor flexível 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 PostgreSQL no modo síncrono.
Cada zona de disponibilidade consiste em um ou mais data centers. As zonas de disponibilidade têm as suas próprias fontes de alimentação, sistemas de refrigeração, infraestrutura de rede, etc., tornando-as independentes umas das outras. Três cópias de arquivos de dados e arquivos de log write-ahead (WAL) são armazenados em armazenamento localmente redundante dentro de cada zona de disponibilidade, fornecendo isolamento físico entre servidores primários e em espera. Se uma zona de disponibilidade falhar, as outras duas provavelmente continuarão funcionando. As zonas de disponibilidade dentro de uma região são conectadas por redes de fibra rápida com latência de ida e volta inferior a 2 milissegundos.
Nota
Nem todas as regiões têm zonas de disponibilidade.
Com alta disponibilidade, os dados são duplicados sempre que o banco de dados está em uso, fornecendo uma cópia atualizada do original. Se houver uma falha, a réplica pode ser usada no lugar da 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 reporta ao servidor primário informações como o último log write-ahead que ele gravou e a última posição liberada no disco, etc. Para definir a frequência mínima para o recetor WAL enviar de volta um relatório, 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 que o servidor pode suportar. Quando wal_level é definido como RÉPLICA, max_replication_slots deve ser pelo menos um, no entanto, o intervalo de valores permitido está entre e 0 e 262.143.
O parâmetro max_wal_senders define o número máximo de processos de remetente WAL.
Os servidores primário e em espera são monitorados e as ações apropriadas são tomadas para corrigir problemas, incluindo o disparo de um failover para o servidor em espera. A seguir, lista os status de alta disponibilidade redundantes da zona:
- Inicialização - No processo de criação de um novo servidor em espera.
- Replicação - A replicação de dados está em estado estável e íntegro.
- Saudável - O standby está sendo atualizado pelo primário.
- Failover - O servidor de banco de dados primário está em processo de failover para o modo de espera.
- Removendo o modo de espera - No processo de exclusão do servidor em espera.
- Não ativado - A alta disponibilidade redundante de zona não está ativada.
Pode adicionar elevada disponibilidade para um servidor de bases 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:
- Navegue até o Banco de Dados do Azure para servidor PostgreSQL.
- Na seção Visão geral, selecione sua configuração atual. A seção Computação + Armazenamento é exibida.
- Em Alta disponibilidade, marque a caixa de seleção Alta disponibilidade (zona redundante) para habilitar a alta disponibilidade. A alta disponibilidade não é suportada para a camada Burstable.
É importante observar que a alta disponibilidade é uma opção de recuperação de desastres. Não é possível usar o servidor em espera para qualquer outra finalidade, como permitir o acesso a bancos de dados somente leitura. No entanto, você pode configurar a replicação entre dois bancos de dados do Azure para servidores PostgreSQL usando um modelo de editor e assinante. Essa configuração mantém dois servidores com dados sendo replicados entre eles. Em seguida, você tem acesso total ao servidor de assinante e pode usar os bancos de dados para qualquer finalidade. Você pratica essa configuração no exercício no final deste módulo.
Descodificaçã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 de gravação antecipada 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 mudou.
A decodificação lógica extrai alterações de todas as tabelas no banco de dados. Ele difere da replicação porque não pode enviar essas alterações para outras instâncias do PostgreSQL. Em vez disso, uma extensão 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 usando a extensão wal2json , que é instalada no Banco de Dados do Azure para servidores Postgres.
Outras extensões podem ser usadas, como a extensão pglógica, que permite a replicação de streaming lógico.
Para usar a decodificação lógica, em Parâmetros do servidor, defina:
- wal_level para LÓGICO
- max_replication_slots = 10
- max_wal_senders = 10
O servidor deve ser reiniciado após essas alterações serem feitas.
Para usar a extensão pglogical do portal do Azure:
- Navegue até o Banco de Dados do Azure para servidor PostgreSQL.
- Selecione Parâmetros do servidor e procure shared_preload_libraries. Na caixa suspensa, selecione pglogical.
- Procure azure.extensions. Na caixa suspensa, selecione pglogical.
- Para aplicar as alterações, reinicie o servidor.
Você também deve conceder ao usuário administrador permissões para replicação:
ALTER ROLE <adminname> WITH REPLICATION;
Para obter mais informações, consulte a documentação on-line da documentação da extensão pglógica.
A decodificação lógica produz alterações de dados como um fluxo chamado slot de replicação lógica.
- Cada slot tem um plugin de saída, que você pode definir.
- Cada slot fornece alterações de apenas um banco de dados, mas um banco de dados pode ter vários slots.
- Cada alteração de dados é normalmente emitida uma vez por slot.
- Se o PostgreSQL for reiniciado, um slot poderá reemitir alterações, que o cliente precisa manipular.
- As faixas horárias devem ser monitorizadas. Os slots não consumidos mantêm todos os arquivos WAL para essas alterações não consumidas. Essa situação pode levar ao armazenamento completo ou ao wraparound do ID da transação.