PostgreSQL em Alta Disponibilidade com WAL Shipping

Objetivo

Manter a disponibilidade do serviço de banco de dados PostgreSql de maneira automatizada, utilizando um recurso nativo de PITR do PostgreSQL. Documentar completamente os passos para uma implantação sobre Debian GNU / Linux 5.x "Lenny".

Escopo

A proposta é de um sistema de alta disponibilidade Nível 1 e continuidade do serviço de até 99%, em cenários aplicáveis, e com simplificação do plano de contingências, não focando em outras características como replicação, balanceamento de carga e fail over.

Para estas outras características, contamos com outras soluções interessantes que poderiam se aplicar em conjunto ao projeto e elevar a disponibilidade até Nível 4 e continuidade de serviços de 99,999% buscando eliminar SPOF (Simple Point of Failure, porém com uma complexidade maior.

Por exemplo PgPool, Slony-I, SqlRelay, Bucardo, GlusterFS, PaceMaker, bancos de dados geograficamente distribuidos entre vários centros de dados.

Precauções

Antes de iniciar a implementação dessa solução, é importante saber que o banco de dados primário enviará constantemente arquivos para o servidor secundário, afim de que esse receba exatamente as mesmas atualizações que aquele. Dessa forma, é extremamente importante que os dois bancos de dados estejam sempre ativos e que haja comunicação entre as duas máquinas, na forma do compartilhamento NFS. Caso surja algum problema que afete o mapeamento NFS ou o funcionamento em standby do servidor secundário, os arquivos deixarão de ser consumidos e passarão a se acumular no disco de uma das máquinas, podendo inviabilizar a solução ou até mesmo causar o travamento do servidor principal, em função do esgotamento da capacidade do disco. Considerando o fluxo de informações do banco e os parâmetros definidos no arquivo de configuração, esses arquivos acumulados podem alcançar o tamanho de 23 GB diários, sendo extremamente recomendado o uso de uma solução adicional de monitoramento do espaço em disco, tanto do servidor principal como do secundário.

Premissas

Para aplicação dessa solução, subentende-se que o ambiente já tenha um servidor Debian Lenny rodando o serviço de banco de dados (PostgreSQL) e que haja mais um servidor disponível, com a instalação básica do Debian Lenny. É necessário, ainda, que os sistemas tenham seus repositórios configurados segundo o documento Configurar APT No Debian. Considera-se, nos procedimentos abaixo, que a última versão estável do PostgreSQL disponível nos repositórios do Debian é a 8.3.

Pinning

Caso a versão do banco de dados em uso no servidor primário seja anterior à última, pode ser necessáriofazer APT PINNING da versão do pacote do postgresql, impedindo que haja upgrade de versão, liberando somente atualizações de segurança. Para isso, edite o arquivo /etc/apt/preferences nas duas máquinas, incluindo o trecho abaixo (a versão listada e o pacote são exemplos):

Package: postgresql-8.1
Pin: version 8.1.*
Pin-Priority: 1001

IPs Utilizados

É necessário saber, de antemão, os IPs que serão utilizados na implementação desses procedimentos. Nesse documento, como exemplo, são utilizados os seguintes IPs:
* Máquina primária (debianpgcluster1): 10.200.27.17
* Máquina secundária (debianpgcluster2): 10.200.27.32
* IP virtual do serviço (heartbeat): 10.200.27.18

UID e GID do usuário postgres na máquina primária

Para mapear o NFS corretamente, é necessário utilizar o mesmo uid e gid do usuário postgres nas máquinas primária e secundária. Para isso, descubra os dados desse usuário na máquina primária através do seguinte comando:

debianpgcluster1:~# id postgres
uid=103(postgres) gid=106(postgres) grupos=106(postgres),107(ssl-cert)

Antes de instalar o postgresql na máquina secundária, crie manualmente o usuário postgres, utilizando o mesmo uid e gid da máquina primária (no exemplo, 103 e 106, respectivamente), através dos seguintes comandos:

debianpgcluster2:~# groupadd --gid 106 postgres
debianpgcluster2:~# adduser --system --home /var/lib/postgresql --shell /bin/bash --uid 103 --gid 106 --disabled-password postgres

Procedimentos

Este documento se iniciou baseado na Proposta de Alta Disponibilidade para PostgreSQL, mas contém mudanças conceituais importantes sobre aquele.

Configurar nomes das máquinas editando /etc/hosts nas duas máquinas

Inclua nesse arquivo o nome das duas máquinas reais, conforme exemplo abaixo:

#versao 25Mai2010
127.0.0.1 localhost
10.200.27.32 debianpgcluster2
10.200.27.17 debianpgcluster1

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Instalar heartbeat, mon, postgresql, postgresql-contrib, nfs, rsync e sudo na máquina secundária

debianpgcluster2:~# apt-get update
debianpgcluster2:~# apt-get upgrade
debianpgcluster2:~# apt-get install heartbeat nfs-kernel-server rsync mon postgresql postgresql-contrib sudo

Criar diretório para logs e conceder propriedade, na máquina secundária

debianpgcluster2:~# mkdir /pgsql-archive
debianpgcluster2:~# chown postgres.postgres /pgsql-archive

Configurar o NFS na máquina secundária editando /etc/exports

Inclua nesse arquivo o compartilhamento do diretório /pgsql-archive, conforme exemplo abaixo. As opções do NFS definem que as escritas serão síncronas, para maior garantia de integridade, e que não serão permitidos comandos remotos de root, por questões de segurança.

#versao 25Mai2010
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
/pgsql-archive 10.200.27.17(rw,sync,no_subtree_check,root_squash)

Exportar o diretório da máquina secundária

debianpgcluster2:~# exportfs -a

Criar um arquivo para verificação de montagem e alterar propriedade

debianpgcluster2:~# su postgres -c 'touch /pgsql-archive/mounted.txt'

Parar o serviço do PostgreSQL na máquina secundária

O serviço somente voltará a ficar ativo num evento de falha do servidor primário. Enquanto não ocorrerem problemas, o servidor secundário operará continuamente em standby.

debianpgcluster2:~# invoke-rc.d postgresql-8.3 stop

Configurar /etc/postgresql/8.3/main/postgresql.conf na máquina secundária

Para que o heartbeat consiga redirecionar as requisições, é preciso que o PostgreSQL responda queries em todas as interfaces. Nessa configuração, a segurança passa a ser provida pelo pg_hba.conf. Para isso, edite a opção listen_addresses, do arquivo postgresql.conf, segundo o exemplo abaixo:

#versao 31Mai2010
listen_addresses = '*'
# what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost', '*' = all
# (change requires restart)

Configurar o arquivo /etc/postgresql/8.3/main/pg_hba.conf nas duas máquinas

Caso seja necessário, libere o acesso a consultas para o IP virtual (10.200.27.18, no exemplo) e o IP do servidor secundário (10.200.27.32, no exemplo), incluindo esses endereços no pg_hba.conf da máquina primária. Utilize esse mesmo arquivo de configuração na máquina secundária. Obs.: Esse arquivo deve conter todos os clientes (ou redes) que acessarão o banco de dados. No exemplo abaixo, foi incluído o IP 10.200.27.40, simulando a configuração de um cliente. Deve-se definir o método de autenticação que for apropriado. No exemplo, foi utilizado o md5.

#versao 27Mai2010
# Database administrative login by UNIX sockets
local all postgres ident sameuser

# TYPE DATABASE USER CIDR-ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all all ident sameuser
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5

host all all 10.200.27.32/32 md5
host all all 10.200.27.18/32 md5
host all all 10.200.27.40/32 md5

Criar o script de gatilho sob o controle do heartbeat na máquina secundária

Crie o arquivo /etc/ha.d/resource.d/trigger, conforme o modelo abaixo. Obs.: Os scripts de ação do heartbeat precisam aceitar os mesmos parâmetros dos que estão em /etc/init.d , seguindo o padrão LSB.

#!/bin/sh
#versao 08out2009 por Joao Cosme de Oliveira Junior
case "$1" in
start) echo "starting failover postgresql"
su postgres -c 'touch /pgsql-archive/trigger.done'

