Replicação no PostgreSQL: Utilização do Log Shipping

A partir da versão 8.3.x, o log shipping também passou a ser usado para criar uma configuração de agrupamento de servidores (cluster) com replicação e alta disponibilidade, com um ou mais servidores slaves prontos para assumirem as operações, caso ocorram falhas no servidor master. Esta capacidade passou a ser chamada de Warm Standby, com o uso de ferramentas nativas do PostgreSQL, sendo possível assim, montar um ambiente de alta disponibilidade ou de recuperação de falhas.

Para este artigo, utilizaremos dois servidores, um master, que receberá todas as requisições dos usuários (tipicamente um servidor de produção), e um slave, que ficará em standby, recebendo os dados replicados pelo master. Estes servidores estarão executando em ambientes Linux de 32 bits, utilizando o Red Hat, com a versão 8.3.3 do PostgreSQL instalada em ambos. Os arquivos dos servidores PostgreSQL estão em seus locais padrões (/var/lib/pgsql). Assumiremos também que o servidor master está com o IP 192.0.0.211 e o slave com o IP 192.0.0.212.

Preparação do Ambiente

Antes de começarmos a implementação dos procedimentos a serem seguidos para a replicação, convém ressaltarmos alguns pontos e executarmos alguns pequenos passos com relação ao ambiente dos servidores e sistema operacional.

Primeiramente, é importante termos servidores master e slave com uma configuração de hardware e software o mais parecido possível.

Uma das razões para isso é a facilidade de manutenção que teremos trabalhando com servidores “idênticos”. Em uma escala mínima de dois ou até mesmos três servidores, a manutenção pode até não ser problemática, mas se pensarmos que grandes datacenters possuem um grande número de servidores, para os mais diversos fins e especificidades, a manutenção pode se tornar bastante complexa.

Ainda relacionado à questão da igualdade de servidores, se tivermos sistemas operacionais e servidores de SGBDs de 32 bits trabalhando com 64 bits, a replicação não irá funcionar, devido às diferenças estruturais internas no armazenamento dos dados, páginas, etc.

A mesma coisa pode-se dizer com relação à diferença de níveis de versões do PostgreSQL. Ou seja, replicações das versões 8.2 para 8.3, ou vice-versa, não irão funcionar devido, entre outras coisas, às mudanças internas de formatos de blocos do PostgreSQL. Replicações entre versões mínimas (8.3.0 para 8.3.1 ou 8.3.2 ou etc., e vice-versa) podem funcionar corretamente, mas o Grupo de Desenvolvimento Global do PostgreSQL aconselha a utilizar servidores com o mesmo número de versão.

Com os servidores configurados de maneira semelhante, isto é, com os sistemas operacionais iguais e os servidores PostgreSQL com as mesmas versões, podemos continuar com nossa preparação do ambiente.

Neste momento, torna-se necessário instalar e configurar um servidor rsync no servidor slave. O rsync é um utilitário para ambientes Unix que tem a funcionalidade de sincronizar arquivos e diretórios entre duas localidades diferentes, enquanto minimiza a transferência de dados, pois transfere apenas o que está diferente entre a origem e o destino. Não mostraremos aqui como instalar o rsync, pois não faz parte do escopo deste artigo, mas na seção Links pode ser encontrado um artigo interessante de instalação, configuração e uso dessa ferramenta.

Abrindo o arquivo rsyncd.conf (localizado no diretório /etc), devemos incluir as linhas da Listagem 1 para dizer ao rsync como controlar a autenticação, acesso, log, entre outras coisas. A Tabela 1 mostra resumidamente o que quer dizer cada linha para facilitar o entendimento geral do utilitário.

Listagem 1. Configuração do rsync, no arquivo rsyncd.conf

1.     [wal]

2.     path = /var/lib/pgsql/archive

3.     uid = postgres

4.     gid = postgres

5.     read only = no

6.     list = no

7.     hosts allow = 192.0.0.211 127.0.0.1