Maneira de evitar o tempo de inatividade do servidor ao criar o relacionamento Master - Slave?

Maneira de evitar o tempo de inatividade do servidor ao criar o relacionamento Master - Slave?

Estou me preparando para configurar um relacionamento mestre-escravo ou mestre-mestre MySQL. No momento eu tenho um único servidor de produção MySQL e é claro que não quero muito tempo de inatividade enquanto conecto o escravo.

Não há como conectar um escravo vazio e deixá-lo sincronizar "lentamente" os dados do mestre, até que sejam idênticos?

Percebi que posso fazer um dump transacional com mysqldump no mestre e depois importá-lo para o escravo, mas quando o escravo importar o dump, muitas linhas novas terão sido escritas e como o escravo obterá essas ?

Espero estar faltando algo óbvio aqui, mas pesquisas extensas no Google dão conselhos como "já que isso resultará em menos tempo de inatividade no futuro, algum tempo de inatividade agora talvez não seja uma coisa tão ruim". Mas eu realmente gostaria de evitar isso.

Relacionadopergunta para MyISAM, mas eu uso o InnoDB.

Responder1

Se você estiver usando 100% InnoDB, então você está com sorte. Você pode usarXtraBackuppara fazer um backup completo do seu banco de dados mestre sem qualquer tempo de inatividade ou bloqueio de tabela. Este será um backup consistente no estilo de instantâneo, o mesmo tipo que você obtém ao executar as opções FLUSH TABLES WITH READ LOCKou --master-data.

A ferramenta XtraBackup também descarta um arquivo extra no diretório de backup que contém as informações MASTER_LOG_POS e MASTER_LOG_FILE necessárias para iniciar a replicação no escravo.

Assim que terminar o backup, você precisará executar --preparea opção do XtraBackup no backup, carregá-lo no escravo, iniciar o backup do processo MySQL escravo e informar os novos valores MASTER_LOG_POS e MASTER_LOG_FILE necessários.

Você vai querer entrar skip-slave-startno seu my.cnf antes de iniciar o escravo.

Tenha também em mente que o mysqlesquema é MyISAM por padrão (e se a memória funcionar corretamente, só pode ser MyISAM), então você ainda terá que ter cuidado para não fazer nenhuma alteração em nenhuma dessas tabelas durante a execução do backup. Contanto que você siga essa regra, as informações principais ainda estarão corretas.

Muitas vezes é uma boa ideiaignore o mysqlesquema em seu my.cnfno escravo e apenas crie usuários com privilégios SELECT. Escravos inconsistentes e fora de sincronia são difíceis de detectar e difíceis de lidar, mesmo quando se usam as ferramentas que Percona (e Maatkit antes deles) fornecem para isso.

Editar:

Embora você tenha dito que está usando o InnoDB, para completar, há outra maneira se você estiver usando tabelas MyISAM. Se você tiver um gerenciador de volume com snapshot (comoZFSouLVM), você pode executar a FLUSH TABLES WITH READ LOCKseguido de a SHOW MASTER STATUS, criar um snapshot e executar UNLOCK TABLES. O tempo de inatividade deve ser mínimo. Para efeito de comparação, o cron job da noite passada que fez isso para fazer backup de um de nossos bancos de dados levou 6 segundos para criar o instantâneo, que é o bit onde o banco de dados está "inativo" e 27 minutos para copiar os arquivos do instantâneo para o servidor de backup.

Responder2

Não é possível iniciar uma replicação mysql “do zero”.

Em vez disso, você poderia usar mysqldump com o --master-data=2parâmetro ao despejar seus bancos de dados - ou seja, assim:

mysqldump --master-data=2 --all-databases --opt -p > myinitialdump.sql

Este comando bloqueará todas as tabelas nos bancos de dados afetados durante o dump e gravará as coordenadas de replicação no cabeçalho do dump de uma forma comentada como esta:

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000018', MASTER_LOG_POS=106;

Após a conclusão da importação, você pode executar manualmente o comando "alterar mestre para" temperado com o nome do host do seu mestre e os dados de autenticação - a replicação será iniciada no ponto de despejo.

Por favor, tenha em mente que o processo mysqldump incorrerá em "tempo de inatividade" devido à contenção de bloqueio - ele coloca bloqueios de leitura em todas as tabelas (semelhante ao que um comando FLUSH TABLES WITH READ LOCK faria) durante toda a duração do dump. Assim, nenhuma solicitação escrita em qualquer uma das tabelas retornará, a menos que o dump seja concluído. Além disso, as solicitações de gravação provavelmente também bloqueariam quaisquer solicitações de leitura subsequentes, a menos que você tenha especificadolow_priority_updatesna sua configuração do MySQL ou emitiu SET GLOBAL LOW_PRIORITY_UPDATES=1 antes do dump.

informação relacionada