checkpointing: desa os em sistemas distribu dos e em ...islene/speechs/ckpt-sd-bd.pdf ·...

Checkpointing: desafios em sistemas distribuıdos eem bancos de dados

Islene Calciolari Garcia

Instituto de Computacao - Unicamp

VIII ERBD - Escola Regional de Bancos de Dados 2012PUCPR—Curitiba

Bom dia!

Um pouco sobre mim...

Formacao e Filiacao:

Instituto de Computacao, Unicamp

Interesses de pesquisa:

Checkpointing

Sumario

1 Motivacao

2 Consistenciaem sistemas distribuıdosem bancos de dadosOutros nıveis de isolamentoResumo

3 RecuperacaoConceitos basicosAlgoritmo simplificadoARIESExemplos

4 Conclusao e desafios futuros

MotivacaoConsistenciaRecuperacao

Conclusao e desafios futurosReferencias

Motivacao

Construcao de sistemas tolerantes a falhas

Defeitos previsıveis de hardwareGrandes desastres

Desempenho, disponibilidade

Islene Calciolari Garcia Checkpointing: desafios em SD e BD



Objetivos do minicurso

Aprofundamento do conceito de consistencia

util para implementacao de mecanismos de recuperacaoutil para o desenvolvimento de aplicacoes

Recuperacao e checkpointing

Bancos de dados reais

Software LivreComo colaborar


Sumario

1 Motivacao






em sistemas distribuıdosem bancos de dadosOutros nıveis de isolamentoResumo

Consistencia

www.CartoonStock.com

Essencial para odesenvolvimento dealgoritmos eficientes

Modelos computacionais

Sistemas distribuıdosBancos de dados


Sumario

1 Motivacao







Sistemas distribuıdos

N Processos

Eventos internos, envio e recepcao de mensagens

Ausencia de relogio global

p2 -s s s s s ��s s �

��sp1 -s sAAU

s sAAU

s s s s ��s sp0 -sAAU

s s s s sAAU

s s s s





Checkpointing

Estados selecionados

Abstracao da computacao

p2 -� � ��

� ��

p1 -�AAU

�AAU

� ��

p0 -�AAU

�AAU

�





Checkpoint global consistente

Observador onisciente externo

Define um instante na computacao (snapshot)

p2 -� ��

� � ��

p1 -�AAU

�AAU

� ��

p0 -�AAU

�AAU

�

@@��





Checkpoint global inconsistente

Mensagens podem ser perdidas

mas nao podem vir do futuro

p2 -� ��

� � ��

p1 -�AAU

�AAU

� ��

p0 -�AAU

�AAU

�

@@��

@@��

��





Efeito domino

p0 � �AAAUm2

�AAAUm4

�@falha

p1 -� ��m1

� ��m3

��@

�@

�@

�@


Sumario

1 Motivacao







Bancos de dados

Dados (tabelas, objetos, tuplas)

Operacoes:

create, dropinsert, deleteselect, update

Transacoes

Definir consistencia e mais facil ou mais difıcil?Obter uma visao global e trivial?





Transacoes

Sequencias de operacoes que sao tratadas como uma unidade

Propriedades ACID

AtomicidadeConsistenciaIsolamentoDurabilidade

T1

T2

T3

T4





Snapshot, backup ou dump

Como obter um estado consistente utilizando transacoes?

Como fazer isso de forma eficiente?

T1

T2Ts

T3

T4





Sistemas distribuıdosAbordagem sıncrona

Mensagens de controle

Bloqueio da aplicacao

pi . . . -��

�*

��

HHHHj

AAAAU

-�

-�

-�

-�





Temperatura do backup

Hot: feito enquanto o sistema esta em operacao.

Warm: interrompe operacoes de escrita durante a execucaodo backup.

Cold: feito enquanto o sistema esta inoperante.





Snapshot, backup ou dump

Como obter um estado consistente utilizando transacoes?

Como fazer isso de forma eficiente?

set transaction isolation level serializable;begin;select * from t1;select * from t2;...select * from tn;commit;





Serializavel

Um escalonamento (possivelmente concorrente) e serializavelse for equivalente a algum escalonamento serial

Como deve ser a implementacao em um sistema baseado emlocks?

locks para leitura e escritaprotocolo de trancamento de duas faseslocks sao mantidos ate o final da transacaodeadlocks?timeouts?


