Título inapropriado: O Título do artigo (e dessa matéria, por consequencia) está inapropriado, não condiz com que o autor se propõe. Por um erro do próprio autor, creio eu.

O que é sugerido no título, fazer um backup com o SGBD ativo já é possível a muito tempo (talvez desde as 1as versões) através do comando pg_dump / pg_dumpall.


O que o autor explica, e é interessante, é como atualizar um servidor espelhado a quente.

Script simples e eficiente. A crítica foi só pelo título, induz a uma idéia um pouco distorcida :)

título: Eu que havia editado o título. Recoloquei agora o título original do trabalho.

pg_dump: Qual usuário de PostreSQL não pensou em tirar uma cópia completa dele e esbarrou no problema de não poder fazer isso sem parar o banco de dados ?

Bacana o script, mas vale lembrar que o comando pg_dump (ou pg_dumpall para todos os bancos no sistema) é hot backup (isto é, não é necessário os usuários desconectarem para que o backup seja efetuado).

O que o autor utilizou foi uma nova característica implementada no postgresql 8.x chamada PITR (Point In Time Recovery). Através da cópia dos logs de transação, é possível replicar um banco do último backup full até o ponto em que se deseja para, por exemplo, recuperar o banco de um desastre.

No caso, o script foi utilizado para replicar o banco num cluster, o que é bem mais esperto do que voltar um banco de dados todo num servidor backup (até porque você não pode tirar um backup full a cada dez minutos numa base de 20 GB). :)



Alexandre de Arruda Paes

pg_dump não é boa alternativa para certos casos: Bom, esta estratégia foi montada pois utilizamos o pg_dump com um banco que tinha uma tabela com uns 10 milhoes de registros.

Já tentou utilizar o restore com uma tabela desse tamanho ?

O recovery vai levar um tempo tão grande que o sistema que depender dessa base vai ficar fora um longo período.

Com esta estrutura vc terá sempre um banco stand-by e o recovery será enormemente menos custoso e todos serão felizes na hora de se recuperar de um desastre. Além disso tiramos um pg_dump de reserva como última cartada, mas, espero nunca precisar dele novamente. Apesar dele ter recursos para recuperar por tabela quando vc gera ele com o formato apropriado.

Mas, valeu a interação, é assim que enriquecemos nossas ideais e matamos nossas dúvidas.

"Backup quente no PG" ainda s: "Backup quente no PG" ainda soa incendiário.
Se usou "standby" poderia ter usado "online", putz! o tempo passa e eu tô ficando cada vez mais chato. :)

Replicar online tem um custo: Replicar online tem um custo para a rede e para os sistemas e geralmente é para aplicaçoes distribuidas tirarem proveito dela, fora isso eu não recomendaria este tipo de solução com a enfase no anti-desastre, até porque solução anti-desastre sao melhores implementadas envolvendo compra de hardware especifico ou um simples espelhamento de HD deixando uma maquina similar de prontidao.

Discordo: Aí eu já discordo de você.
O custo para a rede é mínimo se você ligar as duas máquina dedicadamente com um cabo cross. Segundo que numa máquina com boa quantidade de memória, o comando de cópia do archive vai buscar no cache o log de transações e não no disco.
O impacto de tudo isso no servidor é mínimo e no slave é despresível, visto que ele está lá apenas para esse tipo de serviço.
Outa coisa importante: tempo de paralizaçao. Tenho um cliente que possui um backup de 800 Mb (compactados por usar pg_dump -Fc). Esse banco pussui 1005 tabelas e uns 3000 índices. Num Dell,Dual Xeon 3 Ghz, 4 x SCSI 15k RAID 10, 4 Gb RAM, ele leva 2 horas e 15 minutos para restaurar. São 2 horas e 15 minutos com a esteira parada e 200 funcionários "coçando". E veja: estou falando do SERVIDOR e não do cluster! Imagine voltar o backup numa máquina 4x menor...


Alexandre de Arruda Paes

Sobre Custos de rede e hardware: No exemplo a replicação(entenda como copia dos arquivos do diretório "data") não é on-line e sim as 03:00AM(para nós é o horário que temos menor volume de tráfego na rede).

Isso é só uma idéia que está em prática(e funcionando), e para quem não quer gastar com "hardware específico" que deve ser caro, pode-se fazer isso com outro PC. O mundo ideal é termos máquina SCSI com RAID5, fontes redundantes, dual xeon 3.2 e outras coisas que custam em torno de R$18.000,00(Exemplo um servidor Itautec) contra um PC de 1.200,00

Custo de replicação: O impacto na rede de uma solução dessas é praticamente irrelevante. Sou DBA Oracle e já implementei standby database (exatamente mesmo princípio utilizado pelo PostgreSQL 8x) em bases de dados superiores a 50gb utilzando a rede convencional de 100Mb, sem nem mesmo lançar mão de placa gigabit ou cabo cross. Apenas as alterações são enviadas para a outra ponta, o standby. Os logs redo internos sao gerados, replicando-se ou não. O fato de gravar isso em um arquivo de log é irrelevante em termos de processamento. O tráfego na rede não chega a 100mb por hora (imagine um banco que cresce 100mb/h?). O outro banco fica ocioso apenas aplicando esses logs. Logo é uma excelente opção de contingência (que eu uso exaustivamente) com um custo baixíssimo. Parabens ao PostgreSQL por essa implementação.

