Maneira de evitar o tempo de inatividade do servidor ao criar uma relação mestre-escravo?

Question

Estou me preparando para configurar um relacionamento mestre-escravo ou master-master do MySQL. Agora 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 deixar "lentamente" sincronizar dados do mestre, até que eles sejam idênticos?

Eu tenho notado que eu posso pegar um dump transacional com o mysqldump no master e importá-lo para o slave, mas no momento em que o slave tiver importado o dump, muitas novas linhas terão sido escritas e como será escravo consegue isso?

Eu espero que esteja faltando algo óbvio aqui, mas extenso googling dá 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.

Relacionadas pergunta para o MyISAM , mas eu uso o InnoDB.

    

Answer 1

Se você estiver usando 100% InnoDB, então você está com sorte. Você pode usar XtraBackup para fazer um backup completo do seu banco de dados mestre sem qualquer tempo de inatividade ou qualquer bloqueio de tabela. Esse será um backup consistente no estilo de instantâneo, o mesmo da classificação que você recebe quando executa as opções FLUSH TABLES WITH READ LOCK ou --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 que você precisa para iniciar a replicação no escravo.

Uma vez que você tenha feito o backup, será necessário executar a opção --prepare do XtraBackup no backup, carregá-lo no escravo, iniciar o processo escravo do MySQL e informar os novos valores MASTER_LOG_POS e MASTER_LOG_FILE necessários.

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

Lembre-se também que o mysql schema é MyISAM por padrão (e se a memória é exibida corretamente, ele só pode ser MyISAM), então você ainda terá que tomar cuidado para não fazer alterações em nenhuma dessas tabelas enquanto estiver executando o comando. cópia de segurança. Contanto que você se atenha a essa regra, as informações mestras ainda estarão corretas.

É sempre uma boa ideia ignorar a mysql schema no seu my.cnf no escravo e só cria 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 usa as ferramentas que o Percona (e o Maatkit antes deles) fornecem para isso.

Editar:

Embora você tenha dito que está usando o InnoDB, para completar, existe outra maneira se você estiver usando tabelas MyISAM. Se você tiver um gerenciador de volume com snapshot (como ZFS ou LVM ), você pode executar um FLUSH TABLES WITH READ LOCK seguido por um SHOW MASTER STATUS , criar um instantâneo e executar UNLOCK TABLES . O tempo de inatividade deve ser razoavelmente mínimo. Para comparação, a tarefa do cron na noite passada que fez isso para fazer backup de um dos 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.

    

Answer 2

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

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

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

Esse comando bloqueará todas as tabelas dentro dos bancos de dados afetados durante o despejo e gravará as coordenadas de replicação no cabeçalho do dump de maneira comentada assim:

-- 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" com o nome do host do seu mestre e os dados de autenticação - a replicação será removida no ponto de despejo.

Por favor, tenha em mente que o processo mysqldump incorrerá em "tempo de inatividade" devido a bloqueio de contenção - ele coloca bloqueios de leitura em todas as tabelas (semelhante ao que um comando FLUSH TABLES WITH READ LOCK faria) por toda a duração do despejo. Assim, nenhum pedido escrito em qualquer uma das tabelas retornará a menos que o dump esteja completo. Além disso, as solicitações de gravação provavelmente também bloqueariam as solicitações de leitura subsequend, a menos que você tenha especificado low_priority_updates em sua configuração do MySQL ou emitiu SET GLOBAL LOW_PRIORITY_UPDATES = 1 antes do dump.