Sistemas DistribuídosProfessor: Thales Farias Duarte

Acadêmicos: Anderson dos Santos Ferreira

Jaqueline Nardes França

Valdir Pereira da Silva Junior

Replicação de banco de dados MySql e PostgreSQL

Replicação

Replicação é a manutenção de cópias idênticas

de dados em locais diferentes.

Segundo [Ikematu 2005], o objetivo de um

mecanismo de replicação de dados é permitir a

manutenção de várias cópias idênticas de um

mesmo dado em vários sistemas gerenciadores

de banco de dados (SGBD).

Tipos de Replicação

Assíncrona: Quando um BD é alterado, a alteração nos outros BDs

será feita em uma transição separada levando algum tempo

(segundos, minutos, horas até dias) para concluir. Esse tipo de

replicação é utilizado quando não há necessidade dos dados serem

atualizado em tempo real e quando os conflitos entre transações não

acontecem com muita freqüência. Algumas vantagens: Baixo custo de

comunicação, Aumento do desempenho das aplicações, Menor

concorrência, Maior disponibilidade.

Síncrona: Quando um BD é alterado, a alteração nos outros BDs é

feita instantaneamente. Exemplos de sistemas que utilizam replicação

síncrona: sistema de aviação, bancário, comércio eletrônico e militar.

Modelos de Replicação

Modelo Mutimestre:

Vários sites gerenciam os objetos replicados de

banco de dados. Aplicativos atualizam e as tabelas

replicadas em qualquer site que pertença ao grupo

de BDs. Servidores têm um papel importante,

porque convergem dados automaticamente todas

as replicas de tabelas, assim, garantindo

consistência global e integridade de dados.

Modelos de Replicação

Modelo Mestre / Escravo:

Apenas a base mestre recebe atualizações

enquanto na base só é permitida a leitura.

Objetos e Conflitos da Replicação

Objetos de Replicação:

É um objeto que esta em vários servidores

de um sistema de banco de dados

distribuídos.

Conflitos de Replicação:

Conflitos de replicação que podem ocorrer

quando mais de uma transação tenta

atualizar a mesma informação praticamente

no mesmo momento.

Vantagens e desvantagens da replicação

• Disponibilidade (+)

• Paralelismo aumentado (+): maior a chance de

encontrar o dado no site em que a transação está

executando.

• Sobrecarga na atualização (-): garantir que as

réplicas sejam consistentes pela propagação de

atualizações.

MySql & PostgreSQL

Replicação MySql

Quando falamos em Replicação de bancode dados mySql, pensamos em um tipo dereplicação orientado por paradigmasdistintos:

Replicação Master/Slave: onde apenas aréplica master permite gravação, enquantoas demais réplicas só permitem leitura;

Master-Slave

Master-Slave

Cria usuário

create user replicador indentified by ‘replica’;

Permissões de replicação

grant replication slave,

replication client on *.* to replicator@ ‘192.168.56.%’

identified by ‘replica’

Arquivo de configurações

Arquivo de configurações my.cnf

Master

log-bin = mysql-bin

server-id = 1

Slave

log-bin = mysql-bin

server-id = 2

relay-log = mysql-relay-bin

log-slave-updates = 1

Arquivo de configurações

CHANGE MASTER TO

MASTER_HOST='192.168.56.101',

MASTER_USER='replicador',

MASTER_PASSWORD='replica',

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=0;

START SLAVE

Master-Master e Topologia Anel

Replicação PostgreSQL

Um servidor de banco de dados pode estar

trabalhando bem em uma solução que contém vários

servidores de aplicação e milhares de clientes.

Porém, as empresas estão muito interessadas em

distribuir o processamento enquanto mantêm a

integração dos recursos de informação.

Em um determinado momento poderá surgir a

necessidade de ter um outro servidor de banco de

dados que contenha todos os dados ou parte deles

para fins de disponibilidade, confiabilidade,

desempenho e/ou balanceamento de carga.

Replicação PostgreSQL

Vários tipos de servidores, tais como servidores web,

servidores DNS e servidores de aplicação, que contém dados

estáticos podem ser combinados facilmente para atender

requisições balanceando a carga entre eles.

Da mesma maneira, isso pode ser feito para servidores de

bancos de dados. No entanto, servidores de bancos de dados

geralmente não possuem dados puramente estáticos.

Se permitirmos alteração no servidor de banco de dados,

ainda temos que garantir a atomicidade (vide ACID) o que

nem sempre é um problema nos outros tipos de servidores.

Isto torna soluções de replicação em servidores de bancos de

dados mais complexas do que em outros tipos de servidores.

Replicações disponíveis e suas classificações

As soluções de replicação disponíveis em

SGBDs podem ser classificadas quanto a

sincronia, escrita, fragmentação, envio e

modo.

Sincronia: os dados podem ser sincronizados

"simultaneamente" ou após algum tempo;

síncrono: a transação é efetivada

"simultaneamente" em todos os servidores que

