Copiar arquivos ibdata está repleto de perigos. Importantes bits de metadados podem ser armazenados em outros arquivos, como ib_logfile0 e ib_logfile1 (essa não é uma lista abrangente) e as configurações no novo servidor (como o tamanho desses dois arquivos de log) precisam ser exatamente iguais às do servidor antigo . Se você errar ou errar copiando um dos arquivos, o novo servidor não será iniciado e você terá que lidar com as mensagens de erro úteis do MySQL no log de erros.
Xtrabackup lida com tudo isso para você. Depois que você usá-lo para despejar seus dados e "preparar", você pode fazer uma cópia de arquivo direto para o novo servidor e iniciá-lo com o novo arquivo ibdata. A etapa "preparar" leva um tempo significativo.
No entanto, desde que você mencionou que o banco de dados que você está movendo é apenas 100GB do arquivo ibdata de 250GB, eu suspeito que ele será mais rápido usando o método mysqldump simplesmente porque ele só precisa transferir 100GB de dados em vez de 250GB. >
Você pode canalizar a saída do mysqldump diretamente para o mysql para evitar ter que salvar o dump em disco assim:
mysqldump -uusername -pmypassword MyDB | mysql -h server2 -uusername -pmypassword MyDB
O cliente mysql tem uma opção -C que ativa a compactação se ambas as extremidades o suportarem. Basta colocá-lo antes da opção -h. A transferência pela rede provavelmente será a parte mais lenta de toda a operação. Se o seu servidor não suporta compressão, você pode fazer a transferência via ssh com a opção -C:
mysqldump -uusername -pmypassword MyDB | ssh -C server2 "mysql -uusername -pmypassword MyDB"
Último pensamento: O tempo que levei para escrever isso provavelmente é mais longo do que os dois métodos juntos, a menos que você tenha uma rede de 10MB / s. Começar. : -)