exit 0
;;

stop) echo "uneed to stop anything"
exit 0
;;
esac

Atribua permissão de execução a esse arquivo:

debianpgcluster2:~# chmod a+x /etc/ha.d/resource.d/trigger

Criar e editar o arquivo /etc/ha.d/ha.cf na máquina secundária

Crie o arquivo conforme o modelo abaixo. Note que o tempo para considerar um nó morto (deadtime) precisa ser o dobro do tempo usado (interval) no programa mon.

É importante notar que '''não''' haverá retorno automático ao nó primário, mesmo que ele seja restabelecido, para evitar inconsistência nos dados do banco. Após um chaveamento, o nó secundário terá dados válidos mais novos que o nó primário e será necessária uma intervenção manual para o failback, fazendo a retirada dos dados do nó secundário e carga no nó primário, numa parada programada.

O nome dos nós precisam ser os retornados pelo comando "uname -n".

#versao 25Mai2010
keepalive 1
deadtime 20
warntime 10
initdead 60
logfile /var/log/ha.log
auto_failback off

bcast eth0
node debianpgcluster1
node debianpgcluster2

Criar e editar o arquivo /etc/ha.d/haresources da máquina secundária

Crie o arquivo conforme o modelo abaixo. Nele é configurado o IP virtual e definido que o serviço será oferecido preferencialmente pela máquina primária.
'''IMPORTANTE e não convencional:''' O arquivo /etc/ha.d/haresources será DIFERENTE nas duas máquinas.
A seqüência de inicialização de alta disponibilidade será chaveamento de ip e depois trigger.
A seqüência de parada de alta disponibilidade será trigger e depois chaveamento de ip.
O serviço postgresql estará SEMPRE ativo (em modo recovery) na máquina secundária, para ficar lendo e consumindo os arquivos WAL.