participam da replicação;

Assíncrono: após a transação ser efetivada em

um servidor, ela é propagada para os outros

servidores.

Escrita: os dados podem ser escritos em qualquer

servidor, alguns servidores ou somente em um

servidor. Servidor principal (também chamado de

mestre) é aquele que aceita escrita. Servidor

secundário (também chamado de escravo) é

aquele que aceita somente leitura;

Múltiplos mestres: os dados podem ser escritos

em múltiplos servidores e serão enviados para os

outros servidores que participam da replicação;

Um mestre: somente um servidor

(principal/mestre) aceita escrita de dados. Os

outros servidores só recebem as alterações feitas

no servidor principal.

Fragmentação e Envio

Fragmentação: os dados de uma relação

são particionados em múltiplos servidores.

Horizontal: cada fragmento (que está em

um servidor) contém um subconjunto das

tuplas da relação completa, ou seja, a união

dos fragmentos resulta na relação completa;

Vertical: cada fragmento (que está em um

servidor) contém um subconjunto dos

atributos da relação, ou seja, cada

fragmento é uma projeção da relação

completa;

Envio: os dados podem ser enviados quando o

arquivo que contém logs de transação é

fechado ou quando uma transação é efetivada;

Envio de arquivo: após o preenchimento

(fechamento) de um arquivo que contém logs

de transação, este é enviado a outros

servidores que aplicam os logs de transação.

Este tipo geralmente é utilizado em

combinação com envio assíncrono;

Envio de registro: após a efetivação de uma

transação, o log (registro) da transação é

enviado e aplicado nos servidores que

participam da replicação;

Replicações disponíveis e suas classificações

Modo: os servidores secundários podem

aceitar ou não consultas (somente leitura).

Este tipo é utilizado com escrita somente

em um servidor principal;

Warm standby: os servidores secundários

(aqueles que não recebem escrita) não

aceitam conexões (e consultas);

Hot standby: os servidores secundários

aceitam conexões e consultas que não

modificam dados;

Warm standby e Hot standby

Modelos de replicação

Warm standby e envio de arquivo: os

servidores secundários não aceitam conexões e

se mantêm atualizados de modo assíncrono

através dos arquivos de log de transação

enviados pelo servidor principal após serem

preenchidos ou depois de determinado tempo.

Esta solução está disponível desde a versão 8.0;

Warm standby envio de registro: os servidores

secundários não aceitam conexões e se mantêm

atualizados de modo assíncrono através dos logs

de transação que são enviados pelo servidor

principal e aplicados nos servidores secundários.

Esta solução está disponível desde a versão 9.0;

Hot standby e envio de arquivo: os servidores

secundários aceitam consultas somente leitura e se

mantêm atualizados de modo assíncrono através

dos arquivos de log de transação enviados pelo

servidor principal após serem preenchidos ou

depois de determinado tempo. Esta solução está

disponível desde a versão 9.0;

Hot standby e envio de registro: os servidores

secundários aceitam consultas somente leitura e se

mantêm atualizados de modo assíncrono através

dos logs de transação enviados pelo servidor

principal e aplicados nos servidores secundários.

Esta solução está disponível desde a versão 9.0.

Cenário de Implementação

Apresentamos a implementação dos

quatros tipos de replicação descritos acima

utilizando o seguinte cenário.

Evolução do PostgreSQL Replicação

Evolução de cada versão do PostgreSQl com relação á replicação.

8.0: warm standby

8.1: warm standby (melhorias)

9.0: replicação assincrona e hot standby

9.1: replicação sincrona

9.2: replicação sincrona (remote write) e cascateamento

9.3: replicação lógica e gatilhos de eventos

Exemplo de Script e Replicação por Fluxo

pg standby >=( 8.3)

restore command: script que espera indefinidamente o arquivo WAL

1 triggered = false ;

2 while (! NextWALFileReady ( ) && ! triggered )

3

4 sleep (100000L) ; / *waitfor ~0.1 sec */

5 if(CheckForExternalTrigger ( ) )

6 triggered = true;

7

8 if(!triggered)

9 CopyWALFileForRecovery ( ) ;

WALReceiver estabelece uma conexão (via libpq) com

servidor principal

servidor principal abre o processo WalSender para

enviar WAL ao servidor replica

replicação sincrona espera WAL ser escrito no disco do

servidor replica

Referências

Blog Euler Taveira - http://eulerto.blogspot.com.br/

Acessado em 22/11/2014.

http://www.devmedia.com.br/mysql-replicacao-de-dados/22923

Acessado em 20/11/2014

http://www.devmedia.com.br/topologias-de-replicacao-no-mysql/2073

Acessado em 20/11/2014

http://www.devmedia.com.br/replicacao-de-dados-no-mysql/2054

Acessado em 20/11/2014

Tanenbaum, Andrew S., Sistemas Distribuídos: princípios e paradigmas – 2. ed. -

São Paulo, Pearson Prentice Hall,2007.