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ário fazer 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/