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á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-virgula 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-virgula 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
Postar um comentário