Sumario

1 Motivacao







E sempre assim na pratica?

SGBDs implementam nıveis mais relaxados de isolamento

e serializavel nao e a opcao padrao...

Vamos testar?

MySQL: the world’s most popular open source databasesystem.PostgreSQL: the world’s most advanced open source database.





Seria possıvel relaxar o nıvel de isolamento?

Read UncommittedPode ler valores internos a uma transacaoClaramente, o snapshot nao seria consistente

Read CommittedLe apenas valores escritos por transacoes comprometidas.Leituras repetidas do mesmo objeto podem retornar valoresdiferentes.Esse modo e suficiente?





Seria possıvel relaxar o nıvel de isolamento?Read Committed

Considere x , y pertencentes a tabela Tab0

A soma x + y deve ser constante e isso e mantido viatransacoes;

Um snapshot obtido com Read Committed pode serinconsistente?

Vamos testar com o MySQL?

Suponha que o sistema e implementado com locks e expliqueo comportamento obtido.





Seria possıvel relaxar o nıvel de isolamento?Read Committed

Considere x pertencente a tabela Tab1

Considere y pertencente a tabela Tab2

a soma x + y deve ser constante e isso e mantido viatransacoes;

Snapshot le Tab1;

Alguma transacao altera x e y;

Snapshot le Tab2;

Vamos testar com o MySQL?

Suponha que o sistema e baseado em locks e explique ocomportamento obtido.





Seria possıvel relaxar o nıvel de isolamento?Repeatable Read

Le apenas valores escritos por transacoes comprometidas.Leituras repetidas do mesmo objeto, devem retornar o mesmovalor.

Como a transacao que realiza o snapshot so faz uma leiturapor vez, o resultado deveria ser o mesmo.

Suponha um sistema baseado em locks e explique ocomportamento esperado.

Por que o resultado foi diferente?





Leituras consistentes nao bloqueantes

13.2.4.1.2. Consistent Nonlocking Reads

A consistent read means that InnoDB uses multi-versioning topresent to a query a snapshot of the database at a point in time.The query sees the changes made by transactions that committedbefore that point of time, and no changes made by later oruncommitted transactions.

MySQL 5.6 Documentation






13.2.4.1.2. Consistent Nonlocking Reads

[...] The exception to this rule is that the query sees the changesmade by earlier statements within the same transaction. Thisexception causes the following anomaly: If you update some rowsin a table, a SELECT sees the latest version of the updated rows,but it might also see older versions of any rows. If other sessionssimultaneously update the same table, the anomaly means that youmight see the table in a state that never existed in the database.






Sistemas distribuıdosCheckpointing global consistente

Observador ve um snapshot que poderia ter acontecido

Nao e uma linha reta no tempo

p2 -� ��

� � ��

p1 -�AAU

�AAU

� ��

p0 -�AAU

�AAU

�

@@��






13.2.4.1.2. Consistent nonlocking reads

[...] If the transaction isolation level is REPEATABLE READ (thedefault level), all consistent reads within the same transaction readthe snapshot established by the first such read in that transaction.You can get a fresher snapshot for your queries by committing thecurrent transaction and after that issuing new queries







Se a implementacao do nıvel REPEATABLE READ no MySQL esufiente para se ter um snapshot que parece serializavel notempo, por que este nıvel nao e chamado de SERIALAZIBLE?

PostgreSQL versao 9.0.7

PostgreSQL versao 9.1





Nıves de isolomento no PostgreSQL versao 9.0.7

13.2 Transaction Isolation

In PostgreSQL, you can request any of the four standardtransaction isolation levels. But internally, there are only twodistinct isolation levels, which correspond to the levels ReadCommitted and Serializable. When you select the level ReadUncommitted you really get Read Committed, and when you selectRepeatable Read you really get Serializable, so the actual isolationlevel might be stricter than what you select. This is permitted bythe SQL standard: the four isolation levels only define whichphenomena must not happen, they do not define which phenomenamust happen.





Nıves de isolomento no PostgreSQL versao 9.0.7

13.2.2