#versao 31Mai2010
debianpgcluster1 10.200.27.18/24/eth0 trigger

Criar o arquivo /etc/ha.d/authkeys, editar e restringir permissões, na máquina secundária

No modelo abaixo, é definido o método "1" de autenticação como criptografado "sha1" e configurada a senha "pgha". Utilize alguma senha difícil de deduzir e igual nas duas máquinas.

#versao 25Mai2010
auth 1
1 sha1 pgha

Para que o conteúdo do arquivo possa ser lido apenas pelo usuário root, execute o comando abaixo:

debianpgcluster2:~# chmod 600 /etc/ha.d/authkeys

Instalar heartbeat, hapm, nfs e rsync na máquina primária

debianpgcluster1:~# apt-get update
debianpgcluster1:~# apt-get upgrade
debianpgcluster1:~# apt-get install heartbeat nfs-common rsync hapm

Criar diretório para logs e conceder propriedade na máquina primária

debianpgcluster1:~# mkdir /pgsql-archive
debianpgcluster1:~# chown postgres.postgres /pgsql-archive

Editar /etc/fstab na máquina primária

Inclua nesse arquivo a última linha do modelo abaixo, alterando as configurações para a sua realidade. As outras linhas apenas ilustram o formato do fstab e dever ser adequadas a cada servidor.

#versao 25Mai2010
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda1 / ext3 errors=remount-ro 0 1
/dev/hda5 none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
10.200.27.32:/pgsql-archive/ /pgsql-archive nfs rw,sync,soft,intr 0 0

Importar e montar o diretório da máquina secundária para a primária

