Transacções Atómicas Distribuídas

Transcrição

1 Transacções Atómicas Distribuídas Exemplo O Senhor Silva é possuidor de duas contas em bancos diferentes (A e B) e pretende fazer um movimento de $00 do banco A para o banco B. O procedimento para fazer esta transferência pode ser o seguinte: transferencia (bancoa, bancob, Valor) { LerSaldo (bancoa, SaldoA); /* obtendo $00 */ LerSaldo (bancob, SaldoB); /* obtendo $00 */ ActualizarSaldo (bancoa, saldoa-valor); ActualizarSaldo (bancob, saldob+valor); }

2 Transacção Atómica transferencia (bancoa, bancob, Valor) { begin_transaction; LerSaldo (bancoa, SaldoA); LerSaldo (bancob, SaldoB); ActualizarSaldo (bancoa, saldoa-valor); ActualizarSaldo (bancob, saldob+valor); commit; } Transacção Atómica transferência (bancoa, bancob, Valor) { begin_transaction; LerSaldo (bancoa, SaldoA); LerSaldo (bancob, SaldoB); if (Valor > SaldoA) abort else { ActualizarSaldo (bancoa, saldoa-valor); ActualizarSaldo (bancob, saldob+valor); commit; } } Outras razões para transacção abortar?

3 Sistema Transaccional Aplicações Iniciar Confirmar Abortar Aplicações Ler Escrever Sistema Transaccional Sistema Operativo Hardware Propriedades das transacções ACID (Revisão da cadeira de BD) Atomicidade Transacção ou se executa na totalidade ou não se executa. Consistência Transacção deve manter invariantes associados à aplicação (transita de estado consistente para outro estado consistente)

4 Propriedades das transacções - ACID Seriabilidade (Isolation) se diversas transacções se executarem em paralelo sobre os mesmos objectos, tudo se passa como se as transacções se executassem em série numa determinada ordem. Persistência (Durability) os resultados de uma transacção que confirmou permanecem depois de esta acabar e sobrevivem ao conjunto de faltas expectáveis Atomic, Consistent, Isolated, Durable Assegurar propriedades ACID numa transacção distribuída?

5 Transacções distribuídas: Arquitectura distribuída Consórcio X/OPEN: Esforço de normalização dos protocolos e interfaces para interligação de sistemas de informação heterogéneos DTP (Distributed Transaction Processing) Muito influenciado pela norma de facto que constituiu a arquitectura SNA da IBM e a sua interface LU 6.2 Arquitectura X/Open: Gestores de Recursos - RM (resource manager) Armazenam os dados Em BDs relacionais, sistemas de ficheiros com actualizações atómicas, etc. Garantem localmente as propriedades das transacções Monitores Transaccionais - TM (transaction managers) Coordenadores dos RM Através da interface XA Execução dos protocolos de iniciação/terminação das transacções Um em cada máquina (ou em cada grupo de máquinas) Transacções distribuídas X/Open Aplicação Iniciar Confirmar Abortar TM Associar Preparar Confirmar Abortar Ler Escrever RM

6 Transacções distribuídas: X/Open (com distribuição) TM TM Aplicação SC SC RM RM Transacções distribuídas: X/Open Uma aplicação inicia uma transacção distribuída Invoca um Coordenador que lhe atribui um identificador único A aplicação contacta em seguida os RMs Para efectuar as operações de leitura e escrita Usa o identificador da transacção Os RMs associam-se à transacção Quando um RM recebe a primeira operação relacionada com uma transacção desconhecida contacta o coordenador para se associar à transacção A transacção termina Todos os TM envolvidos executam um protocolo de consenso distribuído (e.g. 2 Phase Commit, 3 Phase Commit, etc)

7 Hipótese: Protocolo One Phase Commit (1PC) Coordenador conhece a lista de participantes que se associaram à transacção Quando cliente lhe pede para confirmar a transacção, coordenador envia docommit a todos os participantes Pedido docommit leva id da transacção distribuída Cada um deles confirma a transacção local Que estava activa até esse momento Porque é que não funciona? Razões para o 1PC ser incorrecto Em TMs que usam controlo de concorrência optimista, por definição, podem falhar no docommit Atomicidade violada se alguns confirmassem e outros não o conseguissem Mesmo em TMs com controlo de concorrência pessimista o commit pode falhar Deadlocks podem levar a abortar transacções que tinham obtido todos os locks com sucesso Falhas de TMs É necessário haver, pelo menos 2 fases no protocolo

8 Protocolo de confirmação em duas fases (Two-Phase Commit, 2PC) Especificação do Problema da Confirmação Atómica n processos, identificados por i {1,, n} Processo máquina Modelo assíncrono Input do processo i: voto i {sim, não} Output do processo i: decisão i {commit, abort}

