Em 20 de setembro de 2012 22:46, Euler Taveira <eu...@timbira.com> escreveu:
> On 20-09-2012 20:31, Flavio Henrique Araque Gurgel wrote: > > > > Em 20-09-2012 20:10, Fábio Telles Rodriguez escreveu: > >> Alguém sabe se é possível e como copiar tabelas fisicamente entre > >> diferentes clusters? > >> > Se fosse fácil assim não teria muita graça. ;) > Nunca pensei que seria fácil. Só queria saber se era possível. > > >> Tenho várias tabelas particionadas e preciso mover periodicamente > >> partições de uma base de produção para uma base histórica. Sei que posso > >> mover dados com um simples dump, mas isso custa muito, muuuuito caro. > >> Queria saber se é possível, mexer com segurança debaixo do capô dos > >> datafiles e fazer este tipo de movimentação. > > > Por que a cópia de segurança lógica é tão cara? Perda de performance? Você > não > dispõe de um standby para fazer essa cópia de segurança a partir dele? Já > pensou em utilizar alguma das ferramentas de replicação lógica (Slony, > Londiste ou Bucardo) ? > > A minha estimativa é de que eu precisaria copiar cerca de 50GB todo FDS. Exportar é fácil, mas importar... custa bem caro. > > Certamente que não. Motivos: > > > > 1) As tabelas são nomeadas com o relfilenode que é guardado em catálogo > > de sistema. Não sei como você criaria esses dados em catálogo sem correr > > riscos. > > > > 2) Algumas informações do mapa de visibilidade sobre as transações já > > concluídas são guardadas em mapa de bits no diretório pg_clog que é para > > todo o cluster > > > Acho que você misturou as coisas... Mapa de visibilidade é um artifício > para > acelerar o VACUUM; se ele se "perder", pode ser reconstruído > _automagicamente_ > (pelo VACUUM). > > > 3) As informações de transações correntes são guardadas em mapa de bits > > nos diretórios pg_multixact, pg_subtrans e pg_twophase, que também são > > para todo o cluster. > > > > 4) Se a arquitetura for diferente, você não conseguirá manipular os > datafiles. > Quando você fala de arquitetura se refere a: a) SO, kernel, sistema de arquivos e versão do Postgres idênticas ou b) Estrutura de tabelas idênticas? > > Não sei se tem algo no todo relativo a "tablespaces portáteis" para o > > PostgreSQL, mas numa conversa com o Bruce Momjian uma vez ele me > > explicou que muitas informações das tabelas são "cluster wide" e, > > portanto, um retrabalho muito grande de código paralizaria outros > > desenvolvimentos mais importantes. > > > Não existe o conceito de tablespace portável ou mesmo tabela portável > ainda. > Concordo que seria um esforço enorme para um caso de uso pequeno senão > ínfimo. > A replicação lógica cobre essa lacuna. FYI está em desenvolvimento a > replicação lógica no core; possivelmente na 9.3 teremos esse recurso sem > precisar utilizar alguma ferramenta externa. > Eu acho que replicação via gatilho custa caro. Eu não quero nenhum overhead no momento de pico do sistema. Veja a minha situação não é mandar os dados da produção direto para a base histórica. O que eu quero e mandar as partições mais antigas para a base histórica para depois poder apagar da produção. Minha base hoje hoje tem quase 10 meses de operação e passou dos 2TB. Para se ter uma ideia do problema, imagine fazer backup full de 2TB todos os dias? Não tem fita que aguente. Não tenho como manter tudo por aí indefinidamente. Não tem disco de alta perfórmance para tudo isso. Por contrato eu tenho que manter pelo menos 2 anos dos dados para consulta e auditoria. Minha intenção é manter apenas os últimos 30 dias na base de produção e todo FDS mover as partições da 5 semana para a base histórica. Se não tiver jeito, vai ter de ser via Dump/Restore. Não vai barato. Ainda mais que os discos da base histórica não serão tão bons. Sei que estou pensando em algo realmente arriscado. Mas sei que em situações de desastres, tem umas mandracarias bem bacanas que dá para fazer. []s -- Atenciosamente, Fábio Telles Rodriguez blog: http:// <http://www.midstorm.org/~telles/>http://tellesr.wordpress.com e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