debianpgcluster1:~# mount -a

Rode o comando abaixo e verfique a sua saída. Nesse momento, deve existir apenas o arquivo mounted.txt, de propriedade de postgres.postgres.

debianpgcluster1:~# ls -lh /pgsql-archive

Configurar /etc/postgresql/8.3/main/postgresql.conf na máquina primária

Para que o heartbeat consiga redirecionar as requisições, é preciso que o PostgreSQL responda queries em todas as interfaces. Nessa configuração, a segurança passa a ser provida pelo pg_hba.conf. Para isso, edite a opção listen_addresses, do arquivo postgresql.conf, segundo o exemplo abaixo:

#versao 31Mai2010
listen_addresses = '*'
# what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost', '*' = all
# (change requires restart)

Configure o WAL archiving, conforme o modelo abaixo. '''Importante:''' As configurações definidas nesse exemplo forçam a geração de um arquivo WAL a cada 60 segundos, mesmo sem atividade. Isso garante um tempo máximo para uma janela de perda de dados, mas gera um grande volume de arquivos.
Obs.: Atenção para as aspas simples.

# - Archiving -

archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = 'test -f /pgsql-archive/mounted.txt && test ! -f /pgsql-archive/%f && rsync -a %p /pgsql-archive/%f'
# command to use to archive a logfile segment
archive_timeout = 60 # force a logfile segment switch after this
# time; 0 is off

Reinicie o serviço PostgreSQL na máquina primária

Antes de executar o comando abaixo, verifique se a máquina secundária está ativa, pois o postgresql precisará do compartilhamento nfs para gravar os arquivos WAL.

debianpgcluster1:~# invoke-rc.d postgresql-8.3 restart

Copiar o script de controle de serviço para o diretório de recursos do heartbeat

debianpgcluster1:~# cp /etc/init.d/postgresql-8.3 /etc/ha.d/resource.d/

Remover o script de controle de serviço da inicialização e paradas automáticas da máquina primária

O Heartbeat controlará o início e a parada do serviço postgresql de agora em diante.

debianpgcluster1:~# update-rc.d -f postgresql-8.3 remove
debianpgcluster1:~# rm /etc/init.d/postgresq-8.3

Editar o arquivo /etc/ha.d/hapm.conf na máquina primária

Edite o arquivo conforme o modelo abaixo. O HAPM derrubará o heartbeat na máquina primária caso não obtenha resposta na porta local 5432 (banco de dados). Obs.: O parâmetro "time" precisa ser maior que os "initdead" e "deadtime" do heartbeat.

###########################################################################
# #
# hapm.conf #
# #
# This file haves hapm configurations #
# #
# High Availability Port Monitor is a Free Software under GNU/GPL License #
# #
# This is a Brazilian Project created by: #
# #
# - Alexandre Antonio Antunes de Almeida #
# - Joao Eriberto Mota Filho #
# - Rosemeri Dantas de Oliveira #
# #
###########################################################################

# You must make one line by IP/Port. Use one IP and port by line only.
#socket=127.0.0.1:5432
socket=10.200.27.17:5432

# This is the time in seconds to check the port status. Caution to use small
# values here or your processor will be very busy. You must use a value
# between 0 and 3600. To use small values check performance with #top
# command (see CPU idle field).
time=120

# The Heartbeat start/stop script path
heartbeat=/etc/init.d/heartbeat

# Check where Heartbeat make the PID file and set it below.
# Default is /var/run/heartbeat.pid
heartbeatpid=/var/run/heartbeat.pid

Criar e editar o arquivo /etc/ha.d/ha.cf da máquina primária

Crie o arquivo conforme o modelo abaixo:

#versao 25Mai2010
keepalive 1
deadtime 20
warntime 10
initdead 60
logfile /var/log/ha.log
auto_failback off

bcast eth0
node debianpgcluster1
node debianpgcluster2

