Não é possível iniciar o mysql depois de mover para a unidade externa

1

No começo deste mês, herdei um servidor MySQL 5.6 hospedado em uma pequena VM do Azure com um único disco rígido de 30 GB. O banco de dados estava consumindo 22 GB; o uso do disco foi de 89%.

Migre / var / lib / mysql para o disco montado com o symlink

lsblk && df
sudo mkdir /media/sdc
fdisk /dev/sdc
     n p 1 2048 209715199 w
sudo mkfs.ext3 /dev/sdc1
sudo mount /dev/sdc1 /media/sdc
sudo systemctl stop mysqld
sudo cp -dpR /var/lib/mysql /media/sdc/mysql
sudo mv /var/lib/mysql /var/lib/mysql.old
sudo ln -s /media/sdc/mysql /var/lib/mysql
sudo systemctl start mysqld

montei uma unidade externa, migrei os arquivos do banco de dados para a unidade externa; depois, e mudou o diretório mysql original em um link simbólico apontando para o novo local. Inicialmente eu pensei que poderia ser um problema de referência com o mysql não atravessando o symlink. Então mudei minha tática para montar o drive externo diretamente em / var / lib / mysql.

Monte o disco em / var / lib / mysql e migre os dados.

#Remove the migrated files (I still have mysql.old)
sudo rm /var/lib/mysql
sudo rm -R /media/sdc/mysql

#Mount the drive to /var/lib/mysql directly.
sudo mount /dev/sdc1 /var/lib/mysql
sudo cp -dpR /var/lib/mysql.old /var/lib/mysql
sudo systemctl restart mysql

Isso também não funcionou. Em ambos os casos, o mysql se recusa a iniciar pelas mesmas razões:

sudo systemctl restart mysql
Job for mysqld.service failed because a timeout was exceeded. See "systemctl status mysqld.service" and "journalctl -xe" for details

systemctl status mysqld.service

systemctl status mysqld.service
● mysqld.service - MySQL Community Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: activating (start-post) since Tue 2017-07-18 20:58:12 UTC; 4min 37s ago
Process: 32798 ExecStart=/usr/bin/mysqld_safe (code=exited, status=0/SUCCESS)
Process: 32787 ExecStartPre=/usr/bin/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
Main PID: 32798 (code=exited, status=0/SUCCESS); : 32799 (mysql-systemd-s)
CGroup: /system.slice/mysqld.service
└─control
├─32799 /bin/bash /usr/bin/mysql-systemd-start post
└─33965 sleep 1

journalctl -xe

~
…
~
...skipping...
~
…
~

Além disso, eu também tentei vários métodos para iniciar o servidor sem sucesso (mesmos resultados):

sudo systemctl start mysqld
sudo systemctl start mysql.service
sudo systemctl start mysql
service mysql restart

ps aux | grep mysql

admin_u+ 58206  0.0  0.0 112648   976 pts/0    R+   14:19   0:00 grep --color=auto mysql 

Como resolvo esse problema e inicio o mysql?

Esqueci de algo? Eu pensei que também pode ser a configuração do datadir como em esta questão ; mas, os dois métodos que eu tomei não modificam o caminho do datadir ...

    
por KareemElashmawy 19.07.2017 / 00:42

1 resposta

2

Yoonix sugeriu que eu olhasse o log do MySQL.

mysqld.log

...
017-07-19 13:45:13 0 [Note] Binlog end
170719 13:45:13 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
170719 13:55:13 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2017-07-19 13:55:13 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
/usr/sbin/mysqld: Error on realpath() on '/var/lib/mysql-files' (Error 2 - No such file or directory)
2017-07-19 13:55:13 0 [ERROR] Failed to access directory for --secure-file-priv. Please make sure that directory exists and is accessible by MySQL Server. Supplied value : /var/lib/mysql-files
2017-07-19 13:55:13 0 [ERROR] Aborting

Solução:

Ao montar a unidade e mover os arquivos para a unidade externa, também movi os arquivos mysql. Ao movê-lo de volta, não consegui renomeá-lo para /mysql-files . Em vez disso, mudei o nome para /mysqlfiles . Renomear o diretório corrigiu o problema.

    
por 19.07.2017 / 16:55

Tags