7

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?

a.barbieri
  • 2,398
  • 3
  • 30
  • 58

4 Answers4

15

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"
Thiago G. Alves
  • 1,202
  • 1
  • 14
  • 24
6

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

a.barbieri
  • 2,398
  • 3
  • 30
  • 58
Padrian
  • 61
  • 2
2

I have come across this issue. Work around is to delete the pv and pvc and recreate them.

P Ekambaram
  • 15,499
  • 7
  • 34
  • 59
0

The do-block-storage StorageClass you were using might have been formatted with the ext2/3/4 file system, which usually creates a lost+found directory at the root.

In addition to using the --ignore-db-dir=lost+found option as suggested by Thiago, you can also add subPath to your entry in the volumeMounts like this:

...
          volumeMounts:
            - name: test-mysql-volume
              mountPath: "/var/lib/mysql"
              subPath: mysql
...

If you add another container to the pod and mount the volume normally (without using subPath), you will see something like this:

root@test-mysql-4355v8b79q-cb97l:/# ls -la /data/
total 24
drwxr-xr-x. 4 root root  4096 Jun 28 02:23 .
drwxr-xr-x. 1 root root    29 Jun 28 02:25 ..
drwx------. 2 root root 16384 Jun 28 02:23 lost+found
drwxr-xr-x. 5  999 root  4096 Jun 28 02:25 mysql

I personally like this method because it should also work with images that require an empty directory but don't have any option to ignore the lost+found directory.

weeix
  • 1,359
  • 1
  • 14
  • 17