The Serializable isolation level provides the strictest transactionisolation. This level emulates serial transaction execution, as iftransactions had been executed one after another, serially, ratherthan concurrently. [...] When a transaction is using the serializablelevel, a SELECT query only sees data committed before thetransaction began; it never sees either uncommitted data orchanges committed during transaction execution by concurrenttransactions. (However, the query does see the effects of previousupdates executed within its own transaction, even though they arenot yet committed.)





Nıveis de isolamento no PostgreSQL versao 9.0.7

13.2.2.1. Serializable Isolation versus True Serializability

The intuitive meaning (and mathematical definition) of”serializable” execution is that any two successfully committedconcurrent transactions will appear to have executed strictlyserially, one after the other [...] in fact PostgreSQL’s Serializablemode does not guarantee serializable execution in this sense.

Vamos construir um exemplo?





Nıves de isolomento no PostgreSQL versao 9.1Modo Serializavel: o retorno

13.2.2

The SQL standard defines four levels of transaction isolation. Themost strict is Serializable, [...] The other three levels are defined interms of phenomena, resulting from interaction betweenconcurrent transactions, which must not occur at each level. Thestandard notes that due to the definition of Serializable, none ofthese phenomena are possible at that level. (This is hardlysurprising – if the effect of the transactions must be consistentwith having been run one at a time, how could you see anyphenomena caused by interactions?)





Nıves de isolomento no PostgreSQL versao 9.1Modo Serializavel: o retorno

13.2.2

In PostgreSQL, you can request any of the four standardtransaction isolation levels. But internally, there are only threedistinct isolation levels, which correspond to the levels ReadCommitted, Repeatable Read, and Serializable. When you selectthe level Read Uncommitted you really get Read Committed, andphantom reads are not possible in the PostgreSQL implementationof Repeatable Read, so the actual isolation level might be stricterthan what you select. [...] The reason that PostgreSQL onlyprovides three isolation levels is that this is the only sensible way tomap the standard isolation levels to the multiversion concurrencycontrol architecture.





Snapshot e outras transacoes

O uso de nıveis mais relaxados de isolamento por outrastransacoes podem comprometer o snapshot?

Nao. Essas transacoes devem garantir a consistencia dosistema mesmo recebendo uma visao inconsistente.

Por exemplo, irao exibir uma media, mas nao irao gravarnovos valores no banco de dados.





Multiversion Concurrency Control

Restricao no que pode ser lido

Uso de varias versoes dos dados

coleta de lixo?

Uso de timestamps





Sistemas DistribuıdosTimestamping em SD

Vetores de relogios

p1 -�(0 0 0)

AAAU

(1 0 0)�(1 0 0)

AAAU

(2 0 0)�(2 0 0)

p2 -�(0 0 0)

AAAU

(1 1 0)�(1 1 0)

AAAU

(1 2 0)�(2 2 0)

p3 -�(0 0 0)

�(1 1 1)

�(1 2 2)





Sistemas DistribuıdosAbordagem Quase-Sıncrona

Checkpoints induzidos por comunicacao

Problema da coleta de lixo

pi . . . -� ��

��

�

-�

-� ��

�: checkpoint forcado


Sumario

1 Motivacao







Resumo

Obtencao de um snapshot nao deve comprometer odesempenho do sistema

Solucoes assıncronas exigem um conhecimento maior sobreconsistencia

Como e a implementacao das ferramentas mysqldump epgdump?

Quando os dados sao muito grandes, gravar snapshots e umaopcao?


Sumario

1 Motivacao






Conceitos basicosAlgoritmo simplificadoARIESExemplos

Tipos de falhas

Falhas de Transacoes

Erro logico (alguma condicao nao foi satisfeita)Erro de sistema (deadlock)

Falhas de Sistemas

Queda de energia ou falha de hardwareComprometem apenas memoria volatil

Falhas no disco

detectaveis com uso de checksums





Tipos de Armazenamento

Volatil

Dados nao resistem a queda de energia

Nao-volatil

Dados sobrevivem a falhas no sistemaCuidado com caching no SO e nos dispositivos

Estavel

sobreviveria a qualquer tipo de falha





Implementacao de Armazenamento Estavel

Multiplas copias dos blocos em discos separados.

Regioes distintas para prevencao de incendios, enchentes etc.

Falha durante transmissao de dados pode resultar em dadosinconsistentes.

Ao gravar, verificar se escrita foi bem sucedida, foi parcial oununca aconteceu.Fazer gravacao em partes:

