Pergunta

Aqui está o cenário. 2 servidores web em dois locais distintos, tendo dois bancos de dados MySQL com tabelas idênticas. Também se espera que os dados dentro das tabelas para ser idêntico em tempo real.

Aqui está o problema. Se um utilizador em qualquer localização entra simultaneamente uma nova ficha em tabelas idênticas, tal como ilustrado nas duas primeiras tabelas abaixo, em que a terceira ficha em cada tabela tem sido introduzidos simultaneamente pelas pessoas diferentes. Os dados nas tabelas não é idêntico. Qual é a melhor maneira de manter que os dados permanece idêntica em tempo real, como ilustrado na terceira tabela abaixo, independentemente de onde as atualizações ocorrem? Dessa forma, nas ilustrações abaixo em vez de acabar com 3 linhas em cada mesa, os novos registros são replicados bi-direcional e eles são inseridos em ambas as tabelas para criar 2 tabelas idênticas novamente com 4 colunas desta vez?

Server A in Location A
==============

Table Names
| ID| NAME  |
|-----------|
| 1 | Tom   |
| 2 | Scott |
|-----------|
| 3 | John  |
|-----------|

Server B in Location B
==============
Table Names
| ID| NAME  |
|-----------|
| 1 | Tom   |
| 2 | Scott |
|-----------|
| 3 | Peter |
|-----------|


Expected Scenario
===========
Table Names
| ID| NAME  |
|-----------|
| 1 | Tom   |
| 2 | Scott |
| 3 | Peter |
| 4 | John  |
|-----------|
Foi útil?

Solução

Não há muito o desempenho a ser adquirida de replicar seu banco de dados sobre a dois senhores. No entanto, há um pouco bacana de failover se você codificar sua aplicação correcta.

Configuração Master-Master é essencialmente o mesmo que a configuração Escravo-Master, mas tem dois escravos iniciados e uma mudança importante para seus arquivos de configuração em cada caixa.

Mestre MySQL 1:

auto_increment_increment = 2
auto_increment_offset = 1 

MySQL Master 2:

auto_increment_increment = 2
auto_increment_offset = 2

Estes dois parâmetros garantir que, quando dois servidores estão brigando por uma chave primária, por alguma razão, eles não duplicar e matar a replicação. Em vez de incrementando por um, qualquer campo auto-incremento será pelo incremento padrão por 2. Em uma caixa que vai começar a compensar a partir de 1 e executar a sequência de 1 3 5 7 9 11 13 etc Na segunda caixa que vai começar a compensar em dois e correr ao longo 2 4 6 8 10 12 etc. a partir de teste atual, aparece auto-incremento para dar o próximo número livre, não um que deixou antes.
Por exemplo. Se o servidor 1 insere os 3 primeiros registros (1 3 e 5) quando o Servidor 2 inserções dia 4, será dada a chave de 6 (não 2, que não for usado).

Uma vez que você configurar isso, começar a ambos como Slaves.
Em seguida, verificar ambos estão trabalhando ok, conectar-se a ambas as máquinas e executar a SHOW SLAVE STATUS de comando e você deve observar que tanto Slave_IO_Running e Slave_SQL_Running ambos devem dizer “sim” em cada caixa.

Então, é claro, criar alguns registros de uma tabela e garantir uma caixa só é inserir chaves primárias estranho numeradas eo outro só é incrementar os números pares.

Em seguida, fazer todos os testes para garantir que você pode executar todas as aplicações padrão em cada caixa com que replicar para o outro.

É relativamente simples, uma vez que vai.
Mas, como já foi mencionado, o MySQL não desencorajá-lo e aconselhar que você garantir que você está atento a esta funcionalidade ao escrever o código do aplicativo.

Editar: Acho que é teoricamente possível adicionar mais mestres se você assegurar que as compensações estão corretas e assim por diante. Você pode de forma mais realista, porém, acrescentar alguns escravos adicionais.

Outras dicas

MySQL não suporta replicação síncrona, no entanto, mesmo que o fizesse, você provavelmente não quer usá-lo (não pode tomar a batida desempenho de esperar por outro servidor para sincronização em cada transação commit).

Você terá que considerar soluções arquitectónicas mais apropriado - há produtos de terceiros que irá fazer uma mala e resolver conflitos de forma predeterminada - esta é a única maneira realmente

.

Esperando a sua arquitetura para a função desta forma é ingênuo - não há "solução fácil" para qualquer banco de dados, não apenas MySQL

.

É importante que os UIDs são os mesmos? Ou será que você entreter o pensamento de ter uma tabela ou coluna mapear o UID remoto para o UID local e escrever código de sincronização personalizada para os objetos que você deseja replicar em toda que faz qualquer mapeamento necessária de UIDs para colunas de chave estrangeira, etc?

A única maneira de garantir que suas tabelas são sincronizadas é configurar uma replicação de 2 maneiras entre bancos de dados.

Mas, MySQL só permite a replicação unidirecional, então você não pode simplesmente resolver o seu problema com essa configuração.

Para ser claro, você pode "configuração" A 2 maneiras de replicação, mas MySQL AB desencoraja esse .

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top