Eu tenho um banco de dados MySQL em um servidor executando o Windows 7, e eu quero criar uma cópia rápida (mas segura!) Sem desligar nada. Eu emito FLUSH TABLES WITH READ LOCK, executo o Robocopy e, em seguida, emito UNLOCK TABLES. Aqui está o problema: Se eu usar a opção / B para Robocopy, ele imprime muitas mensagens dizendo "O processo não pode acessar o arquivo porque ele está sendo usado por outro processo." E apenas copia 209 dos 535 arquivos em dados MySql diretório. Se eu deixar a opção / B, o Robocopy relatará que todos os arquivos foram copiados. Mas agora estou inseguro. Eu estou supondo que o MySQL deixa os arquivos da tabela abertos mesmo enquanto as coisas estão travadas, e o Robocopy / B decide que fazer backup deles não seria seguro. Sem / B, o Robocopy faz o seu melhor esforço, o que deve funcionar porque o MySQL não está fazendo qualquer I / O, mas eu

MyISAM

Se você tiver um banco de dados all-MyISAM, isso pode funcionar, porque todas as tabelas MyISAM terão 0 contadores de identificadores de arquivos em seus cabeçalhos.

InnoDB

Se você tiver alguma tabela InnoDB, FLUSH TABLES WITH READ LOCK;pode não fornecer isolamento adequado para a integridade dos dados. Eu escrevi sobre isso no DBA StackExchange em novembro de 2012 (Como executar um backup frio com Linux / tar sem desligar o MySQL slave?)

Dada a Arquitetura InnoDB (Imagem feita por Percona CTO Vadim Tkechenko)

existem quatro objetos que ainda estão se movendo após FLUSH TABLES WITH READ LOCK;serem emitidos:

• Double Write Buffer
• Inserir buffer
• Redo Logs
• Desfazer Logs

Suponha que você execute o FLUSH TABLES WITH READ LOCK;Robocopy e leve 5 minutos para copiar. Isso significa que as alterações físicas que estão sendo feitas durante os 5 minutos não estarão presentes no backup. Pior ainda, as alterações no arquivo não serão de um único ponto no tempo. Isso significa que pode haver alguns .ibdarquivos que podem ou não ter sido alterados, mas a transação que mantém suas alterações não foi totalmente confirmada.

Você teria que copiar esses dados para outra máquina, iniciar o MySQL e verificar se a recuperação de falhas (que ocorre durante a inicialização do mysqld, ler e processar esses quatro objetos) torna os dados estáveis ​​e utilizáveis.

Você está melhor usando mysqldumpa --single-transactionopção.

Para algumas ideias, veja minhas postagens antigas do DBA StackExchange

• Apr 17, 2011: Como posso otimizar um mysqldump de um banco de dados grande?
• Mar 14, 2014: mysqldump com nome de exportação gerado automaticamente