Hoje um e-mail na lista do PostgreSQL me levou inspirou a escrever este texto. A questão é que muitas pessoas confundem replicação com clustering. A confusão não é a tôa… a palavra Cluster possui vários significados diferentes dependendo do contexto. Temos a idéia de tabelas clusterizadas, que possuem significado diferente no Oracle e PostgreSQL por exemplo e por sua vez não tem nada haver com o conceito de cluster de SGDB. O PostgreSQL chama de Cluster o conjunto de banco de dados gerenciados por uma única instância (conjunto de datafiles, arquivos de controle e processos no servidor que formam um SGDB). O PGCluster apesar do nome, é uma solução de replicação e não de clustering! Algumas soluções proprietárias também gostam de adotar o status de Cluster, quando na verdade se tratam de soluções de replicação. O princípio da replicação é a de ter cópias de dados em mais de um banco de dados que possam ser sincronizadas entre si. O princípio do cluster é ter vários SGDBs se comportando como se fossem uma só instância de forma transparente para a aplicação. Veja por exemplo que o conceito de Grid, que a Oracle adotou como buzz word, não existe de fato em banco de dados!

Quando falamos em Cluster de banco de dados, pensamos em 3 tipos de clusters:

• Shared All: Onde a memória (shared buffers) e os discos (datafiles) são compartilhados por cada nó do cluster;
• Shared Disc: Onde apenas os disco são compartilhados pelos nós do cluster;
• Shared Nothing: Onde cada nó tem a sua própria memória e discos;

Quando falamos em Replicação de banco de dados, pensamos em 4 tipos de replicação orientados por 2 paradigmas distintos:

• Replicação sincrona: onde todas as réplicas possuem sempre os mesmo dados;
• Replicação assíncrona: onde as réplicas podem ser sincronizadas depois que um alteração nos dados é realizada;

• Replicação MultiMaster: onde é possível realizar leitura e gravação em qualquer réplica;
• Replicação Master/Slave: onde apenas a réplica master permite gravação, enquanto as demais réplicas só permitem leitura;

Vejamos algumas diferenças entre replicação e cluster:

A replicação pode ser parcial ou total (em relação aos objetos do banco de dados), enquanto o cluster é sempre total em relação a uma instância do banco de dados (no caso do PostgreSQL seria em relação a um cluster criado pelo initdb).

• A replicação pode ocorrer em apenas uma parte dos dados de cada réplica enquanto no cluster toda a instância (datafiles + processos no servidor) do SGDB de cada nó deve fazer parte do cluster;
• A replicação pode ser assincrona ou síncrona enquanto o cluster sempre trabalha de forma síncrona.

• A replicação pode ser MultiMaster ou Master/Slave, e no Cluster todos os nós podem realizar operações de leitura e escrita (o equivalente a um MultiMaster).

• Técnicas de replicação, em geral não são boas para aumentar a escalabilidade horizontal de bancos de dados com alto volume de gravação (OLTP) enquanto os clusters shared all tem esta capacidade;
• A replicação guarda uma cópia dos dados replicados em cada instância do banco de dados enquanto o cluster mantém apenas uma cópia dos dados compartilhado para todos os nós do cluster. Note que, em algumas implementações de clusters, técnicas de replicação são combinadas para se evitar o Storage como ponto vulnerável no caso de tolerância a falha.

Em princípio, parece que uma uma replicação MultiMaster síncrona é equivalente a um Cluster Shared Nothing. No entanto, note que um Cluster Shared Nothing cada nó possui apenas uma fatia do banco de dados em seu storage enquanto na replicação MultiMaster síncrona, cada nó possui uma cópia completa dos dados. Cada técnica de cluster e replicação tem diversos tipos de implementações servindo para diferentes propósitos e com diferentes limitações. Saber distinguir cada um deles é fundamental para saber por onde começar a procurar por uma solução adequada para cada tipo de problema, seja ele de alta disponibilidade, balanceamento de carga ou de bancos de dados distribuídos.

