Gerência de Transações Distribuídas de Consultas

2.281 visualizações

Publicada em

Trabalho com modelos de transações, como garantir atomicidade, efetivação, como fazer eleição do coordenador e tratar deadlocks

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
2.281
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
49
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Gerência de Transações Distribuídas de Consultas

  1. 1. Gerência de Transações Distribuídas de Consultas Alunos: Raphael Paiva Wendel Moreira
  2. 2. Modelo de Transações Distribuídas <ul><li>Transações que afetam os dados em apenas um nó são processadas como em BDs centralizados. </li></ul><ul><li>Porém transações podem acessar dados em vários nós. </li></ul><ul><li>As propriedades ACID precisam ser mantidas em todas as máquinas envolvidas na transação. </li></ul><ul><ul><li>Mudança de estado a tômica nas várias máquinas. </li></ul></ul><ul><ul><li>Todos os nós devem ter dados c onsistentes. </li></ul></ul><ul><ul><li>Transações i soladas apesar do paralelismo. </li></ul></ul><ul><ul><li>Alterações d uráveis em todas as réplicas dos dados. </li></ul></ul>
  3. 3. Exemplo de transação <ul><li>Begin_transaction Reservation </li></ul><ul><li>begin </li></ul><ul><ul><li>input (flight_no, date, customer_name); </li></ul></ul><ul><ul><li>EXEC SQL UPDATE FLIGHT </li></ul></ul><ul><ul><ul><li>SET STSOLD = STSOLD + 1 </li></ul></ul></ul><ul><ul><ul><li>WHERE FNO = flight_no AND DATE = date; </li></ul></ul></ul><ul><ul><li>EXEC SQL INSERT </li></ul></ul><ul><ul><ul><li>INTO FC(FNO, DATE, CNAME, SPECIAL); </li></ul></ul></ul><ul><ul><ul><li>VALUES (flight_no, date, customer_name, null ); </li></ul></ul></ul><ul><ul><li>output (“reservation completed”) </li></ul></ul><ul><li>end . {Reservation} </li></ul>
  4. 4. Coordenação de Transações <ul><li>Cada nó tem um gerente local de transações , responsável por: </li></ul><ul><ul><li>Manter log para recuperação. </li></ul></ul><ul><ul><li>Coordenar a execução concorrente das transações executando no nó. </li></ul></ul><ul><li>Cada nó tem um coordenador de transações , responsável por: </li></ul><ul><ul><li>Iniciar a execução de transações que são originadas no nó. </li></ul></ul><ul><ul><li>Distribuir sub-transações para nós apropriados. </li></ul></ul><ul><ul><li>Coordenar a terminação de transações originadas no nó, o que resulta na transação ser validada em TODOS os nós ou desfeita em TODOS os nós. </li></ul></ul>
  5. 5. Garantindo a Atomicidade <ul><li>Protocolos de efetivação garantem que todos os nós efetivarão a transação ou nenhum o fará. </li></ul><ul><li>Protocolo two-phase commit (2PC): </li></ul><ul><li>Preparação: </li></ul><ul><ul><li>Um dos participantes é designado coordenador do two-phase commit e envia a cada nó envolvido na transação uma solicitação para se preparar para fazer commit. </li></ul></ul><ul><ul><li>Uma vez preparado, cada participante escreve uma marca no seu log, avisa o coordenador e não pode mais abortar. </li></ul></ul><ul><li>Commit: </li></ul><ul><ul><li>Se todos os participantes estão prontos, o coordenador envia um sinal de commit para cada participante, que o executa. </li></ul></ul><ul><ul><li>Se algum dos participantes falhar na preparação para o commit , este notifica o coordenador, que envia um sinal de rollback para todos os participantes. </li></ul></ul>
  6. 6. Garantindo a Atomicidade <ul><li>Protocolo three-phase commit (3PC): </li></ul><ul><ul><li>Fase 1 : idêntica à preparação do protocolo de duas fases. </li></ul></ul><ul><ul><li>Fase 2: o coordenador responde a todos os nós com a mensagem precommit se todos indicaram dentro do tempo limite que podem efetivar a transação, ou com abort em caso contrário; os nós devem responder com a mensagem ack (reconhecimento). </li></ul></ul><ul><ul><li>Fase 3: após receber N+1 mensagens ack , o coordenador manda a mensagem commit a todos os nós, que ao recebê-la efetivam a transação. </li></ul></ul>
  7. 7. Protocolos de Efetivação <ul><li>Uso de logs nos protocolos de efetivação </li></ul><ul><ul><li>Mensagens enviadas/recebidas são gravadas em logs. </li></ul></ul><ul><ul><li>Caso o nó reinicie após uma falha, ele deve verificar o que ocorreu com as transações registradas no seu log que ainda não foram efetivadas ou abortadas. </li></ul></ul><ul><li>Comparação dos protocolos de efetivação </li></ul><ul><ul><li>3PC tolera falhas no coordenador, porém seu custo é mais alto devido ao maior número de mensagens trocadas pela rede. </li></ul></ul><ul><ul><li>No protocolo de 2 fases, se o coordenador falha, sistema bloqueia. </li></ul></ul><ul><li>Soluções possíveis para falha do coordenador </li></ul><ul><ul><li>Um coordenador de backup pode assumir o seu lugar. </li></ul></ul><ul><ul><li>Um novo coordenador pode ser eleito pelos nós. </li></ul></ul>
  8. 8. Eleição de Coordenador <ul><li>Coordenador de backup </li></ul><ul><ul><li>Reside em um nó diferente do coordenador. </li></ul></ul><ul><ul><li>Recebe as mesmas mensagens que o coordenador. </li></ul></ul><ul><ul><li>Assume o lugar do coordenador ao detectar sua falha. </li></ul></ul><ul><li>Algoritmo de eleição de coordenador </li></ul><ul><li>Associa a cada nó id único. </li></ul><ul><li>Nó envia msg para nós com id maior que o seu e aguarda determinado tempo; se nó recebeu alguma solicitação dentro de tempo (então existe outro coordenador), senão nó assume como novo coordenador. </li></ul><ul><li>O novo coordenador deve requisitar as mensagens registradas nos logs de todos os nós para poder dar continuidade às transações em andamento. </li></ul>
  9. 9. Garantindo a Consistência <ul><li>Escalonamentos seriais: entrelaçamento da execução de operações de diferentes transações, com resultado idêntico ao da execução serial das transações. </li></ul><ul><li>Serialização deve ser observada não só localmente, mas também globalmente quando os dados forem replicados para garantir a consistência entre réplicas. </li></ul><ul><li>Exclusão mútua por bloqueio ( lock) </li></ul><ul><ul><li>Troca de mensagens para solicitar bloqueios locais. </li></ul></ul><ul><ul><li>Deadlock é mais difícil detectar em um SGBDD. </li></ul></ul><ul><li>Métodos otimistas </li></ul><ul><ul><li>Livre execução das operações. </li></ul></ul><ul><ul><li>Monitoramento de conflitos (via grafos/árvores de execução e/ou relógios lógicos). </li></ul></ul><ul><ul><li>Em caso de conflito, a transação mais nova pode ser desfeita, para depois ser realizada novamente. </li></ul></ul>
  10. 10. Escalonamento Completo - Exemplo <ul><li>Dadas 3 Transações </li></ul><ul><li>Um possível escalonamento completo é dado como o DAG </li></ul>
  11. 11. Falhas = escalonamento incompleto
  12. 12. Algoritmos de Controle de Concorrência <ul><li>Pessimista </li></ul><ul><li>Otimista </li></ul>Validação Leitura Computação Escrita Validação Leitura Computação Escrita
  13. 13. Teste de validação de Controle de Concorrência Otimistas <ul><li>Ordens possíveis </li></ul>
  14. 14. Algoritmos de Bloqueio
  15. 15. Falhas em BDs Distribuídos <ul><li>Além de falhas locais nos nós, podem ocorrer ainda falhas na comunicação entre eles. </li></ul><ul><li>Tipos de falhas de comunicação: </li></ul><ul><ul><li>Falha de mensagem: uma mensagem enviada pela rede é perdida, corrompida ou duplicada. </li></ul></ul><ul><ul><li>Falha de desempenho: o atraso na rede faz com que o timeout se esgote, afetando o funcionamento. </li></ul></ul><ul><ul><li>Falha de rota: um link de rede deixa de operar, impedindo a comunicação entre servidores. </li></ul></ul>
  16. 16. Falhas em BDs Distribuídos <ul><li>Rede impede a detecção precisa de falhas </li></ul><ul><ul><li>Quando um servidor não responde, não é possível saber se a máquina ou a rede falhou. </li></ul></ul><ul><li>Particionamento da Rede </li></ul><ul><ul><li>Nós continuam ativos, mas não podem se comunicar. </li></ul></ul><ul><ul><li>Cada partição acha que a outra falhou. </li></ul></ul>
  17. 17. Tratamento de Falhas <ul><li>Réplicas dos dados no nó com falha deixam de ser atualizadas e não serão usadas em futuras consultas. </li></ul><ul><li>Transações ativas no nó com falha são abortadas. </li></ul><ul><li>Se algum servidor central falhar, deve ser eleito um novo nó para esta função (ex.: servidor de nomes, coordenador de concorrência, detector de deadlock ). </li></ul><ul><li>Servidor deve ter o estado atualizado ao reintegrar-se ao sistema; qualquer conflito deve ser resolvido. </li></ul>
  18. 18. Tratamento de DeadLocks em SGBDD <ul><li>Detecção de ciclos centralizada: Os grafos locais são enviados para um nó central para concatenação e detecção de ciclos. </li></ul><ul><li>Timeout: Abortar uma transação quando esta estiver esperando por muito tempo, para recomeçá-la logo depois. </li></ul>
  19. 19. Grafos de Espera
  20. 20. Gerência de impasses <ul><li>Ignorar </li></ul><ul><li>Prevenção </li></ul><ul><li>Anulação </li></ul><ul><li>Detecção e Recuperação </li></ul>

×