Checklist mensal do PostgreSQL

Este post é uma humilde adaptação de um ótimo artigo sobre o SQL Server. Sim, você leu certo: Peguei umas idéias do checklist do SQL Server.

1. Atualize o SO do seu servidor

Eu sei. Você não faz isso. Acha que não precisa, que o problema não é seu, mas nos últimos anos tivemos tantos problemas de segurança recentes (HeartBleead, Shellshock, etc), que sabe-se lá o que pode nos assustar no futuro. Quer uma sugestão? Atualiza tudo, sempre [que possível].

2. Atualize seu servidor PostgreSQL

Por que? por que sim, oras. Precisa de mais motivos? Então pensa que BUGs e falhas de segurança são corrigidos o quanto antes.

Sua versão instalada não tem mais atualizações ou não é mais suportada? Para tudo e bora atualizar. Não só pela segurança, mas toda versão tem muita coisa bacana, aposto que os desenvolvedores implorariam pra você atualizar. Vai lá e mostra o release notes pros caras, depois vem e me agradece. :P

Não acredita? Abre aí então:

https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.5

Pra te dar uma dica de como atualizar, sempre dê uma lida no release notes. Lá tem tudo o que nós, meros mortais (ou não devs), precisavamos saber pra atualizar o banco. Normalmente é bem simples (para o banco, atualiza os binários, sobe o banco), e caso seja mais elaborado, vai estar la no release notes, bem bonitinho.

Quer saber das versões novas e tem preguiça de ver o site toda hora? Então assine o feed RSS.

Ainda assim da muito trabalho? Então utilize os repositórios do PGDG, que tem pra varios sabores (APT e YUM por exemplo).

3. Valide suas rotinas de backup

Verifique todo seu processo de backup. Messa os tempos de execução, documente cada etapa do processo e tente deixar ele o mais simples possível. Pontos importantes a validar são: Tamanho ocupado, duração, falhas na execução e monitoramento do mesmo.

Já que estamos falando de backup, faça a lição de casa e avalie as soluções de backup mais populares:

Já que você faz backup do seu banco, não esqueça de fazer backup das suas configurações. Afinal, nunca se sabe quando vamos precisar fazer um Disaster Recovery. Falando nisso, é uma boa planejar uma solução de HA, não é mesmo?

Se você ainda usa o pg_dump como sua principal solução de backup, dá uma olhada nesse artigo bacana do @telles.

4. Teste, com vontade, a sua rotina de restore

Backup bom é o que restaura.

Eu nunca canso de dizer isso!

Já que seu backup está rodando certinho, faça um restore dos dados. Meça os tempos, documente o processo. Se tiver como fazer isso num servidor novo, melhor aínda! O importante é ficar tranquilo e ter tudo sob controle quando a casa cair e ele for realmente necessário.

5. Verifique o desempenho e a saude do seu banco

Deixe de sofrer. Há muitas soluções de monitoramento no mercado (zabbix, Nagios, etc). Coloque ele pra funcionar e monitorar detalhes uteis do SO e também do servidor PostgreSQL. Ajuste seu log para um formato de leitura mais eficiente (como o CSV, por exemplo) e gere reports do pgbadger ou uma solução mais elaborada.

Caso você use a versão 9.3 ou superior, você DEVE dar uma olhada no PoWA.

6. Revise seu tuning no SO e no postgresql.conf

Agora que você passou a monitorar o banco, aproveita o embalo e começa a dar uma revisada no tuning do sistema operacional, começando pelo /etc/sysctl.conf. Infelizmente, cada evento pode apontar um arquivo de configuração diferente. O jeito fácil é entender o que está rolando no servidor e ver se isso tu trata num dos 3 pilares: Hardware, Sistema Operacional e Banco de dados.

SO revisado? Então manda ver e da uma olhada configurações do postgresql.conf. Se você nunca fez isso, eu sugiro que dê uma olhada no PGConfig. Lá é um bom lugar pra começar.

Não esqueça do hardware. As vezes não tem jeito, precisamos de um upgrade. :D

7. Analise e ajuste o baseline

Chegou a conclusão que precisa de algum ajuste no tuning? O que mudou? Aumentou a quantidade de usuários? Nova feature baseado em boas praticas do mercado?

