Esse artigo faz parte da revista SQL Magazine edição 64. Clique aqui para ler todos os artigos desta edição

Clique aqui para ler esse editorial em PDF

Replicação no PostgreSQL

Utilização do Log Shipping

Todos os SGBDs, pagos ou free, possuem de uma forma ou de outra a habilidade de copiar os logs de transações para outro local, seja por motivos de backup ou para replicação – e o PostgreSQL não foge à regra. A esta habilidade damos o nome de Log Shipping.

Em versões anteriores, o log shipping era mais utilizado para o arquivamento dos logs de transações do que propriamente à replicação em si. Isto acontecia por motivos diversos, como por exemplo, o fato de ter que desenvolver códigos próprios para a replicação.

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." [...] continue lendo...