DBMS Distribuído - Controle de Replicação

Este capítulo examina o controle de replicação, necessário para manter dados consistentes em todos os sites. Vamos estudar as técnicas de controle de replicação e os algoritmos necessários para o controle de replicação.

Como discutido anteriormente, replicationé uma técnica usada em bancos de dados distribuídos para armazenar várias cópias de uma tabela de dados em diferentes sites. O problema de ter várias cópias em vários sites é a sobrecarga de manter a consistência dos dados, especialmente durante as operações de atualização.

Para manter dados mutuamente consistentes em todos os sites, técnicas de controle de replicação precisam ser adotadas. Existem duas abordagens para o controle de replicação, a saber -

Controle de replicação síncrona
Controle de replicação assíncrona

Controle de replicação síncrona

Na abordagem de replicação síncrona, o banco de dados é sincronizado para que todas as replicações sempre tenham o mesmo valor. Uma transação solicitando um item de dados terá acesso ao mesmo valor em todos os sites. Para garantir essa uniformidade, uma transação que atualiza um item de dados é expandida para que faça a atualização em todas as cópias do item de dados. Geralmente, o protocolo two-phase commit é usado para esse propósito.

Por exemplo, consideremos uma tabela de dados PROJECT (PId, PName, PLocation). Precisamos executar uma transação T1 que atualize PLocation para 'Mumbai', se PLocation for 'Bombay'. Se não houver replicações, as operações na transação T1 serão -

Begin T1: 
   Update PROJECT Set PLocation = 'Mumbai' 
   Where PLocation = 'Bombay'; 
End T1;

Se a tabela de dados tiver duas réplicas no Site A e no Site B, T1 precisa gerar dois filhos T1A e T1B correspondentes aos dois sites. A transação expandida T1 será -

Begin T1: 
   Begin T1A : 
      Update PROJECT Set PLocation = 'Mumbai' 
      Where PLocation = 'Bombay'; 
   End T1A;  
	
   Begin T2A : 
      Update PROJECT Set PLocation = 'Mumbai'
      Where PLocation = 'Bombay'; 
   End T2A; 
	
End T1;

Controle de replicação assíncrona

Na abordagem de replicação assíncrona, as réplicas nem sempre mantêm o mesmo valor. Uma ou mais réplicas podem armazenar um valor desatualizado e uma transação pode ver os diferentes valores. O processo de trazer todas as réplicas para o valor atual é chamadosynchronization.

Um método popular de sincronização é o método de armazenamento e encaminhamento. Nesse método, um site é designado como o site primário e os outros sites são sites secundários. O site principal sempre contém valores atualizados. Todas as transações entram primeiro no site principal. Essas transações são então enfileiradas para aplicação nos sites secundários. Os sites secundários são atualizados usando o método de distribuição apenas quando uma transação está programada para ser executada nele.

Algoritmos de controle de replicação

Alguns dos algoritmos de controle de replicação são -

Algoritmo de controle de replicação mestre-escravo.
Algoritmo de votação distribuída.
Algoritmo de consenso da maioria.
Algoritmo de token circulante.

Algoritmo de controle de replicação mestre-escravo

Há um site mestre e sites escravos 'N'. Um algoritmo mestre é executado no site mestre para detectar conflitos. Uma cópia do algoritmo escravo é executada em cada site escravo. O algoritmo geral é executado nas duas fases a seguir -

Transaction acceptance/rejection phase- Quando uma transação entra no monitor de transação de um site escravo, o site escravo envia uma solicitação ao site mestre. O site mestre verifica se há conflitos. Se não houver conflitos, o mestre envia uma mensagem “ACK +” para o site escravo que inicia a fase de aplicação da transação. Caso contrário, o mestre enviará uma mensagem “ACK-” ao escravo que rejeitará a transação.
Transaction application phase- Ao entrar nesta fase, o site escravo onde a transação foi inserida transmite uma solicitação a todos os escravos para executar a transação. Ao receber as solicitações, os escravos pares executam a transação e enviam um “ACK” ao escravo solicitante na conclusão. Depois que o escravo solicitante recebe mensagens “ACK” de todos os seus pares, ele envia uma mensagem “CONCLUÍDO” para o site mestre. O mestre entende que a transação foi concluída e a remove da fila pendente.

Algoritmo de votação distribuída

É composto por sites 'N' pares, todos os quais devem “OK” uma transação antes de começar a ser executada. A seguir estão as duas fases deste algoritmo -

Distributed transaction acceptance phase- Quando uma transação entra no gerenciador de transações de um site, ele envia uma solicitação de transação a todos os outros sites. Ao receber uma solicitação, um site par resolve os conflitos usando regras de votação baseadas em prioridade. Se todos os sites pares estiverem “OK” com a transação, o site solicitante inicia a fase de aplicação. Se qualquer um dos sites pares não “OK” uma transação, o site solicitante rejeita a transação.
Distributed transaction application phase- Ao entrar nesta fase, o local onde foi realizada a transação, transmite a todos os escravos um pedido de execução da transação. Ao receber as solicitações, os escravos pares executam a transação e enviam uma mensagem “ACK” ao escravo solicitante na conclusão. Depois que o escravo solicitante recebe mensagens “ACK” de todos os seus pares, ele informa ao gerenciador de transações que a transação foi concluída.

Algoritmo de consenso da maioria

Esta é uma variação do algoritmo de votação distribuída, onde uma transação pode ser executada quando a maioria dos pares “OK” uma transação. Isso é dividido em três fases -

Voting phase- Quando uma transação entra no gerenciador de transações de um site, ele envia uma solicitação de transação a todos os outros sites. Ao receber uma solicitação, um site par testa os conflitos usando regras de votação e mantém as transações conflitantes, se houver, na fila pendente. Em seguida, ele envia uma mensagem “OK” ou “NÃO OK”.
Transaction acceptance/rejection phase- Se o site solicitante receber a maioria “OK” na transação, ele aceita a transação e transmite “ACEITAR” para todos os sites. Caso contrário, ele transmite “REJEITAR” para todos os sites e rejeita a transação.
Transaction application phase- Quando um site par recebe uma mensagem “REJEITAR”, ele remove esta transação de sua lista pendente e reconsidera todas as transações adiadas. Quando um site par recebe uma mensagem “ACEITAR”, ele aplica a transação e rejeita todas as transações adiadas na fila pendente que estão em conflito com esta transação. Ele envia um “ACK” ao escravo solicitante na conclusão.

Algoritmo de Token Circulante

Nesta abordagem, as transações no sistema são serializadas usando um token circulante e executadas de acordo com cada réplica do banco de dados. Assim, todas as transações são aceitas, ou seja, nenhuma é rejeitada. Isso tem duas fases -

Transaction serialization phase- Nesta fase, todas as transações são programadas para serem executadas em uma ordem de serialização. Cada transação em cada site recebe um tíquete único de uma série sequencial, indicando a ordem da transação. Depois que um ticket é atribuído a uma transação, ele é transmitido para todos os sites.
Transaction application phase- Quando um site recebe uma transação junto com seu ticket, ele coloca a transação para execução de acordo com seu ticket. Após o término da execução da transação, este site transmite uma mensagem apropriada. Uma transação termina quando completa a execução em todos os sites.