Not the answer you need?
Register and ask your own question!

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

cleverwisecleverwise EntrantCurrent User Role Beginner
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

Comments

  • paul.namuagpaul.namuag Entrant Current User Role Beginner
    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 <error-log-path>
  • TelfordTelford Entrant Legacy User Role Beginner
    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.
Sign In or Register to comment.

MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.
Copyright ©2005 - 2020 Percona LLC. All rights reserved.