TOP FISL 9: Backup prático

Para mim, a palestra mais inovadora do FISL 9, que mais acrescentou conteúdo, a palestra que eu pensei “bah, valeu os cenzão que paguei”, foi a de backup prático, ministrado pelo Solli Honório. Na verdade, não sei até que ponto realmente é inovador, mas é que eu nunca tinha ouvido falar sobre o tal backup diferencial em disk-to-disk.

O modo mais comum de se fazer backup é em fita magnética, mas quem nunca precisou restaurar um, não sabe o significado disso. Isso sem falar nos riscos de dar erro na mídia, quando não é testada a copia.

Eu já tive que esperar quase 12 horas para recuperar um backup, com o cliente nervoso, aguardando ansiosamente pelo seu dado perdido. Depois desta experiência, quando o backup passa dos 20Gb, eu sempre sugiro embutir na política de backup, um armazenamento em disco também, além do meio magnético.

Em geral, os clientes gostariam que fosse mantido backup em disco de dados de mais de 1 dia, mas infelizmente, isso é muito difícil, pois implica em gastar muito dinheiro em discos rígidos. No máximo, eu consigo armazenar 2 dias de backup em disco. No geral, isso resolve. Mas, sempre tem o caso do cliente querer dados de vários dias atrás; pior, nem sempre sabe o dia exato que o dado foi perdido. Dai não tem jeito. Se fica “algumas-muitas-horas” procurando nas fitas magnéticas.

Bem, vamos ao que interesse…

Após um panorama geral sobre backup, o Solli abordou o disk-to-disk, preferencialmente se usando disk storage, mas que poderia ser até via web. Depois ele começou a falar em manter um histório de backup em disco, eu já pensei: “bah, vai ser difícil de implementar isso. Soluções muito caras”… Mas dai ele começou a falar em backup diferencial, eu confundi os termos e pensei que já era o famoso backup incremental (esse dai eu não arrisco de jeito nenhum). Já estava quase indo embora, quando eu entendi a diferença. “Uau! Um backup que você fica com o arquivo atualizado e pode aplicar diff para regredir?! Fantástico!!!”

É isso mesmo. O sistema faz uma checagem dos arquivos que foram modificados, marca estes arquivos, vê apenas as partes dos arquivos que foram alterados, gera um diff e atualiza o arquivo. Com o diff, é possível regredir o backup. Na pior hipótese, caso seja perdido estes arquivos com o diff, você ainda terá o último backup completo.

Só isso já seria suficiente para me deixar muito feliz. Mas, ainda tem mais: existe um front-end escrito em Perl (eu amo Perl!), que roda via browser e faz todo o gerenciamento do backup diferencial e ainda por cima com o histórico! Maravilhoso! Espetacular! Não tenho palavras para resumir o que estou sentido, hehehe

O aplicativo se chama BackupPC, e pode ser encontrado no link: http://backuppc.sourceforge.net/. Vale a pena incorporar isso em sua vida!

Para finalizar, o Solli sugeriu que o backup em fita não deve ser abandonado totalmente. O ideal é usar o backup disk-to-disk, associado com um backup disk-to-disk-to-tape (neste caso, usando outra ferramenta para gravar na fita, ou seja, você precisa de um BackupPC e um Bacula, por exemplo).

Replicação em PostgreSQL: Fim do sonho

Assisti hoje, no segundo dia do FISL, a outra palestra sobre replicação de dados no PostgreSQL, com o Bucardo. Já cheguei meio “traumatizado” com a palestra sobre replicação do dia anterior (porque não é tão simples replicar dados no PostgreSQL como é no MySQL???).

Até que a palestra começou bem, e eu comecei a ficar feliz quando o palestrante falou que ela era uma solução multi-master e escrita em Perl, Pl/Perl e Pl/pgsql, mas começou a desandar quando falou que usa triggers (não me agrada usar triggers na minha base de dados para implementar replicação, pois não quero “sujar” minha BD). Piorou quando disse que era uma solução que não aceitava chave primária composta, apesar que os autores do projeto estão pensando em melhorar esta funcionalidade. Na verdade, creio que até eu poderia adaptar o Bucardo para as minhas necessidades, mas o fato de usar triggers realmente não me agrada. Eu quero ter controle total sobre a minha base de dados. Sou muito possessivo com as minhas coisas!

Tem mais alguns pré-requisitos, como PostgreSQL 8.1 ou superior, além de ter que ter o Perl e mais alguns módulos do Perl instalados no servidor “principal” de replicação, mas o fato de não aceitar chave primária composta é muito limitante.

Achei interessante que ele tem alguns controles para resolver conflito de chave, como por exemplo, você pode escolher qual servidor tem prioridade, em caso de conflito, ou até uma opção engraçada, que é a “random” (isso mesmo, faz um “sorteio”, huahuhauhua). Mas bem que podia ter uma opção do tipo “migrate“, onde os registros duplicados de um dado servidor tivessem sua chave primária modificada, sem perda de dado, mas tudo bem. No fim, o que vale mesmo é adotar o velho range de auto-numeração.

Creio que vou pesquisar um pouco mais a replicação por log e ver se existe maneira de deixar o servidor “escravo” aberto para seleção, assim como eu faço atualmente com o MySQL (solução perfeita para as aplicações que eu tenho atualmente). Na pior das hipóteses, foi implementar a replicação manualmente usando triggers MINHAS, hehehe

FISL 9: Dia do PostgreSQL!!!

