Este é a primeira parte de uma série de três textos que quero escrever sobre sobre o Log de Transações de SGDBs. A primeira parte é uma explicação inicial sobre o que é um log de transações e para que ele serve. Espero escrever em breve mais duas partes falando mais detalhadamente sobre como uma transação ocorre dentro do SGDB e outra falando sobre configurações de Alta Disponibilidade e desempenho envolvendo o Log de Transações.
D
Todo SGDB relacional que eu conheço usa logs de transação. O Oracle chama isso de “Redo Log” o PostgreSQL chama de “Write Ahead Log”, o DB2 chama de “Active Log” e o MySQL chama de “Binary Log”, mas todos tem. O log de transações é uma forma engenhosa dos SGDBs conseguirem garantir o “D” do ACID. A questão é simples: você precisa garantir que após a conclusão com sucesso de uma transação, com um COMMIT, este dado dure no banco de dados, mesmo que alguma falha aconteça, como a falta de luz. Isto significa que de alguma forma os dados devem ser gravados em disco e não estarem simplesmente na memória. Esta é uma exigência que tem um profundo impacto no projeto de um SGDB. Para lidar com isso, a melhor forma de garantir isso não é gravar os dados direto nos datafiles. Este tipo de gravação tem um custo alto pois:
- A órdem da gravação é randômica;
- Uma operação de UPDATE pode fazer com que os dados que antes cabiam num bloco de dados não caibam mais, exigindo algum tipo de reorganização;
- Você tem que atualizar não só os dados como os índices também;
- Você tem que gerenciar o espaço livre em disco;
- Um mesmo dado pode ser alterado várias vezes num curto espaço de tempo;
É claro que em algum momento você deverá gravar todos os dados alterados, mas os SGDBs preferem gravar os dados a partir dos buffers em memória onde eles tem algorítimos que gerenciam a operação de gravação em disco com muito mais eficiência. Então o que ocorre é que o SGDB trabalha com os buffers de memória o tempo todo e grava os dados destes buffers nos datafiles de tempos em tempos, num processo conhecido como “Checkpoint”.
Bom, eu disse que a cada COMMIT, você precisa gravar em disco as informações sobre os dados alterados. Se houver uma falta de energia depois do COMMIT e antes do Checkpoint você terá problemas! O que é feito é criar um log com todas as alterações realizadas nos dados. Este log tem de seguir rigorosamente a lógica de realizar uma gravação para cada transação confirmada. No caso de uma falta de energia, ao reiniciar o servidor, o SGDB vai utilizar o log de transação para recuperar todas as transações concluídas depois do último Checkpoint. É assim que o “D” do ACID é garantido.
Arquivamento
Os logs de transação são um mal necessário. É um mal porquê ele é um grande gargalo de desempenho no SGDB. É necessário porquê você não está disposto a arcar com os riscos de perder os seus dados. Para ter um impacto de desempenho menor, a gravação dos logs é sempre feita de forma sequêncial e não aleatória. Ou seja o log é um arquivo que vai crescendo de forma incremental. No entanto estes logs não crescem de maneira indefinida. Eles possuem um formato finito e quando o arquivo atinge este tamanho ele inicia um novo arquivo de log.Os arquivos de logs trabalham de forma rotativa, reaproveitando arquivos de logs antigos. Uma coisa importante a saber sobre eles é que eles tem tamanho e quantidade predefinidas. Alguns SGDBs tem maior ou menor facilidade em configurar opções neste sentido. Em ambientes de teste, o reaproveitamento dos logs não constitui um problema, mas em ambientes de produção é importante realizar uma cópia dos logs antes deles serem reaproveitados. A cópia destes logs é conhecida como arquivamento. O arquivamento é fundamental para a recuperação no caso de perda um datafile. Se você tiver perdido um datafile, você pode recuperar ele de um backup realizado em fita ou outro meio. No entanto, este datafile estará com as informações desatualizadas a partir da data do backup. É aí que os log arquivados entram em ação. Após recuperar o datafile, você pode utilizar todos os logs arquivados após o backup para recriar as transações naquele datafile específico. Desta forma, uma boa estratégia de backup em ambiente de produção deve incluir o backup físico dos datafiles e a realização do arquivamento dos logs de trasação.
Além disso, graças ao arquivamento dos logs, alguns recursos interessantes podem ser implementados, como veremos a seguir.
Point In Time Recovery (PITR):
O PITR é um recurso sofisticado que lhe possibilita realizar não apenas recuperar os seus dados em caso de uma falha, mas voltar para um ponto específico no tempo, como alguns minutos antes de alguém apagar uma tabela ou realizar alguma outra transação catastrófica. O PITR pode ser uma verdadeira máquina do tempo. Algumas ferramentas de PITR permitem restaurar apenas uma parte dos dados para um ponto no passado.
Backup On Line
O backup físico do banco de dados (em contraste com o backup lógico) é uma parte fundamental numa estratégia de recuperação de desastres. A forma mais comum de fazer isso é desativar totalmente o SGDB e copiar todos os arquivos do banco de dados (tente um dia copiar estes arquivos com o SGDB no ar e você verá o seu emprego sumindo sob os seus pés como num alçapão). Os backups físicos deste tipo são conhecidos como backup off line. Eles funcionam muito bem, mas podem ser um problema em ambientes 24/7. A cópia dos arquivos pode demorar algumas horas e ficar se backup não costuma ser uma idéia muito inteligente. Graças a existência dos logs de transação, é possível realizar o chamado backup on line onde o backup físico pode ser realizado sem tirar o SGDB do ar. No backup on line o processo de backup envia um comando para o SGDB que adia a realização do Checkpoint e os datafiles podem ser copiados mesmo com o banco de dados no ar. Assim que a cópia termina, um novo comando é enviado para o SGDB e o Checkpoint é liberado. Alguns SGDBs permitem que o backup on line seja feito para cada TABLESPACE individulmente. Em bancos de dados muito grandes ou com um grande volume de transações, isto pode ser uma boa idéia, pois você adia o Checkpoint somente para um TABLESPACE de cada vez.
Um detalhe importante é que para realizar backups on line, o arquivamento dos logs se torna obrigatório!
Stand By
Um outra coisa muito interessante que é possível se fazer com os logs de arquivamento, é a criação do SGDB em Stand By e outras técnicas de replicação Master/Slave. A idéia é simples: você pode criar um clone do seu servidor de produção num servidor secundário conhecido como Stand By e deixar ele sincronizado com o seu servidor de produção. Para isso você tem de criar outro SGDB idêntico e com uma cópia idêntica dos datafiles (backup off line). A partir do momento em que os servidor de produção volta ao ar após a cópia dos datafiles, você passa a exportar os log do ambientes de produção para o Stand By. Em caso de falha do ambiente de produção, você pode subir o Stand By que irá recuperar todos os logs arquivados até atingir a mesma posição do ambiente de produção.
O Stand By consistem um plano de contingência muito interessante e pode ter diferentes tipos implementações com características peculiares:
- Normalmente os logs são exportados do ambiente de produção somente no momento do arquivamento, portando o o Stand By está sempre um pouco defasado em relação ao ambiente de produção. Existem soluções de Stand By que são síncronas e só realizam o COMMIT após a confirmação da gravação do log no servidor de produção e no Stand By. Este tipo de solução, torna a gravação dos logs de transação um gargalo de desempenho ainda maior e devem ser implementados com cautela e uma excelente conexão de rede entre os servidores de produção e Stand By.
- Normalmente os logs só são importados no Stand By no momento em que ele é ativado (o SGDB fica inativo por padrão) e então o processo de recuperação dos logs é iniciado. É possível realizar recuperações programadas num intervalo regular de tempo para não acumular uma quantidade de logs muito grande para serem recuperados. Em outros casos, é utilizado o Stand By on line, onde os SGDB fica sempre no ar e vai aplicando os logs imediatamente após ele receber os logs do servidor de produção. Com o Stand By on line, é possível utilizar ele para realizar consultas, mas não para realizar gravações. Um Stand by on line pode ser muito útil para extrair relatórios pesados sem sobrecarregar as operações de OLTP no ambiente de produção;
- Normalmente os dados relativos ao Stand By se aplicam a todos os dados existentes na instância de produção. Existem implementações de Stand By que filtram os logs da instância de produção, replicando apenas uma parte objetos no banco de dados de produção.