Criar e editar o arquivo /etc/ha.d/haresources da máquina primária

Crie o arquivo conforme o modelo abaixo. Nele é definido o nó primário e configurado os recursos a serem gerenciados pelo heartbeat: o IP virtual e o serviço de banco de dados.

IMPORTANTE:
* O arquivo ''/etc/ha.d/haresources'' será '''diferente''' nas duas máquinas.
* O heartbeat controlará o início e parada do postgresql.
* Os dois recursos configurados nesse arquivo (IP virtual e banco de dados) inicializarão somente após o tempo definido do parâmetro ''initdead'', do arquivo ''ha.cf''.

#versao 25Mai2010
debianpgcluster1 10.200.27.18/24/eth0 postgresql-8.3

Criar o arquivo /etc/ha.d/authkeys, editar e restringir permissões, na máquina primária

No modelo abaixo, é definido o método "1" de autenticação como criptografado "sha1" e configurada a senha "pgha". Utilize alguma senha difícil de deduzir e igual nas duas máquinas.

#versao 25Mai2010
auth 1
1 sha1 pgha

Para que o conteúdo do arquivo possa ser lido apenas pelo usuário root, execute o comando abaixo:

debianpgcluster1:~# chmod 600 /etc/ha.d/authkeys

Backup inicial a quente do PostgreSQL na máquina primária

Entre no prompt do psql como superusuário postgres e comece o processo de criação de um backup inicial com a identificação YYYYMMDD, conforme exemplificado abaixo:

debianpgcluster1:~# su - postgres
postgres@debianpgcluster1:~$ psql
Bem vindo ao psql 8.3.9, o terminal iterativo do PostgreSQL.

Digite: \copyright para mostrar termos de distribucao
\h para ajuda com comandos SQL
\? para ajuda com comandos do psql
\g ou terminar com ponto-e-vi­rgula para executar a consulta
\q para sair

postgres=# select pg_start_backup('20100525');
pg_start_backup
-----------------
2/B3000020
(1 registro)

postgres=# \q

O execução do comando vai durar um tempo proporcional ao tamanho dos bancos de dados no servidor.

Compactar os arquivos do postgresql em execução

Como o engine do banco de dados estará em execução, poderá haver avisos de arquivos alterados durante a compactação.

debianpgcluster1:~# su - postgres
postgres@debianpgcluster1:~$ cd /var/lib/postgresql/8.3/
postgres@debianpgcluster1:~$ tar -czf /pgsql-archive/backup_20100525.tar.gz *

Finalizar a criação de backup inicial

Entre na console do psql como usuário postgres e execute o comando abaixo:

postgres@debianpgcluster1:~$ psql
Bem vindo ao psql 8.3.9, o terminal iterativo do PostgreSQL.

Digite: \copyright para mostrar termos de distribuicao
\h para ajuda com comandos SQL
\? para ajuda com comandos do psql
\g ou terminar com ponto-e-vi­rgula para executar a consulta
\q para sair

postgres=# select pg_stop_backup();
pg_stop_backup
----------------
2/B300007C
(1 registro)

postgres=#

Parar o heartbeat na máquina secundária

Pare o Heartbeat e remova o arquivo citado, caso ele exista.

debianpgcluster2:~# invoke-rc.d heartbeat stop
debianpgcluster2:~# rm /pgsql-archive/trigger.done

Cópia do arquivo de backup inicial para a máquina secundária

Antes de executar os comandos abaixo, certifique-se de que o PostgreSQL esteja parado. Pode-se mover a antiga base de dados "main" ou apagá-la. Os comandos abaixo armazenam essa antiga base no diretório "main.old1".

debianpgcluster2:~# invoke-rc.d postgresql-8.3 stop
debianpgcluster2:~# cd /var/lib/postgresql/8.3/
debianpgcluster2:~# mv main main.old1
debianpgcluster2:~# tar -xzvf /pgsql-archive/backup_20100525.tar.gz
debianpgcluster2:~# rm -rf main/pg_xlog/*

