How to reset super-read-only option? It prevents database creation

[devdattakulkarni]

Is this a BUG REPORT or FEATURE REQUEST?

BUG REPORT

Versions

MySQL Operator Version:
Latest SHA c98210b

Environment:

• Kubernetes version (use kubectl version): 1.10.0
• Cloud provider or hardware configuration: Minikube
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Others:

What happened?

Trying to create a database gives error. Here is exact output. I created cluster with name 'mysql1'.

kubectl run mysql-client --image=mysql:5.7 -it --rm --restart=Never -- mysql -h mysql1 -uroot -pfy5VYHCUtgpHS9Z1p -e 'create database testdb;'
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1290 (HY000) at line 1: The MySQL server is running with the --super-read-only option so it cannot execute this statement.

What you expected to happen?

The database 'testdb' should have been created.

How to reproduce it (as minimally and precisely as possible)?

1. Create cluster
2. Once cluster is ready, execute above command

Anything else we need to know?

Before creating the cluster I did create a configMap with following my.cnf to reset the ready-only and super-read-only flags. But it did not help as you can see in above error.

my.cnf

[mysqld]

read_only = 0
super_read_only = 0

[vladas]

In my case, the issue was that I had 3 members, of which only 1 was in 'write', and others in 'read' mode.

However, the service domain name didn't point to the 'write' instance.

Not exactly sure how this is supposed to work, but I see the following solutions/workarounds:

• Reduce cluster size to 1 (members: 1)
• Make cluster "multiMaster: true"
• connect directly to to the "write" instance

[gabrieljackson]

I seemingly just stumbled upon this issue myself.

We had a 2-member configuration with one pod running read-only due to the mysql cluster not being set with multiMaster: true. The service name resolves to both pod IPs after deployment, which I think is the real bug here.

It's a tricky failure case, because if your client happens to resolve to the right IP, you will get the non-read-only node and it will work, while another client may not be so lucky.

[RongoDog]

I'm experiencing this issue myself. Could this have anything to do with the fact that I'm using an AWS storage class to define my volumes? I'm running a 3 node cluster with multi-master turned off.

Edit:

For more info I thought I would paste my kubernetes yaml file.

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-cnf
data:
  my.cnf: |-
    [mysqld]
    read_only = 0
    super_read_only = 0
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: persist
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
mountOptions:
  - debug
volumeBindingMode: Immediate
---
apiVersion: mysql.oracle.com/v1alpha1
kind: Cluster
metadata:
  name: manifest-cluster
spec:
  members: 3
  multiMaster: false
  config:
    name: mysql-cnf
  volumeClaimTemplate:
    metadata:
      labels:
        type: local
      name: manifest-data
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 2Gi
      storageClassName: persist