O PostgreSQL conta hoje com várias soluções de Replicação Assíncrona Master/Slave que vai do Stand By (implementado no PostgreSQL padrão), Slony I e outros. O PgPool I e II é não são exatamente soluções de replicação e sim de pool de conexões com suporte a um tipo de replicação síncrona. A única solução de replicação MultiMaster Síncrona existente hoje é o PGCluster. O projeto do Slony II pretendia ser uma nova implementação deste tipo mas foi abandonado devida a alta complexidade do projeto. O PGCluster II pretende ser uma implementação de Cluster Shared All (no mesmo estilo do Oracle RAC), mas o projeto ainda é muito recente para se saber se ele será bem sucedido.

Para saber mais veja:

• PostgreSQL Replication Solutions por Bruce Monjian (um pouco defasado, mas muito didático);
• Replication/Clustering por Josh Berkus (tem uns erros nas últimas páginas, mas é muito interessante também);
• Database Clustering por Neil McAllister (foca a diferença entre as soluções de cluster da Orace e IBM)
• Transformando um Elefante numa Manada (palestra minha realizada no”1° Seminário de Inovações Tecnológicas em Cluster e Grid no Governo Federal“)

Há tempos atrás, escrevi um tutorial para mostrar como unificar vários bancos de dados em um único banco de dados com vários esquemas. Hoje na lista do PostgreSQL, houve uma dúvida sobre se valia a pena juntar tudo num banco de dados ou manter cada aplicação em um banco de dados diferente no mesmo servidor.

Realmente é difícil justificar o uso de bancos de dados separados. Em geral, utilizar esquemas é sempre mais indicado. Vale a pena lembrar que existem 3 níveis de compartilhamento num mesmo servidor PostgreSQL:

• Cluster, que compartilham a mesma porta, os mesmos processos e a mesma configuração global (postgresql.conf e pg_hba.conf);
• Bancos de Dados, que compartilham o mesmo cluster mas podem ter codificação de caracteres distintos e dependendo da configuração, podem ter usuários distintos (se ‘db_user_namespace’ for configurado como ON);
• Esquemas, que compartilham o mesmo banco de dados;

Em geral, utilizar mais de um banco de dados num mesmo cluster pode ser válido se

• Você precisa ter um ambiente onde o desenvolvedor precise ter poderes plenos num banco de dados de teste sem afetar outras aplicações. Isto é muito incomum, pois é normal você dar permissões para um usuário em um schema específico, mas existem ambientes de testes que podem ser um pouco extremos… Mas se você quiser soltar o desenvolvedor para brincar a vontade no seu servidor, esta pode ser uma opção. Mas jamais faça isso num servidor de produção! O ideal seria instalar o PostgreSQLlocalmente na máquina do usuário ou criar uma máquina virtual com XEN só para isso.
• Em um provedor de serviços onde vários clientes tenham que compartilhar um mesmo servidor PostgreSQL e ao mesmo tempo ter isolação total das contas de usuários esta pode ser uma opção interessante. Vale a pena lembrar de configurar o parâmetro ‘db_user_namespace’ para OFF, opções de memória pequenas para cada banco de dados e de criar um TABLESPACE padrão para cada banco de dados procurando balancear eles entre os discos disponíveis. A partir daí cada cliente poderá colocar as suas várias aplicações em vários esquemas do mesmo banco de dados. É claro que um cliente grande vai querer ter um servidor de banco de dados dedicado, mas para clientes pequenos, isto pode ser uma opção viável.

• Você precisa de ambientes de teste, homologação e/ou produção na mesma máquina. Em geral é melhor deixar seu ambiente de teste em outro servidor. Você vai descobrir que uma única consulta mal feita no ambiente de teste pode sentar todo o servidor… melhor evitar isso a todo o custo! Você também pode criar ambientes isolados em clusters separados e garantir mais recursos para o ambiente de testes ao ambiente de produção e ainda deixar os ambientes mais isolados utilizando portas distintas. Sempre utilize discos separados para o ambiente de produção, mesmo que esteja utilizando um cluster separado ou até mesmo uma máquina virtual XEN. Se você estiver num ambiente de produção mais exigente em termos de I/O, vai descobrir logo que mesmo com discos distintos, o limite de banda do próprio barramento interno do servidor pode se esgotar!

