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/

Comentários

Postagens mais visitadas deste blog

Tutorial Cyrus IMAP aggregator (murder) 2.3.16 sobre Debian GNU Linux 5.x Lenny

How to configure multipath for high availability and performance on Debian and CentOS for storage at IBM DS8300 SAN

Como instalar Oracle Client no Debian e Ubuntu