Como alterar com segurança a variável innodb do MySQL 'innodb_log_file_size'?

Sim, é seguro deletar o arquivo de log assim que o mysqld for desligado

Diante disso, basta realizar os seguintes passos:

mysql -uroot -p... -e"SET GLOBAL innodb_fast_shutdown = 0"
service mysql stop
mv /var/lib/mysql/ib_logfile[01] /tmp
service mysql start

A inicialização do mysqld irá recriar ib_logfile0eib_logfile1

De uma chance !!!

ATUALIZAÇÃO 2011-10-20 16:40 EDT

Ele limpa todos os dados no InnoDB Buffer Pool antes de refazer os arquivos de log, você deve definir esta opção cerca de 1 hora antes do desligamento:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Por padrão, innodb_max_dirty_pages_pct é 75 (MySQL 5.5+) ou 90 (antes do MySQL 5.5). Definir isso como zero mantém o número de páginas sujas abaixo de 1% do InnoDB Buffer Pool. Performing service mysql stopfaz isso de qualquer maneira. Além disso, um desligamento encerrará todos os itens restantes no log de redo. Para manter esta opção, basta adicioná-la ao /etc/my.cnf:

[mysqld]
innodb_max_dirty_pages_pct = 0

ATUALIZAÇÃO 2013-04-19 16:16 EDT

Atualizei minha resposta um pouco mais com innodb_fast_shutdown porque costumava reiniciar o mysql e parar o mysql para fazer isso. Agora, essa etapa é vital porque cada transação não confirmada pode ter outras partes móveis dentro e fora dos logs de transações do InnoDB ( consulte InnoDB Infrastructure ).

Por favor, note que definir innodb_fast_shutdown para 2 limparia os logs também, mas mais partes móveis ainda existem e são escolhidas no Crash Recovery durante a inicialização do mysqld. A configuração de 0 é a melhor.

Em vez disso, eu recomendaria o método oficial , que reproduzo aqui por conveniência:

Para alterar o número ou o tamanho dos arquivos de log do InnoDB no MySQL 5.6.7 ou anterior , use as instruções a seguir. O procedimento a ser usado depende do valor de innodb_fast_shutdown, que determina se o tablespace do sistema deve ou não ser totalmente atualizado antes de uma operação de desligamento:

• Se innodb_fast_shutdown não estiver definido como 2: Pare o servidor MySQL e certifique-se de que ele seja encerrado sem erros, para garantir que não haja informações de transações pendentes no redo log. Copie os arquivos de redo log antigos para um local seguro, caso algo dê errado durante o desligamento e você precise deles para recuperar o tablespace. Exclua os arquivos de log antigos do diretório de arquivos de log, edite my.cnf para alterar a configuração do arquivo de log e inicie o servidor MySQL novamente. mysqld vê que nenhum arquivo de log do InnoDB existe na inicialização e cria novos.

• Se innodb_fast_shutdown estiver definido como 2: Defina innodb_fast_shutdown como 1:

mysql> SET GLOBAL innodb_fast_shutdown = 1;

Em seguida, siga as instruções do item anterior.

A partir do MySQL 5.6.8 , a configuração innodb_fast_shutdown não é mais relevante ao alterar o número ou o tamanho dos arquivos de log do InnoDB. Além disso, não é mais necessário remover arquivos de log antigos, embora você ainda queira copiar os arquivos de log antigos para um local seguro, como backup. Para alterar o número ou o tamanho dos arquivos de log do InnoDB, execute as seguintes etapas:

1. Pare o servidor MySQL e certifique-se de que ele seja encerrado sem erros.

2. Edite my.cnf para alterar a configuração do arquivo de log. Para alterar o tamanho do arquivo de log, configure innodb_log_file_size. Para aumentar o número de arquivos de log, configure innodb_log_files_in_group.

3. Inicie o servidor MySQL novamente.

Se o InnoDB detectar que o innodb_log_file_size difere do tamanho do arquivo de log de redo, ele gravará um ponto de verificação de log, fechará e removerá os arquivos de log antigos, criará novos arquivos de log no tamanho solicitado e abrirá os novos arquivos de log.

innodb_buffer_pool_size-- simplesmente mude my.cnf( my.ini) e reinicie o mysqld.

innodb_log_file_sizeé menos crítico. Não altere a menos que haja uma razão para isso. Roland deu os passos , mas um aspecto me preocupa... Não sei se os dois primeiros passos são importantes; parece que eles podem ser:

1. set innodb_fast_shutdown = OFF
2. reinicie o mysql
3. parar o mysql
4. remova os arquivos de log
5. iniciar mysql

Os arquivos de log acompanham os negócios inacabados; " innodb_fast_shutdown" diz para lidar com essas coisas depois de reiniciar. Então, remover os arquivos pode perder informações?

Novas versões melhoraram as coisas: (mais discussão nos comentários)

• 5.6 Permite innodb_log_file_size> 4 GB
• 5.6 innodb_log_file_sizepode ser alterado sem primeiro remover o iblog*
• 5.7 permite redimensionar dinamicamenteinnodb_buffer_pool_size

Devo alterar log_file_size?

Use GLOBAL STATUSpara calcular o número de minutos antes dos ciclos de log.

Uptime / 60 * innodb_log_file_size / Innodb_os_log_written`

Se for muito inferior a 60 (minutos), pode ajudar a aumentar log_file_size. Se for muito mais, os arquivos de log estão desperdiçando espaço em disco. Essa "1 hora" é bastante arbitrária, portanto, se você estiver perto disso, não se preocupe em alterar o log_file_size.

Deixe innodb_log_files_in_groupno padrão de 2.

Quando você fizer logon no mysql, digite esses comandos:

pager grep seq;
show engine innodb status \G select sleep(60); show engine innodb status \G

Você receberá dois números. Primeiro você pega um e depois espera um minuto. Você vai conseguir outro.

Digamos que o primeiro seja 3.456.718.123 e o segundo seja 4.098.873.134

Agora (4.098.873.134-3.856.718.123)*60/1024/1024

O resultado é = 13,856 MB

Você tem dois arquivos de log. Então divida por dois e você terá um número próximo a 7.000 MB. Só para ter certeza, defina o tamanho do arquivo de log de 8 GB

chown mysql:mysql -R /etc/mysql /var/lib/mysql && cd /var/lib/mysql && rm -f ib_logfile* && service mysql restart || serviço mysql reiniciar

Experimente, garanto que está funcionando [testado no Debian 6]