Chega o final do ano e todos mandam seus cartões de natal, e-mails com executáveis suspeitos (que não abrem no Linux ) e desejam aquele kit felicidade com natal, ano novo, páscoa, carnaval, fada dos dentes, etc. Também é época de balanço de fim de ano, promessas para o ano que vem, etc.

Bom, não gostaria de falar de mim no momento, gostaria de falar sobre como foi a minha sensação e o que eu espero para o ano que vem na comunidade PostgreSQL Brasileira.

Balanço 2007

Este ano foi sem dúvida um marco histórico na comunidade que já vem crescendo há algum tempo. O crescimento da comunidade de Software Livre como um todo, tem favorecido muito o PostgreSQL que é visto como uma solução livre robusta para ambientes corporativos. Os desenvolvedores tem feito um trabalho fantástico agregando um desempenho crescente e funcionalidades dignas dos maiores competidores do mercado. Mas foi o porte nativo para Windows que fez a comunidade brasileira dar um salto em 2004.

Hoje é difícil haver um grande evento de Software Livre sem uma palestra de PostgreSQL. O FISL costuma ter pelo menos uma meia dúzia de excelentes palestras. Em 2006 o PostgreSQL contou com um stand próprio no CONISLI e em 2007 um stand no FISL.

A participação no FISL de 2007 teve algumas conseqüências importantes. O pessoal da comunidade decidiu se organizar um pouco e tiraram algumas resoluções:

