É seguro modificar o valor do innodb_data_file_path para o mysql 5?

Question

Recentemente, experimentei a corrupção de dados depois de alterar o valor desse parâmetro em my.cnf de:

innodb_data_file_path = ibdata1:10M:autoextend:max:128M

para:

innodb_data_file_path = ibdata1:10M:autoextend:max:256M

Eu não estou completamente certo de que este foi o motivo da corrupção, uma vez que anteriormente o DB ficou sem espaço. Minha pergunta é, é seguro modificar o tamanho máximo do banco de dados quando o espaço estiver cheio?

    

Answer 1

Se você quiser ter certeza, você deve fazer o seguinte:

Primeiro, altere o innodb_data_file_path em /etc/my.cnf para

[mysqld]
innodb_data_file_path = ibdata1:10M:autoextend

O, execute o seguinte

cd
service mysql restart --skip-networking --skip-grant-tables
mysqldump --single-transaction --routines --triggers --all-databases > MySQLData.sql
service mysql stop

Certifique-se de que /root/MySQLData.sql existe. Então, prossiga com

rm /var/lib/mysql/ibdata1
rm /var/lib/mysql/ib_logfile0
rm /var/lib/mysql/ib_logfile1
service mysql start --skip-networking --skip-grant-tables
mysql < MySQLData.sql
service mysql restart

Experimente!

Na verdade, eu tenho um monitoramento no meu trabalho que usa o MySQL como repositório e mudei o número máximo de 1TB para 16TB. Durante a coleta de dados, nada poderia ser escrito, mas nenhuma corrupção foi introduzida. Você poderia simplesmente mudar o número.

Eu removeria o valor máximo como mencionei

innodb_data_file_path = ibdata1:10M:autoextend

por dois motivos:

1. a alteração é muito pequena
2. ibdata1 sempre será escrito porque o espaço para tabelas undo está dentro dele e deve ser gravado. Isso causará algum crescimento ocasional de ibdata1. Você pode simplesmente se deparar com isso novamente. Então, é melhor remover a opção max.