Criar e editar o arquivo /var/lib/postgresql/8.3/main/recovery.conf na máquina secundária

Crie o arquivo conforme o modelo abaixo. Se houver um chaveamento, o postgresql renomeará esse arquivo para "recovery.done".
Obs.: Atenção para aspas simples.

restore_command = '/usr/lib/postgresql/8.3/bin/pg_standby -d -l -r 3 -s 60 -t /pgsql-archive/trigger.done /pgsql-archive %f %p %r 2>>/tmp/pg_standby.log'

Conceda a propriedade desse arquivo ao usuário postgres e remova os arquivos de log, caso existam.

debianpgcluster2:~# chown postgres.postgres /var/lib/postgresql/8.3/main/recovery.conf
debianpgcluster2:~# rm /tmp/pg_standby.log

Configurar o Mon

O Mon servirá para evitar situações de split-brain caso haja uma interrupção na rede, já que não usaremos conexão direta de controle de heartbeat (cabo crossover) entre as máquinas. Para configurá-lo, siga as instruções do documento Como Configurar MON Para Monitorar Remotamente Em Sistemas Debian.

Parar o heartbeat e o hapm na máquina primária

debianpgcluster1:~# invoke-rc.d heartbeat stop
debianpgcluster1:~# invoke-rc.d hapm stop

Reiniciar o cluster de alta disponibilidade

1. Reinicie a máquina secundária. Ela precisa ser iniciada primeiro, para disponibilizar o diretório NFS para a primária.

2. Para que a máquina secundária não interprete o reboot do nó primário como uma queda do servidor, pare o serviço do heartbeat na máquina secundária, através do seguinte comando:

debianpgcluster2:~# invoke-rc.d heartbeat stop

3. Reinicie a máquina primária. Os recursos configurados no heartbeat (IP virtual e postgresql) iniciarão após decorido o tempo definido no parâmetro ''initdead'', no arquivo ''ha.cf'' (60 segundos, nesse modelo).

4. Confira se o diretório compartilhado foi montado corretamente na máquina primária. O comando abaixo deverá retornar ao menos o arquivo ''mounted.txt''.

debianpgcluster1:~# ls -lh /pgsql-archive

5. Caso a montagem do diretório NFS não tenha sido bem sucedida, force esse procedimento através do seguinte comando:

debianpgcluster1:~# mount -a

6. Inicie o heartbeat na máquina secundária, através do seguinte comando:

debianpgcluster2:~# invoke-rc.d heartbeat start

OBSERVAÇÕES:
* A máquina primária oferecerá o serviço postgresql através do IP virtual.
* A máquina secundária permanecerá com o serviço postgresql em modo ''recovery'' até que ocorra um chaveamento.
* Num chaveamento, o IP virtual é repassado para a máquina secundária, o postgresql recebe o ''trigger.done'' e o serviço sai do modo ''recovery'', passando a responder transações.
* '''Não''' haverá retorno automático de serviço para o nó primário. Esse procedimento deverá ser feito manualmente, durante uma parada programada, seguindo os passos abaixo.

Procedimentos de retorno de operação da máquina primária após um chaveamento

Se ocorrer um chaveamento para a máquina secundária, a máquina primária '''não''' poderá ter o serviço postgresql, nem o heartbeat reiniciados sem antes recuperar os dados da secundária.

Isso porque durante algum tempo a secundária recebeu dados novos e válidos.

Se for possível tolerar algum downtime, o modo mais simples é fazer uma parada programada de tudo para retirar os dados da secundária, carregar na primária e refazer o backup inicial para a secundária.

Bloquear queries nos servidores postgresql

Você terá de bloquear queries nos DOIS servidores postgresql. Alternativas:
* Poderá reconfigurar o pg_hba.conf de AMBOS e recarregar configurações.
* Parar o cliente que origina as queries.
* Bloquear temporariamente por iptables as queries vindas do cliente.