Grava a informacao no primeiro bloco;Se houve sucesso, grava-se segundo bloco;. . . (mais copias?)Atualizacao termina quando todas as copias foram feitas comsucesso





Caching

Blocos fısicos: residem no disco

Blocos do buffer: residem temporariamente na memoriaprincipal

[Database System Concepts, Silberschatz, Korth e Sudarshan]





Caching (mais detalhado)






Propagacao das atualizacoes para o disco

ShadowingEscrita e feita em um endereco diferente

In-placeEscrita e feita no mesmo endereco de disco

Para garantir atomicidade

Gravacao de uma descricao das alteracoes (log)Gravacao do bloco modificado





Log

Registro sequencial

armazenado em memoria estavelotimizacao: parte mais recente em memoria volatil

Descricao das operacoes

Informacoes mınimas para se refazer ou desfazer operacoes

Operacoes de transacoes distintas podem ficar intercaladas





Tipos de entrada no log

Start 〈Ti start 〉Commit 〈Ti commit 〉Abort 〈Ti abort 〉Update 〈Ti , X, valorAntigo, valorNovo 〉

X: identifica do dadovalorAntigo: util para se desfazer operacoesvalorNovo: util para se refazer operacoes

Compensation 〈Ti , X, valor 〉valor: valor a ser restaurado





Exemplo de log

〈T0 start〉〈T0, A, Aantigo, Anovo〉〈T1 start〉〈T1, B, Bantigo, Bnovo〉〈T0 commit〉〈T1 B, Bantigo〉〈T1 abort〉





Controle de concorrencia

Varias transacoes compartilham buffer e log

Entradas no log de varias transacoes podem aparecerintercaladas

Uso de locks

Garantem os nıveis de isolamento





Propagacao das atualizacoes para o disco

Modo Deferido

Alteracoes sao propagadas apenas no momento docomprometimento da transacaoSimplifica a recuperacaoLimita o gerenciamento do buffer

Modo Imediato

Alteracoes podem ser gravadas antes de a transacao estarcomprometidaAlgumas alteracoes precisarao ser desfeitasOrdem das atualizacoes nao precisa ser a mesma do log





Exemplo de log e modo imediato

Log Buffer Discoa b c

〈T0 start〉〈T0, A, a, a′〉 a′

〈T1 start〉〈T1, B, b, b′〉 b′

〈T0, C, c, c′〉 c′

b′ c′

〈T0 commit〉a′

〈T1, B, b〉 b〈T1 abort〉

b





Transacao comprometida

Devem estar em memoria estavel

Registro de log do commit da transacaoRegistro de todas as operacoes anteriores

Blocos modificados nao precisam estar em memoria estavel

Atualizacoes feitas no buffer





Forcar ou roubar?

Problemas do gerenciamento:

Volatil: conteudo do buffer e perdido em caso de falhaEspaco limitado: buffer pode ficar lotado

Algumas opcoes para o gerenciamento de buffer:

Forcar uma escrita a cada alteracao. Dados nao sao perdidos,mas desempenho e baixo.Nao forcar: e se o sistema sofrer uma falha antes da escrita?Nao roubar: apenas alteracoes de transacoes concluıdas saosalvas, mas a vazao do sistema e baixa.Roubar: e se a transacao for abortada?

Ideal: Sem forcar e roubando (No-force/Steal)

No-force: precisa saber refazer operacoesSteal: precisa saber desfazer operacoes





Gerenciamento do buffer

Area de memoria separada

Memoria virtual controlada pelo SO

uma pagina pode ser transferida para espaco de swape depois para sua posicao no discodesperdıcio de I/O

Gravacao direta na posicao do disco

Log precisa estar em memoria estavelCooperacao com o SO


Sumario

1 Motivacao







Recuperacao de Falhas

Uma transacao precisa ser refeita

Se o log contem starte contem commit ou abort

Uma transacao precisa ser desfeita

Se o log contem startmas nao contem commit ou abort





Exemplo de Recuperacao



〈T0, C, c, c′〉 c′

〈T0 commit〉c′

Falhaa′

c′

a′ c′





Outro Exemplo de Recuperacao



〈T0, C, c, c′〉 c′

c′

Falha〈T0, C, c〉 c〈T0, A, a〉 a〈T0 abort〉

a c





