Trabalho de Sistemas Distribuídos - Replicação de Banco de Dados MySql e PostgreSQL. 5º Semestre - Curso superior de tecnologia em Sistemas para Internet. Instituto Federal de Educação, Ciência e Tecnologia de Mato Grosso do Sul.

1. Sistemas Distribuídos
Professor: Thales Farias Duarte
Replicação de banco de dados MySql e PostgreSQL
Acadêmicos: Anderson dos Santos Ferreira
Jaqueline Nardes França
Valdir Pereira da Silva Junior

2. 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).

3. 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.

4. 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.

5. Modelos de Replicação
Modelo Mestre / Escravo:
Apenas a base mestre recebe atualizações
enquanto na base só é permitida a leitura.

6. 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.

7. 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.

8. MySql & PostgreSQL

9. Replicação MySql
Quando falamos em Replicação de banco
de dados mySql, pensamos em um tipo de
replicação orientado por paradigmas
distintos:
Replicação Master/Slave: onde apenas a
réplica master permite gravação, enquanto
as demais réplicas só permitem leitura;

10. Master-Slave

11. 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’

12. 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

13. 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

14. Master-Master e Topologia Anel

15. 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.

16. 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.

17. 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.

18. 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;

19. 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;

20. Warm standby e Hot standby

21. 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.

22. Cenário de Implementação
Apresentamos a implementação dos
quatros tipos de replicação descritos acima
utilizando o seguinte cenário.

23. 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

24. 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

25. 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.