Será que é realmente necessário esse ajuste?

8. Valide o seu Capacity Plan

Se você tem um em ação, será que o mesmo está adequado? Se você fez algum ajuste sugerido acima, será que o mesmo não precisa de nenhum ajuste? Talvez seja o momento de mudar algumas projeções.

9. Sumarize e monte um plano

Avaliou tudo o que precisa mudar? Agora monte o seu proprio plano de ação, alinhe com a equipe e batalhe pelas janelas de manutenção.

Depois de tudo pronto e configurado, mande o seu próprio release notes pro pessoal do marketing e deixe eles fazerem propaganda da saude do seu banco! :P

Faltou algo?

Certamente algo importante pode ter ficado pra trás. Deixa um comentário pra gente ajustar assim que der. :D

[]’s

Desafio sobre a replicação do PostgreSQL!

Esse ano, segundo fontes confiáveis, é aniversário da Comunidade Brasileira de PostgreSQL. E pra fazer a minha parte (e tirar a poeira do blog) eu lanço um desafio público: falar sobre a replicação do PostgreSQL. E isso não é pouca coisa!

Até o momento, essas são as soluções mais populares:

A proposta

A idéia é fazer um ambiente de testes utilizando a versão mais recente do banco e da solução cobrindo os pontos abaixo:

  • Instalação e configuração
  • Operação basica para replicar dados ou conjunto de dados
  • Procedimentos que previnem tolerancia a falhas
  • Validar meios para replicar dados distribuidos geograficamente
  • Medição dos tempos de carga intensa (como o restore do banco) e moderado (como a atualização de dados e tudo mais)
  • Avaliação de pontos fortes e fracos

Sobre o ambiente de testes

Quanto a máquina virtual dos testes

Pra simplificar o processo de setup do lab, eu criei uma configuração do Vagrant composta de duas máquinas virtuais na configuração abaixo:

  • 2GB de RAM
  • 35GB espaço em disco
  • CEntOS 7 64 Bits
  • Repositórios configurados: epel, pgdg94 e pgdg95

Detalhes da configuração de rede:

Hostname IP
master 192.168.100.100
slave 192.168.100.200

Abaixo segue o Vagrantfile:

Para utiliza-lo, execute:

Quanto a base de dados

A base de testes adotada é o banco do IMDB. Pra simplificar o processo de importação e teste eu já deixei um dump prontinho na URL abaixo:

http://1drv.ms/1TjlPXl

Detalhes pra importação do dump são os de sempre:

createdb -U postgres imdb
pg_restore -U postgres -d imdb -Fc --disable-triggers imdb.dump -j 4
vacuumdb -U postgres -d imdb -z

Na sequência já publico detalhes de como popular e alterar os dados.

E aí, vai encarar?

Um rascunho sobre banco de dados e containers

Eu tenho notado que a onda do momento é deixar pra lá a virtualização e passar colocar tudo em container. As pessoas comentam com emoção: minha aplicação rodando no container fica auto-suficiente, configurada conforme os padrões do meu produto e todas as preocupações do fabricante.

Usar o docker e criar um container é relativamente fácil, se você der uma olhada no google, vai achar uma dezena de tutoriais e dicas infalíveis pra deixar tudo rodando como deve. Vou deixar uns links abaixo pra tentar fazer a minha parte.

O docker tem uma limitação simples: até o momento, ele só roda no linux. Temos artificios pra usar o docker no Windows e ou Mac, mas a verdade é que mesmo “com jeitinho”, vai ter uma vm linux rodando o docker por debaixo dos panos. Não sei da Apple, mas a Microsoft ta dando um jeitinho pra rodar ele no Windows Server 2016.

O que isso quer dizer?

Quer dizer que, no atual momento, docker só funciona no linux.

Se você ficou curioso sobre como usar ele no windows ou mac, dá uma olhada no Kitematic.

Bom, depois de discurso todo eu quero dizer uma coisa bem simples: Se sua aplicação precisa do Windows pra rodar (seja pelo SQL Server, IIS, etc) acho que esse post não é bem pra você.