• Você precisa de bancos de dados com codificações de caractere diferentes. Seria ideal você pensar em utilizar utf-8 para todas as bases se você está nesta situação. Mas isto é uma longa conversa, para lá de complicada. Em todo caso, você vai descobrir que terá problemas em manter bases com diferentes codificações de caractere. Há um certo consenso de que o futuro é o UTF-8, e há quem diga que até o Windows vai trabalhar direito com ele um dia.

• Você precisa de configurações de desempenho diferentes para diferentes aplicações (OLTP x BI por exemplo). Bom, você pode fazer isso com esquema também, mas pode não ser tão simples se cada usuário da aplicação possuir uma conta de usuário no banco de dados. No entanto, se você quer levar isto realmente a sério, é melhor criar clusters distintos e melhor ainda, utilizar servidores distintos para cada aplicação. Afinal, você precisa de mais desempenho, não é mesmo?

Conclusão:
Se mais de uma aplicação podem conviver no mesmo servidor e no mesmo cluster, então elas podem estar no mesmo banco de dados. Existem raros casos em que isto não se aplique… mas são exceções e não a regra.

O Oracle possui várias formas de se rastrear uma conexão e saber o que está ocorrendo por lá. Você pode utilizar gatilhos (particularmente os gatilhos de sistema são muito interessantes) pode utilizar o comando AUDIT, pode utilizar o TRACE e a versão 10g traz recursos ainda mais sofisticados para rastrear suas aplicações. Se você está procurando por problemas de performance, provavelmente o TRACE será uma boa opção, pois traz para você o resultado dos planos de consulta da sessão sem você ter de conhecer muitos detalhes sobre como ele funciona.

Rastrear uma sessão é bastante simples, o problema é que muitas vezes eu preciso rastrear a conexão de uma aplicação de terceiros, onde eu não tenho acesso ao código fonte da aplicação. Em geral, eu preciso fazer isso num ambiente de produção, portanto rastrear todas as conexões do banco de dados é absolutamente proibitivo! Em resumo, preciso rastrear um sessão que não é minha. Como a documentação do Oracle é um pouco vaga neste ponto específico, achei melhor documentar o processo.

Vejamos como fazer:

1. Conheça os parâmetros de inicialização:
   Existem alguns parâmetros que devem ser ajustados/conhecidos antes de se utilizar o TRACE Você pode dar uma olhada em quais valores estão ativos no momento utilizando a visão v$parameter.
   1. STATISTICS_LEVEL: Se você ajustar este parâmetro para ‘ALL’ estará automaticamente rastreando todas as sessões (não recomendado em ambiente de produção) além de uma série de outras estatísticas. O valor padrão é ‘TYPICAL’ e não costuma ser uma boa idéia alterar este valor na inicialização. No entanto, você pode utilizar o comando ALTER SESSION para ativar a coleta de estatísticas apenas na sua sessão. Se quiser saber afinal o que muda se você alterar este parâmetro, veja a visão v$statistics_level.
   2. SQL_TRACE: Este parâmetro está em desuso e não deve ser utilizado. Ele também ativa o rastreamento dos comandos SQL, mas existem formas mais elegantes de se fazer isso;
   3. TIMED_STATISTICS: Este sim é o parâmetro que nos interessa! Mas é a forma mais utilizada para rastrear uma conexão. No entanto, há apenas um detalhe… você só pode alterar o seu valor para uma instancia ou para a sua própria sessão (assim como o SQL_TRACE e o STATISTICS_LEVEL).
   4. MAX_DUMP_FILE_SIZE: Este parâmetro é importante pois ele limita o tamanho dos seus arquivos gerados pelo rastreamento. Vale a pena conferir para ver se ele atende às suas necessidades. O valor padrão é ilimitado, mas se você pensa em deixar o rastreamento ativado por longos períodos, é bom pensar num limite razoável.
   5. USER_DUMP_DEST: Este parâmetro diz em qual local os arquivos de rastreamento serão criados. O valor padrão é ‘$ORA_HOME/admin/$ORA_SID/udump/’ mas você pode altera-lo, principalmente se precisar de mais espaço em disco.
