Início / dba / Perguntas / 34149
Accepted
Jharwood
Asked: 2013-02-06 06:47:56 +0800 CST

Sincronização automática do MySQL do mestre, onde o escravo ficou offline por um longo período de tempo

  • 772

Alguém aqui sabe se há alguma ferramenta, que não use a replicação integrada do mysql, que sincronizará dois bancos de dados quando o escravo estiver inacessível da Internet por longos períodos de tempo?

A ideia é configurar uma base de máquina virtual para nossos desenvolvedores da Web, que podem ligar a VM e cloná-la automaticamente de um escravo do banco de dados de produção para fins de teste/desenvolvimento. todos eles requerem seus próprios bancos de dados, mas todos devem replicar o banco de dados mestre na inicialização.

Diagrama de funcionamento:

Banco de dados de produção -> Escravo somente leitura de produção -> Máquina virtual de desenvolvimento

mysql replication

1 respostas

  1. Best Answer

    O único banco de dados que eu poderia pensar seria Percona XtraDB Cluster (PXC)

    Ele tem dois métodos para copiar um nó de cluster inteiro

    • SST (State Snapshot Transfer) é a cópia completa dos dados de um nó para outro. É usado quando um novo nó se junta ao cluster, ele tem que transferir dados do nó existente. Existem três métodos de SST disponíveis no Percona XtraDB Cluster: mysqldump, rsync e xtrabackup (o Percona XtraBackup com suporte ao XtraDB Cluster será lançado em breve, atualmente você precisa usar nosso repositório de código-fonte). A desvantagem do mysqldump e do rsync é que seu cluster se torna READ-ONLY enquanto os dados estão sendo copiados de um nó para outro (o SST aplica o comando FLUSH TABLES WITH READ LOCK). O Xtrabackup SST não requer READ LOCK para todo o processo de sincronização, apenas para sincronizar arquivos .frm (o mesmo que com backup regular).
    • IST (Transferência de Estado Incremental) : Funcionalidade que, em vez do instantâneo de estado inteiro, pode alcançar o grupo recebendo os conjuntos de gravações ausentes, mas somente se o conjunto de gravações ainda estiver no cache do conjunto de gravações do doador.

    Eu abordei isso antes

    EMBARGO

    Esta seria a solução ideal se todo o banco de dados for InnoDB. Se você tiver tabelas MyISAM somente leitura, tudo bem, desde que você copie o MyISAM para cada nó manualmente. O SST fará uma cópia completa das tabelas MyISAM, mas o recurso MultiMaster Replication do PXC não replicará os dados MyISAM.

    Quanto ao PXC, testei rigorosamente no Amazon EC2 e funciona como um sonho. O PXC funciona como anunciado.

    ATUALIZAÇÃO 2013-02-06 16:40 EDT

    drogart fez o seguinte comentário:

    Não acho que ter um nó do cluster de produção como um ambiente de desenvolvimento/teste seja uma boa ideia. Isso misturaria o tráfego de gravação de desenvolvimento de volta ao banco de dados prod. Isso também criaria uma situação em que os desenvolvedores poderiam impactar o cluster prod db ativando um novo nó.

    Aqui tem um ponto muito válido. À luz disso, seja muito cuidadoso e econômico quanto ao que os desenvolvedores podem fazer.

    No entanto, se você precisar de uma cópia completa da produção em um servidor de desenvolvimento, fora do pico:

    • STEP01) Configurar novo servidor PXC
    • STEP02) Configurar opções wsrep
    • STEP03) Inicie o MySQL (o SST deve começar)
    • STEP04) Desligar o MySQL
    • STEP05) Comente as opções do wsrep
    • STEP06) Reinicie o MySQL (cheio de dados de produção sem conectividade com o cluster real)

    Depois que esse servidor de desenvolvimento estiver configurado, faça o seguinte para atualizá-lo:

    • STEP01) Desligar o MySQL
    • STEP02) Descomente as opções do wsrep
    • PASSO 03)rm -f /var/lib/mysql/galera.cache
    • PASSO 04)rm -f /var/lib/mysql/grastate.dat
    • STEP05) Inicie o MySQL (o SST deve começar)
    • STEP06) Comente as opções do wsrep
    • STEP07) Reinicie o MySQL (cheio de dados de produção sem conectividade com o cluster real)

    CAVEAT: Faça esta cópia do Prod to Dev fora do horário de pico !!!

    • 1

relate perguntas