O que é Slony?
O Slony-I (referido apenas como 'Slony' daqui em diante) é um sistema de replicação de terceiros para PostgreSQL que remonta a antes da versão 8.0, tornando-o uma das opções mais antigas de replicação disponíveis. Ele opera como um método de replicação baseado em gatilho que é uma solução "mestre para vários escravos".
O Slony opera instalando triggers em cada tabela a ser replicada, tanto no master quanto nos slaves, e toda vez que a tabela recebe um INSERT, UPDATE ou DELETE, ele registra qual registro foi alterado e qual é a alteração. Processos externos, chamados de 'daemons slon', conectam-se aos bancos de dados como qualquer outro cliente e buscam as alterações do mestre, depois as reproduzem em todos os nós escravos inscritos no mestre. Em uma configuração de replicação com bom desempenho, esse assíncrono pode-se esperar que a replicação esteja de 1 a 20 segundos atrasada em relação ao mestre.
No momento da redação deste artigo, a versão mais recente do Slony está na versão 2.2.6 e suporta PostgreSQL 8.3 e superior. O suporte continua até hoje com pequenas atualizações, no entanto, se uma versão futura do PostgreSQL alterar a funcionalidade fundamental de transações, funções, gatilhos ou outros recursos principais, o projeto Slony pode decidir descontinuar grandes atualizações para oferecer suporte a novas abordagens drásticas.
O mascote do PostgreSQL é um elefante conhecido como 'Slonik', que em russo significa 'pequeno elefante'. Como este projeto de replicação é sobre muitos bancos de dados PostgreSQL replicando uns com os outros, a palavra russa para elefantes (plural) é usada:Slony.
Conceitos
- Cluster:uma instância de replicação Slony.
- Nó:um banco de dados PostgreSQL específico como nó de replicação Slony, que opera como mestre ou escravo para um conjunto de replicação.
- Conjunto de replicação:um grupo de tabelas e/ou sequências a serem replicadas.
- Assinantes:um assinante é um nó que está inscrito em um conjunto de replicação e recebe eventos de replicação para todas as tabelas e sequências desse conjunto do nó mestre.
- Slony Daemons:os principais workers que executam a replicação, um daemon Slony é iniciado para cada nó no conjunto de replicação e estabelece várias conexões com o nó que ele gerencia, bem como com o nó mestre.
Como é usado
O Slony é instalado por fonte ou através dos repositórios PGDG (PostgreSQL Global Development Group) que estão disponíveis para distribuições Linux baseadas em Red Hat e Debian. Esses binários devem ser instalados em todos os hosts que conterão um nó mestre ou escravo no sistema de replicação.
Após a instalação, um cluster de replicação Slony é configurado emitindo alguns comandos usando o binário ‘slonik’. ‘slonik’ é um comando com uma sintaxe simples, porém única, própria para inicializar e manter um cluster slony. É a interface principal para emissão de comandos para o cluster Slony em execução que é responsável pela replicação.
A interface com o Slony pode ser feita escrevendo comandos slonik personalizados ou compilando o slony com o sinalizador --with-perltools, que fornece os scripts 'altperl' que ajudam a gerar esses scripts slonik necessários.
Criando um cluster de replicação Slony
Um ‘cluster de replicação’ é uma coleção de bancos de dados que fazem parte da replicação. Ao criar um cluster de replicação, é necessário escrever um script de inicialização que defina o seguinte:
- O nome do cluster Slony desejado
- As informações de conexão para cada parte do nó da replicação, cada uma com um número de nó imutável.
- Listando todas as tabelas e sequências a serem replicadas como parte de um "conjunto de replicação".
Um script de exemplo pode ser encontrado na documentação oficial do Slony.
Quando executado, o slonik se conectará a todos os nós definidos e criará o esquema Slony em cada um. Quando os daemons do Slony são iniciados, eles limpam todos os dados nas tabelas replicadas no escravo (se houver) e copiam todos os dados do mestre para o(s) escravo(s). A partir desse ponto, os daemons replicarão continuamente as alterações registradas no mestre para todos os escravos inscritos.
Configurações inteligentes
Embora o Slony seja inicialmente um sistema de replicação Master-to-Multiple-Slave e tenha sido usado principalmente dessa maneira, existem vários outros recursos e usos inteligentes que tornam o Slony mais útil do que uma simples solução de replicação. A natureza altamente personalizável do Slony o mantém relevante para uma variedade de situações para administradores que podem pensar fora da caixa.
Replicação em cascata
Os nós Slony podem ser configurados para replicar em cascata uma cadeia de nós diferentes. Se o nó mestre for conhecido por receber uma carga extremamente pesada, cada escravo adicional aumentará essa carga ligeiramente. Com a replicação em cascata, um único nó escravo conectado ao mestre pode ser configurado como um 'nó de encaminhamento', que será responsável por enviar eventos de replicação para mais escravos, mantendo a carga no nó mestre ao mínimo.
Replicação em cascata com Slony Processamento de dados em um nó escravo
Ao contrário da replicação integrada do PostgreSQL, os nós escravos não são realmente ‘somente leitura’, apenas as tabelas que estão sendo replicadas são bloqueadas como ‘somente leitura’. Isso significa que em um nó escravo, o processamento de dados pode ocorrer criando novas tabelas que não fazem parte da replicação para hospedar os dados processados. As tabelas que fazem parte da replicação também podem ter índices personalizados criados dependendo dos padrões de acesso que podem diferir do escravo e do mestre.
As tabelas somente leitura nos escravos ainda podem ter funções baseadas em trigger personalizadas executadas nas alterações de dados, permitindo mais personalização com os dados.
Processamento de dados em um nó escravo Slony Atualizações de tempo de inatividade mínimo
A atualização das principais versões do PostgreSQL pode consumir muito tempo. Dependendo do tamanho dos dados e da contagem de tabelas, uma atualização incluindo o processo de 'analisar' pós-atualização pode levar vários dias. Como o Slony pode replicar dados entre clusters PostgreSQL de diferentes versões, ele pode ser usado para configurar a replicação entre uma versão mais antiga como master e uma versão mais recente como slave. Quando a atualização estiver para acontecer, basta realizar uma ‘troca’, tornando o escravo o novo mestre, e o antigo mestre se torna o escravo. Quando a atualização for marcada como bem-sucedida, descomissione o cluster de replicação Slony e desligue o banco de dados antigo.
Atualize o PostgreSQL com tempo de inatividade mínimo usando o Slony Alta disponibilidade com manutenção frequente do servidor
Assim como o tempo de inatividade mínimo para atualizações, a manutenção do servidor pode ser feita facilmente sem tempo de inatividade, realizando uma “troca” entre dois ou mais nós, permitindo que um escravo seja reinicializado com atualizações/outras manutenções. Quando o escravo voltar a ficar online, ele se reconectará ao cluster de replicação e recuperará todos os dados replicados. Os usuários finais que se conectam ao banco de dados podem ter longas transações interrompidas, mas o tempo de inatividade em si seria de segundos à medida que a alternância ocorre, em vez do tempo necessário para reinicializar/atualizar o host.
Envio de Log
Embora não seja uma solução popular, um escravo Slony pode ser configurado como um nó de 'envio de log', onde todos os dados recebidos por meio de replicação podem ser gravados em arquivos SQL e enviados. Isso pode ser usado por vários motivos, como gravar em uma unidade externa e transportar para um banco de dados escravo manualmente, e não por uma rede, compactado e mantido arquivado para backups futuros ou até mesmo ter um programa externo analisando os arquivos SQL e modificar o conteúdo.
Compartilhamento de dados de vários bancos de dados
Como qualquer número de tabelas pode ser replicado à vontade, os conjuntos de replicação Slony podem ser configurados para compartilhar tabelas específicas entre bancos de dados. Embora o acesso semelhante possa ser obtido por meio de Wrappers de dados estrangeiros (que foram aprimorados nas versões recentes do PostgreSQL), pode ser uma solução melhor usar o Slony, dependendo do uso. Se for necessário buscar uma grande quantidade de dados de um host para outro, fazer com que o Slony replique esses dados significa que os dados necessários já existirão no nó solicitante, eliminando o longo tempo de transferência.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper
Replicação atrasada
Normalmente, deseja-se que a replicação seja o mais rápida possível, mas pode haver alguns cenários em que um atraso é desejado. O daemon slon para um nó escravo pode ser configurado com um lag_interval, o que significa que ele não receberá nenhum dado de replicação até que os dados sejam antigos conforme especificado. Isso pode ser útil para acesso rápido a dados perdidos se algo der errado, por exemplo, se uma linha for excluída, ela existirá no escravo por 1 hora para recuperação rápida.
O que você precisa saber:
- Quaisquer alterações de DDL nas tabelas que fazem parte da replicação devem ser executadas usando o comando slonik execute.
- Qualquer tabela a ser replicada deve ter uma chave primária ou um índice UNIQUE sem colunas anuláveis.
- Os dados replicados do nó mestre são replicados após a geração funcional de quaisquer dados. Ou seja, se os dados foram gerados usando algo como 'random()', o número resultante é armazenado e replicado nos escravos, em vez de 'random()' ser executado novamente no escravo, retornando um resultado diferente.
- Adicionar a replicação Slony aumentará um pouco a carga do servidor. Embora escrita com eficiência, cada tabela terá um gatilho que registra cada INSERT, UPDATE e DELETE em uma tabela Slony, esperando um aumento de carga de servidor de cerca de 2 a 10%, dependendo do tamanho do banco de dados e da carga de trabalho.
Dicas e truques:
- Os daemons do Slony podem ser executados em qualquer host que tenha acesso a todos os outros hosts, no entanto, a configuração de melhor desempenho é executar os daemons nos nós que estão gerenciando. Por exemplo, o daemon mestre em execução no nó mestre, o daemon escravo em execução no nó escravo.
- Se estiver configurando um cluster de replicação com uma quantidade muito grande de dados, a cópia inicial pode levar muito tempo, o que significa que todas as alterações que acontecem desde o início até a conclusão da cópia podem significar ainda mais tempo para acompanhar e sincronizar . Isso pode ser resolvido adicionando algumas tabelas de cada vez à replicação (muito demorado) ou criando uma cópia do diretório de dados do banco de dados mestre para o escravo e, em seguida, fazendo um 'conjunto de assinatura' com a opção OMIT COPY definida como verdadeiro. Com esta opção, o Slony assumirá que a tabela escrava é 100% idêntica à master e não a limpará e copiará os dados.
- O melhor cenário para isso é criar um Hot Standby usando as ferramentas internas do PostgreSQL e, durante uma janela de manutenção com zero conexões, modificando os dados, coloque o standby online como um mestre, valide as correspondências de dados entre os dois, inicie o cluster de replicação slony com OMIT COPY =true e, finalmente, reative as conexões do cliente. Isso pode levar algum tempo para configurar o Hot Standby, mas o processo não causará um grande impacto negativo aos clientes.
Comunidade e documentação
A comunidade do Slony pode ser encontrada nas listas de discussão, localizadas em http://lists.slony.info/mailman/listinfo/slony1-general, que também inclui arquivos.
A documentação está disponível no site oficial, http://slony.info/documentation/, e fornece ajuda com análise de log e especificação de sintaxe para interface com o slony.
