Initialize specified but the data directory has files in it. Aborting.

[cleverwise]

Hello Community,

I was curious if anyone has run across this issue when trying to install Percona 5.7.13. The install from Percona yum packages for CentOS 7 goes fine, however the database won’t initialize.

When “systemctl start mysqld.service” is issued I get the following error message:

[error] --initialize specified but the data directory has files in it. Aborting.

I have repeatly deleted the mysql directory at /var/lib/mysql and rerun “systemctl start mysqld.service” and same message and no root password is generated. I can manually issue “mysqld --initialize --user=mysql --defaults-file=/etc/my.cnf” and get a root password. However the database still won’t load.

I was able to bring 5.7 up on another node a month ago with zero issues. I am not really not sure why 5.7 won’t initialize itself. The directory and all permissions are own by MySQL. My understanding is Percona thinks there is another database and thus aborts the start up process.

Yes I looked over https://dev.mysql.com/doc/refman/5.7/en/data-directory-initialization-mysqld.html

Nothing on that page lead to any assistance as this version just doesn’t seem to want to initialize itself.

SELinux is off.

Anyone have any thoughts?

Thanks!

Respectfully,

Jeremy

[paul.namuag]

Hi Jeremy,

Can you check the permission of /var/lib/mysql? Aside from that double check the /etc/my.cnf if you have the right path for the data dir:

$ egrep ‘data.*dir|error.*log’ /etc/my.cnf

Then paste the last lines from that error log.

$ tail -n50

[Telford]

Hi cleverwise, I got the same error when attempting to initialize a blank database with audit log items in the my.cnf file:

audit_log_policy=ALL
audit_log_rotate_on_size=64M
audit_log_rotations=10

Commenting out those lines allowed the initialization to complete successfully.

After the node was up and running, it was possible to shut it down, then put back the audit log configuration and then start it back up again. The node rejoined the cluster successfully, and I can see the audit.log output and also I see the audit_log plugin is loaded. Something in the audit log configuration blocks initialization from a blank start, even though same configuration works perfectly OK once the database exists.

If anyone knows how to avoid this difficulty, by all means update me.

On close inspection I note that the error, –initialize specified but the data directory has files in it. Aborting. actually comes several seconds after an earlier error unknown variable ‘audit_log_policy=ALL’ which suggests there are two stages to the failure and the second stage reports a distracting error, unrelated to the real problem. I would guess that other configuration problems could cause a similar symptom here.