Re: [pgbr-geral] Solução para backup
Enviado pelo meu Nexus Em 20/08/2013 23:55, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Em 20 de agosto de 2013 22:40, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2013/8/20 Danilo Silva danilo.dsg.go...@gmail.com: estava tendo em meu ambiente de desenvolvimento, que é o meu notebook, somente problema de lentidão, considerando que o ambiente estava em uma VM com 4 GiB de RAM, S.O linux, mais o apache e o banco tinha em torno de 7 GiB de tamanho, ou seja, não ocorria outros problemas. Recentemente formatei meu notebook e deixei o linux como S.O principal, agora continuo com o mesmo ambiente (banco, apache), porém, o notebook agora tem 6 GiB de RAM, e para minha surpresa, a lentidão não existe. 2 GiB de memória viva podem fazer muita diferença, mas suspeito que o principal seja a base direto numa máquina física. Virtualização em PC costuma ter E/S sofrível. Eu sei que se a gente efetuar um dump e subir novamente, vai subir um banco totalmente limpo (sem tuplas mortas) e etc, diminuindo até o tamanho do banco. Agora a dúvida: isso não seria facilmente resolvido executando vacuum full e até mesmo um reindex? ou estou enganado? Correto. Pois é, no servidor produção, que não está em VM e possui 12 GiB de ram, mesmo executando vacuum full, reindexdb, continuo tendo a lentidão. Acho até que estou com a minha memória (a da cabeça mesmo) corrompida, pois lembrei de alguns detalhes importantes: No servidor de produção, apesar do max_connections estar em 70, eu ainda não vi (a olho nú por assim dizer) esse número em conexões simultânea, mas a replicação nativa está ativa. Posso até ativar uma replicação no meu ambiente de desenvolvimento, mas como poderia simular as conexões simultâneas, não só as conexões mas as transações também? Você pode usar o JMeter da Apache. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 5 de agosto de 2013 14:33, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 14:46, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Em 5 de agosto de 2013 12:10, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Pessoal, O banco cresceu!!! Cresceu para quanto? Nos dê uma ideia de valores. Atualmente está com 30 GiB. É muito pouco para medidas drásticas como particionamento. Por falta de recursos de hardware, Quais recursos de hardware estão faltando hoje? Espaço em disco? Desempenho em disco? Memória, CPU? Server com 12 GiB de Ram e HD de 1TB. É muito difícil saber se isto é suficiente. Uma vez que há o apache no mesmo servidor. Você também não disse ainda onde está o gargalo. Quando as consultas ficam lentas, qual recurso está no talo? Vamos ser mais práticos. No momento do pico, o processador fica como no top? A máquina faz swap? e a lentidão que está atrapalhando algumas rotinas, Quais rotinas? Como você faz o backup hoje? Único servidor que roda, além do postgres, replicação nativa, apache, php. O banco sofre muitos selects e inserts simultâneos. Além da replicação, é feito dump 4x aos dia, todos os dias. Dump 4x ao dia é algo muito ruim. Muito mesmo. Leia o post que recomendei antes Dump não é Backup. Ver artigo Dump não é backup: http://savepoint.blog.br/dump-nao-e-backup/ E também a palestra do Flávio no PGBR2011: Meu ambiente cresceu e eu não planejei. E agora? http://pgbr.postgresql.org.br/2011/palestras.php?id=53 foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. Você pensa em criar uma base histórica no mesmo servidor ou montar um novo servidor com a base histórica? Como disse anteriormente, não será fornecido um novo servidor para tal finalidade, portanto, deveremos efetuar no mesmo servidor. Existem várias alternativas para isso, como alguns comentaram uma delas é o particionamento. Mas particionamento está longe de ser algo simples. * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-como/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-automatizando/ O que é indicado/recomendado para este cenário? Você precisa dar mais detalhes sobre o seu cenário para podermos avaliar. Em todo caso, deixei aí algumas dicas que já podem lhe ajudar a pensar no assunto. Respondido? Ainda não. Você tem um longo caminho pela frente. 1) Rever completamente as rotinas de backup 2) Encontrar quais são os recursos que estão engargalando. 3) Encontrar quais consultas ficam lentas e se é possível otimiza-las. Se você não tem verba para ter um servidor separado para a aplicação e a base... então certamente não terá verba para contratar uma consultoria. Reserve uns trocados para estudar melhor o assunto. Para começar, bons livros sobre o assunto: http://www.packtpub.com/postgresql-90-high-performance/book http://www.packtpub.com/how-to-postgresql-backup-and-restore/book É possível efetuar o particionamento em tabelas já *populadas*? Pois tudo que li até agora somente falam sobre o particionamento começado do zero. []s 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] Solução para backup
2013/8/20 Danilo Silva danilo.dsg.go...@gmail.com: Em 5 de agosto de 2013 14:33, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 14:46, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Em 5 de agosto de 2013 12:10, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: O banco cresceu!!! Cresceu para quanto? Nos dê uma ideia de valores. Atualmente está com 30 GiB. É muito pouco para medidas drásticas como particionamento. É possível efetuar o particionamento em tabelas já *populadas*? Pois tudo que li até agora somente falam sobre o particionamento começado do zero. Antes que alguém te responda a pergunta que fizeste, farei a minha: por que é que você acha que particionamento te ajudará? Lembra que particionamento, se não for indicado, é contraindicado… em outros termos, se não ajudar, atrapalha, porque também consome recursos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
2013/8/20 Danilo Silva danilo.dsg.go...@gmail.com Em 5 de agosto de 2013 14:33, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 14:46, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Em 5 de agosto de 2013 12:10, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Pessoal, O banco cresceu!!! Cresceu para quanto? Nos dê uma ideia de valores. Atualmente está com 30 GiB. É muito pouco para medidas drásticas como particionamento. Por falta de recursos de hardware, Quais recursos de hardware estão faltando hoje? Espaço em disco? Desempenho em disco? Memória, CPU? Server com 12 GiB de Ram e HD de 1TB. É muito difícil saber se isto é suficiente. Uma vez que há o apache no mesmo servidor. Você também não disse ainda onde está o gargalo. Quando as consultas ficam lentas, qual recurso está no talo? Vamos ser mais práticos. No momento do pico, o processador fica como no top? A máquina faz swap? e a lentidão que está atrapalhando algumas rotinas, Quais rotinas? Como você faz o backup hoje? Único servidor que roda, além do postgres, replicação nativa, apache, php. O banco sofre muitos selects e inserts simultâneos. Além da replicação, é feito dump 4x aos dia, todos os dias. Dump 4x ao dia é algo muito ruim. Muito mesmo. Leia o post que recomendei antes Dump não é Backup. Ver artigo Dump não é backup: http://savepoint.blog.br/dump-nao-e-backup/ E também a palestra do Flávio no PGBR2011: Meu ambiente cresceu e eu não planejei. E agora? http://pgbr.postgresql.org.br/2011/palestras.php?id=53 foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. Você pensa em criar uma base histórica no mesmo servidor ou montar um novo servidor com a base histórica? Como disse anteriormente, não será fornecido um novo servidor para tal finalidade, portanto, deveremos efetuar no mesmo servidor. Existem várias alternativas para isso, como alguns comentaram uma delas é o particionamento. Mas particionamento está longe de ser algo simples. * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-como/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-automatizando/ O que é indicado/recomendado para este cenário? Você precisa dar mais detalhes sobre o seu cenário para podermos avaliar. Em todo caso, deixei aí algumas dicas que já podem lhe ajudar a pensar no assunto. Respondido? Ainda não. Você tem um longo caminho pela frente. 1) Rever completamente as rotinas de backup 2) Encontrar quais são os recursos que estão engargalando. 3) Encontrar quais consultas ficam lentas e se é possível otimiza-las. Se você não tem verba para ter um servidor separado para a aplicação e a base... então certamente não terá verba para contratar uma consultoria. Reserve uns trocados para estudar melhor o assunto. Para começar, bons livros sobre o assunto: http://www.packtpub.com/postgresql-90-high-performance/book http://www.packtpub.com/how-to-postgresql-backup-and-restore/book É possível efetuar o particionamento em tabelas já *populadas*? Pois tudo que li até agora somente falam sobre o particionamento começado do zero. Sim, é possível. Basta você montar o particionamento (adicionar as tabelas filhas - com constraints, índices, etc. - e as triggers) e, em seguida, mover os dados da pai para as filhas. Por exemplo, imagine um particionamento por mês/ano onde a pai chama foo e cada filha chama foo_anomes, para mover os dados já presentes: BEGIN; ... INSERT INTO foo_201306 SELECT * FROM foo WHERE bar BETWEEEN '2013-06-01' AND '2013-06-30'; INSERT INTO foo_201307 SELECT * FROM foo WHERE bar BETWEEEN '2013-07-01' AND '2013-07-31'; INSERT INTO foo_201308 SELECT * FROM foo WHERE bar BETWEEEN '2013-08-01' AND '2013-08-31'; ... TRUNCATE ONLY foo; COMMIT; Veja que isso foi feito em uma transação para evitar a visão de dados duplicados. Também recomendo fazer algumas consultas antes do truncate (um count(*) em cada tabela já é uma boa ideia) para verificar que não foi esquecida nenhuma partição. Outra forma que já vi pessoas usando é reinserir tudo na própria tabela, já que a trigger de particionamento cuidará de mover os dados para a partição correta: BEGIN; INSERT INTO foo SELECT * FROM foo; TRUNCATE ONLY foo; COMMIT; Apesar de funcionar bem, e talvez mais fácil, vai ser menos performático, mas isso vai depender da quantidade de dados. Por fim, lembre-se que não necessariamente a tabela pai deve ficar vazia, é possível manter dados na mesma,
Re: [pgbr-geral] Solução para backup
Como disse anteriormente, não será fornecido um novo servidor para tal finalidade, portanto, deveremos efetuar no mesmo servidor. Considere a possibilidade de convencer seus superiores em novas aquisições. Não se pode fazer milagres. A maioria dos SGBD exigem servidores dedicados. Além disso, você menciona anteriormente que está tirando dados do banco mas tem que deixá-los disponíveis para consultas. Vai colocar onde? Em uma nova instância no mesmo servidor? Acho que isso não vai resolver muito... Para lhe ajudar: Recentemente, após muitas tentativas de convencer os gestores de fazer uma nova aquisição (sem sucesso), tivemos uma parada de 2 horas em um dos equipamentos. Onde rodamos um sistema 24X7, onde as pessoas precisam do serviço para se manter vivos, 2 horas de parada podem representar muitos problemas, além de perdas humanas irreparáveis. Sorte a minha ter documentado todas as minhas solicitações, porque dessa forma, tive argumentos para justificar e conseguir o que precisava. Na pior das hipóteses você perde seu emprego mas não perde sua reputação. Att Carlos Antônio Pereira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
2013/8/20 carlosanto...@utivida.com.br: Considere a possibilidade de convencer seus superiores em novas aquisições. Mas sem diagnóstico da lentidão? Isso pode queimar filme… amiúde o problema é aplicação, e o servidor dedicado pode até aumentar a latência. Não se pode fazer milagres. A maioria dos SGBD exigem servidores dedicados. Não necessariamente. Além disso, você menciona anteriormente que está tirando dados do banco mas tem que deixá-los disponíveis para consultas. Vai colocar onde? Em uma nova instância no mesmo servidor? Acho que isso não vai resolver muito... Uma instância separada consumirá ainda mais recursos, de fato. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 20/08/2013 21:25, Guimarães Faria Corcete DUTRA escreveu: 2013/8/20 carlosanto...@utivida.com.br: Considere a possibilidade de convencer seus superiores em novas aquisições. Mas sem diagnóstico da lentidão? Isso pode queimar filme… amiúde o problema é aplicação, e o servidor dedicado pode até aumentar a latência. Tá certo. Deve ser melhor investigado. Acho que senti na pele o problema de verba... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 20 de agosto de 2013 20:40, carlosanto...@utivida.com.br escreveu: Em 20/08/2013 21:25, Guimarães Faria Corcete DUTRA escreveu: 2013/8/20 carlosanto...@utivida.com.br**: Considere a possibilidade de convencer seus superiores em novas aquisições. Mas sem diagnóstico da lentidão? Isso pode queimar filme… amiúde o problema é aplicação, e o servidor dedicado pode até aumentar a latência. Tá certo. Deve ser melhor investigado. Acho que senti na pele o problema de verba... Mais uma pulga atrás da orelha... Sobre a lentidão que comentei, também estava tendo em meu ambiente de desenvolvimento, que é o meu notebook, somente problema de lentidão, considerando que o ambiente estava em uma VM com 4 GiB de RAM, S.O linux, mais o apache e o banco tinha em torno de 7 GiB de tamanho, ou seja, não ocorria outros problemas. Recentemente formatei meu notebook e deixei o linux como S.O principal, agora continuo com o mesmo ambiente (banco, apache), porém, o notebook agora tem 6 GiB de RAM, e para minha surpresa, a lentidão não existe. Eu sei que se a gente efetuar um dump e subir novamente, vai subir um banco totalmente limpo (sem tuplas mortas) e etc, diminuindo até o tamanho do banco. Agora a dúvida: isso não seria facilmente resolvido executando vacuum full e até mesmo um reindex? ou estou enganado? []s 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] Solução para backup
2013/8/20 Danilo Silva danilo.dsg.go...@gmail.com: estava tendo em meu ambiente de desenvolvimento, que é o meu notebook, somente problema de lentidão, considerando que o ambiente estava em uma VM com 4 GiB de RAM, S.O linux, mais o apache e o banco tinha em torno de 7 GiB de tamanho, ou seja, não ocorria outros problemas. Recentemente formatei meu notebook e deixei o linux como S.O principal, agora continuo com o mesmo ambiente (banco, apache), porém, o notebook agora tem 6 GiB de RAM, e para minha surpresa, a lentidão não existe. 2 GiB de memória viva podem fazer muita diferença, mas suspeito que o principal seja a base direto numa máquina física. Virtualização em PC costuma ter E/S sofrível. Eu sei que se a gente efetuar um dump e subir novamente, vai subir um banco totalmente limpo (sem tuplas mortas) e etc, diminuindo até o tamanho do banco. Agora a dúvida: isso não seria facilmente resolvido executando vacuum full e até mesmo um reindex? ou estou enganado? Correto. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 20 de agosto de 2013 22:40, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2013/8/20 Danilo Silva danilo.dsg.go...@gmail.com: estava tendo em meu ambiente de desenvolvimento, que é o meu notebook, somente problema de lentidão, considerando que o ambiente estava em uma VM com 4 GiB de RAM, S.O linux, mais o apache e o banco tinha em torno de 7 GiB de tamanho, ou seja, não ocorria outros problemas. Recentemente formatei meu notebook e deixei o linux como S.O principal, agora continuo com o mesmo ambiente (banco, apache), porém, o notebook agora tem 6 GiB de RAM, e para minha surpresa, a lentidão não existe. 2 GiB de memória viva podem fazer muita diferença, mas suspeito que o principal seja a base direto numa máquina física. Virtualização em PC costuma ter E/S sofrível. Eu sei que se a gente efetuar um dump e subir novamente, vai subir um banco totalmente limpo (sem tuplas mortas) e etc, diminuindo até o tamanho do banco. Agora a dúvida: isso não seria facilmente resolvido executando vacuum full e até mesmo um reindex? ou estou enganado? Correto. Pois é, no servidor produção, que não está em VM e possui 12 GiB de ram, mesmo executando vacuum full, reindexdb, continuo tendo a lentidão. Acho até que estou com a minha memória (a da cabeça mesmo) corrompida, pois lembrei de alguns detalhes importantes: No servidor de produção, apesar do max_connections estar em 70, eu ainda não vi (a olho nú por assim dizer) esse número em conexões simultânea, mas a replicação nativa está ativa. Posso até ativar uma replicação no meu ambiente de desenvolvimento, mas como poderia simular as conexões simultâneas, não só as conexões mas as transações também? []s 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] Solução para backup
Bom dia! Se você precisa de menos dados, reduzir o montante de dados armazenados excluindo dados antigos é uma boa ideia. Mas me parece que os mesmos dados continuarão existindo, em outras tabelas, para consulta. Neste caso, o ganho será menor. pois não se ganhará espaço em disco. Mas haverá ganho pois as consultas aos dados dos últimos meses serão mais rápidas. Se você não puder apagar todos os dados históricos, tente colocar no histórico de dados anteriores a três meses apenas as colunas realmente necessárias, eliminando as demais. Reveja também as configurações de log do banco de dados, para liberar algum espaço. Mas se a necessidade é de hardware mesmo, não dá pra fugir de uma nova aquisição de disco, memória e processadores em breve. Cordialmente, Cláudio Leopoldino postgresqlbr.blogspot.com/ = De: Danilo Silva danilo.dsg.go...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Segunda-feira, 5 de Agosto de 2013 2:06 Assunto: [pgbr-geral] Solução para backup Pessoal, O banco cresceu!!! Por falta de recursos de hardware, e a lentidão que está atrapalhando algumas rotinas, foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. O que é indicado/recomendado para este cenário? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Particionamento... dá uma olhada nesta feature... partitioning. funciona muito bem, e vc mantem os dados online, desde que habilite constraint_exclusion e faça os indices corretamente. Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.comescreveu: Pessoal, O banco cresceu!!! Por falta de recursos de hardware, e a lentidão que está atrapalhando algumas rotinas, foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. O que é indicado/recomendado para este cenário? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att, -- Marco Andrade Celular: (21)8178-5201 - Tim Skype: marco.antonio.dandrade ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Pessoal, O banco cresceu!!! Cresceu para quanto? Nos dê uma ideia de valores. Por falta de recursos de hardware, Quais recursos de hardware estão faltando hoje? Espaço em disco? Desempenho em disco? Memória, CPU? e a lentidão que está atrapalhando algumas rotinas, Quais rotinas? Como você faz o backup hoje? Ver artigo Dump não é backup: http://savepoint.blog.br/dump-nao-e-backup/ E também a palestra do Flávio no PGBR2011: Meu ambiente cresceu e eu não planejei. E agora? http://pgbr.postgresql.org.br/2011/palestras.php?id=53 foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. Você pensa em criar uma base histórica no mesmo servidor ou montar um novo servidor com a base histórica? Existem várias alternativas para isso, como alguns comentaram uma delas é o particionamento. Mas particionamento está longe de ser algo simples. * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-como/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-automatizando/ O que é indicado/recomendado para este cenário? Você precisa dar mais detalhes sobre o seu cenário para podermos avaliar. Em todo caso, deixei aí algumas dicas que já podem lhe ajudar a pensar no assunto. []s -- Atenciosamente, Fábio Telles Rodriguez blog: http://savepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 5 de agosto de 2013 12:10, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Pessoal, O banco cresceu!!! Cresceu para quanto? Nos dê uma ideia de valores. Atualmente está com 30 GiB. Por falta de recursos de hardware, Quais recursos de hardware estão faltando hoje? Espaço em disco? Desempenho em disco? Memória, CPU? Server com 12 GiB de Ram e HD de 1TB. e a lentidão que está atrapalhando algumas rotinas, Quais rotinas? Como você faz o backup hoje? Único servidor que roda, além do postgres, replicação nativa, apache, php. O banco sofre muitos selects e inserts simultâneos. Além da replicação, é feito dump 4x aos dia, todos os dias. Ver artigo Dump não é backup: http://savepoint.blog.br/dump-nao-e-backup/ E também a palestra do Flávio no PGBR2011: Meu ambiente cresceu e eu não planejei. E agora? http://pgbr.postgresql.org.br/2011/palestras.php?id=53 foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. Você pensa em criar uma base histórica no mesmo servidor ou montar um novo servidor com a base histórica? Como disse anteriormente, não será fornecido um novo servidor para tal finalidade, portanto, deveremos efetuar no mesmo servidor. Existem várias alternativas para isso, como alguns comentaram uma delas é o particionamento. Mas particionamento está longe de ser algo simples. * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-como/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-automatizando/ O que é indicado/recomendado para este cenário? Você precisa dar mais detalhes sobre o seu cenário para podermos avaliar. Em todo caso, deixei aí algumas dicas que já podem lhe ajudar a pensar no assunto. Respondido? []s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
2013/8/5 Danilo Silva danilo.dsg.go...@gmail.com Você precisa dar mais detalhes sobre o seu cenário para podermos avaliar. Em todo caso, deixei aí algumas dicas que já podem lhe ajudar a pensar no assunto. Respondido? Danilo, as estatísticas estão atualizadas? O AutoVacuum está ocorrendo normalmente? Desculpa mas 30GiB de base não é esse volume todo. Como estão configurações como shared_buffers, work_mem, etc... ? Você acompanha as consultas ou uso de recursos do seu banco? Te aconselho usar o pgfouine ou o pgBadger ( recomendo ) para te auxiliarem nisso. Bruno E. A. Silva. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 5 de agosto de 2013 14:46, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Em 5 de agosto de 2013 12:10, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Pessoal, O banco cresceu!!! Cresceu para quanto? Nos dê uma ideia de valores. Atualmente está com 30 GiB. É muito pouco para medidas drásticas como particionamento. Por falta de recursos de hardware, Quais recursos de hardware estão faltando hoje? Espaço em disco? Desempenho em disco? Memória, CPU? Server com 12 GiB de Ram e HD de 1TB. É muito difícil saber se isto é suficiente. Uma vez que há o apache no mesmo servidor. Você também não disse ainda onde está o gargalo. Quando as consultas ficam lentas, qual recurso está no talo? Vamos ser mais práticos. No momento do pico, o processador fica como no top? A máquina faz swap? e a lentidão que está atrapalhando algumas rotinas, Quais rotinas? Como você faz o backup hoje? Único servidor que roda, além do postgres, replicação nativa, apache, php. O banco sofre muitos selects e inserts simultâneos. Além da replicação, é feito dump 4x aos dia, todos os dias. Dump 4x ao dia é algo muito ruim. Muito mesmo. Leia o post que recomendei antes Dump não é Backup. Ver artigo Dump não é backup: http://savepoint.blog.br/dump-nao-e-backup/ E também a palestra do Flávio no PGBR2011: Meu ambiente cresceu e eu não planejei. E agora? http://pgbr.postgresql.org.br/2011/palestras.php?id=53 foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. Você pensa em criar uma base histórica no mesmo servidor ou montar um novo servidor com a base histórica? Como disse anteriormente, não será fornecido um novo servidor para tal finalidade, portanto, deveremos efetuar no mesmo servidor. Existem várias alternativas para isso, como alguns comentaram uma delas é o particionamento. Mas particionamento está longe de ser algo simples. * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-como/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-automatizando/ O que é indicado/recomendado para este cenário? Você precisa dar mais detalhes sobre o seu cenário para podermos avaliar. Em todo caso, deixei aí algumas dicas que já podem lhe ajudar a pensar no assunto. Respondido? Ainda não. Você tem um longo caminho pela frente. 1) Rever completamente as rotinas de backup 2) Encontrar quais são os recursos que estão engargalando. 3) Encontrar quais consultas ficam lentas e se é possível otimiza-las. Se você não tem verba para ter um servidor separado para a aplicação e a base... então certamente não terá verba para contratar uma consultoria. Reserve uns trocados para estudar melhor o assunto. Para começar, bons livros sobre o assunto: http://www.packtpub.com/postgresql-90-high-performance/book http://www.packtpub.com/how-to-postgresql-backup-and-restore/book -- Atenciosamente, Fábio Telles Rodriguez blog: http://savepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Solução para backup
Pessoal, O banco cresceu!!! Por falta de recursos de hardware, e a lentidão que está atrapalhando algumas rotinas, foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. O que é indicado/recomendado para este cenário? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