discordo outra vez.: Se tivesse feito espelhamento de HD e apenas tivesse colocado o disco espelho no outro micro, o resultado não teria sido o mesmo ? Até mais rápido porque neste caso não precisaria nem reconfigurar o outro micro para ser o servidor atual (hostname, ip fixo,...) ?

Com mil perdoes, mas se tem 200 pessoas conectadas a um banco, este cliente deveria estar um pouco mais preocupado em ter uma sala para este servidor e um RAID de servidores ou de disco que seria uma solução rápida para quem não quer parar a empresa por nem sequer um segundo. Com tanta gente conectada ao banco, requer cuidados na escolha até do servidor, servidores HP além de oferecerem RAID ainda oferecem fontes redundantes, houve uma época (não sei se ainda existe), mas tinha até memória redundante.

Replicação para mim tem outra finalidade, ser usada para aplicaçoes distribuidas, servidores de datamining, datawarehouse,...

Ok, voce usou uma solução de replicação para um fim anti-desastre, mas a replicação não foi concebida para este proposito. É este o ponto que eu quero chegar, não estou dizendo que não possa faze-lo ou que é proibido faze-lo, apenas (repetindo) a replicação não foi feito para este proposito.

Acho que você não leu direito.: Num Dell,Dual Xeon 3 Ghz, 4 x SCSI 15k RAID 10, 4 Gb RAM

Tem 4 discos espelhados em RAID 1+0 (fonte redundante, controladora com 256 Mb de cache com bateria, bla,bla,bla - R$ 30.000,00), numa sala com climatização controlada e apenas o servidor, cluster e switchs dentro.

Aliás, não há 200 pessoas conectadas ao banco. Há 400 funcionários (errei na conta) e os processos utilizam-se do banco para operações críticas de produção.

Se tivesse feito espelhamento de HD e apenas tivesse colocado o disco espelho no outro micro,

Você está dizendo quer o problema ocorre apenas na máquina (processador, memória, fonte) ???
E se alguma coisa acontecer LOGICAMENTE no banco? Tipo DELETE * FROM CLIENTES (exemplo tosco, mas há centenas de outros)?
E se todos os discos falharem (numa descarga elétrica) ?
Não há espelho que salve isso, amigo !

Junte isso a lenda do "retira o disco rodando de um computador e coloca no outro que 1 minuto depois tá funcionando"...

Em STORAGE é outra história, mas mesmo assim corre-se o risco das falhas lógicas em que é preciso voltar "no tempo" para recuperá-la.

Alexandre de Arruda Paes

Controle contra falhas é com: Controle contra falhas é como um seguro, um seguro contra falhas no HD seria um espelhamento por hardware (atualmente as placas maes com sata oferecem raid-0 e 1) ou sofware. Se o seguro quiser cobertura contra placa-mae tem que comprar um segundo servidor. Se o seguro for cobrir roubo então fitas DAT/DLT/SDLT. Se o seguro for cobrir enchente (em Sao Paulo isso é importante) talvez contratando host num ISP, bla, bla, bla... Não tem fim, um esforço para alcançar o vento.

Existe a possibilidade de cluster para oferecer redundancia de servidores trabalhando juntamente(e acelerando o trabalho) ou apenas como servidores redundantes de backup.

Mas não seja tão céptico, se o slave estiver perto do master, todos os riscos físicos podem ocorrer com ambos, se cair um raio no mesmo barramento é provavel que ambos sejam detonados, se um assaltante invadir e quiser roubar entao levará a ambos, se há replicação de comandos SQL, um SQL "delete from" que for dado aqui será dado acolá também.

Evitar riscos é como adquirir um seguro, quanto mais cobertura mais caro fica. Qualquer dia desses eu monto em laboratorio um cluster entre dois micros e vejo qual é a dificuldade, mas imagino que adquirindo o knowhow será uma solução muito melhor que replicar dados se a questão for segurança.

;) - Sem flames: se há replicação de comandos SQL, um SQL "delete from" que for dado aqui será dado acolá também.

Depende amigão. Quem disse que a replicação precisa ser feita a cada segundo ?!?!? O segredo está aí: o servidor envia o log para o servidor do lado e também o envia para a pastelaria ao lado, por exemplo, ligada por wireless. No servidor ao lado, os backups são relicados a cada meia hora e na pastelaria eles são apenas armazenados. Putz! Deram o DELETE as 13:00 e só foram perceber as 13:30:01 !!! O cluster já replicou mas o computador do seu Manoel continua firme e forte com os arquivos da replicação! Volta-se o último backup full e replica-se os logs.

O que parece que você está se negando a ver é que todos os SGDBs "enterprise" possuem esse função PRIMARIAMENTE para atender a requisitos de SEGURANÇA.
Para sistemas distribuidos há inúmeras outras formas também, todas com seus prós e contras.

Alexandre de Arruda Paes

Postgresql para Oracle: Alguem sabe me dizer se consigo utilizar essa funcionalidade replicando de Postgresql para Oracle?