9 Especificação do Problema CA1: Todos os processos tomam a mesma decisão CA2: A decisão só pode ser commit se todos os votos forem sim CA3: Se todos os votos forem sim e não houver falhas nos processos, a decisão é commit CA4: Se todos processos recuperarem das suas falhas, e não ocorrerem mais falhas, então todos os processos eventualmente tomam uma decisão Coordenador Envia cancommit? a todos Protocolo (sem falhas) if (todos votaram yes) decisão coord = commit Envia docommit a todos else decisão coord = abort Envia doabort a todos que votaram yes exit Participante i Envia voto i (yes/no) ao coord. if (voto i == no) decisão i = abort exit if (recebe ABORT) decisão i = abort responde haveaborted else decisão i = commit responde havecommitted Exit

10 2PC e a propriedade Isolamento Na ausência de falhas, 2PC garante Atomicidade E então o Isolamento? Se TMs usarem locking? Automaticamente garantido, mas podem ocorrer deadlocks distribuídos (mais difíceis de resolver que locais) Se TMs usarem timestamps? Necessário timestamps globais (p.ex. <IP coordenador, timestamp local>) Se TMs usarem esquema optimista? Validação é feita após cancommit. Se tiver sucesso, é preciso garantir que terá também sucesso no docommit. Como? Trancar objectos acedidos. 2PC com suporte a falhas Protocolo do Coordenador inicial temporizador expirou Input: - Output: Envia cancommit? a todos Input: Recebe um ou mais No Ou temporizador expira Output: Envia doabort a todos abort espera Input: Recebe Yes de todos Output: Envia docommit a todos commit

11 2PC com suporte a falhas Protocolo do Participante Input: (Recebe cancommit? e voto i == No) Ou temporizador expira Output: Envia No ao coord. inicial uncertain temporizador expirou Input: Recebe cancommit? e voto i == Yes Output: Envia Yes ao coordenador Executar protocolo de terminação abort Input: Recebe doabort Input: Recebe docommit commit Protocolo de Terminação Se o temporizador expirar no participante após votar sim, envia PEDIDO_DECISÃO a todos participantes Restantes participantes respondem com: decisão i se já decidiram doabort se estiverem no estado inicial uncertain se estiverem no estado espera Se algum participante responder docommit ou doabort, essa é a decisão final do participante Caso todos respondam uncertain esperar que coordenador recupere 3PC evita espera no caso de falha do coordenador

12 Protocolo de Recuperação Assume um diário (log) persistente com escritas atómicas (no caso de falhas) Evento Coord. envia PREPARAR Participante vota sim Participante vota não Coord. decide commit Coord. decide abort Particip. recebe decisão Info. escrita no log Coordinator Prepared Participant Uncertain Participant Aborted Coordinator Committed Coordinator Aborted Part. Commited ou Aborted Cada entrada exprime uma intenção, que deve ser escrita no diário antes de se passar à acção Em alguns casos, podemos optimizar e passar à acção em paralelo com a escrita no diário. Quais casos? Protocolo de Recuperação Assume um diário (log) persistente com escritas atómicas (no caso de falhas) Evento Info. escrita no log Instante da escrita Coord. envia PREPARAR Coordinator Prepared Em paralelo com envio Participante vota sim Participant Uncertain Antes de enviar voto Participante vota não Participant Aborted Em paralelo com envio Coord. decide commit Coordinator Committed Antes de enviar commit Coord. decide abort Coordinator Aborted Em paralelo com envio Particip. recebe decisão Part. Commited ou Aborted Em paralelo com decisão

13 Protocolo de Recuperação Após recuperar, processo inspecciona o diário Se era coordenador: Se estava prepared, nenhuma decisão tinha sido tomada, logo aborta Se estava committed/aborted, re-envia docommit a todos os participantes Caso contrário era participante: Se estava committed, envia confirmação havecommitted para o coordenados Se não existir registo que votou Yes, decide abort Caso contrário (estava uncertain), corre protocolo de terminação. Desempenho do 2PC Sem falhas, após 3N mensagens todos os participantes confirmaram as suas transacções locais Com falhas: Mensagens re-enviadastransacção abortada Participantes à espera que coordenador em falta recupere para decidirem Coordenador à espera que participante em falta recupere para limpar transacção do seu diário Em que casos pode ocorrer cada situação?

14 Variantes do 2PC Várias variantes do 2PC foram propostas (algumas que assumem um modelo síncrono ou outros pressupostos) Outra é o Three phase commit Protocolo com 3 fases Quando coordenador falha, participantes tentam eleger novo coordenador Casos em falha do coordenador obriga os participantes a bloquearem sem poderem decidir são muito menos prováveis