AutoMysqlBackup --lock-tables = false

Question

Estou tentando usar o script AutoMysqlBackup para executar backups diários do meu aplicativo. Infelizmente, na primeira tentativa, não me serviu como eu pensei que seria.

Acredito que o script usou o parâmetro --lock-tables=true e fez meu aplicativo parar de funcionar.

Se este for o caso, como posso fazer com que o script não bloqueie as tabelas? (então meu aplicativo pode continuar sendo executado)?

Obrigado.

    

Answer 1

Ok, não estou realmente familiarizado com esse software, mas:

• É um script de shell, tão trivial (em teoria) para editar. Claro, é um script de linha de 2200 linhas.
• Eu acho que --lock-tables vem de --opt, que é especificado (de um rápido muito ) no topo da função parse_configuration . Você pode adicionar --skip-lock-tables .
• Ele usa os utilitários mysql, então você também pode adicioná-lo no seu .my.cnf da maneira normal.

Em geral:

• Você não está usando InnoDB, mas está usando MyISAM, então você não tem transações. Então você não pode usar --single-transaction .
• Você precisa, portanto, bloquear para garantir a consistência. Mesmo com o bloqueio, não é garantido (apenas mais provável). Mas é tanto quanto você está garantido em operação normal. Considere o InnoDB, seriamente (mas, por favor, leia os documentos, pesquise primeiro e teste, para ter certeza de que ele não quebrará seu aplicativo).
• Se você desabilitar o bloqueio, você pode ter:
  1. Iniciar backup
  2. Tabela de backup A.
  3. Exclua um registro de A e também o registro filho em B.
  4. Tabela de backup B.
  5. Seu backup agora contém um registro em A que aponta para um registro inexistente em B. Em outras palavras, não é consistente.
• Existem soluções de backup do MySQL mais amplamente usadas. Talvez você deva mudar para um deles. É mais fácil encontrar ajuda com software que mais pessoas usam (e também tende a ser melhor testado).
• Você pode pensar que você tem um backup, mas não o faz até que tenha feito uma restauração bem-sucedida, de preferência a partir do bare-metal (disco rígido recém-formatado). Idealmente, você faz isso rotineiramente e, de preferência, automatiza-o. Isso não é específico do MySQL, aplica-se a todos os backups .

Existe uma solução (além de mudar para o InnoDB): você pode executar seu backup em um servidor escravo. Não importa se você bloqueia todas as tabelas ou SLAVE STOP SQL_THREAD durante o backup, porque isso não importará para o primário. Esta é a solução sem tempo de inatividade. Você deve ter este servidor de qualquer maneira, como um modo de espera quente / quente no caso de o primário falhar.

Há outra solução, que minimiza o tempo de inatividade: coloque o banco de dados em um volume LVM, faça um FLUSH TABLES WITH READ LOCK , tire um instantâneo LVM e libere seu bloqueio de leitura (a desconexão fará isso). Você pode então fazer um backup do instantâneo. Esta é a solução "Não posso pagar por outra máquina".

    

Answer 2

1. Para Innodb você pode simplesmente adicionar CONFIG_mysql_dump_single_transaction = 'yes' no seu arquivo conf.

2. Para o mecanismo MyISAM, você precisará adicionar --skip-add-locks no arquivo automysqlbackup. encontre a função parse_configuration e adicione o valor da matriz como dado abaixo.

Eu verifiquei o seu ótimo trabalho.

Alterar

parse_configuration () {
    # OPT string for use with mysqldump ( see man mysqldump )
    opt=( '--quote-names' '--opt')

para

parse_configuration () {
    # OPT string for use with mysqldump ( see man mysqldump )
    opt=( '--quote-names' '--opt' '--skip-add-locks' '--skip-add-drop-table')