Depois do primeiro dia de FISL, daria para “apelidar” hoje como o dia do PostgreSQL. Amanhã, ainda, terá pelo menos mais uma palestra sobre replicação de dados, mas somente hoje eu participei de 4 palestras sobre este SGDB.

---

Logo cedo, assisti a palestra sobre replicação de dados, onde foram abordados conceitos como replicação síncrona e assíncrona e que às vezes uma solução mais simples pode ser a mais indicada. O palestrante usou uma analogia com vários tipos de carros de velocidade, passando por carros que desenvolviam mais de 400Km/h mas que só andavam em linha reta, sem muito controle, passando por fusca, que chega a 120Km/h por hora com algum esforço, mas anda para todos os lados e pode ser usado na cidade, até chegar no carrinho de rolimã, que não tem motor, mas em compensação tem custo quase zero de manutenção.
Mostrou várias ferramentas para replicação, sendo que eu destacaria o skytools da Skype, uma solução de replicação síncrona com centenas de servidores rodando em ambiente de produção, soluções mais clichês, como o Slony (que usa triggers para replicações assíncronas, mais indicado para replicação de tabelas), Warm-Standby (baseado em log), que aparentemente seria algo similar ao sistema de replicação do MySQL, mas que precisa que o slave fique em modo de espera, sem poder ser usado.
Fiquei surpreso com a afirmação de que pg_cluster é extremamente instável com base de dados grande (ele citou ser impossível em usar em uma base de dados de mais de 10GB, porque simplesmente o SGBD pára de funcionar com ele). Pensava em adotar esta solução em um projeto.

Depois, teve uma palestra muito interessante sobre segurança de dados no PostgreSQL. O palestrante, usou a frase “Safe Data Is Happy Data” (Dado seguro é dados feliz) como referência em toda a apresentação.

Basicamente, ele falou que a maioria das soluções de sistemas de banco de dados não se preocupavam com a segurança do lado de dentro do firewall, apenas definindo políticas de segurança no roteador, servidor web, etc. Esta despreocupação com a segurança interna é uma das principais causas de “dado infeliz”. Ele citou, que cerca de 2/3 das invasões são internas, com roubo de dados por funcionários, etc.

Para ter uma base de dados realmente segura, é necessário várias ações, entre elas, definir corretamente uma política de acesso de senhas no arquivo pg_hda.conf (por exemplo, usando ident apenas para usuários tipo administradores logados em rede local e segura e md5 para usuários web com conexão ssl, etc.).

Outra atitude a ser adotada é definir corretamente os direitos de acesso as tabelas. Por exemplo, definir usuários web com acesso apenas de select e os usuários da sua rede interna com acesso total, bem como definir acesso apenas as tabelas necessárias para cada grupo.

Infelizmente não lembro mais de todas as práticas de segurança que foram sugeridas, mas tem uma que achei muito interessante, que nem sempre é utilizada, que se trata da auditoria do sistema. Eventualmente, pessoas mal intencionadas com acesso ao sistema ou a base de dados podem roubar informações ou alterar dados por má fé ou até mesmo erro. A auditoria ajuda a detectar estes problemas e até mesmo corrigir, voltando ao estado anterior. Para isso, é essencial usar triggers e definir corretamente o acesso as tabelas de auditoria, para que um invasor não consiga comprometer esta auditoria, também.

Em seguida, teve uma palestra sobre “Postgres Application Server” (aliás, a palestra poderia ser chamada de Perl no PostgreSQL, hehehe), que seria basicamente mover parte da aplicação para o SGDB, como por exemplo, validação de dados, uso de store procedures para processamentos em lote, etc.

Podem ser usadas várias linguagens para a implementação, sendo que o palestrante citou o pl/sql que seria uma linguagem segura e que não precisa de nada, pois é como se fosse um “default” do PostgreSQL e linguagens ditas “inseguras”, as quais poderiam fazer um bom estrago na base de dados ou no sistema (se forem mal utilizadas), pois implementam acesso a disco, etc. Entre estas linguagens, o palestrante deu destaque para a Lua e o Perl, mas também poderia ser usado PHP, C, etc.

Destaque para a implementação de um domain email (tipo de dado), validado via Perl, com poucas linhas (graças ao uso do CPAN).

A última palestra de PostgreSQL do dia foi sobre boas práticas em desenvolvimento em banco de dados. Foi a palestra mais genérica sobre PostgreSQL, mas certamente foi a mais interessante. Para quem tiver interesse, dá para conferir o pdf dos slides da palestra, aqui (foi alterado um pouco para o FISL, pelo que eu pude ver, mas a idéia original da mensagem continua a mesma).
As partes que eu acredito que valem a pena destacar, são:

1. Uma pessoa sem bom senso não se preocupa com melhores práticas;
2. Uma pessoa com bom senso e pouca experiência procura aprender e utilizar as melhores práticas;
3. Uma pessoa com bom senso e muita experiência sabe quando não utilizar as melhores práticas.

A maioria dos desenvolvedores devem procurar se enquadrar no segundo item e apenas quando tiverem muita “estrada” e muitas “melecas” (como o palestrante gostava de dizer) feitas é que pode pensar em ir para o terceiro grupo de pessoas.

Além disso, vale a pena citar uma frase de Eric Raimond: “Estrutura de dados inteligente e código burro trabalham muito melhor do que o contrário”, ou seja, se a estrutura de dados for mal definida, nada salva o projeto, nem programadores fenomenais. Tudo parte de uma boa definição da modelagem dos dados. Nos slides tem várias dicas boas para se conseguir isso. Vale a pena conferir.