Captulo 25.

Registro prvio da escrita (WAL) O registro prvio da escrita (WAL = write ahead logging) uma abordagem padro para registrar transaes. A descrio detalhada pode ser encontrada na maioria (se no em todos) os livros sobre processamento de transao. Em poucas palavras, o conceito central do WAL que as alteraes nos arquivos de dados (onde as tabelas e os ndices residem) devem ser escritas somente aps estas alteraes terem sido registradas, ou seja, quando os registros que descrevem as alteraes tiverem sido descarregados em um meio de armazenamento permanente. Se este procedimento for seguido, no ser necessrio descarregar as pginas de dados no disco a cada efetivao de transao, porque se sabe que no evento de uma queda ser possvel recuperar o banco de dados utilizando o registro: todas as alteraes que no foram aplicadas s pginas de dados so refeitas a partir dos registros (isto a recuperao de rolar para a frente, roll-forward, tambm conhecida como REDO), 25.1. Benefcios do WAL O primeiro grande benefcio da utilizao do WAL a reduo significativa do nmero de escritas em disco, uma vez que na hora em que a transao efetivada somente precisa ser descarregado em disco o arquivo de registro, em vez de todos os arquivos de dados modificados pela transao. Em ambiente multiusurio, a efetivao de vrias transaes pode ser feita atravs de um nico fsync() do arquivo de registro. Alm disso, o arquivo de registro escrito seqencialmente e, portanto, o custo de sincronizar o registro muito menor do que o custo de descarregar as pginas de dados. Isto especialmente verdade em servidores tratando muitas transaes pequenas afetando partes difereztes do armazenamento de dados. O benefcio seguinte a consistncia das pginas de dados. A verdade que antes do WAL o PostgreSQL nunca foi capaz de garantir a consistncia no caso de uma queda. Antes do WAL, qualquer queda durante a escrita poderia resultar em: 1. linhas de ndice apontando para linhas inexistentes da tabela 2. perda de linhas de ndice nas operaes de quebra de pgina (split) 3. contedo da pgina da tabela ou do ndice totalmente corrompido, por causa das pginas de dados parcialmente escritas Os problemas com os ndices (problemas 1 e 2) possivelmente poderiam ter sido resolvidos atravs de chamadas adicionais funo fsync(), mas no bvio como tratar o ltimo caso sem o WAL; se for necessrio, o WAL salva todo o contedo da pgina de dados no registro, para garantir a consistncia da pgina na recuperao aps a queda. Por fim, o WAL permite que seja feita cpia de segurana em linha e recuperao para um ponto no tempo, conforme descrito na Seo 22.3. Fazendo cpia dos arquivos de segmento do WAL pode-se retornar para qualquer instante no tempo coberto pelos registros do WAL: simplesmente se instala uma verso anterior da cpia de segurana fsica do banco de dados, e se refaz o WAL at o ponto desejado no tempo. Alm disso, a cpia de segurana fsica no precisa ser um instantneo do estado do banco de dados se a cpia for realizada durante um perodo de tempo, quando o WAL for refeito para este perodo de tempo da cpia sero corrigidas todas as inconsistncias internas. 25.2. Configurao do WAL Existem diversos parmetros de configurao relacionados com o WAL que afetam o desempenho do banco de dados. Esta seo explica como defini-los. Para obter detalhes gerais sobre como definir parmetros de configurao para o servidor deve ser consultada a Seo 16.4 . Os pontos de controle (checkpoints) so pontos na seqncia de transaes onde se garante