• Se associar a ASL. A associação junto a ASL ficou por conta dos nossos desenvolvedores nacionais (Euler e Diogo) e nos permitirá ter mais autonomia e transparência no trato com doações e patrocínio. Junto a ASLa comunidade PostgreSQL tem uma conta no banco e pode emitir recibos e realizar gastos para viabilizar projetos da comunidade.
• Unificar todas as listas de discussão no domínio da própria comunidade ( http://listas.postgresql.org.br/ ). Não foi uma tarefa simples, no começo muita gente chiou um pouco… mas logo a lista tomou seu rumo natural e as discussões estão cada dia mais interessantes. Tivemos assuntos com mais de 100 e-mails com ótimo nível de discussão.
• Realizar o primeiro evento só de PostgreSQL no Brasil. Parece incrível mas deu certo! Nos dias 7 e 8 de dezembro o PostgreSQL Conference Brasil 2007 aconteceu em grande estilo. Muita gente organizando, alguns erros e muitos acertos. Ficou com um excelente gosto de quero mais. Só para se ter uma idéia, vou colocar alguns números dos participantes que se inscreveram normalmente para o evento (não inclui organizadores, palestrantes e patrocinadores):
  • Tivemos a seguinte distribuição por estado:
    • 7 de Brasília
    • 3 de Goiás
    • 1 de Roraima
    • 11 de Minas Gerais
    • 16 do Rio de Janeiro
    • 113 de São Paulo
    • 17 do Paraná
    • 9 de Santa Catarina
    • 6 do Rio Grande do Sul
  • Por tipo de cargo, tivemos:
    • 9 Administradores de Sistema / Rede
    • 84 Analistas de Sistema / Desenvolvedores / Programadores
    • 42 Coordenadores, gerentes, diretores ou sócios
    • 16 DBAs
    • 8 Área de projetos
    • 3 Suporte
    • 21 Outros
• Montar um site novo com um CMS que use PostgreSQL (foi escolhido o Drupal). Esta ação começou a pouco, graças aos esforços do Ribamar Sousa que provocou o pessoal na lista e tomou a iniciativa. Não sei se vamos terminar de arrumar o portal antes do final do ano, mas certamente já estaremos com as coisas bem encaminhadas.

Idéias para 2008

Realmente não foi pouca coisa. Deu muito trabalho tudo isso. No entanto, melhor que 2007 são as perspectivas para 2008. Não há nada oficial por enquanto… não há um plano definido, mas há idéias no ar. Algumas coisas que direi aqui são fruto do meu delírio pessoal, outras são coisas que são praticamente certas de que irão ocorrer.

• Consolidar o novo site com Drupal em www.postgresql.org.br . Com o novo portal, creio que poderemos fazer algumas coisas novas, como um newsletter, banners de patrocinadores, busca textual etc;
• Mais artigos em pt_BR sobre PostgreSQL. Com o novo portal deveremos ter mais gente escrevendo sobre PostgreSQL. Muitos já se disponibilizaram a ajudar.
• Um planeta PostgreSQL em pt_BR. Já temos um número considerável de pessoas escrevendo sobre PostgreSQL. Após uma discussão na lista, parece que teremos muitos novos blogueiros falando sobre PostgreSQL;
• Um PostgreSQL Weekly News em pt_BR. Já houve uma tentativa de traduzir o PWN no final do ano passado, mas faltou fôlego para dar conta do trabalho. Outra coisa que poderia ser feito é publicar o PWN pt_BR no site e numa lista separada só para isto;
• Traduções, muitas traduções. Há um trabalho enorme de tradução para ser feito: documentação oficial, mensagens de erro, PGAdmin3, etc. Organizar isso não é fácil, mas acredito que no ano que vem teremos mais gente ajudando nisso;
• Maior aproximação com as universidades. Soluções como o Tamanduá da UFMG e o Pargres da UFRJ precisam ter alguma ligação com o PostgreSQL internacional. Precisamos servir como ponte entre as universidades e o PGDG.
• Uma lista de provedores de hospedagem com PostgreSQL no Brasil. Este é um trabalho complicado, mas um dia alguém via começar! Tive a idéia de montar uma tabela inicial e pedir para as pessoas ajudarem a completar as lacunas. Pode ser uma iniciativa interessante;
• Mais casos de Sucesso. Fiquei pensando numa forma de publicar melhor alguns casos de sucesso. Tem muita gente usando o PostgreSQL e poucos divulgam isso. Precisamos melhorar esta parte. Fracassei miseravelmente na tentativa de fazer isso neste ano, mas creio que em breve conseguiremos coisa melhor. Já estou com algumas idéias
• PGCon Brasil 2008! Sim, é quase certo que ocorrerá entre agosto e setembro de 2008 em São Paulo. Ainda temos que começar a organizar isto, mas pela empolgação de quem foi, deveremos ter mais patrocinadores, o que significa melhores condições, por explo para trazer mais palestrantes internacionais. Creio que o formato deva ser o mesmo, pois de certo: dois dias de evento numa Sexta e Sábado. Uma sugestão que eu achei interessante, é a de fazer o evento num hotel. Apesar da maioria das pessoas serem de SP, apenas 25% dos participantes moram na cidade de São Paulo e imediações. Isto facilitaria muito o entrosamento dos participantes e simplifica muito o deslocamento. Creio também que deverão haver um número maior de propostas de trabalho, o que elevará o nível do evento. Por fim podemos precisar de um auditório maior…

E por que não… sonhar com 2009!

Em 2009 eu espero que tenhamos uma comunidade mais amadurecida. Se conseguirmos realizar a maior parte do que escrevi aqui em 2008, em 2009 estaremos colhendo frutos interessantes como:

• Maior demanda por DBAs PostgreSQL no mercado;
• Maior número de Empresas que dêem suporte e formação em PostgreSQL;
• Ter a Documentação Oficial completa traduzida para pt_BR;
• Ter um maior número de desenvolvedores contribuindo com código no PostgreSQL e seus derivados no PgFoudry;
• Ter eventos menores (provavelmente de 1 dia) em outros locais além de São Paulo, como DF e Nordeste;
• Mandar um desenvolvedor brasileiro para o PgCon internacional. Acho que temos muita coisa interessante por aqui… precisamos ir lá fora mostrar o nosso trabalho também. Eu achava que seria um exagero… mas o Sr. David Fetter me deu um puxão de orelha e me convenceu da importância que temos.

Bom… por enquanto é melhor eu parar de delirar um pouco e arregaçar as mangas. Afinal, 2008 já está aí!!!

Todo DBA um dia vai se deparar com esta situação. Um colega na lista chegou nesta situação e perguntou o que fazer.

Antes de comprar um novo disco:

Vejamos o que podemos fazer antes de sair correndo para colocar um novo disco.

VACUUM

Antes de mais nada, você deve rodar um VACUUM FULL no se banco de dados para reclamar o espaço em disco desperdiçado. Rodar um VACUUM deve ser rotina no PostgreSQL, se você não o faz… terá uma boa surpresa quando finalmente o rodar.

WAL

De qualquer forma, se você já sabe que o espaço ocupado pelo PostgreSQL já está bem comportado, está na ora de olhar para outros possível comedores de espaço em disco: os logs! Se você está num ambiente de produção, você deveria estar arquivando os logs do WAL em algum lugar. Se você tem o hábito de fazer backup físico on-line, faça um off-line e guarde todos os seus logs arquivados em fita. O backup off-line permite que você não precise de nenhum log arquivado com data anterior ao backup para restaurar o banco. Outros logs, como logs do PostgreSQL também podem ocupar muito espaço. Vale a pena guardar os mais antigos em outro lugar. Para saber onde ficam os seus logs, verifique a configuração do seu arquivo ‘postgresql.conf’.

Tabelas de Histórico

Este é o limite da economia que você pode chegar. Procure por tabelas que guarde informações de auditoria ou dados históricos não utilizados e faça um backup destes dados. Depois simplesmente exclua os registros. Particionar este tipo de tabela costuma ser uma boa idéia, uma vez que lhe permite agilizar o processo de apagar registros antigos utilizando o TRUNCATE na partição da tabela. Também fica mais simples fazer o bakcup antes de apagar os registros.

Adicionando um novo disco:

Bom, você fez o possível para economizar alguns gigabytes enquanto o seu disco novo não chegava, mas chegou a hora acrescentar um novo disco. Nunca espere seus discos chegarem a mais de 80% de capacidade de armazenamento para adicionar um novo disco. Faça o possível e o impossível para acrescentar o novo disco ANTES de acabar o espaço com uma margem se segurança de 20%. Outra coisa importante é acompanhar o crescimento da base, saber qual é a taxa de crescimento esperada e real ano a ano é fundamental para permitir um planejamento seguro para aquisição de novos discos. Enquanto um novo disco SCSI comum pode custar pouco (cerca de uns R$2000), montar um novo RAID com discos de 15Krpm num Storage Fiber Channel pode custar 100 vezes mais que isso. De qualquer forma, uma vez que o disco foi instalado fisicamente (discos Hot Swap são uma benção nestas horas) e lógicamente (com o suas partições de sistemas de arquivos), chega a hora de você alocar os seus dados. Se você adicionou um novo disco em um RAID ou LVM, tudo será transparente para o seu banco de dados e surgirá mais espaço em disco livre pronto para ser utilizado. No entanto, se você estiver realmente criando novas partições, você pode simplesmente passar a alocar novos objetos em novos Tablespaces criados nas novas partições. Se você está pretendendo colocar um novo sistema no mesmo banco de dados, esta é uma opção viável. Para sistemas já existentes, isto não funcionará, pois as tabelas e índices já se encontram alocados em um Tablespace existente.

Este é um momento oportuno para uma redistribuição dos Tablespaces entre os discos. Uma boa distribuição dos Tablespaces através dos discos deve simplificar o gerenciamento do espaço livre. Ao mesmo tempo, deve paralelizar ao máximo o uso dos discos, aumentando a velocidade geral no acesso. Existem duas formas básicas de mover dados para uma nova partição, pelo SO ou pelo PostgreSQL. Seja qual for a sua abordagem, lembre-se de antes de iniciar o seu procedimento desconectar todos os seus usuários do PostgreSQL e tirar uma cópia de segurança. Você pode desconectar seus usuários simplesmente desligando o cabo de rede do servidor. Eu realmente não recomendo isso, além de ser perigoso (no caso de uma fibra ótica, nunca faça isso) trabalhar na temperatura do ar condicionado do CPD não é tão agradável. Faça um bem para si mesmo, crie um novo arquivo pg_hba.conf que só permita conexões locais e faça a recarga (um ‘reload’) dos arquivos de configuração do PostgreSQL utilizando este arquivo.

Movendo Tablespaces via Sistema Oparacional:

1. Crie as partições no novo disco;
2. Desconecte todos os usuários (alterando o pg_hba.conf por exemplo);
3. Faça um backup completo de toda a base;
4. Baixe o PostgreSQL;
5. Monte a nova partição do novo disco para um ponto de montagem provisório;
6. Copie o Tablespace a ser movido para a nova partição (tenha certeza de que o PostgreSQL não está rodando antes)
7. Apague todo o conteúdo na pasta original do Tablespace (certifique-se que a cópia foi realizada com sucesso e que o backup também foi realizado antes);
8. Desmonte a partição nova do ponto provisório e monte no lugar do Tablespace correto. Em *nix isso é muito simples, no Windows também é possível mas é um pouco menos transparente;
9. Suba novamente o PostgreSQL;
10. Teste os dados no novo Tablespace;
11. Restaure o acesso aos usuários;

É claro que você precisará de um pouco de conhecimento sobre sistemas de arquivos para ter sucesso. É função de todo DBA conhecer este lado do SO.Este procedimento, apesar de parecer complexo, é bastante rápido. Se você tem Tablespace já segmentadas por sistema ou tipo de carga será mais fácil utilizar este tipo de abordagem. Se você utiliza apenas os Tablespaces padrões do PostgreSQL, será necessário utilizar o procedimento a seguir.

Movendo tabelas e índices entre Tablespaces via PostgreSQL:

1. Crie as partições no novo disco;
2. Monte as novas partições em pontos de montagem adequados para
   receber os novos Tablespaces;
3. Desconecte todos os usuários (alterando o pg_hba.conf por exemplo);
4. Faça um backup completo de toda a base;
5. Crie novos Tablespaces nas novas partições com o comando CREATE TABLESPACE;
6. Utilize os comandos ALTER TABLE e ALTER INDEX com a opção SET
   TABLESPACE para mover tabelas e índices para os novos Tablespaces;
7. Teste os dados no novo Tablespace;
8. Restaure o acesso aos usuários;

Este procedimento é um pouco mais trabalhoso, pois exige que você indique tabela por tabela e índice por índice em qual Tablespace eles deverão ficar. No entanto, é a opção mais flexível, permitindo um ajuste de desempenho mais fino.

Bom, depois de escrever meu “breve” relato sobre o PgCon Brasil 2007 descobri mais alguns e o pessoal montou uma lista de relatos em outros blogs. Se você publicou um relato e ele não se encontra la lista… não se intimide, acrescente-o.

Outra coisa bacana é que os slides das palestras já estão on-line. As fotos ainda não foram publicadas… tenho algumas aqui que foram tiradas pela câmera do Euler e do Dutra.

Bom… por enquanto é só pessoal.

Tanto para dizer e tão pouco tempo para escrever. Em poucas palavras eu diria que o PgConBrasil 2007 foi como um todo bom evento de PostgreSQL merece: Inesquecível! Depois de tantos trocadilhos infames durante o evento, eu não poderia deixar este passar.

Não vou comentar agora os detalhes de como foi o evento, mas quero apenas registrar algumas sensações. A primeira coisa é a de que erramos em inúmeras coisas. Mas os acertos foram tantos… parece até que nada deu errado. Soubemos até mesmo tirar proveito das dificuldades. Enfim, deu certo.

A equipe que organizou está de parabéns. Devo agradecer aqui, especialmente o nosso amigo Leonardo Cezar. Mesmo com todas as suas dificuldades pessoais, ele foi capaz de segurar o rojão e assumiu a maior parte do trabalho na organização do evento, além de ajudar no CONISLI também. Com certeza o evento não teria acontecido sem a inestimável contribuição do Leo. Como se tudo isso não bastasse, ele ainda trouxe chopp para nossa festa de encerramento!

Mas é claro que contamos com a ajuda de mais pessoas e é bem possível que eu nem saiba direito quem são todas elas. O Diogo e o Euler estiveram sempre conosco ajudando em N coisas e particularmente na seleção e encaminhamento das propostas de trabalho. A Kenia e a Isis também tiveram uma participação decisiva na montagem do nosso stand e na divulgação do evento. Bom, a lista de pessoas que eu lembro agora para por aqui. Peço desculpas a outras pessoas que ajudaram e eu esqueci de citar. Se alguém lembrar, me avisa que eu corrijo aqui.

De toda forma, não foram muitas pessoas. Estou esgotado e radiante. Foi um tanto trabalhoso. Tenho aqui que agradecer profundamente a minha esposa. Ela me aturou e cuidou de mim durante o tempo em que me dediquei a organização do evento. Eu sempre digo a ela que ajudar nessas coisas ajuda na carreira, que é importante, etc e tal. Mas, na verdade, eu bem sei, e ela sabe melhor ainda, que fazemos isso por um único motivo: nós gostamos! É cansativo, há sempre alguns detalhes desagradáveis no caminho, mas não há como negar, é muito bom. Poder conviver com pessoas como as que citei anteriormente é realmente um privilégio.

Quando conheci o Sr. Josh Berkus este ano, fiquei espantado com a erudição dele. Não é comum um americano aprender muitas línguas, conhecer tão bem o mundo fora do seu país e ter um nível cultural tão alto. Ao mesmo tempo, o Sr. Josh e outros palestrantes internacionais demonstravam uma paciência enorme para escutar meu inglês esfarrapado e conseguimos ter conversas realmente interessantes, não apenas sobre informática. No PgCon Brasil, não foi diferente. Conversei com o Sr. David Fetter e continuo espantado. Ele me faz lembrar de que o bom humor, parece ser outra característica marcante do Software Livre. Lendo “Programação Perl” do Larry Wall, isso fica claro. Documentação técnica de software proprietário é mais chata de ler. Evento de software proprietário é mais chato de participar. Realmente os desenvolvedores de software livre são realmente mais divertidos. O Sr. David Fetter mostrou uma boa disposição conosco de fazer inveja. Não há dinheiro que pague isso. E é claro… nós não pagamos nenhum tostão. Nunca pagamos ninguém mesmo. Acreditem, o Sr. David Fetter fez mais que isso… ele comprou suas passagens para vir para cá antes de nós sabermos se conseguiríamos pagar a passagem dele!

Entretanto, quanto mais eu convivo com a comunidade de Software Livre, mais eu me convenço de que esta é uma característica das pessoas que participam ativamente da comunidade. Há uma ou outra exceção, é claro. Mas são fáceis de se identificar e não costumam ganhar muito espaço. Fora estes casos, são pessoas que realmente gostam do que fazem e não sonham em ficar milionários. A cada dia que passa eu me convenço que o Software Livre traz muito mais coisa que apenas códigos e licenças… trás o valor do ser humano acima do valor do papel. O Software Livre poderia se resumir talvez em pessoas querendo construir algo melhor para todos. Estas pessoas são excepcionais realmente. Não o são por serem dotadas de conhecimento, experiência ou capacidade intelectual fora do comum. Muito longe disso! São excepcionais simplesmente por gostarem de fazer parte disso tudo. O resto, é tão somente uma conseqüência disto. Acho que o Sr. Paulo Freire concordaria com estas palavras.

De qualquer forma, o sucesso do evento estava na platéia, muito mais que nos palestrantes. Havia muita gente boa por lá… e descobrimos experiências fantásticas! Pessoas de todas as regiões do país. Desenvolvedores, DBAs, Sysadmins e gestores deram ao público um colorido muito mais interessante do que foi exposto no palco. Isto nos faz pensar que temos uma comunidade com um potencial muito maior do que imaginamos. Ano que vem teremos outro PgCon Brasil. Teremos mais patrocinadores, teremos mais gente ajudando a organizar. Teremos gente nova subindo ao palco. Teremos novos palestrantes internacionais. Mas teremos o mesmo prazer em participar de uma comunidade tão empolgante quanto a do PostgreSQL brasileira! E saibam… não aguardem o ano que vem… vamos começar o próximo evento já! Na verdade, nós já começamos efetivamente.

Bom… todos reclamam que eu escrevo muuuuuito. Então segue uma pequena compilação de algumas coisas rápidas:

• Começa amanhã o PgConBrasil, primeiro evento de PostgreSQL no Brasil. Já temos mais de 250 inscritos, mas ainda dá tempo de se inscrever na hora H. Não perca.
• Menos é mais… fiz mais de 40 slides para a minha palestra no PgConBrasil. Por causa da organização do evento, acabei vendo os slides de outros palestrantes. Vou lhe dizer… o dia que eu fizer como o Diogo Biazus eu fico rico!
• Depois de tomar cerveja com alguns amigos na semana passada eu conheci a mais rápida ferramenta de busca na área de Software Livre! Fikepedia, a ferramenta mais rápida que o google e o wikipédia. Realmente fantástico, aguardem o novo site!
• Em outra cerveja, alguém me soltou uma outra frase ótima: “Esta certificação é muito respeitada, eu aprendi excelentes técnicas de memorização para tirar ela!”
• Em mais outra cerveja (hum… acho que preciso entrar no AA), falando sobre a história de que software livre não paga propina alguém me solta essa: “O PostgreSQL é como amante, você gosta, usa e abusa, mas não assume publicamente!”
• Uma dica para quem me encontrar no PgConBrasil… eu tenho uma memória péssima para nomes. Depois que coloquei o meu e-mail neste blog as coisas só pioraram. Sempre aparece alguém do nada. Faço o possível para tratar todo mundo como se eu lembrasse de quem é. Vou atrás do histórico dos meus e-mails, comentários no blog, etc. Mas ao vivo isso muda… é terrível. Então se eu te chamar de “amiguinho”, “mestre” ou qualquer outra coisa do tipo. Por favor não fique bravo comigo.

Bom, por hoje é só pessoal.

4 de Dezembro, chego em casa umas 23 horas e vejo o e-mail na lista pgsql-announce: “Lançada a versão Beta4 do PostgreSQL”. Hum… isto significa que o 8.3 não vai sair até o PgCon Brasil. É uma pena… e motivo de orgulho ao mesmo tempo. É uma pena que a festa não vai ser completa durante o evento. É um motivo de orgulho pelo simples fato de não haver data para o lançamento oficial. É isso mesmo. Isto é uma das maiores vantagens dos softwares realmente livres. Já ouviram falar na piada de que o Windows seria o maior programa Beta da história? Bom… isso não ocorre só com o Windows. Acontece com quase toda empresa cuja receita provém da venda de caixinhas. Se você lançar um versão excelente e estável, você venderá suas caixinhas. Mas você precisa vender o mesmo produto para seus clientes daqui a um ou dois anos. Resultado: existe uma pressão dos acionistas para que a versão saia logo, custe o que custar. E o custo costuma significar estabilidade.

Os projetos de Software Livre mantidos por comunidades não sofrem este tipo de pressão. O Debian chegou a demorar alguns anos para lançar o Sarge enquanto as outras distibuições Linux eram lançadas a cada ano ou mesmo a cada 6 meses. Mas se você procura por uma distribuição realmente estável… o Debian é uma excelente escolha. Quando falamos de Bancos de Dados, a estabilidade é motivo de paranóia constante. É absolutamente normal uma nova versão de um SGDB demorar 3 ou 4 anos para ser lançado. O PostgreSQL tem liberado praticamente um release por ano. Isto pode assustar alguns DBAs que não estão acostumados com o ritmo de desenvolvimento de uma comunidade ativa. A comunidade de desenvolvedores do PostgreSQL tem se mostrado bastante ágil no desenvolvimento de novas funcionalidades e na correção de erros. O importante, é não ceder a pressões para lançar um produto imaturo no mercado. Ao olharmos a história das versões de vários produtos conhecidos de mercados, encontramos vários lançamentos de valor questionável como o o MS-DOS 6 ou o impagável Windows Milenium Edition, para citar casos mais clássicos. O Corel Draw perdeu muito da sua credibilidade entre os designers para a Adobe, devido a uma política de lançamento de versões agressiva no final da década de 90. A própria IBM teve a versão 6 do DB2 que não foi bem recebida pelo mercado.

Software Livre também não está livre destes problemas. Assim, Red Hat, SUSE, Mandriva, Canonical e outras distribuições mantidas por empresas sofrem uma pressão para lançar rápido novas versões. Assim como em distribuições Linux, temos o mesmo ocorrendo com outros tipos de Software Livre. Assim, entre os SGDBs o PostgreSQL ganha mais um ponto por ser mantido por uma comunidade realmente fantástica. Pode ser que demore muito até o dia em que os DBAs reconheçam isto como um ponto positivo. Em todo caso, só o tempo irá dizer se isto realmente fará a diferença.

Então, se alguém lhe perguntar quando sairá a nova versão do PostgreSQL (ou outro Software Livre mantido por uma comunidade), não tenha dúvida e responda:

- Quando estiver pronto!