É comum usarmos docker para rodar nossa aplicação web, seja ela como for: ERP rodando em java, blog em php, etc. A idéia é simples: a gente sobe um container com o mínimo pra ela rodar e gentilmente manda o docker rodar muitas instancias dessa mesma imagem simultaneamente. Pensando assim você indaga: Se precisar um balanceador de carga, o que fazemos? Subimos ele num container também. Fácil assim.

Quer um exemplo? Suponha que tenhamos que publicar um blog feito no wordpress. Wordpress precisa do php e um banco MySQL pra funcionar. Dessa forma, precisamos, necessariamente de 2 containers: 1 de MySQL e outro de apache+php (ou qualquer outro webserver que rode php e te deixe feliz).

Assim que nosso servidor estiver rodando esses containers e nosso blog imaginario começa a receber muitos acessos, nosso container de apache e php começa a ter dificuldade de responder a todas as requisições e assim, temos a grande idéia de colocar mais um container rodando apache com minha aplicação (wordpress) e assim, ganhamos um problema novo: tenho 2 apaches e nimguém pra balancear o mesmo.

O que fazer nesse caso? você pode subir um container com o haproxy e passar a apontar tuas requisições pra ele e ele passar a balancear as conexões entre os apaches. Até que é facil não é? agora, se o site ficar lento denovo, o que a gente faz? aumenta os apaches! Quantos? Quantos forem necessários!!! :D

Agora, quando baixou a demanda, o que eu faço?

Diminuo a quantidade de containers em execução, fazendo manualmente um autoscaling.

Talvez aqui tenhamos um furo no conceito: a aplicação do wordpress vai eventualmente criar uns arquivos no disco com dados da aplicação (imagens, css, js, etc) e isso a gente pode contornar com uma area de disco compartilhada entre os containers.

A analogia é simples nesse caso: cada imagem docker tem tudo que eu preciso pra rodar o php+wordpress+coisas+do+blog e o MySQL é quem guarda os dados dinamicos.

Então vai chegar o temido dia: meu banco rodando no container não dá conta do recado. Você tenta todo tipo de mandinga necessária: tunning, hardware e não tem jeito. Aí, depois de pensar em todos os planos pra aumentar os recursos passa pra pensar em algum tipo de processamento horizontal e nota que vai precisar distribuir a carga e balancear os acessos entre esses nós. Assim, você que já foi doutrinado vai dizer: “ótimo! vou colocar a rodar mais um haproxy e vou subir outro container MySQL!”. Não, isso não vai funcionar.

Por que? basicamente por causa da integridade dos dados. Precisamos de algum mecanismo (seja nativo ou não) que garanta que ambas os containers rodando MySQL tenham a mesma informação. Isso não é tão simples: cada fabricante de banco de dados implementa do seu jeito e cada solução de replicação tem seus prós e contras.

Tá, mas o MySQL não tem replicação? eu não posso usar pra resolver meu problema? Pode. E posso fazer igual como fiz com os apaches+php, apagando os containers conforme ele não for usado? Provavelmente não.

Aqui é o ponto em questão: bancos de dados não apenas arquivos no disco. Precisamos pensar uma forma diferente de tratar ele pra que funcione bem como de costume.

Quanto ao armazenamento, tem alguns links que valem a pena dar uma olhada:

Continua…

Deu trabalho! mas agora o blog usa o octopress 3.0

Depois de apanhar, desistir, insistir e jogar tudo pra cima. Blog está sendo migrado pra usar o octopress 3.0.

Já que meti a mão na massa, aproveitei e mudei o tema para baseado no Pooler chamado Lanyon.

Falta pouco, mas acho que agora vai.

PS: No fim a unica coisa que estou usando do octopress 3 é o deploy. Conforme eu for pegando a manha eu ajeito essa bagunça que eu fiz.

PGConfig agora tem um dominio próprio!

Depois de umas noites trabalhando no projeto do PGConfig, eu decidi registrar um dominio para facilitar o acesso ao mesmo e aí isso acabou mudando a URL de acesso do mesmo. Agora ficou http://pgconfig.org.

Pra quem interessar, o mesmo está hospedado na infraestrutura do OpenShift.

Sugestões são bem vindas! =)