A replicação nativa de streaming no PostgreSQL funciona apenas entre servidores com a mesma versão principal. Falamos sobre replicação lógica em uma postagem anterior . Vimos como a replicação lógica ajuda a mover dados de uma versão do PostgreSQL para outra. Mas a replicação lógica é adequada apenas para versões suportadas do PostgreSQL, por exemplo, PostgreSQL 9.4 e PostgreSQL 11. O que fazer com versões anteriores à 9.4? Use Slony-I .
Use a replicação com o Slony-I para transferir dados de bancos de dados antigos para a versão mais recente do PostgreSQL. O que é o Slony e como ele funciona?
Este é o quarto post da nossa série Atualizando ou migrando versões antigas do PostgreSQL para novas , onde aprendemos métodos diferentes para atualizar os bancos de dados do PostgreSQL.
Slony
Slony é uma implementação de replicação lógica em nível de aplicativo para o PostgreSQL. Ou melhor, é uma ferramenta de replicação de terceiros que requer instalação e configuração separadas. Slony já existe há muito tempo. A versão mais recente suporta PostgreSQL 8.4 a 11.
O principal objetivo da replicação é transferir alterações de um servidor de banco de dados para outro. Para entender melhor a arquitetura, vejamos os termos: Slon, eventos e slonik.
A propósito, Slony, se você ainda não adivinhou, esses são "elefantes". E eles realmente têm uma ótima memória. Não é por acaso que um elefante rigoroso, porém fofo, ostenta o logotipo do PostgreSQL.
Slon
Slon é um daemon que é executado em todos os nós do PostgreSQL na replicação do Slony-I. Esses daemons são usados para manipular eventos de configuração e replicação para cada servidor PostgreSQL. Cada servidor PostgreSQL é chamado de host. Todos os nós juntos formam um cluster Slony.
O nó do publicador é a fonte das alterações e o nó do assinante recebe e aplica as alterações do publicador.
Para configurar a replicação, você deve especificar todas as tabelas replicadas ou um conjunto de replicação. A assinatura funciona para um conjunto específico. As alterações nas tabelas replicadas são combinadas no SYNC, um grupo de transações aplicadas em conjunto nos assinantes.
Eventos
As alterações são relatadas pelo editor como eventos. Quando um evento é processado pelo daemon Slon no host remoto, uma confirmação é gerada. E os eventos notificam os nós de alterações na configuração, como adicionar ou remover novos nós, novas assinaturas ou alterações DDL.
Cada evento possui seu próprio identificador de origem exclusivo, número de série, identificador de transação para a captura instantânea no nó do evento, vários argumentos e um registro de data e hora com um fuso horário.
Os gatilhos gravados no PL / pgSQL registram todas as alterações nas tabelas replicadas. Infelizmente, não há uma maneira confiável de lidar com alterações em blobs, DDLs ou alterações em usuários e funções.
slonik
Este é um utilitário de linha de comando com um analisador e intérprete que aceita scripts slonik - uma linguagem declarativa simples. Ele foi projetado para superar as limitações de uma linguagem processual. Com a ajuda dos comandos do slonik, você pode configurar ou modificar a replicação no Slony, e eles podem ser incorporados em scripts de shell. Ele aceita comandos da entrada padrão ou de arquivos. O exemplo abaixo mostra como o script slonik é passado para o slonik e incorporado nos scripts shell.
O script que cria a configuração inicial para um esquema mestre-escravo simples em nosso banco de dados pgbench é semelhante a este:
#!/bin/sh slonik <<_EOF_ cluster name = percona_pg; node 1 admin conninfo = 'dbname=pg93 host=pg93_host user=percona_pg93_user'; node 2 admin conninfo = 'dbname=pg11 host=pg11_host user=percona_pg11_user'; #-- # Creates a _$(clustername), this example, _percona_pg schema #-- init cluster ( id=1, comment = 'Legacy PG Node'); #-- # Add a list of tables being replicated to a set. #-- create set (id=1, origin=1, comment='pgbench'); set add table (set id=1, origin=1, id=1, fully qualified name = 'public.pgbench_accounts', comment='accounts'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.pgbench_branches', comment='branches'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.pgbench_tellers', comment='tellers'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.pgbench_history', comment='history'); #-- # Create the second node (the slave) tell the 2 nodes how to connect to # each other and how they should listen for events. #-- store node (id=2, comment = 'Target node', event node=1); store path (server = 1, client = 2, conninfo='dbname=pg93 host=pg93_host user=percona_pg93_user'); store path (server = 2, client = 1, conninfo='dbname=pg11 host=pg11_host user=percona_pg11_user'); _EOF_
Por que o Slony é conveniente para migrações?
Apesar das vantagens da replicação lógica interna, para versões anteriores ao PostgreSQL 9.4, você precisa usar esta solução de terceiros. A abordagem baseada em acionador depende da API do banco de dados - ambas as versões devem ser compatíveis para usar a sintaxe PL / pgSQL e SQL.
Como adaptar o banco de dados para uso com o Slony?
- As tabelas devem ter chaves primárias. Adicione um campo serial a todas as tabelas sem uma chave primária.
- Alterações no blob OID não são replicadas. Se você tiver colunas com valores curtos, converta-as em BYTEA. Se os objetos forem muito grandes - por exemplo, imagens - é melhor armazenar dados em armazenamento externo (por exemplo, S3 na nuvem da Amazon). Se a alteração do aplicativo for muito complicada, aplique as alterações do blob na última etapa da migração.
- ALTER TABLE e outras operações DDL. Slony não detecta alterações na estrutura da tabela. Use o comando slonik EXECUTE SCRIPT para aplicar um arquivo SQL com cadeias SQL ou DDL a todo o cluster de replicação.
Migração online de versões anteriores do PostgreSQL
- Crie um usuário de replicação com privilégios de superusuário. Você pode configurar os direitos em detalhes, mas é muito mais complicado.
- Crie um banco de dados no destino com acesso TCP / IP.
- Copie as definições da tabela do mestre para os escravos.
- Instale o Slony-I. Em servidores com uma versão antiga do sistema operacional, será mais fácil instalar o Slony-I a partir do código-fonte.
- Defina o cluster, o conjunto de tabelas e as informações de conexão do nó como uma lista de comandos slonik.
- Execute o daemon slon em cada servidor PostgreSQL. Verifique os arquivos de saída ou log padrão quanto a erros de conexão.
- Execute os comandos de assinatura slonik para iniciar a sincronização.
- Teste solicitações somente leitura na nova versão do Postgres.
- Quando todos os dados forem replicados e sincronizados, pare os aplicativos e encaminhe-os para o novo servidor Postgres.
- Use o nó de desinstalação na nova versão do PostgreSQL para remover todos os vestígios da replicação do Slony.
Transição para versões anteriores
Use o mesmo procedimento para atualizar para versões anteriores. Com o Slony, você pode replicar de qualquer versão e para qualquer versão do PosgreSQL suportada pela versão do Slony. A versão mínima suportada é 8.4.
Sumário
Vimos em termos gerais como você pode atualizar para a nova versão com tempo de inatividade mínimo usando o Slony. Saiba mais em nosso webinar .