Garantir serviços de cluster HA parados na máquina primária

debianpgcluster1:~# invoke-rc.d heartbeat stop
debianpgcluster1:~# invoke-rc.d hapm stop
debianpgcluster1:~# /etc/ha.d/resource.d/postgresql-8.3 restart

Garantir serviços de cluster HA parados na máquina secundária

debianpgcluster2:~# invoke-rc.d heartbeat stop
debianpgcluster2:~# invoke-rc.d mon stop
debianpgcluster2:~# invoke-rc.d postgresql-8.3 restart

Extrair todos dados do postgresql secundário

debianpgcluster2:~# su - postgres
postgres@debianpgcluster2:~$ pg_dumpall --clean --inserts --column-inserts --file=/pgsql-archive/pgdumpall_YYYYMMDD.sql

Carregar todos dados no postgresql primário

debianpgcluster1:~# su - postgres
postgres@debianpgcluster1:~$ psql -f /pgsql-archive/pgdumpall_YYYYMMDD.sql template1

Parar ambos os postgresql

debianpgcluster1:~# /etc/ha.d/resource.d/postgresql-8.3 stop

debianpgcluster2:~# invoke-rc.d postgresql-8.3 stop

Reiniciar serviços de cluster HA parados na máquina primária

postgres@debianpgcluster2:~$ exit
debianpgcluster1:~# invoke-rc.d heartbeat restart

Aguarde o serviço postgresql levantar na máquina primária. Esse tempo deverá corresponder ao parâmetro ''initdead'' mais o tempo necessário para o próprio postgresql iniciar.

debianpgcluster1:~# invoke-rc.d hapm restart

Limpar arquivos compartilhados e logs de recuperação

debianpgcluster1:~# su - postgres
postgres@debianpgcluster1:~$ rm /pgsql-archive/0*
postgres@debianpgcluster1:~$ rm /pgsql-archive/pgdumpall*
postgres@debianpgcluster1:~$ rm /pgsql-archive/backup*
postgres@debianpgcluster1:~$ rm /pgsql-archive/trigger.done
postgres@debianpgcluster1:~$ rm /tmp/pg_standby.log

Refazer o backup inicial

Agora refaça todos os passos para criar o backup inicial da máquina primária e depois copiar para a máquina secundária.
* Backup inicial a quente do PostgreSQL na máquina primária
* Compactar os arquivos do postgresql em execução
* Finalizar a criação de backup inicial
* Parar o heartbeat na máquina secundária
* Cópia do arquivo de backup inicial
* Criar e editar o arquivo /var/lib/postgresql/8.3/main/recovery.conf

Reinicie os serviços de cluster HA e o PostgreSQL na máquina secundária

debianpgcluster2:~# invoke-rc.d heartbeat restart
debianpgcluster2:~# invoke-rc.d mon restart
debianpgcluster2:~# invoke-rc.d postgresql-8.3 start

Desbloquear queries nos servidores postgresql

Você pode desbloquear as queries sobre os servidores postgresql.
Os passos dependem do método utilizado no bloqueio.

Bibliografia

[0] http://www.postgresql.org/docs/8.3/interactive/continuous-archiving.html

[1] http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

[2] http://www.linux-ha.org/wiki/Ha.cf

[3] http://www.linux-ha.org/wiki/Haresources

[4] http://www.linux-ha.org/wiki/Authkeys

[5] http://www.linux-ha.org/wiki/Configuration

[6] http://www.linuxwebcluster.com/documentation/high-availability-linux-setup-heartbeat-ipfail-ping-node-configuration.html

[7] http://www.linuxvirtualserver.org/docs/ha/heartbeat_mon.html

[8] http://joaocosme.wordpress.com/2009/10/30/ha-em-postgresql-warm-stand-by-heartbeat-hapm/