O que deve ser feito antes de atualizar o MySQL?

Se você interromper o processo do servidor MySQL normalmente, o sistema de arquivos e os bancos de dados não serão corrompidos.

Aqui estão algumas coisas que eu normalmente faço:

Verifique se innodb_fast_shutdownestá desabilitado. Se não estiver, desative-o.

mysql> show variables like 'innodb_fast_shutdown';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| innodb_fast_shutdown | 0     |
+----------------------+-------+
1 row in set (0.00 sec)

De acordo com a documentação , isso só é necessário ao fazer uma atualização de versão principal , mas eu mantenho que ainda é uma boa ideia - esta etapa aumenta o tempo de desligamento, mas deixa sua instância em um estado mais estável para a reinicialização.

Em seguida, você pode bloquear todas as tabelas para impedir que os clientes façam qualquer coisa. Essa etapa também não é tecnicamente necessária, mas eu gosto dela porque me dá a sensação de saber o que está acontecendo -- e o que não está -- e quando -- e encurta a próxima parte do desligamento, já que não haverá nenhuma atividade do cliente para aguardar.

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)

Observe que em um servidor ocupado, essa instrução não retornará tão rapidamente. Ele não retornará até que o servidor tenha fechado com sucesso todas as tabelas abertas e adquirido um bloqueio em todas as tabelas em todo o banco de dados - portanto, se você tiver consultas em execução quando emitir esta instrução, elas poderão terminar, então os bloqueios adquirido, e então é quando você receberá seu prompt de volta.

mysql>

Importante: deixe esta conexão aberta. Apenas deixe-o ficar lá e vá para uma nova janela, porque a conexão que está sendo aberta é o que mantém o bloqueio de leitura global. Se você fechar ou perder essa conexão, o bloqueio de leitura será liberado.

Se você quiser olhar para quaisquer variáveis, a lista de processos, etc., você ainda pode usar esta conexão se quiser. Apenas não se desconecte do servidor.

Neste ponto (desde que você recebeu seu prompt de volta), suas tabelas estão bloqueadas para novas alterações e sua camada de aplicativo pode começar a se comportar mal porque um backlog pode estar crescendo. Isso é de se esperar, já que qualquer consulta no servidor aguardará indefinidamente por esse bloqueio de leitura. O número de conexões de clientes pode estar aumentando, mas eles não poderão fazer nada.

Em outra janela, siga seu log de erros do MySQL.

shell> tail -f /usr/local/mysql/data/hostname.err 

Em outra janela, desligue o MySQL Server:

shell> mysqladmin shutdown

Você provavelmente precisará adicionar --username --password e possivelmente outras opções a este comando. Você não verá muito desta janela, então volte e observe seu log de erros:

O servidor diz: "vamos fazer um desligamento normal". (Não com tantas palavras, mas é isso que esta próxima entrada de log significa...)

130119 13:29:17 [Note] /usr/local/mysql-5.5.28-solaris10-x86_64/bin/mysqld: Normal shutdown

O servidor encerra todos os encadeamentos do sistema. Nesse caso, deixei o agendador de eventos e até mesmo a replicação em execução para ilustrar que um desligamento normal é realmente normal. (Sim, meu servidor foi iniciado imediatamente, incluindo a replicação, logo após eu capturar esta saída.) Na prática, pode ser melhor interromper a replicação manualmente STOP SLAVE;antes de liberar as tabelas e adquirir o bloqueio de leitura. O Agendador de eventos é um recurso opcional, que você pode ou não usar. Aqui está a saída de exemplo:

130119 13:29:17 [Note] Event Scheduler: Killing the scheduler thread, thread id 1
130119 13:29:17 [Note] Event Scheduler: Waiting for the scheduler thread to reply
130119 13:29:17 [Note] Slave I/O thread killed while reading event
130119 13:29:17 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.001539', position 849647640
130119 13:29:17 [Note] Event Scheduler: Stopped
130119 13:29:17 [Note] Event Scheduler: Purging the queue. 3 events
130119 13:29:17 [Note] Slave SQL thread exiting, replication stopped in log 'mysql-bin.001539' at position 849626716

O InnoDB faz sua limpeza (incluindo o "desligamento lento")...

130119 13:29:19  InnoDB: Starting shutdown...
130119 13:29:20  InnoDB: Waiting for 6 pages to be flushed
130119 13:29:26  InnoDB: Shutdown completed; log sequence number 2718873505306

O servidor desliga...

130119 13:29:26 [Note] /usr/local/mysql-5.5.28-solaris10-x86_64/bin/mysqld: Shutdown complete

O wrapper mysqld_safe avisa que o servidor parou de funcionar. Este processo é responsável por tentar reiniciar o servidor se ele travar, mas se o servidor tiver removido seu próprio arquivo pid, nenhuma tentativa de reinicialização é feita, porque o desligamento é considerado normal.

130119 13:29:27 mysqld_safe mysqld from pid file /usr/local/mysql-5.5.28-solaris10-x86_64/data/psi2.pid ended

Agora você está graciosamente desligado.

Isso tudo é bonito, mas um pouco paranóico. Dependendo do tipo de servidor que você está executando, você pode usar o ionice para garantir que a máquina não esteja fazendo nada pesado, o resto é feito pelo próprio mysql. Digamos que alguns dos scripts do meu servidor mysql sofram de vazamento de memória, descobrirei a hora do dia em que o servidor está com o uso mais baixo e, em seguida, reinicio graciosamente o mysqld quando a CPU estiver ociosa, então uso o crontab e faço o seguinte:

# clear and clean start MySQL and httpd daily
38 5 * * * root ionice -c3 /etc/init.d/mysqld restart > /dev/null 2>&1
39 5 * * * root /usr/sbin/apachectl graceful > /dev/null 2>&1