2. Descubra qual é a sessão que você deseja rastrear:
   Para isso faça com que a aplicação se conecte e saiba qual é o usuário utlizado pela aplicação e rode o seguinte script:
   SELECT sid, serial#, username FROM v$session WHERE username = 'FOO';
   Você utilizará o ’sid’ e o ’serial#’ para ativar e desativar o rastreamento.
3. Ative o rastreamento:
   Se você deseja ativar o rastreamento da sua própria sessão, um simples
   ALTER SESSION SET SQL_TRACE = TRUE;
   é suficiente. Para alterar outra sessão se conecte como sysdba e rode o seguinte comando:
   EXEC sys.dbms_system.set_sql_trace_in_session(sid,serial#,TRUE);
   substituindo ’sid’ e ’serial#’ pelos valores obtidos pelo select anterior e ‘foo_trace’ por uma string a ser utilizada para nomear o arquivo gerado.
4. Libere o usuário para realizar as ações que você deseja rastrear;
5. Rode o comando a seguir para terminar o rastreamento:
   EXEC sys.dbms_system.set_sql_trace_in_session(sid,serial#,FALSE);
6. Procure na pasta indicada pelo parâmetro ‘USER_DUMP_DEST’ . Podem haver vários arquivos lá, então tente encontrar o arquivo referente ao seu rastreamento pela data;
7. Rode na linha de comando do seu SO o comando tkprof para formatar a saida para um formato mais legível:
   $ tkprof arquivo_trace arquivo_final.txt
   onde ‘arquivo_trace’ é o nome do arquivo gerado pelo rastreamento e ‘arquivo_final.txt’ é o arquivo a ser criado com o resultado do rastreamento formatado.

O planejamento é uma das fases mais delicadas do processo. Você deve realmente dedicar um bom período para ele e estar pronto para corrigir o processo todo no meio do caminho. Há uma série de decisões para serem tomadas no caminho e você deve conhecer bem as possibilidades para fazer uma migração bem feita.

O cronograma

A primeira coisa é prever um calendário generoso que contenha ao menos as seguintes etapas:

• Estudo das novas funcionalidades. Leia a documentação oficial da Oracle. Conheça as novas funcionalidades, limitações e facilidades. Verifique atentamente as suas opções de licenciamento e verifique quais são as suas necessidades reais.

• Disponibilize um ambiente de teste dedicado. Você deve ter um servidor dedicado exclusivamente para os seus testes. Você terá de reiniciar o servidor, particionar discos e fazer tarefas que exigem um servidor exclusivo. Não tente compartilhar ele com outro ambiente, mesmo que ele seja de teste também.

• Testes o desempenho. Para os testes iniciais, um servidor mais simples pode dar conta. Mas se você se preocupa com testes comparativos de performance, um ambiente de homologação semelhante ao de produção é fundamental. A configuração de discos e memória mudam bastante no 10g em relação às versões anteriores e você deve estar apto a decidir qual é a configuração ideal para o seu servidor antes dele entrar em produção.

• Documentação do processo. Você deve anotar todo o processo de forma a tornar qualquer pessoa capaz de reproduzir ele sem a sua presença. Tire o tempo que for necessário para isso. Não deixe de anotar detalhes, ajustes finos no servidor, alterações sutis e pequenos passos que possam passar desapercebidos.

• Criação de scripts para agilizar a migração do ambiente de produção. A partir da sua documentação crie um conjunto de scripts para automatizar um pouco o seu processo. Faça scripts separados para bancos de dados distintos. Os scripts vão fazer você ganhar agilidade na hora H além de diminuir a chance de você cometer erros.

• Teste cronometrado da migração. Depois que todos a documentação estiver pronta junto com os scripts, faça uma simulação final da migração o mais realista possível, utilizando os seus scripts e seguindo rigorosamente a sua documentação. Corrija a documentação tiver que alterar alguma coisa no caminho.

• Agende a migração do ambiente de produção para um final-de-semana ou feriado prolongado, em uma época que não for crítica para os negócios (como época de lançamento de folha de pagamento, fechamento de ano fiscal, etc).

• Monitore atentamente o servidor depois que ele entrar em produção: não agente nenhuma outra tarefa para o período imediatamente após a migração. Você precisará estar 100% atento para eventuais problemas que possam surgir. Se você estiver muito esgotado antes da migração, considere tirar uns dias de folga antes da migração (já que você vai ter que trabalhar no final-de-semana).
• Após estabilizar o ambiente de produção, lembre-se de migrar também o ambiente de homologação e de testes também.

Lembre-se que muitos problemas vão surgir durante os testes e você terá que pesquisar novas soluções no meio do caminho. Algumas decisões você só poderá tomar depois de testar algumas coisas, então é possível prever com segurança quando você poderá agendar a migração do ambiente de produção.

As decisões

Uma parte difícil do processo é tomar algumas decisões. Algumas você só descobrirá no meio do projeto, mas posso lhe adiantar algumas. Vou aproveitar aqui para explorar algumas mudanças que poderiam ser feitas na versão atual, mas que por ocasião da migração podem se tornar interessantes.

• Devo instalar a interface gráfica no meu servidor? 10 em 10 administradores de sistemas em Linux respeitáveis lhe dirão NÃO. Mas em se tratando de Oracle, alguns podem abrir exceções. Se as pessoas responsáveis pela manutenção do Sistema Operacional e pela instalação do Oracle estão presentes e se sentem a vontade com o procedimento, não há porque instalar a interface gráfica. Mas parece que muitos DBAs tem dificuldade de instalar o Oracle em Linux e não se acertam bem com o administrador de sistema responsável pelo SO. A própria documentação da Oracle dá pouca ênfase ao processo de instalação sem utilizar a interface gráfica. Vale a pena testar ambos os métodos. Eu realmente prefiro não utilizar a interface gráfica quando possível pois:
  • Você economiza recursos do sistema, principalemente memória;
  • Você tem um menor número de falhas de segurança no seu servidor;
  • No dia-a-dia de um DBA ou de um administrador de sistemas, o SSH é a ferramenta mais utilizada e não a interface gráfica;
  • Você pode utilizar todas as ferramentas clientes remotamente: sqlplus, Enterprise Manager (a versão client-server), SQL Developer, etc;
  • A instalação e a atualização do servidor se tornam muito mais simples;
  • O processo de instalação sem interface gráfica é mais rápido e mais fácil de ser reproduzido sem erros.
• Devo utilizar a migração automática do servidor? A Oracle disponibiliza uma ferramenta para migração automática do servidor de 9i para 10g. Apesar de poder tornar o processo mais simples e rápido, deixa pouca margem para ajustes no meio do caminho. Se o tempo for um limitador muito grande, a migração automática pode ser uma opção, mas se puder evite.
• Devo instalar as ferramentas web? O Oracle 10g traz duas ferramentas web que rodam no mesmo servidor que o banco de dados.
  • O iSQLplus é uma ferramenta leve mas que também não ajuda muito. O uso do SQLplus original ou o SQL Developer são mais recomendados. O iSQLplus pode ser interessante por ser web, mas é bom lembrar que a sua distribuição foi descontinuada no 11g;
  • O Enterprise Manager ou Database Control é uma ferramenta muito interessante e um pouco mais pesada. É particularmente interessante para quem comprou os pacotes extras para a versão Enterprise. Vale a pena experimentar para conhecê-la. Vale a pena lembrar que a versão cliente-servidor do Enterprise Manager foi descontinuada no 11g.
• Devo utilizar o ASM (Automatic Storage Management) ou RAW Devices? Esta é uma dúvida realmente difícil. O ASM é realmente uma grande novidade na versão 10g. O ASM é um pouco mais lento que o RAW Devices mas tras a possibilidade de fazer o balanceamento dos datafiles entre diversos discos. Se você procura extrair até a última gota de desempenho do seu SGDB, o RAW Device é uma opção extrema. O ASM pode ser muito interessante se você dispões de vários discos ou arranjos em RAID e possue centenas de datafiles que precisam ser distribuídos. Particularmente eu prefiro utilizar os sistemas de arquivos pois consigo ter acesso aos arquivos do banco de dados através do Sistema Operacional. Mesmo em ambientes RAC, o OCFS2 é amplamente utilizado no lugar do ASM ou dos RAW Devices. No entanto, se você já utiliza opções como o Data Guard e o RMAN, o acesso aos arquivos podem ser menos vital. Em geral, nas versões Standard do Oracle, você tem menos recursos da própria Oracle para manipular os arquivos então não é uma boa idéia utilizar o ASM ou RAW Devices neste ambiente.

• Devo utilizar o bigfile? No Oracle 10g você pode criar datafiles com tamanhos realmente enormes! Isto pode facilitar muito a administração dos arquivos do banco de dados. Até a versão 8 do Oracle, havia uma recomendação para não criar datafiles maiores de 250MB. Esta limitação deixou de existir na versão 9, mas alguns DBAs preferem evitar arquivos muito maiores do que 1GB para facilitar o trabalho de movimentação destes entre discos. Com a nova orientação de criar grandes RAIDs 0+1, o uso de arquivos grandes se tornou mais comum, tendendo a se criar um datafile por TABLESPACE. Se você tem TABLESPACES realmente grandes, cabe a você olhar para a sua estrutura de Storage e avaliar isso.

• Devo utilizar o gerenciamento automático de memória? Uma facilidade interessante no 10g é poder deixar o próprio Oracle distribuir dinamicamente os buffers disponíveis para os processos do Oracle. Eu acredito que esta seja uma funcionalidade que você deve utilizar a menos que você seja um mestre nesta área. É claro que você pode impor limites para este gerenciamento automático, impondo limites mínimos para algumas áreas. Somente uma homologação com testes de carga muito bem realizados poderão lhe dizer se o desempenho vai melhorar ou não com o gerenciamento automático. Monitore com cuidado o servidor em produção e guarde as configurações utilizadas no 9i debaixo do braço em todo caso. A versão 11g inclui novas melhorias no gerenciamento automático de memória estendendo o gerenciamento a PGA, além da SGA.

Não existem fórmulas mágicas para responder estas questões, mas é bom saber que elas existem e estar pronto para tomar decisões antes de migrar definitivamente. Algumas decisões são fáceis de serem alteradas mesmo depois da migração estar concluída, como a parte de memória ou de ferramentas, mas particularmente as decisões a respeito de Storage são difíceis de serem revertidas e devem ser tomadas com muito cuidado.

Após o Jack me mandar o link para esta geladeira da LG fiquei imaginando coisas bacanas que poderiam inventar…

• Autenticação biométrica para a gaveta de cervejas;
• OverClocking com processador no freezer;
• Sensor para avisar quando a cerveja já gelou;
• Sensor para saber quando acabaram as cervejas;
• Cluster de eletrodomésticos?
• Home server com servidor de arquivos, e-mail, proxy, firewall, e stream de vídeo e áudio. A geladeira já está sempre ligada e o seu processador nunca vai esquentar, então é um bom lugar para um servidor 24×7!

Convido para dar as suas sugestões:

Jack, Fike, Everaldo, Mussi e Anderson. Gostaria de saber o que o Sr. Nicholas Negroponte diria sobre isso, mas acho que ele não acompanha meu blog (preciso começar a escrever em inglês) ;-p