Ainda Outro Exemplo de Recuperacao



〈T0, C, c, c′〉 c′

c′

〈T0, C, c〉 c〈T0, A, a〉 a〈T0 abort〉Falha

a′

c′

ca

a cIslene Calciolari Garcia Checkpointing: desafios em SD e BD




Checkpointing

Repetir todo o log pode ser custosoe desnecessario (caso algumas modificacoes ja tenham sidopropagadas para memoria estavel)

Durante o checkpointing sao gravados em memoria estavel:

Todos os registro do logTodas os blocos atualizadose uma lista de transacoes ativas

Entrada especial no log 〈Checkpoint L〉Atualizacoes precisam ficar suspensas durante o processo decheckpointing?

Estado gravado no disco e consistente?





Exemplo de Checkpoint e Falha


T1 esta consolidada

T2 e T3 precisam ser refeitas

T4 precisa ser desfeita





Exemplo de Log com Checkpoint



〈T1 commit〉〈T2 start〉〈T2, B, b〉 b′

〈Checkpoint L = {T2}〉 a′ b′

〈T2 commit〉〈T3 start〉〈T3, A, a′, a′′〉 a′′

〈T3 commit〉〈T4 start〉〈T4, C, c〉 c′

FalhaIslene Calciolari Garcia Checkpointing: desafios em SD e BD




Exemplo de Recuperacao

Log Buffer Disco〈Checkpoint L = {T2}〉 a′ b′ c〈T2 commit〉 L = ∅〈T3 start〉 L = {T3}〈T3, A, a′, a′′〉 a′′ refazer〈T3 commit〉 L = ∅〈T4 start〉 L = {T4}〈T4, C, c, c′〉 c′ refazer---〈T4, C, c〉 c desfazer〈T4 abort〉 L = ∅





Algoritmo basico para recuperacao

Encontre 〈Checkpoint L〉 mais recente

L e o valor inicial da lista de transacoes a serem desfeitas

Refaca todas as transacoes

percorra o log na ordem diretarefaca todas as atualizacoesao encontrar 〈Ti start〉, inclua Ti em Lao encontrar abort ou commit, retire Ti de L

Desfaca transacoes incompletas

Percorra o log na ordem inversaDesfaca as operacoes das transacoes em LAo encontrar 〈Ti start〉, remova Ti da listaProcesso termina quando a lista estiver vazia.





Buffering de registros do log

Registro em memoria volatil melhora o desempenho

Ordem deve ser mantida

Gravacao em memoria estavel e forcada quando

um bloco esta cheio ouuma transacao esta pronta para ser comprometida

Um bloco do buffer so pode ser gravado quando

todos os registros de sua atualizacoes ja estiverem em memoriaestavelWrite-Ahead Logging





Exemplo de log com parte volatil




a′

〈T0, C, c, c′〉 c′





Exemplo de log com parte volatil




a′

〈T0, C, c, c′〉 c′

〈T0 commit〉b′ c′





Write-Ahead Logging

O gerenciador precisa coordenar a escrita dos registros no log coma gravacao dos blocos em memoria estavel

Precisa forcar a escrita de todas as operacoes no log antes queo buffer seja escrito no disco (para garantir Atomicidade)

Precisa escrever todas as entradas de uma transacao antes deum commit (para garantir Durabilidade)





Fuzzy checkpointing

Interrompa atualizacoes

Registre 〈Checkpoint L〉Monte lista M de blocos modificados

Permita atualizacoes

Grave no disco os blocos em M

blocos nao devem ser alterados durante a gravacaoRespeite WAL

Registre marca que o checkpointing terminou


Sumario

1 Motivacao







ARIES

Algorithms for Recovery and Isolation Exploiting Semantics

Reconhecimento “10 Year Best Impact Paper Award” naInternational Conference on Very Large Data Bases 1999(VLDB99)

Varias otimizacoes

Foi incorporado a varios bancos de dados: IBM DB2 eMicroSoft SQL Server





Estruturas de dados

LSN (Log sequence number)Identificacao para os registros no log

Cresce sequencialmente

Uso do deslocamento em relacao ao inıcio do arquivo

Facilita o acessoTecnica pode ser usada para varios arquivos

1 〈T0 start〉2 〈T0, A, Aantigo, Anovo〉3 〈T1 start〉4 〈T1, B, Bantigo, Bnovo〉5 〈T0 commit〉





