Re: [pgbr-geral] copiar tabelas fisicamente
Em 21 de setembro de 2012 10:27, Euler Taveira eu...@timbira.com escreveu: On 20-09-2012 22:56, Fabrízio de Royes Mello wrote: Será que revogando todos acessos a relação e após um checkpoint não é possível fazer essa operação? Até pq o pg_upgrade faz +- o que o Telles precisa, ou estou errado? Não. Está errado. Checkpoint só garante que os dados estejam nos datafiles; o que é preciso é congelar as tuplas para podermos utilizar o histórico de transações noutro lugar. Fiz uns testes aqui e claro que funcionou até porque é um ambiente controlado e não existe alta concorrencia de acesso aos objetos, mas fiz assim: ambiente controlado é desse artifício que o pg_upgrade utiliza; mas o caso do Telles é um outro cluster existente (com id de transação distinto e histórico de transações pré-existente) e ainda mais, não se pode copiar o histórico de transações (aka pg_clog/*) porque não há maneira fácil de separar somente aqueles referentes as tabelas copiadas. Se eu fizer a copia a frio (baixar o cluster), não é possível? []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
Re: [pgbr-geral] copiar tabelas fisicamente
On 21-09-2012 10:42, Fábio Telles Rodriguez wrote: Se eu fizer a copia a frio (baixar o cluster), não é possível? Não. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
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, mito 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
Re: [pgbr-geral] copiar tabelas fisicamente
Em 21-09-2012 11:19, Fábio Telles Rodriguez escreveu: A minha estimativa é de que eu precisaria copiar cerca de 50GB todo FDS. Exportar é fácil, mas importar... custa bem caro. 50 GiB não é tanto assim. Na boa, é até bem pouco. 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. Você pode usar via gatilho (com algum overhead, claro, mas depende do seu TPS aí) e usar dblink pra mandar pro histórico. Se quiser *muito pouco* overhead você pode usar pl/proxy pra isso, já que é só cópia de dados de um lado pro outro. O overhead vai ficar todo no outro servidor, o servidor principal só passa parâmetro. 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. Excelente estratégia. E, pra guardar em fita, prefiro dump. 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. Alternativamente você pode usar um ETL para isso todo fim de semana. Recomendo o ETL da suíte Spago BI que é 100% software livre (ao contrário do Pentaho) e é muito bom. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
On 21-09-2012 11:19, Fábio Telles Rodriguez wrote: A minha estimativa é de que eu precisaria copiar cerca de 50GB todo FDS. Exportar é fácil, mas importar... custa bem caro. Então o que você precisa é de um importador eficiente. Sugiro fazer alguns testes com pgloader [1] (vai te surpreender). 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? opção (a) mas você tem que garantir opção (b) também. 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. Mas com replicação via gatilho você pode: (i) inscrever as tabelas a serem replicadas, (ii) replicar toda tabela e (iii) desinscrever as tabelas replicadas. (Estou imaginando que as tabelas a serem replicadas não sofrerão mudanças após o início desse processo). IMHO, é menos complexo tentar utilizar um importador eficiente do que replicação. [1] https://github.com/dimitri/pgloader -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
IMHO, é menos complexo tentar utilizar um importador eficiente do que replicação. [1] https://github.com/dimitri/pgloader É, acho que vai ser por aí mesmo. Obrigado pela ajuda, Srs. -- 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
Re: [pgbr-geral] copiar tabelas fisicamente
Em 21 de setembro de 2012 12:43, Euler Taveira eu...@timbira.com escreveu: On 21-09-2012 11:19, Fábio Telles Rodriguez wrote: A minha estimativa é de que eu precisaria copiar cerca de 50GB todo FDS. Exportar é fácil, mas importar... custa bem caro. Então o que você precisa é de um importador eficiente. Sugiro fazer alguns testes com pgloader [1] (vai te surpreender). É bom mesmo esse cara? Já usei o pg_bulkloader [1] e achei bem interessante... o [1] http://pgbulkload.projects.postgresql.org/ -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
Em 21 de setembro de 2012 11:19, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: corte 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. Backup dos logs (pg_xlog) não resolveria? Pois assim você teria um volume menor a ser gravado em fita e dependendo da quantidade de transações não ficaria tão caro. Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
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? 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, mito caro. Queria saber se é possível, mexer com segurança debaixo do capô dos datafiles e fazer este tipo de movimentação. 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 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. Acho que você terá graves problemas se tentar algo desse tipo, linhas que já passaram por limpeza ou congelamento podem se tornar visíveis novamente, por exemplo, vide bug no pg_upgrade corrigido na versão 9.0.4 que justamente confundia isso, e eu já perdi dados por isso. Obóviamente Mr. Taveira pode ser mais claro que eu :) 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. Pergunto: por que é tão caro assim fazer os dumps que você está citando? A restauração até entendo, mas o dump não deveria ser uma dor tão insuportável. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
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. ;) 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, mito 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) ? 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. 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. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
Em 20 de setembro de 2012 20:31, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: 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 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. Concordo... Acho que você terá graves problemas se tentar algo desse tipo, linhas que já passaram por limpeza ou congelamento podem se tornar visíveis novamente, por exemplo, vide bug no pg_upgrade corrigido na versão 9.0.4 que justamente confundia isso, e eu já perdi dados por isso. Será que revogando todos acessos a relação e após um checkpoint não é possível fazer essa operação? Até pq o pg_upgrade faz +- o que o Telles precisa, ou estou errado? Fiz uns testes aqui e claro que funcionou até porque é um ambiente controlado e não existe alta concorrencia de acesso aos objetos, mas fiz assim: 1) Revoguei todas permissões de acesso a tabela 2) Checkpoint 3) pg_dump -s da tabela e restaurei esse dump no outro banco 4) Verifiquei os arquivos fisicos a serem copiados pelo catalogo na origem (guardei o pg_class.relfilenode) 5) Verifiquei os arquivos fisicos a serem copiados pelo catalogo no destino (guardei o pg_class.relfilenode) 6) Copiei os arquivos (pg_class.relfilenode) com o relfilenode na origem para o relfilenode do destino (substituindo assim o datafile) 7) Recuperei as permissões de acesso a tabela no destino e os dados estavam lá Obs: Eu copiei TUDO (tabelas, sequencias e indices) Obóviamente Mr. Taveira pode ser mais claro que eu :) É verdade... colabora ai Euler... 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. Imagino mesmo que não seja algo trivial Pergunto: por que é tão caro assim fazer os dumps que você está citando? A restauração até entendo, mas o dump não deveria ser uma dor tão insuportável. Mas eu acho que o principal problema do Telles ai pode ser a restauração mesmo... Att, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
