Suporte remoto ao Postgres
16 de Maio de 2013, 0:00 - sem comentários aindaEste artigo foi escrito por telles
É sabido que contratar um DBA Sênior em período integral não é algo que pequenas e medias empresas podem arcar com facilidade. É bem comum encontrar empresas com mais de 100 funcionários e uma equipe de TI com 2 pessoas: um chefe e um estagiário. Também é bem comum boa parte das operações desta empresas estarem rodando num ERP ou outra aplicação vital para a empresa. E quem cuida do banco de dados? O fornecedor do ERP? O estagiário? Deus? Seja como for, acender uma vela dentro do CPD não parece ser uma boa ideia. A maioria das empresas que tem uma equipe pequena de TI acaba terceirizando alguns serviços críticos, o DBA é um deles.
Durma tranquilo
Ter um bom DBA por perto quando precisa é saber que na hora do desastre sua base vai ser restaurada. O restore não apenas vai funcionar como vai ocorrer num intervalo de tempo mínimo e com uma perda de dados mínima. Ter um bom DBA é poder prever quando vai precisar de mais storage ou quando cutucar o desenvolvedor para ajustar alguma coisa na aplicação. Eu trabalhei alguns anos dando suporte à ambientes Oracle remotamente e presencialmente. É um mercado já bem conhecido e com muitas empresas que oferecem este tipo de serviço. Lá eu aprendi como estruturar o trabalho e organizar as rotinas de forma a poder se conectar num cliente remotamente com segurança e velocidade na resolução de problemas. Muitas vezes nós resolvíamos o problema antes do cliente perceber que ele existia. Você trabalha como uma eminência parda, que poucos sabem que existem… quando o ambiente de banco de dados deixa de ser uma preocupação, os outros membros da equipe estão se preocupando com outras coisas, como ficar de olho na aplicação. E claro, o DBA vai ajudar bastante a equipe nisso.
Os planos de suporte da Timbira
Na Timbira nós trabalhamos com este tipo de serviço há mais de 3 anos. Neste período conseguimos automatizar as tarefas tediosas e repetitivas (geralmente sujeitas a erros) e configurar um ambiente bem padronizado que agilize o nosso trabalho. Com isso a qualidade do atendimento aumentou e o nosso custo caiu. Hoje temos 4 planos distintos para atender diferentes públicos:
- O plano básico é destinado a ambientes pequenos e médios com um custo mínimo. Ele inclui duas visitas de manutenção preventiva por mês e ainda inclui até 4 horas de chamados avulsos. Este plano cobre toda a parte de backup e manutenções periódicos, verificação de logs, ajustes de desempenho no postgres e SO e coisas do tipo e ainda deixa uma sobra para solicitações ad hoc do cliente;
- O plano padrão é semelhante ao plano básico com uma grande diferença: ele inclui a instalação de uma ferramenta desenvolvida pela Timbira para o monitoramento remoto. Com isto nós podemos atuar antes de um potencial problema acontecer;
- O plano avançado tem as facilidades do plano padrão mas vai bem além… ele inclui o uso de stand by, ferramentas de replicação e outras ferramentas. É destinada a ambientes mais complexos e que precisam de um uptime maior.
- O plano guru é completamente diferente. Não se destina a ambientes de produção. Se destina a equipes de desenvolvimento. A ideia aqui é ter um consultor de plantão para poder indicar o melhor caminho em situações mais complexas de desenvolvimento, seja na modelagem, SQL puro, PL/pgSQL, arquitetura de banco de dados, etc. Com isso, seus desenvolvedores sempre tem uma referência segura para construir uma aplicação mais eficiente;
Garantia de correção de bugs
Tem gente que ainda vive repetindo que precisa comprar o banco de dados da empresa X ou Y por causa da garantia. A garantia de correção de bugs é algo realmente importante para quem vê a vida da empresa rodando sobre um banco de dados. Bom, com software livre a situação é bem mais tranquila. Existem várias empresas no mundo que garantem a correção de bugs no Postgres. E no Brasil, nós fazemos exatamente isto na Timbira. E claro: isso vem escrito em contrato. Se você tiver um bug crítico, a Timbira garante que consegue uma correção para o problema em até 24h. A receita é simples: ter desenvolvedores do postgres na nossa equipe. E a grande vantagem é que você não precisa contratar a Timbira só para ter este tipo de proteção. Se você não gostar da gente, você pode contratar qualquer uma das ótimas empresas ao redor do mundo que também oferecem este tipo de suporte. No final, você só fica conosco se realmente estiver satisfeito. Esta é a beleza do software livre: remunerar o talento, competência e esforço de que trabalha bem.
Hoje eu posso dizer que são os contratos de suporte da Timbira que tem garantido um crescimento seguro e a possibilidade de nos lançar a novos desafios. Acho que depois das nossas “cursotorias“, os planos de suporte são o trabalho do qual eu mais me orgulho na Timbira.
O artigo Suporte remoto ao Postgres apareceu primeiro em Savepoint.
Bons motivos para ir ao PGBR2013
28 de Abril de 2013, 0:00 - sem comentários aindaEste artigo foi escrito por telles
O PGBR2013 é a 5ª edição da Conferência Brasileira de PostgreSQL. Esta edição será muito especial pois será a primeira a ser realizada fora do estado de São Paulo. O nosso Big Kahuna, Luis Fernando Bueno é famoso por organizar verdadeiras maratonas de PGDays em Rondônia, trazendo muitos palestrantes conhecidos para lá.
Eu já tive a oportunidade de palestrar em vários eventos no Brasil e confesso que uma das experiências mais bacanas para mim foram os PGDays de Rondônia em 2009. E hoje gostaria de contar alguns dos motivos para você ir ao PGBR de 2013:
- O PGBR em si é o maior evento de PostgreSQL do Brasil e já foi considerado por alguns como o maior do mundo. Palestrantes de alto nível do Brasil e do mundo, usuários e desenvolvedores de todo o país e uma grade bem balanceada garantiram o sucesso das 4 edições anteriores que começou como uma reunião de entusiastas e hoje é reconhecido como um evento de alto nível técnico.
- Visitar lugares diferentes é sempre um prazer. Eu tive a oportunidade de passear um pouco em Porto Velho e em Ji Paraná e curti muito. Quem puder ficar um dia a mais não pode deixar de conhecer as ruínas da antiga Estrada de Ferro Madeira Mamoré e o maravilhoso passeio de barco pelo Rio Madeira com destaque para a Usina Hidrelétrica Santo Antônio, para as comunidades ribeirinhas com casas de palafita e claro, uma boa cerveja à bordo.
- Tomar um chope à noite com a turma e experimentar um dos maravilhosos peixes da região. O Dourado na brasa é imperdível. Destaque também para a famosa pimenta da murupi da Amazônia.
- Conhecer o projeto de monitoramento da Amazônia Legal o SIPAM, que usa PostGIS.
- Para quem tiver um pouco mais de tempo, espírito de aventura e uns trocados, existem agências de turismos que fazem passeios na floresta amazônica também…
Esta é a última semana da chamada de trabalhos do PGBR2013. A chamada se encerra no dia 03/05/2013. E como o prazo está apertado, este ano não teremos prorrogação. Então perca tempo e faça sua inscrição já. Em geral eu sempre cadastro umas 2 ou 3 propostas, o que aumenta a chance de ser escolhido e permite a banca descartar temas repetidos e fazer uma grade mais equilibrada. Para quem pretende ir mas não quer palestrar, os dados de hospedagem e inscrições já estão no site do evento.
O artigo Bons motivos para ir ao PGBR2013 apareceu primeiro em Savepoint.
Palestra nova no FLISOL 2013 em Santo André
23 de Abril de 2013, 0:00 - sem comentários aindaEste artigo foi escrito por telles
Todo ano rola o Festival Latino Americano de Instalação de Software Livre este ano não será diferente, a data é 27/04. Eu participei de alguns nos tempos de PSL-ABCD. Este ano me novamente. A brincadeira vai rolar em vários lugares, eu vou estar em Santo André na Universidade Federal do ABC, na Rua Santa Adélia.
O título da minha palestra será “Vivendo e sobrevivendo de Software Livre”. A ideia é dar um panorama sobre o mercado de trabalho para as pessoas que estão entrando neste universo. Como o público alvo é mais iniciante, resolvi pegar um tema mais genérico, mas que deve dar bastante polêmica também….
Encontro vocês por lá.
O artigo Palestra nova no FLISOL 2013 em Santo André apareceu primeiro em Savepoint.
Livro sobre Backup em PostgreSQL
22 de Abril de 2013, 0:00 - sem comentários aindaEste artigo foi escrito por telles
Eu ando meio bravo com a PACKT Pub, pois o livro que eu comprei em Janeiro na pré-venda estava prometido para fevereiro. Aí eles mudaram para março e agora está previsto para junho.
Mas… eles lançaram um e-book sobre backup e restore por 5 dólares. Eu comprei o livro e achei bem bacana. O livro cobre o pg_dump, pg_dumpall, backup físico, stand by com log shipping e o stream replication. E o mais importante de tudo, fala sobre restore, que é uma das coisas mais importantes que um DBA deve conhecer, e bem.
Por enquanto só dei uma folheada no livro. Mas para qualquer um que lida com Backups de ambientes de produção e pode ter com um Disaster Recover… pode ser uma boa companhia. Acho que vale os 5 dólares fácil.
O artigo Livro sobre Backup em PostgreSQL apareceu primeiro em Savepoint.
Zerando Large Objects numa base PostgreSQL
19 de Abril de 2013, 0:00 - sem comentários aindaEste artigo foi escrito por telles
Se tem uma coisa que eu realmente não recomendo é sair guardando zilhões de imagens dentro do banco de dados. Uma vez ou outra vá lá… se as imagens forem poucas e pequenas. Bom, mas sabe aquela coisa desenvolvida há décadas, com zilhões de otimizações, pesquisas e intermináveis discussões para se chegar num produto ótimo chamado Sistema de Arquivos? Então, por algum motivo bizarro algumas pessoas realmente acham que o seu banco de dados é um lugar melhor que o Sistema de arquivos para guardar…. arquivos!
Bom, estes dias eu precisei lidar com um destes sistemas “inteligentes”, desenvolvido por pessoas realmente “inteligentes” que guarda milhões de imagens no pobre do PostgreSQL. Não se engane, se fosse no Oracle ou no SQL Server, você estaria no sal do mesmo jeito. Em determinado momento, o sistema que estava em fase de rollout precisou parar tudo e começar de novo. Na verdade eu estou adiantando um pouco a história. Houveram capítulos de terror antes. Eles utilizam os Large Objects e excluem as linhas das tabelas e esquecem de apagar os arquivos da tabela pg_largeobjects. A solução seria rodar o vacuumlo, que faz este tipo de limpeza para nós. Veja a situação:
- A base tem uns 150GB;
- 1GB de dados em tabelas normais;
- Aproximadamente 75 milhões de arquivos na pg_largeobjects em 149GB;
- Previsão de excluir 80% dos arquivos, ou seja: 60 milhões de arquivos em 119GB.
Resultado: rodamos o vacuumlo por 12 horas e…. continuou rodando….
Bom, como todo mundo tem chefe a nova solicitação seria zerar TODOS os arquivos, e rápido. Claro, um TRUNCATE é muito mais fácil que um DELETE. Ops, Large Object não faz DELETE. Para remover um arquivo do tipo Large Object você tem de fazer um lo_unlink.
Ok, você poderia pensar que agora é só dar um simples TRUNCATE na tabela pg_largeobjects e tudo estaria resolvido, certo? Então veja isso:
teste=# TRUNCATE pg_largeobject; ERROR: permission denied: "pg_largeobject" is a system catalog
Ah… claro, não é possível sair truncando tabelas de sistema assim numa boa. Bom, existe um jeitinho de se fazer isso. Você pode inicializar o postgres com o parâmetro allow_system_table_mods = TRUE no postgresql.conf. Claro, você tem de reiniciar o postgres para fazer isso.
teste=# TRUNCATE pg_largeobject; TRUNCATE TABLE teste=# SELECT * from pg_largeobject; loid | pageno | data ------+--------+------ (0 rows)
Depois disso, melhor você remover o parâmetro do seu postgresql.conf e reiniciar o servidor novamente. Mas…. um requisito importante apareceu. Eu não poderia reiniciar o Postgres. Outra base no mesmo cluster estava em produção… e a próxima janela para reiniciar o Postgres estava muito longe, isto poderia atrasar todo o projeto em uma semana. Qual foi a solução? Usar o velho e bom pg_dump. A questão é que se você especificar tabelas e/ou esquemas no seu dump (--schema ou --table), o nosso amigo pg_dump NÃO traz os dados da pg_largeobjects. Como os dados representam apenas 1GB, a solução foi considerada rápida o suficiente para nós:
# Gerar dump sem os Large Objects pg_dump -Fc -n public teste > teste_sem_lo.dmp # Apagar base do SQN dropdb teste # Recriar a base zerada createdb teste # Importar a base novamente pg_restore -d teste teste_sem_lo.dmp # Entrar no psql psql teste
Encontrando as tabelas que referenciam Large Objects
Isto realmente funcionou bem. Agora faltava truncar as tabelas que usam OID ou LO, que são as colunas que apontam para os nossos Large Objects. Para descobrir quais são estas tabelas, este SELECT pode lhe ajudar:
SELECT nspname AS esquema, relname AS tabela, attname AS coluna
FROM
pg_type t
JOIN pg_attribute a ON a.atttypid = t.oid
JOIN pg_class c ON a.attrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
typname IN ('oid','lo') AND
attname NOT IN ('oid', 'tableoid') AND
nspname NOT IN ('pg_catalog', 'pg_toast', 'information_schema');Segue um exemplo do que você pode encontrar. Primeiro vamos adicionar algumas tabelas contendo OID e LO:
CREATE TABLE teste_lo (aaa varchar, bbb oid, ccc lo); CREATE TABLE teste2_lo (aaa varchar, ccc lo); CREATE TABLE teste3_lo (aaa varchar, bbb oid);
Depois vemos o resultado da consulta:
esquema | tabela | coluna ---------+-----------+---------- public | teste_lo | bbb public | teste_lo | ccc public | teste_lo2 | ccc public | teste_lo3 | bbb (7 rows)
Com isso em mãos, fizemos um TRUNCATE nas tabelas restantes e zeramos finalmente todas os arquivos binários e suas referências na base.
O artigo Zerando Large Objects numa base PostgreSQL apareceu primeiro em Savepoint.