Estruturas de dados

PageLSNIdentifica o registro da ultima alteracao na pagina

RecLSNIndica qual registro tornou a pagina suja

Tabela de Paginas SujasPageId PageLSN RecLSN

100 2546 2233120 2789 2255





Estruturas de dadosAtualizacao de paginas

Para atualizar uma pagina

X-latch a pagina e grave o registro no logAtualize a paginaAtualize o PageLSNDesbloqueie a pagina

Para gravar uma pagina no disco

S-latch a pagina

PageLSN e utilizado durante a recuperacao para evitar Redorepetido

FlushedLSN e a marca que divide o que esta em memoria doque esta no disco.





Estruturas de dadosRegistro de log e tabela de transacoes

Registro de logLSN TransID PrevLSN RedoInfo UndoInfo

Tabela de transacoes ativas:

XID

status (running, commited, aborted)

lastLSN

UndoNxtLSN (proximo registro a ser processado em caso derollback)





Estruturas de dadosMemoria volatil e nao-volatil






ARIES: princıpios

steal : paginas podem ser gravadas no disco com transacoesem andamento

no-force: paginas no buffer modificadas por uma transacaonao precisam ser necessariamente gravadas no disco quando atransacao termina.

daemon: paginas sao gravadas no disco continuamente





Depois do crash

O gerenciador de recuperacao e invocado e inicia-se 3 fases:1 Analise: identifica paginas sujas no disco e transacoes ativas2 Refazer: repete as acoes a partir de um ponto adequado no log3 Desfazer: desfaz todas as transacoes incompletas



Sumario

1 Motivacao







InnoDB checkpointingMySQL Server

Arquivos de log devem ser grandes

Fuzzy checkpointing

Paginas vao para o disco em lotes pequenos

Em caso de falha, acoes sao refeitas





InnoDB HotBackupMySQL Enterprise Backup

Versao nao livre

Copias comprimidas

Nao bloqueante, incremental





Percona XtraBackup

Backups that complete quickly and reliably

Uninterrupted transaction processing during backups

Savings on disk space and network bandwidth

Automatic backup verification

Higher uptime due to faster restore time

Versao livre

http://www.percona.com/software/percona-xtrabackup/





PostgreSQL

Comunidade bem consolidada

Participacao no Google Summer of Code

TODO list

Melhorias para Point in time recovery

Resolucao de bugs

Fix problem with btree page splits during checkpoints


http://www.postgresql.org/developer/summerofcode/

Sumario

1 Motivacao






Conclusao e desafios futuros

Checkpointing e recuperacao:

(1) Acoes durante o processamento normal da aplicacao(2) Acoes para o restabelecimento de um estado globalconsistente apos a ocorrencia de uma falha.

Solucoes assıncronas (nao-bloqueantes) sao mais eficientes,mas mais difıceis de serem implementadas

Manutencao da consistenciaColeta de lixo

O que fazer quando os dados ficam grandes demais?


Referencias: bancos de dados

Database System Concepts, 6th edition, McGrawHillA. Silberschatz, H. F. Korth, S. SudarshanSlides disponıveis∗

Fundamentals of Database Systems, 5th edition, PearsonR. Elmasri, S. B. NavatheSlides disponıveis via registro

ARIES: A Transaction Recovery Method SupportingFine-Granularity Locking and Partial Rollbacks UsingWrite-Ahead LoggingC. Mohan et al.ACM Trans. on Database Systems, Vol. 17, No. 1, March 1992

MySQL Documentation∗

PostgreSQL Documentation∗ ∗ ultimo acesso em abril de 2012

http://db-book.com/db6/slide-dir

http://dev.mysql.com/doc/

http://www.postgresql.org/docs/

Referencias: sistemas distribuıdosResultados fundamentais

Distributed snapshots: determining global states of distributedsystemsK. M. Chandy, L. LamportACM Trans. Comp. Systems, Vol. 3, No 1, 1985

A survey of rollback-recovery protocols in message-passingsystemsE. N. Elnozahy, D. B. Johnson, Y. M. YangACM Comp. Surveys

checkpointing: desa os em sistemas distribu dos e em ...islene/speechs/ckpt-sd-bd.pdf ·...

Documents