I'm trying to setup a MySQL pod on Digital Ocean with Kubernetes.
I kept getting this error:
Initializing database
2019-03-05T14:32:58.707421Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-03-05T14:32:58.708753Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2019-03-05T14:32:58.711746Z 0 [ERROR] Aborting
My yaml as a lot of stuff but the lines that interest this part of the config are the following.
# ------------------- Persistent Volume Claim ------------------- #
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: test-mysql-volume-claim
...
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
storageClassName: do-block-storage
---
# ------------------- Deployment ------------------- #
kind: Deployment
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
...
spec:
...
spec:
containers:
- image: mysql:5.7
...
volumeMounts:
- name: test-mysql-volume
mountPath: "/var/lib/mysql"
volumes:
- name: test-mysql-volume
persistentVolumeClaim:
claimName: test-mysql-volume-claim
---
If I comment out the PVC and the lines relative to PVC in the deployment config, everything works.
Also, if I change
mountPath: "/var/lib/mysql"
to
mountPath: "/data"
it works. But I obviously need /var/lib/mysql
...
It happens also on brand new clusters.
Any idea?
The mysql directory corresponds to the mysql system schema, which contains information required by the MySQL server as it runs. This database contains data dictionary tables and system tables.
When you initialize a database, you delete all data (including the application data and database catalog) and all log entries from the volumes. The configuration of the database (database parameters, volume definitions, and so on) is retained, however.
I had this issue with Kubernetes and MySQL 5.7 as well.
Adding the suggestion from yosifki to my container's definition got things working.
A new ext4 disk partition is not usually empty; there is a lost+found directory, which mysql is known to choke on. You could try adding --ignore-db-dir=lost+found to the CMD to know for sure (from mysql docs)
Here's an extract of my working YAML definition:
name: mysql-master
image: mysql:5.7
args:
- "--ignore-db-dir=lost+found"
I had a similar problem.
Using mysql:5.6 fixed it.
For more information refer to:
https://github.com/docker-library/mysql/issues/69
https://github.com/docker-library/mysql/issues/186
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With