que os arquivos de dados foram atualizados com todas as informaes registradas antes deste ponto. No momento do ponto de controle, todas as pginas de dados sujas (dirty) so descarregadas no disco, e escrito um registro especial de ponto de controle no arquivo de segmento do WAL. Como resultado, no caso de uma queda o procedimento de recuperao sabe a partir de qual ponto do WAL (chamado de registro de refazer (REDO)) deve comear a operao de refazer, uma vez que todas as mudanas feitas nos arquivos de dados anteriores a este ponto j se encontram gravadas em disco. Aps ter sido feito o ponto de controle, nenhum dos arquivos de segmento do WAL, escritos antes do registro de refazer, continua sendo necessrio, podendo ser reciclados ou removidos (Quando est sendo feita cpia dos arquivos de segmento do WAL, os arquivos de segmento devem ser copiados antes de serem reciclados ou removidos). O processo de escrita em segundo plano do servidor realiza, automaticamente, um ponto de controle de tempo em tempo. Um ponto de controle realizado a cada checkpoint_segments do WAL, ou a cada checkpoint_timeout segundos, o que ocorrer primeiro. As definies padro so 3 segmentos e 300 segundos, respectivamente. Tambm possvel obrigar a realizao de um ponto de controle utilizando o comando SQL CHECKPOINT. Reduzir checkpoint_segments e/ou checkpoint_timeout faz os pontos de controle serem feitos com maior freqncia, permitindo uma recuperao mais rpida aps a queda (uma vez que haver menos trabalho para ser refeito). Entretanto, deve haver um balano entre isto e o aumento de custo causado pela descarga das pginas sujas com maior freqncia. Alm disso, aps cada ponto de controle, para garantir a consistncia das pginas de dados, a primeira modificao feita em uma pgina de dados ocasiona o registro de todo o contedo desta pgina. Por isso, um intervalo de ponto de controle menor aumenta o volume de sada para o WAL, negando parcialmente o objetivo de utilizar um intervalo menor e, em qualquer caso, causando mais E/S em disco. Os pontos de controle so muito dispendiosos, primeiro porque requerem a escrita de todos os buffers sujos correntes, e depois porque resultam em um trfego adicional subseqente para o WAL, conforme visto acima. Portanto, aconselhvel definir os parmetros do ponto de controle altos o suficiente para que no ocorram com muita freqncia. Como uma verificao de sanidade simples para os parmetros de ponto de controle, pode ser definido o parmetro checkpoint_warning. Se os pontos de controle ocorrerem antes de checkpoint_warning segundos, ser gerada uma mensagem para o log do servidor recomendando o aumento de checkpoint_segments. Uma apario ocasional desta mensagem no motivo de alarme, mas se aparecer com freqncia ento os parmetros de controle de ponto de verificao devem ser aumentados. H pelo menos um arquivo de segmento e, normalmente, no mais de 2 * checkpoint_segments + 1 arquivos de segmento do WAL. Normalmente cada arquivo de segmento possui o tamanho de 16 MB (embora este tamanho possa ser alterado na construo do servidor). Isto pode ser utilizado para estimar a necessidade de espao do WAL. Normalmente, quando os arquivos de segmento do WAL antigos no so mais necessrios, estes so reciclados (os nome so mudados para se tornarem os prximos segmentos da seqncia numerada). Se, por causa de um pico de pouca durao da taxa de sada para o WAL, existirem mais de 2 * checkpoint_segments + 1 arquivos de segmento, os arquivos de segmento desnecessrios sero removidos em vez de reciclados at o sistema voltar a ficar abaixo deste limite. Existem duas funes do WAL utilizadas com freqncia: LogInsert e LogFlush. A funo LogInsert utilizada para colocar um novo registro nos buffers do WAL na memria compartilhada. Se no houver espao para o novo registro, LogInsert ter que escrever (mover para o cache do ncleo) uns poucos buffers do WAL cheios. Isto no desejado, porque LogInsert utilizada em todas as modificaes de baixo nvel do banco de dados (por exemplo, insero de linha), quando um bloqueio exclusivo mantido nas pginas de dados afetadas, portanto esta operao precisa ser to rpida quanto for possvel. O que pior, escrever os buffers do WAL tambm pode obrigar a

