Respondendo pela posteridade.
Innobackupex com --rsync fez o truque. Reduziu o tempo de bloqueio para segundos.
Eu tenho um banco de dados MySQL 5.5 com milhares de tabelas e pesada carga de trabalho de gravação.
Eu preciso usar o xtrabackup para fazer backup online (criar um escravo do servidor de produção com tempo de inatividade mínimo), mas o problema é que o estágio final do backup (quando ele emite FLUSH TABLES WITH READ LOCK) leva muito tempo para ser concluído . Eu suspeito que isso é porque copia milhares de arquivos de definição de tabela frm. Posso acelerar este processo por qualquer meio? Por exemplo, se eu tenho certeza de que a estrutura da tabela não está mudando?
Também vi que innobackupex tem uma opção chamada --rsync que supostamente deveria ajudar, mas innobackupex está obsoleto agora, e o xtrabackup está perdendo essa opção por algum motivo.
Qualquer ajuda para reduzir o período durante o qual o FLUSH TABLES WITH READ LOCK é efetivo será bem-vinda.
Existe uma --no-lock opção , no entanto, você só poderá usá-lo se não tiver tabelas não-InnoDB graváveis e se não se importar com a posição do log binário.
Se você não puder usar --no-lock , sugiro configurar uma réplica e fazer backups dela.
BTW, --rsync não ajudaria aqui mesmo.
Use o parâmetro --rsync.
Surpreendentemente, está disponível no xtrabackup, apesar de não aparecer em nenhum lugar na documentação do Percona XtraBackup 2.4 a partir desta escrita. A documentação está errada. = /
Se você passar o parâmetro para o comando xtrabackup, ele funcionará como faria com o innobackupex. E isso faz sentido, já que o innobackupex é apenas um link simbólico de 'chamador' agora.
Eu vi em sua auto-resposta que você 'voltou' ao uso do innobackupex. Eu recomendaria contra, uma vez que, de acordo com a documentação:
From Percona XtraBackup version 2.3 innobackupex is has been rewritten in C and set up as a symlink to the xtrabackup. innobackupex supports all features and syntax as 2.2 version did, but it is now deprecated and will be removed in next major release. Syntax for new features will not be added to the innobackupex, only to the xtrabackup.
já está desatualizado e não possui novas funcionalidades disponíveis no xtrabackup. Por exemplo "--dados de dados-exclude"
No meu cenário, os backups costumavam desperdiçar 6 minutos em LOCK TABLES:
180824 14:52:53 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
180824 14:52:53 Executing FLUSH TABLES WITH READ LOCK...
(...)
180824 14:58:55 Executing UNLOCK TABLES
180824 14:58:55 All tables unlocked
E com --rsync, ficou menos de um segundo.
180824 13:07:28 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
180824 13:07:28 Executing FLUSH TABLES WITH READ LOCK...
180824 13:07:28 Starting to backup non-InnoDB tables and files
180824 13:07:28 Starting rsync as: rsync -t . --files-
(...)
180824 13:07:28 Executing UNLOCK TABLES
180824 13:07:28 All tables unlocked
Eu tive exatamente o mesmo problema que você teve e encontrei sua pergunta & resposta, que juntamente com a falta de uma documentação consistente, me fez acreditar que não estava disponível e acabei perdendo um dia procurando soluções alternativas, já que o innobackupex está desatualizado e não tem algumas funções que eu preciso, como as já citadas - -databases-exclude.
Poste esta resposta para que, se alguém se encontrar com o mesmo problema exato, saiba que pode usar o parâmetro mesmo que não esteja nos documentos.