Protocolos de coordenação das transações distribuídas, False Tolerance to Faith Commit, ou 2PC, tolerante à falha. E se, no momento da tomada de decisão, o nó coordenador da transação distribuída falhar, travou no momento de tomada de decisão. O que acontece? Nós vimos que o 2PC é um protocolo síncrono. Então, neste momento, vai ficar tudo parado. A transação não vai progredir, não teremos progresso. Então, por essa razão, existe uma variante do 2PC, que é justamente o 2PC tolerante à falha. Vamos detalhar um pouquinho mais esta abordagem. Conforme já antecipei para vocês, o Fault Tolerant To-Face Commit é confirmação em duas fases tolerante à falha. E a ideia é que justamente aconteça maior robustez e mais resiliência à falha. E tudo isso sempre visando garantir a atomicidade da transação. Qual é o problema que nós temos no 2PC básico? Nós temos a questão de que o coordenador é um ponto único de falha. Então, nós vimos que temos vários passos dentro da fase 1 e da fase 2 e principalmente o momento da tomada de decisão do coordenador pela confirmação ou reversão das operações em todos os nossos distribuídos é um ponto único de falha, é um ponto crítico. Então, se o coordenador falhar naquele instante, os demais participantes da transação vão ficar aguardando uma decisão e tudo pode parar. Vai ficar uma falta de progresso na transação e, consequentemente, o coordenador precisa ter a capacidade de se recuperar e conseguir voltar a mandar mensagens e entender o estado de cada um dos participantes. Então, aqui o grande objetivo é justamente garantir o progresso da transação, não abrir mão da atomicidade e contornar essa questão de que o coordenador é um ponto único de falha. Então, para isso, nós vamos ver que aconteceu uma extensão do protocolo 2PC e nós vamos ter mecanismos adicionais, que são mecanismos de detecção de falhas e também mecanismos de recuperação dessas falhas. Então, vamos dar uma olhada aqui. Detecção de falhas. Então, é necessário conseguir detectar essas falhas entre os nossos participantes e do coordenador. Geralmente, isso está associado com mecanismos de timeout, ou seja, o tempo vai expirar, demorou muito para concluir a tarefa, seja para sinalizar que a transação poderia avançar ou ser cancelada. Então, a partir desse instante, os nós ganham a capacidade de identificar falhas. Também vai acontecer o seguinte, o papel de coordenação vai adquirir uma característica assíncrona. Até agora, nós falamos de confirmação atômica e 2PC para resolver um problema que necessita de sincronismo. E aqui nós começamos a abrir mão desse sincronismo, já existe uma assincronia. Os participantes podem continuar com as operações de transação, inclusive na ausência temporária do coordenador. E a coordenação é retomada posteriormente, quando este coordenador conseguir se recuperar. é retomada posteriormente quando este coordenador conseguir se recuperar. Também vai acontecer a capacidade de eleição e failover. Então, um novo coordenador pode ser selecionado em caso de falha do coordenador atual. E aqui nós vamos entender que vai ter uma implementação de algoritmos de eleição distribuída, como por exemplo, Paxos. uma implementação de algoritmos de eleição distribuída, como por exemplo, Paxos. Também vamos ter uma lógica robusta para lidar com as diferentes falhas, seja um coordenador falho durante a preparação ou um participante que falhou durante a confirmação. E estas ações de recuperação envolvem retransmissão de mensagens entre coordenador e participantes, revisão do estado da transação entre todo mundo e execução de procedimentos específicos de recuperação. Também vamos perceber aqui que este protocolo avançou com estratégias de reconfiguração e ressincronização, sempre visando a consistência da transação, em caso de paixão de rede. A comunicação entre os nós falhou. Os nós podem perder a conectividade entre si ou com o coordenador. Obrigado.