criao de um novo arquivo de segmento, que toma mais tempo ainda. Normalmente, os buffers do WAL devem ser escritos e descarregados pela chamada LogFlush que feita, na maioria das vezes, na hora da efetivao da transao para garantir que os registros da transao sejam descarregados no armazenamento permanente. Nos sistemas com sada para o WAL alta, as chamadas LogFlush podem no ocorrer com uma freqncia suficiente para evitar que LogInsert tenha que realizar escritas. Nestes sistemas, deve ser aumentado o nmero de buffers do WAL pela modificao do parmetro wal_buffers. O nmero padro de buffers do WAL 8. O aumento deste valor aumenta de forma correspondente a utilizao de memria compartilhada (Deve ser observado que no momento existe pouca evidncia sugerindo que aumentar wal_buffers acima do padro valha a pena). O parmetro commit_delay define a quantidade de microssegundos que o processo servidor vai aguardar aps escrever um registro de efetivao no WAL com LogInsert, antes de realizar o LogFlush. Este retardo permite que outros processos servidor adicionem seus registros de efetivao ao WAL para que todos sejam descarregados em uma nica sincronizao do WAL. No ocorre nenhum retardo quando fsync no est habilitado, nem se menos de outras commit_siblings sesses estiverem com transaes ativas no momento; isto evita o retardo quando pouco provvel que outras sees efetivem em breve. Deve ser observado que na maioria das plataformas a resoluo de uma solicitao de retardo de dez milissegundos, portanto qualquer definio de commit_delay diferente de zero e entre 1 e 10000 microssegundos produz o mesmo efeito. Ainda no est claro quais so os melhores valores para estes parmetros; incentiva-se que sejam feitas experincias. O parmetro wal_sync_method determina como o PostgreSQL vai fazer a solicitao ao ncleo para forar o envio das atualizaes do WAL para o disco. Todas as opes devem ser idnticas em termos de confiabilidade, mas bem especfico da plataforma qual delas a mais rpida. Deve ser observado que este parmetro irrelevante se fsync estiver desabilitado. Habilitar o parmetro de configurao wal_debug (desde que o PostgreSQL tenha sido compilado com suporte ao mesmo) resulta em que cada chamada s funes LogInsert e LogFlush feita pelo WAL seja registrada no log do servidor. Esta opo poder ser substituda por um mecanismo mais genrico no futuro. 25.3. Internamente O WAL habilitado automaticamente; no requerida nenhuma ao por parte do administrador, exceto garantir que o espao em disco adicional necessrio para o WAL seja atendido, e que seja feito qualquer ajuste necessrio (consulte a Seo 25.2). O WAL armazenado no diretrio pg_xlog, sob o diretrio de dados, como um conjunto de arquivos de segmento, normalmente com o tamanho de 16 MB cada. Cada segmento dividido em pginas, normalmente de 8 kB cada. Os cabealhos dos registro esto descritos em access/xlog.h; o contedo do registro depende do tipo de evento que est sendo registrado. So atribudos para nomes dos arquivos de segmento nmeros que sempre aumentam, comeando por 000000010000000000000000. Atualmente os nmeros no recomeam, mas deve demorar muito tempo at que seja exaurido o estoque de nmeros disponveis. Os buffers do WAL e estruturas de controle ficam na memria compartilhada e so tratados pelos processos servidor filhos; so protegidos por bloqueios de peso leve. A demanda por memria compartilhada dependente do nmero de buffers. O tamanho padro dos buffers do WAL 8 buffers de 8 kB cada um, ou um total de 64 kB. vantajoso o WAL ficar localizado em um disco diferente do que ficam os arquivos de banco de dados principais. Isto pode ser obtido movendo o diretrio pg_xlog para outro local (enquanto o servidor estiver parado, bvio), e criando um vnculo simblico do local original no diretrio de dados principal para o novo local.

A finalidade do WAL, garantir que a alterao seja registrada antes que as linhas do banco de dados sejam alteradas, pode ser subvertida pelos controladores de disco (drives) que informam ao ncleo uma escrita bem-sucedida falsa, e na verdade apenas colocam os dados no cache sem armazenar no disco. Numa situao como esta a queda de energia pode conduzir a uma corrupo dos dados no recupervel. Os administradores devem tentar garantir que os discos que armazenam os arquivos de segmento do WAL do PostgreSQL no fazem estes falsos relatos. Aps um ponto de controle ter sido feito e o registro descarregado, a posio do ponto de controle salva no arquivo pg_control. Portanto, quando uma recuperao vai ser feita o servidor l primeiro pg_control, e depois o registro de ponto de controle; em seguida realiza a operao de REDO varrendo para frente a partir da posio indicada pelo registro de ponto de controle. Como, aps o ponto de controle, na primeira modificao feita em uma pgina de dados salvo todo o contedo desta pgina, todas as pginas modificadas desde o ltimo ponto de controle sero restauradas para um estado consistente. Para tratar o caso em que o arquivo pg_control foi corrompido, necessrio haver suporte para a possibilidade de varrer os arquivos de segmento do WAL em sentido contrrio mais novo para o mais antigo para encontrar o ltimo ponto de controle. Isto ainda no foi implementado. O arquivo pg_control pequeno o suficiente (menos que uma pgina de disco) para no estar sujeito a problemas de escrita parcial, e at o momento em que esta documentao foi escrita no haviam relatos de falhas do banco de dados devido unicamente a incapacidade de ler o arquivo pg_control. Portanto, embora este seja teoricamente um ponto fraco, na prtica o arquivo pg_control no parece ser um problema.