MySQL Forums - MySQL & Kubernetes

What are the three arguments expected by this script (build_deps.sh)? (no replies)

Bing Ma — Fri, 10 Apr 2026 10:05:31 +0000

I need to upgrade kopf to fix a bug, but the required version depends on a newer Python.
I'm not sure how Python is installed in your base image — is it provided via PYTHON_TARBALL in this script?
Is this a custom-built Python package maintained internally?

What's wrong with this configuration? (no replies)

Raphy Stonehorse — Tue, 11 Nov 2025 09:56:35 +0000

I defined Innodb cluster configuration file as follows :

# https://medium.com/edstem/postgres-deployment-to-kubernetes-using-nodeport-626a93d8a919

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: mysql-sc
#namespace: default
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

---

# https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-backups.html

apiVersion: v1
kind: PersistentVolume
metadata:
name: innodb-volume
labels:
type: local
#app: mysql
spec:
storageClassName: mysql-sc
capacity:
storage: 40Gi
accessModes:
- ReadWriteOnce
hostPath:
path: /var/lib/data/mysql # https://stackoverflow.com/questions/62577494/mkdir-mnt-data-read-only-file-system-back-off-restarting->;

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: innodb-volume-claim
#labels:
#app: mysql
spec:
storageClassName: mysql-sc
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 40Gi

---

# https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-innodbcluster-common.html

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
name: mycluster
spec:
secretName: mypwds
tlsUseSelfSigned: true
instances: 3
version: 9.5.0
router:
instances: 1
version: 9.5.0
datadirVolumeClaimTemplate:
storageClassName: mysql-sc
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 40Gi
initDB:
clone:
donorUrl: mycluster-0.mycluster-instances.another.svc.cluster.local:3306
rootUser: root
secretKeyRef:
name: mypwds
mycnf: |
[mysqld]
max_connections=162

Applying this configuration :

(base) raphy@raohy:~/.talos/openmetadata/mysql$ kubectl apply -f mysqlcluster.yaml
storageclass.storage.k8s.io/mysql-sc unchanged
persistentvolume/innodb-volume created
persistentvolumeclaim/innodb-volume-claim created
innodbcluster.mysql.oracle.com/mycluster configured

I get :

(base) raphy@raohy:~/.talos/openmetadata/mysql$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
innodb-volume-claim Pending mysql-sc 11m

(base) raphy@raohy:~/.talos/openmetadata/mysql$ kubectl -n default get pods
NAME READY STATUS RESTARTS AGE
omd-os-cluster-dashboards-5b9fbdfd45-rzhsn 1/1 Running 0 63m
omd-os-cluster-masters-0 1/1 Running 0 63m
omd-os-cluster-masters-1 1/1 Running 0 60m
omd-os-cluster-masters-2 1/1 Running 0 58m
omd-os-cluster-securityconfig-update-cj7bh 0/1 Completed 0 63m
opensearch-operator-controller-manager-7448949c9b-6kzlm 2/2 Running 47 (65m ago) 18h

How to make the InnoDB Cluster working?

a lot c++ errors when invoke get_cluster() (no replies)

Bing Ma — Tue, 28 Oct 2025 09:13:05 +0000

[2025-10-28 09:05:14,779] kopf.objects [ERROR ] status() failed at mabing1028-1-2.mabing1028-1-instances.default.svc.cluster.local:3306: error=LogicError: Uncaught exception: std::bad_alloc
Traceback (most recent call last):
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/diagnose.py", line 147, in diagnose_instance
mstatus = cluster.status({"extended": 1})
RuntimeError: LogicError: Uncaught exception: std::bad_alloc

[2025-10-28 09:05:14,785] kopf.objects [INFO ] ||||do_diagnose_cluster.5.1
[2025-10-28 09:05:14,963] kopf.objects [ERROR ] get_cluster() error for mabing1028-1.mabing1028-instances.default.svc.cluster.local:3306: error=LogicError: Uncaught exception: std::bad_alloc
Traceback (most recent call last):
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/diagnose.py", line 119, in diagnose_instance
cluster = dba.get_cluster()
RuntimeError: LogicError: Uncaught exception: std::bad_alloc

[2025-10-28 09:05:14,965] kopf.objects [INFO ] ||||do_diagnose_cluster.5.1
[2025-10-28 09:05:15,022] kopf.objects [ERROR ] get_cluster() error for mabing1028-2-2.mabing1028-2-instances.default.svc.cluster.local:3306: error=LogicError: Uncaught exception: std::bad_alloc
Traceback (most recent call last):
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/diagnose.py", line 119, in diagnose_instance
cluster = dba.get_cluster()
RuntimeError: LogicError: Uncaught exception: std::bad_alloc

[2025-10-28 09:05:15,026] kopf.objects [INFO ] ||||do_diagnose_cluster.5.1
[2025-10-28 09:05:15,045] kopf.objects [ERROR ] get_cluster() error for mabing1028-1-0.mabing1028-1-instances.default.svc.cluster.local:3306: error=LogicError: Uncaught exception: std::bad_alloc
Traceback (most recent call last):
File "/usr/lib/mysqlsh/python-packages/mysqloperator/controller/diagnose.py", line 119, in diagnose_instance
cluster = dba.get_cluster()
RuntimeError: LogicError: Uncaught exception: std::bad_alloc

====
I changed the logger.info to logger.exception to get the stack info

malloc_consolidate() error (no replies)

Bing Ma — Tue, 28 Oct 2025 06:56:28 +0000

[2025-10-28 06:49:47,734] CM_mabing1028-1 [INFO ] Trying to connect to a member of cluster default/mabing1028-1
malloc_consolidate(): invalid chunk size

What is the cause of this error? (2 replies)

Bing Ma — Tue, 22 Jul 2025 03:45:02 +0000

2025-07-21 22:21:13: Info: mysqlsh Ver 8.3.0 for Linux on aarch64 - for MySQL 8.3.0 (MySQL Community Server (GPL)) - build 13725054 - commit_id b871a975f78bf8d8cafe15536b5a6e1507c090c7 - product_id el8-arm-64bit rpm
2025-07-21 22:21:13: Info: Using credential store helper: /usr/bin/mysql-secret-store-login-path
2025-07-21 22:21:13: Info: Loading startup files...
2025-07-21 22:21:13: Info: Loading plugins...
[2025-07-21 22:21:16,160] root [INFO ] Environment provided cluster domain: cluster.local
[2025-07-21 22:21:16,163] kopf.activities.star [INFO ] MySQL Operator/operator.py=2.1.2 timestamp=2024-01-02T06:45:11 kopf=1.35.4 uid=2
[2025-07-21 22:21:16,171] kopf.activities.star [INFO ] KUBERNETES_VERSION =1.31
[2025-07-21 22:21:16,171] kopf.activities.star [INFO ] OPERATOR_VERSION =2.1.2
[2025-07-21 22:21:16,171] kopf.activities.star [INFO ] OPERATOR_EDITION =community
[2025-07-21 22:21:16,171] kopf.activities.star [INFO ] OPERATOR_EDITIONS =['community', 'enterprise']
[2025-07-21 22:21:16,171] kopf.activities.star [INFO ] SHELL_VERSION =8.3.0
[2025-07-21 22:21:16,172] kopf.activities.star [INFO ] DEFAULT_VERSION_TAG=8.3.0
[2025-07-21 22:21:16,172] kopf.activities.star [INFO ] SIDECAR_VERSION_TAG=8.3.0-2.1.2
[2025-07-21 22:21:16,172] kopf.activities.star [INFO ] DEFAULT_IMAGE_REPOSITORY =container-registry.oracle.com/mysql
[2025-07-21 22:21:16,183] kopf.activities.star [INFO ] Activity 'on_startup' succeeded.
[2025-07-21 22:21:16,184] kopf._core.engines.a [INFO ] Initial authentication has been initiated.
[2025-07-21 22:21:16,186] kopf.activities.auth [INFO ] Activity 'login_via_client' succeeded.
[2025-07-21 22:21:16,186] kopf._core.engines.a [INFO ] Initial authentication has finished.
[2025-07-21 22:21:16,254] kopf._core.reactor.o [ERROR ] Peering observer for mysql-operator@none has failed: ('storage is (re)initializing', {'kind': 'Status', 'apiVersion': 'v1', 'metadata': {}, 'status': 'Failure', 'message': 'storage is (re)initializing', 'reason': 'TooManyRequests', 'details': {'retryAfterSeconds': 1}, 'code': 429})
Traceback (most recent call last):
File "/usr/lib/mysqlsh/python-packages/kopf/_cogs/clients/errors.py", line 148, in check_response
response.raise_for_status()
File "/usr/lib/mysqlsh/python-packages/aiohttp/client_reqrep.py", line 1005, in raise_for_status
raise ClientResponseError(
aiohttp.client_exceptions.ClientResponseError: 429, message='Too Many Requests', url=URL('https://10.233.0.1:443/apis/zalando.org/v1/clusterkopfpeerings';)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/lib/mysqlsh/python-packages/kopf/_cogs/aiokits/aiotasks.py", line 108, in guard
await coro
File "/usr/lib/mysqlsh/python-packages/kopf/_core/reactor/queueing.py", line 175, in watcher
async for raw_event in stream:
File "/usr/lib/mysqlsh/python-packages/kopf/_cogs/clients/watching.py", line 82, in infinite_watch
async for raw_event in stream:
File "/usr/lib/mysqlsh/python-packages/kopf/_cogs/clients/watching.py", line 159, in continuous_watch
objs, resource_version = await fetching.list_objs(
File "/usr/lib/mysqlsh/python-packages/kopf/_cogs/clients/fetching.py", line 28, in list_objs
rsp = await api.get(
File "/usr/lib/mysqlsh/python-packages/kopf/_cogs/clients/api.py", line 111, in get
response = await request(
File "/usr/lib/mysqlsh/python-packages/kopf/_cogs/clients/auth.py", line 45, in wrapper
return await fn(*args, **kwargs, context=context)
File "/usr/lib/mysqlsh/python-packages/kopf/_cogs/clients/api.py", line 85, in request
await errors.check_response(response) # but do not parse it!
File "/usr/lib/mysqlsh/python-packages/kopf/_cogs/clients/errors.py", line 150, in check_response
raise cls(payload, status=response.status) from e
kopf._cogs.clients.errors.APIClientError: ('storage is (re)initializing', {'kind': 'Status', 'apiVersion': 'v1', 'metadata': {}, 'status': 'Failure', 'message': 'storage is (re)initializing', 'reason': 'TooManyRequests', 'details': {'retryAfterSeconds': 1}, 'code': 429})

What is the version correspondence between the operator and MySQL? (4 replies)

Bing Ma — Mon, 30 Mar 2026 10:32:05 +0000

For example, if I'm using MySQL 8.0.31, should I use MySQL Operator for Kubernetes 8.0.31-2.0.7 (2022-10-11, General Availability) or should I use the latest Operator for Kubernetes 8.0.40-2.0.16 (2024-10-15, General Availability)?

Will the operator automatically set the value of innodb-buffer-pool-size based on resources.request.memory or resources.limit.memory? (no replies)

Bing Ma — Wed, 04 Dec 2024 09:59:41 +0000

For example, when resources.request.memory is greater than 4G, innodb-buffer-pool-size is resources.request.memory*0.8, otherwise it is half of resources.request.memory.

Recovery after node restart (1 reply)

Annie Blomqvist — Sat, 28 Sep 2024 16:18:11 +0000

Hi,

I'm running a K3S cluster on a number of virtual Debian 6.1.106-3 hosts:

Client Version: v1.29.9
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.0+k3s1

Its running on 3 masters and 3 worker nodes and is using metallb for loadbalancing.

I've created a mysql cluster with the helm chart:

helm upgrade --install mysql-cluster mysql-operator/mysql-innodbcluster --namespace test --create-namespace -f mysql-cluster/mysql-cluster-values.yaml

It seems like the router is not able to recover when the worker node is restarted.

kubectl logs -n test pods/mysql-cluster-router-7988469f76-fcbff --all-containers
[Entrypoint] MYSQL_CREATE_ROUTER_USER is 0, Router will reuse mysqlrouter account at runtime
[Entrypoint] Succesfully contacted mysql server at mysql-cluster-instances.test.svc.cluster.local:3306. Checking for cluster state.
[Entrypoint] Succesfully contacted mysql server at mysql-cluster-instances.test.svc.cluster.local. Trying to bootstrap reusing account "mysqlrouter".
Please enter MySQL password for mysqlrouter:
Error: The provided server is currently not an ONLINE member of a InnoDB cluster.

I was finally able to recover the cluster by restarting all worker nodes, after which I could perform a dba.rebootClusterFromCompleteOutage()

I thought by using a cluster and by using the operator I would have a system able to handle single node failure?
Should the operator not be able to survive and recover from a temporary failure of one of the cluster nodes?

Not able to install a mysql cluster with the operator (2 replies)

Annie Blomqvist — Sat, 28 Sep 2024 11:42:57 +0000

I'm running a K3S cluster on a number of virtual Debian 6.1.106-3 hosts:

Client Version: v1.29.9
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.0+k3s1

Its running on 3 masters and 3 worker nodes and is using metallb for loadbalancing.

I've installed the mysql operator with helm chart version 2.2.1:

helm install my-mysql-operator mysql-operator/mysql-operator --namespace mysql-operator --create-namespace

I've then started the cluster with the example giving from the output of the helm install:

helm install my-mysql-innodbcluster mysql-operator/mysql-innodbcluster -n $NAMESPACE --create-namespace --version 2.2.1 --set credentials.root.password=">-0URS4F3P4SS" --set tls.useSelfSigned=true

The problem is that the cluster does not come up, instead the complains about the sidecar.

kubectl get all -n $NAMESPACE
NAME READY STATUS RESTARTS AGE
pod/my-mysql-innodbcluster-0 0/2 Init:CrashLoopBackOff 9 (4m29s ago) 25m
pod/my-mysql-innodbcluster-1 0/2 Init:CrashLoopBackOff 9 (4m2s ago) 25m
pod/my-mysql-innodbcluster-2 0/2 Init:CrashLoopBackOff 9 (4m4s ago) 25m

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/my-mysql-innodbcluster ClusterIP 10.43.103.55 3306/TCP,33060/TCP,6446/TCP,6448/TCP,6447/TCP,6449/TCP,6450/TCP,8443/TCP 25m
service/my-mysql-innodbcluster-instances ClusterIP None 3306/TCP,33060/TCP,33061/TCP 25m

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/my-mysql-innodbcluster-router 0/0 0 0 25m

NAME DESIRED CURRENT READY AGE
replicaset.apps/my-mysql-innodbcluster-router-6bd9464bcd 0 0 0 25m

NAME READY AGE
statefulset.apps/my-mysql-innodbcluster 0/3 25m

After start kubectl describe -n $NAMESPACE pod/my-mysql-innodbcluster-0 lists these events:

Normal Scheduled 71s default-scheduler Successfully assigned your-namespace/my-mysql-innodbcluster-0 to spruce
Warning FailedScheduling 75s default-scheduler 0/6 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/6 nodes are available: 6 Preemption is not helpful for scheduling.
Warning FailedScheduling 73s default-scheduler 0/6 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/6 nodes are available: 6 Preemption is not helpful for scheduling.
Error Logging 74s kopf Handler 'on_pod_create' failed temporarily: Sidecar of my-mysql-innodbcluster-0 is not yet configured
Normal SuccessfulAttachVolume 61s attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-cf926941-fb3a-4ec0-aba7-0ea3627012f5"
Normal Created 59s kubelet Created container fixdatadir
Normal Pulled 59s kubelet Container image "container-registry.oracle.com/mysql/community-operator:9.0.1-2.2.1" already present on machine
Normal Started 59s kubelet Started container fixdatadir
Normal Pulled 58s kubelet Container image "container-registry.oracle.com/mysql/community-operator:9.0.1-2.2.1" already present on machine
Normal Created 58s kubelet Created container initconf
Normal Started 58s kubelet Started container initconf
Error Logging 44s kopf Handler 'on_pod_create' failed temporarily: Sidecar of my-mysql-innodbcluster-0 is not yet configured
Normal Pulled 15s (x4 over 56s) kubelet Container image "container-registry.oracle.com/mysql/community-server:9.0.1" already present on machine
Normal Created 15s (x4 over 56s) kubelet Created container initmysql
Normal Started 15s (x4 over 56s) kubelet Started container initmysql
Error Logging 14s kopf Handler 'on_pod_create' failed temporarily: Sidecar of my-mysql-innodbcluster-0 is not yet configured
Warning BackOff 13s (x6 over 54s) kubelet Back-off restarting failed container initmysql in pod my-mysql-innodbcluster-0_your-namespace(ee16423a-d87a-414b-9690-a294c0686b77)

After a while the following gets repeated:

Error Logging 2m41s kopf Handler 'on_pod_create' failed temporarily: Sidecar of my-mysql-innodbcluster-0 is not yet configured
Error Logging 2m10s kopf Handler 'on_pod_create' failed temporarily: Sidecar of my-mysql-innodbcluster-0 is not yet configured
Error Logging 100s kopf Handler 'on_pod_create' failed temporarily: Sidecar of my-mysql-innodbcluster-0 is not yet configured
Warning BackOff 88s (x197 over 26m) kubelet Back-off restarting failed container initmysql in pod my-mysql-innodbcluster-0_your-namespace(ee16423a-d87a-414b-9690-a294c0686b77)
Error Logging 70s kopf Handler 'on_pod_create' failed temporarily: Sidecar of my-mysql-innodbcluster-0 is not yet configured
Error Logging 40s kopf Handler 'on_pod_create' failed temporarily: Sidecar of my-mysql-innodbcluster-0 is not yet configured
Error Logging 10s kopf Handler 'on_pod_create' failed temporarily: Sidecar of my-mysql-innodbcluster-0 is not yet configured

Log output that might be relevant:

kubectl logs -n $NAMESPACE my-mysql-innodbcluster-0
Defaulted container "sidecar" out of: sidecar, mysql, fixdatadir (init), initconf (init), initmysql (init)
Error from server (BadRequest): container "sidecar" in pod "my-mysql-innodbcluster-0" is waiting to start: PodInitializing

Would appriciate any information on what might be causing this issue?

MySQL Operator Not Processing InnoDBCluster Resources in Kubernetes 1.30.1 (no replies)

Noel Ashford — Thu, 19 Sep 2024 00:59:47 +0000

Hello everyone,

I'm experiencing an issue with deploying a MySQL InnoDBCluster using the Oracle MySQL Operator in a Kubernetes cluster. Despite the operator pod running and having the necessary permissions, it isn't processing the InnoDBCluster resource, and no pods or other resources are being created in the target namespace.

Environment Details:

Kubernetes Version:

Client Version: v1.30.3
Server Version: v1.30.1
MySQL Operator Version: 9.0.1-2.2.1

Namespace for Operator: mysql-operator

Namespace for InnoDBCluster: tn-sql

Issue Description:

The MySQL Operator pod is running in the mysql-operator namespace without any restarts or errors.
The InnoDBCluster CustomResourceDefinition (CRD) is installed and established.
All necessary secrets are created and contain the required data.
The operator's service account (mysql-operator-sa) has the necessary permissions, confirmed using kubectl auth can-i commands.
The InnoDBCluster resource (tn-sql-cluster) is created in the tn-sql namespace.
No pods, services, or other resources are being created by the operator in the tn-sql namespace.
The operator logs show no activity beyond the initial startup; no errors or exceptions are logged.
Steps Taken So Far:

RBAC Configuration:

Created a ClusterRole (mysql-operator-cluster-admin-role) with permissions for all necessary API groups and resources.
Created a ClusterRoleBinding (mysql-operator-rolebinding) linking the ClusterRole to the operator's service account.
Verified that the operator's service account has the necessary permissions using kubectl auth can-i commands.
Operator Deployment:

Deployed the operator using an Ansible playbook (see playbook below).
Set the WATCH_NAMESPACE environment variable to watch all namespaces ("").
Increased the operator's logging level to DEBUG.
Resource Definitions:

Created all necessary secrets for the cluster admin, root, metrics, router, and backup users.
Deployed the InnoDBCluster resource with the required specifications.
Diagnostics:

Checked operator logs for any errors or reconciliation activity.
Verified that the InnoDBCluster resource exists but has no status updates.
Confirmed there are no network policies or resource quotas interfering.
Ensured that the CRD is established and uses the correct API version.
Sanitized Ansible Playbook:

yaml
Copy code
---
- name: Deploy MySQL Operator and Create InnoDBCluster with Dynamic PVCs, Router, and Prometheus Metrics
hosts: localhost
connection: local
gather_facts: no
collections:
- kubernetes.core
vars:
mysql_namespace: tn-sql
storage_class: csi-sc-cinderplugin
mysql_root_password: "YourRootPassword"
mysql_metrics_user: "metrics"
mysql_metrics_password: "YourMetricsPassword"
mysql_router_user: "mysqlrouter"
mysql_router_password: "YourRouterPassword"
mysql_backup_user: "mysqlbackup"
mysql_backup_password: "YourBackupPassword"
mysql_instances: 3
mysql_routers: 1
metrics_enabled: true

tasks:
- name: Create Namespaces
kubernetes.core.k8s:
state: present
definition:
apiVersion: v1
kind: Namespace
metadata:
name: "{{ item }}"
loop:
- "{{ mysql_namespace }}"
- mysql-operator

- name: Create Secrets for MySQL Users
kubernetes.core.k8s:
state: present
definition:
apiVersion: v1
kind: Secret
metadata:
name: tn-sql-cluster-privsecrets
namespace: "{{ mysql_namespace }}"
type: Opaque
stringData:
clusterAdminUsername: "admin"
clusterAdminPassword: "{{ mysql_root_password }}"
rootUser: "root"
rootHost: "%"
rootPassword: "{{ mysql_root_password }}"
metricsUser: "{{ mysql_metrics_user }}"
metricsPassword: "{{ mysql_metrics_password }}"

- name: Create Secrets for Router and Backup Users
kubernetes.core.k8s:
state: present
definition:
apiVersion: v1
kind: Secret
metadata:
name: tn-sql-cluster-router
namespace: "{{ mysql_namespace }}"
type: Opaque
stringData:
routerUsername: "{{ mysql_router_user }}"
routerPassword: "{{ mysql_router_password }}"

- name: Create Secret for Backup User
kubernetes.core.k8s:
state: present
definition:
apiVersion: v1
kind: Secret
metadata:
name: tn-sql-cluster-backup
namespace: "{{ mysql_namespace }}"
type: Opaque
stringData:
backupUser: "{{ mysql_backup_user }}"
backupPassword: "{{ mysql_backup_password }}"

- name: Create Service Account for MySQL Operator
kubernetes.core.k8s:
state: present
definition:
apiVersion: v1
kind: ServiceAccount
metadata:
name: mysql-operator-sa
namespace: mysql-operator

- name: Create ClusterRole with Admin Permissions
kubernetes.core.k8s:
state: present
definition:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: mysql-operator-cluster-admin-role
rules:
- apiGroups: ["mysql.oracle.com"]
resources:
- "innodbclusters"
- "innodbclusters/status"
- "mysqlbackups"
- "mysqlbackups/status"
verbs:
- "*"
- apiGroups: ["apps"]
resources:
- "statefulsets"
- "deployments"
- "daemonsets"
- "replicasets"
verbs:
- "*"
- apiGroups: [""]
resources:
- "pods"
- "services"
- "configmaps"
- "secrets"
- "persistentvolumeclaims"
verbs:
- "*"
- apiGroups: ["batch"]
resources:
- "jobs"
- "cronjobs"
verbs:
- "*"
- apiGroups: ["events.k8s.io"]
resources:
- "events"
verbs:
- "get"
- "list"
- "watch"
- apiGroups: ["apiextensions.k8s.io"]
resources:
- "customresourcedefinitions"
verbs:
- "get"
- "list"
- "watch"
- apiGroups: ["zalando.org"]
resources:
- "clusterkopfpeerings"
verbs:
- "*"

- name: Create ClusterRoleBinding for MySQL Operator
kubernetes.core.k8s:
state: present
definition:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: mysql-operator-rolebinding
subjects:
- kind: ServiceAccount
name: mysql-operator-sa
namespace: mysql-operator
roleRef:
kind: ClusterRole
name: mysql-operator-cluster-admin-role
apiGroup: rbac.authorization.k8s.io

- name: Deploy MySQL Operator CRDs
kubernetes.core.k8s:
state: present
src: "https://raw.githubusercontent.com/mysql/mysql-operator/9.0.1-2.2.1/deploy/deploy-crds.yaml";

- name: Deploy MySQL Operator
kubernetes.core.k8s:
state: present
definition:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-operator
namespace: mysql-operator
labels:
name: mysql-operator
spec:
replicas: 1
selector:
matchLabels:
name: mysql-operator
template:
metadata:
labels:
name: mysql-operator
spec:
serviceAccountName: mysql-operator-sa
containers:
- name: mysql-operator
image: container-registry.oracle.com/mysql/community-operator:9.0.1-2.2.1
args:
- mysqlsh
- --log-level=DEBUG
- --pym
- mysqloperator
- operator
env:
- name: MYSQL_CLUSTER_DOMAIN
value: "cluster.local"
- name: MYSQL_OPERATOR_K8S_CLUSTER_DOMAIN
value: "cluster.local"
- name: WATCH_NAMESPACE
value: ""
readinessProbe:
exec:
command:
- cat
- /tmp/mysql-operator-ready
initialDelaySeconds: 5
periodSeconds: 10

- name: Wait for MySQL Operator to be Ready
kubernetes.core.k8s_info:
kind: Deployment
namespace: mysql-operator
name: mysql-operator
register: operator_deployment
until: operator_deployment.resources[0].status.availableReplicas | default(0) | int >= 1
retries: 20
delay: 15

- name: Deploy PersistentVolumeClaims for MySQL Instances
kubernetes.core.k8s:
state: present
definition:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: tn-sql-cluster-pvc-{{ item }}
namespace: "{{ mysql_namespace }}"
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 20Gi
storageClassName: "{{ storage_class }}"
loop: "{{ range(0, mysql_instances) | list }}"

- name: Deploy InnoDBCluster
kubernetes.core.k8s:
state: present
definition:
apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
name: tn-sql-cluster
namespace: "{{ mysql_namespace }}"
spec:
secretName: tn-sql-cluster-privsecrets
tlsUseSelfSigned: true
instances: "{{ mysql_instances }}"
router:
instances: "{{ mysql_routers }}"
backup:
enabled: true
metricsExporter:
enabled: "{{ metrics_enabled }}"
user: "{{ mysql_metrics_user }}"
password: "{{ mysql_metrics_password }}"
serviceMonitor:
enabled: true

- name: Wait for InnoDBCluster to be Ready
kubernetes.core.k8s_info:
api_version: "mysql.oracle.com/v2"
kind: InnoDBCluster
namespace: "{{ mysql_namespace }}"
name: tn-sql-cluster
register: cluster_info
retries: 30
delay: 20
until: cluster_info.resources | length > 0 and cluster_info.resources[0].get('status', {}).get('cluster', {}).get('status') == "ONLINE"

Operator Logs:

The operator logs show only the initial startup information and do not display any reconciliation activity or errors. Here's a snippet:

css
Copy code
[2024-09-18 05:17:19,091] kopf.activities.star [INFO ] Activity 'on_startup' succeeded.
[2024-09-18 05:17:19,092] kopf._core.engines.a [INFO ] Initial authentication has been initiated.
[2024-09-18 05:17:19,094] kopf.activities.auth [INFO ] Activity 'login_via_client' succeeded.
[2024-09-18 05:17:19,094] kopf._core.engines.a [INFO ] Initial authentication has finished.
InnoDBCluster Resource Status:

yaml
Copy code
Name: tn-sql-cluster
Namespace: tn-sql
API Version: mysql.oracle.com/v2
Kind: InnoDBCluster
Metadata:
Creation Timestamp: 2024-09-18T05:33:41Z
Generation: 1
Resource Version: 26739894
UID: 63a0bd37-e553-4100-a88f-61e7a41254d1
Spec:
Base Server Id: 1000
Instances: 3
Router:
Instances: 1
Secret Name: tn-sql-cluster-privsecrets
Tls Use Self Signed: true
Events:
Additional Diagnostic Outputs:

CRD Version:

arduino
Copy code
$ kubectl get crd innodbclusters.mysql.oracle.com -o jsonpath='{.spec.versions[*].name}'
v2
Operator Pod Status:

sql
Copy code
$ kubectl get pods -n mysql-operator -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mysql-operator-5878c5fdcc-f9dft 1/1 Running 0 11m 10.244.3.220 k8s-node-2
Events in tn-sql Namespace:

csharp
Copy code
$ kubectl get events -n tn-sql --sort-by='.metadata.creationTimestamp'
No events found.
RBAC Verification:

csharp
Copy code
$ kubectl auth can-i get innodbclusters.mysql.oracle.com --as=system:serviceaccount:mysql-operator:mysql-operator-sa -n tn-sql
yes
Network Policies and Resource Quotas:

sql
Copy code
$ kubectl get networkpolicy -n tn-sql
No resources found.

$ kubectl get resourcequota -n tn-sql
No resources found.
Attempts to Resolve the Issue:

Set WATCH_NAMESPACE to Watch All Namespaces:

Confirmed that the WATCH_NAMESPACE environment variable is set to "" in the operator deployment.
Increased Operator Logging Level:

Set the logging level to DEBUG but still did not observe any reconciliation activity or errors in the logs.
Verified RBAC Configurations:

Ensured that the operator's service account has the necessary permissions.
Tested with a Minimal InnoDBCluster:

Deployed a minimal cluster configuration but experienced the same issue.
Request for Assistance:

I'm seeking help to determine why the MySQL Operator isn't processing the InnoDBCluster resource. Any insights or suggestions would be greatly appreciated.

Questions:

Has anyone successfully deployed the Oracle MySQL Operator on Kubernetes version 1.30.x?
Are there any known compatibility issues between MySQL Operator version 9.0.1-2.2.1 and Kubernetes 1.30.x?
Could there be any hidden configurations or steps that I'm missing?
Thank you in advance for your help!

MySQL Operator - Backup S3 (CloudFlare) (no replies)

Stefan Walther — Mon, 17 Jun 2024 12:43:00 +0000

Dear community, I am not sure how to use backup in combination with s3.
The values.yaml file also did not hinted much how to use it

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
name: my-db
namespace: mysql-operator
spec:
secretName: my-db-secrets
tlsUseSelfSigned: true
instances: 2
router:
instances: 1

backupProfiles:
- name: my-db-s3-backup-profile
dumpInstance:
dumpOptions:
excludeSchemas: ["information_schema"]
storage:
s3:
bucketName: my-db-backup
config: my-db-backup-secrets
prefix: mysql
endpoint: https://XXXX.eu.r2.cloudflarestorage.com
backupSchedules:
- name: my-db-daily-s3-backup
schedule: "27 12 * * *" # Daily at 2 AM
backupProfileName: my-db-s3-backup-profile
deleteBackupData: false
enabled: true
---
apiVersion: v1
kind: Secret
metadata:
name: my-db-backup-secrets
namespace: mysql-operator
type: Opaque
stringData:
awsAccessKeyId: XXX
awsSecretAccessKey: XXX

FYI: the target is to use S3 provided by Cloudflare
https://www.cloudflare.com/en-gb/developer-platform/r2/

FYI: Helm Chart values https://github.com/mysql/mysql-operator/blob/trunk/helm/mysql-innodbcluster/values.yaml seams to miss a : at line 154 for endpoint?

thank you for your help in advance!

When access single storage from multiple pods of MySQL give error (2 replies)

Sivakajan Sivaparan — Fri, 31 May 2024 11:02:35 +0000

Actually what happen is, I need a MySQL deployment which accesses the same storage as a datastore. When creating a MySQL with more than one replica, only one replica becomes healthy. This is because, at a time only one pod can access the """ibdata1""" file. When check the logs of the pod it says, "Unable to lock ./ibdata1 error: 11" Give me a alternative way to access the same storage through two pods.

Recreate the issue: Create PV and PVC

apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv
labels:
type: local
spec:
persistentVolumeReclaimPolicy: Retain
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
Create the mysql deployment

apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
replicas: 2
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:latest
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: pwd
ports:
- containerPort: 3306
volumeMounts:
- name: mysql-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-storage
persistentVolumeClaim:
claimName: mysql-pvc
After some seconds, you can see both pods running successfully.(k get pods)
Then open the bash of from the first pod. kubectl exec --stdin --tty mysql-pod-name-0 -- /bin/bash. Then open the mysql in that bash. mysql -u root -ppwd. Now you can access the MySQL. Play with it and create a db for reference.

Then exit from the pod-0 and open the bash of the second pod by kubectl exec --stdin --tty mysql-pod-name-1 -- /bin/bash. You can access the bash of pod-1. Now open the MySQL there. mysql -u root -ppwd. You will get an error like

bash-4.4# mysql -u root -ppwd
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2
In other way, try delete the pod-0(the workable pod).(kubectl delete pod pod_name_0). Then you can see another new pod(named pod-2) created. Now do the same procedure to access the mysql from both pods, you can observe that accessing the mysql from pod-1 will works with the already created db. and the pod-2 will expose the same error we observed in the pod-1 early.

Too many connection errors while connecting to InnoDB Cluster running on EKS (3 replies)

Vyaghri Kasibhatla — Thu, 02 May 2024 11:54:48 +0000

Hi All,

We have installed mysql-operator and mysql-innodbcluster on EKS using the instructions provided in the documentation:

https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-innodbcluster.html.

After the installation is successful, we are updating the mysql service to a LoadBalancer type and trying to access the cluster using the LB Name and port 3306.

It worked fine initially. But after sometime it started giving these errors:

ERROR 1129 (HY000): Too many connection errors from xxxx:xxxx

I tried increasing the maxconnections, flushing the hosts etc. Nothing helped.
I bounced the pods on the statefulset as well.

Any thoughts on what could be going wrong ?

MySQL Router performance (no replies)

netadmin netadmin — Thu, 18 Apr 2024 19:27:44 +0000

Hi, i have 3 nodes kubernetes cluster and i have a mysql innodb cluster inside the kubernetes with kubernates operator and when i am running 3 mysql servers with 3 routers and i am doing tests the performance is worst than when i have 1 mysql server without the router. When i a run the tests to one of my mysql server behind the router the results is also better. I thought that because i have 3 servers the results will be better but it doesn't. For example with 300 threads in 10 seconds with the routers and 3 mysql servers i have 77510 read queries and with one mysql server without router i have 81000 in 10 seconds.... (All the databases are with the default settings except the max_connections and i am using the lastest version of mysql and router 8.3.0). Also the ram and cpu in our nodes are not consume more that 60%.
Thanks.

deleteBackupData not work? (no replies)

Bing Ma — Wed, 10 Apr 2024 09:59:14 +0000

Is it that I'm not using it correctly, or is there a bug? When I deleted the MBK resources, the backup files in Minio were not removed.

the mbk:
########
apiVersion: mysql.oracle.com/v2
kind: MySQLBackup
metadata:
name: a-cool-one-off-mgr0410
spec:
clusterName: mgr-0409-newop
backupProfile:
name: s3-backup-profile
dumpInstance:
dumpOptions:
storage:
s3:
bucketName: username
prefix: mgr-backup
config: s3-secret
endpoint: http://xxxx

deleteBackupData: true

MySQL Operator not self-healing innodb cluster (no replies)

Keegan Bantom — Tue, 09 Apr 2024 08:51:33 +0000

Hello, we've been experimenting with the community edition of the MySQL Operator and deployed an InnoDB cluster. Everything went smoothly initially, but recently, two MySQL pods failed to start up, and the MySQL router couldn't connect to our MySQL instance. Consequently, our applications lost access to the database.
Further investigation revealed incomplete data replication among the pods.

Has anyone encountered a similar issue? Shouldn't the operator handle such operations/failures?

Additionally, any suggestions on resolving this problem would be helpful. Thank you in advance.

Snippet from our mysql-operator logs:

[2024-04-09 08:31:19,327] kopf.objects [INFO ] mysql: all={, , } members={, , } online=set() offline={, , } unsure=set()
[2024-04-09 08:31:19,730] kopf.objects [INFO ] cluster probe: status=ClusterDiagStatus.OFFLINE online=[]
[2024-04-09 08:31:19,932] kopf.objects [INFO ] Cluster cannot be restored because there are unreachable pods: retrying after 5 seconds
[2024-04-09 08:31:21,994] kopf.objects [WARNING ] Patching failed with inconsistencies: (('remove', ('status', 'kopf'), {'dummy': '2024-04-09T08:31:21.670928'}, None),)
[2024-04-09 08:31:22,113] kopf.objects [INFO ] Handler 'on_pod_event' succeeded.
[2024-04-09 08:31:23,402] kopf.objects [WARNING ] Patching failed with inconsistencies: (('remove', ('status', 'kopf'), {'dummy': '2024-04-09T08:31:23.217513'}, None),)
[2024-04-09 08:31:23,523] kopf.objects [INFO ] Handler 'on_pod_event' succeeded.
[2024-04-09 08:31:23,642] kopf.objects [ERROR ] Handler 'on_pod_delete' failed temporarily: mysql busy. lock_owner=mysql-0 owner_context=n/a lock_created_at=2024-04-09T08:31:22.539191
[2024-04-09 08:31:23,805] kopf.objects [WARNING ] Patching failed with inconsistencies: (('remove', ('status', 'kopf'), {'progress': {'on_pod_delete': {'started': '2024-02-18T09:29:44.888978', 'stopped': None, 'delayed': '2024-04-09T08:31:33.643064', 'purpose': 'delete', 'retries': 276494, 'success': False, 'failure': False, 'message': 'mysql busy. lock_owner=mysql-0 owner_context=n/a lock_created_at=2024-04-09T08:31:22.539191', 'subrefs': None}}}, None),)
[2024-04-09 08:31:23,923] kopf.objects [INFO ] Handler 'on_pod_event' succeeded.
[2024-04-09 08:31:25,026] kopf.objects [INFO ] mysql busy. lock_owner=mysql-0 owner_context=n/a lock_created_at=2024-04-09T08:31:22.539191: retrying after 10 seconds
[2024-04-09 08:31:25,877] kopf.objects [INFO ] Could not connect to mysql-2.mysql-instances.infra.svc.cluster.local:3306: error=MySQL Error (2003): mysqlsh.connect_dba: Can't connect to MySQL server on 'mysql-2.mysql-instances.infra.svc.cluster.local:3306' (113)
[2024-04-09 08:31:26,033] kopf.objects [INFO ] mysql-2.mysql-instances.infra.svc.cluster.local:3306: pod.phase=Running deleting=True
[2024-04-09 08:31:26,035] kopf.objects [INFO ] diag instance mysql-2 --> InstanceDiagStatus.OFFLINE quorum=None gtid_executed=None
[2024-04-09 08:31:29,376] kopf.objects [INFO ] Could not connect to mysql-0.mysql-instances.infra.svc.cluster.local:3306: error=MySQL Error (2003): mysqlsh.connect_dba: Can't connect to MySQL server on 'mysql-0.mysql-instances.infra.svc.cluster.local:3306' (113)
[2024-04-09 08:31:29,619] kopf.objects [INFO ] mysql-0.mysql-instances.infra.svc.cluster.local:3306: pod.phase=Running deleting=True
[2024-04-09 08:31:29,621] kopf.objects [INFO ] diag instance mysql-0 --> InstanceDiagStatus.OFFLINE quorum=None gtid_executed=None
[2024-04-09 08:31:29,982] kopf.objects [INFO ] get_cluster() error for mysql-1.mysql-instances.infra.svc.cluster.local:3306: error=Shell Error (51314): Dba.get_cluster: This function is not available through a session to a standalone instance (metadata exists, instance belongs to that metadata, but GR is not active)
[2024-04-09 08:31:29,986] kopf.objects [INFO ] diag instance mysql-1 --> InstanceDiagStatus.OFFLINE quorum=None gtid_executed=09eb7e8d-821a-11ee-88eb-5a412442a166:1-21,
0a387b50-821a-11ee-89ad-3a757c649278:1-10,
476b478a-821a-11ee-9b2b-5a412442a166:1-1368775:2340682-2340727,
476bbbd0-821a-11ee-9b2b-5a412442a166:1-44,
9bf7ae20-af14-11ee-9d0f-9e5a8ec4b826:1-537496:1000478-1001192,
9bf7ba05-af14-11ee-9d0f-9e5a8ec4b826:1-57
[2024-04-09 08:31:29,988] kopf.objects [INFO ] mysql: all={, , } members={, , } online=set() offline={, , } unsure=set()
[2024-04-09 08:31:30,275] kopf.objects [INFO ] cluster probe: status=ClusterDiagStatus.OFFLINE online=[]
[2024-04-09 08:31:30,277] kopf.objects [INFO ] ATTEMPTING CLUSTER REPAIR
[2024-04-09 08:31:30,421] kopf.objects [ERROR ] Handler 'on_pod_delete' failed temporarily: Cluster cannot be restored because there are unreachable pods
[2024-04-09 08:31:30,688] kopf.objects [WARNING ] Patching failed with inconsistencies: (('remove', ('status', 'kopf'), {'progress': {'on_pod_delete': {'started': '2024-03-08T09:21:31.041514', 'stopped': None, 'delayed': '2024-04-09T08:31:35.421718', 'purpose': 'delete', 'retries': 255087, 'success': False, 'failure': False, 'message': 'Cluster cannot be restored because there are unreachable pods', 'subrefs': None}}}, None),)
[2024-04-09 08:31:30,809] kopf.objects [INFO ] Handler 'on_pod_event' succeeded.
[2024-04-09 08:31:34,119] kopf.objects [WARNING ] Patching failed with inconsistencies: (('remove', ('status', 'kopf'), {'dummy': '2024-04-09T08:31:33.644117'}, None),)
[2024-04-09 08:31:34,237] kopf.objects [INFO ] Handler 'on_pod_event' succeeded.
[2024-04-09 08:31:35,431] kopf.objects [INFO ] mysql busy. lock_owner=mysql-2 owner_context=n/a lock_created_at=2024-04-09T08:31:34.541457: retrying after 10 seconds
[2024-04-09 08:31:35,458] kopf.objects [INFO ] get_cluster() error for mysql-1.mysql-instances.infra.svc.cluster.local:3306: error=Shell Error (51314): Dba.get_cluster: This function is not available through a session to a standalone instance (metadata exists, instance belongs to that metadata, but GR is not active)
[2024-04-09 08:31:35,463] kopf.objects [INFO ] diag instance mysql-1 --> InstanceDiagStatus.OFFLINE quorum=None gtid_executed=09eb7e8d-821a-11ee-88eb-5a412442a166:1-21,

MySQL Operator not self-healing innodb cluster (no replies)

Keegan Bantom — Tue, 09 Apr 2024 08:47:55 +0000

MySQL InnoDB backup using flush tables (no replies)

Praveen Kumar B A — Tue, 12 Mar 2024 14:10:51 +0000

Hi All

I am trying to design a backup strategy to backup the files of MySQL using storage snapshot. It primarily has InnoDB engine files.It's mentioned in the MySQL blog that the "flush command with read lock" will flush the table contents to disk for InnoDB but keep the table open. It blocks the write queries for the innodb tables. I see the same is repeatedly mentioned in the steps to setup replication blog as well. Though same lock command is executed, it is recommending to shutdown the server if innodb files are available.

What could be writing to innodb files even when the write queries are blocked and make the data inconsistent?

1. https://dev.mysql.com/doc/refman/8.0/en/flush.html

Snippet from above article

"The descriptions here that indicate tables are flushed by closing them apply differently for InnoDB, which flushes table contents to disk but leaves them open. This still permits table files to be copied while the tables are open, as long as other activity does not modify them. "

2. https://dev.mysql.com/doc/refman/8.0/en/replication-snapshot-method.html

Snippet from above article

If you are using InnoDB tables, and also to get the most consistent results with a raw data snapshot, shut down the source server during the process, as follows:

Thanks
Praveen

MySQL InnoDB backup using flush tables (no replies)

GURU PRASHANTH THANAKODI — Mon, 04 Mar 2024 14:34:57 +0000

MySQL enterprise Edition license (2 replies)

Maqsood Pasha — Mon, 19 Feb 2024 12:34:45 +0000

We’re thinking of virtualize a MySQL Enterprise database on VMware and we’d like to know the correct way to license it.

There are four servers running the VMware environment, and one VM (with MySQL Enterprise) that can run on any of the servers, depending on the circumstances. Should we have to purchase four licenses (one for each server the VM can run in), or just one for the VM?

Unable to start metrics sidecar innodbcluster (1 reply)

Thomas de Gier — Thu, 01 Feb 2024 08:46:06 +0000

I recently upgraded the mysql-operator from 8.0.33 to 8.3.0 to use the added metrics feature for prometheus monitoring. I want to deploy the sidecars in my existing innodbclusters in kubernetes. The operator is updated and the existing innodbclusters seem to deploy with their previous manifest.

However, when applying the manifest with a metrics object, the metrics sidecar keeps crashing. I also tried this with a new test cluster. The applied manifest for this cluster:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
name: ictest
namespace: testing
spec:
secretName: ictest-secret
tlsUseSelfSigned: true
datadirVolumeClaimTemplate:
accessModes:
- ReadWriteOnce
storageClassName: ceph-nvme-block
metrics:
enable: true
image: prom/mysqld-exporter
---
apiVersion: v1
kind: Secret
metadata:
name: ictest-secret
namespace: testing
stringData:
rootUser: mysql
rootHost: "%"
rootPassword: pass

Otherwise, the other containers seem functional and the cluster seems operational.

Is something wrong with this innodbcluster configuration? Can someone share their experience with correctly deploying the sidecar?

How to setup Database version control for MySQL (no replies)

Shanthini G — Mon, 08 Jan 2024 11:52:47 +0000

Hi,

How to setup Database version control for MySQL. Please suggest.

I am using WAMP server for PHP web application development

Thanks

Does this operator support mariadb? I saw skip_log_error in configuration (2 replies)

Bing Ma — Wed, 22 Nov 2023 15:46:20 +0000

00-basic.cnf: |
# Basic configuration.
# Do not edit.
[mysqld]
plugin_load_add=auth_socket.so
loose_auth_socket=FORCE_PLUS_PERMANENT
skip_log_error
log_error_verbosity=3

#####
skip_log_error is a mariadb config item,I think

Does the operator support multiple replicas? I found that the replica field is not exposed in values.yaml (no replies)

Bing Ma — Tue, 21 Nov 2023 02:15:20 +0000

The default value of replica is 1.

when I use kubectl get ic, the ROUTERS column is empty (no replies)

Bing Ma — Fri, 17 Nov 2023 09:07:14 +0000

is this correct? and I can see the router's pod.I think the 'ROUTERS' column exists, should show sth, something should I fix?
===
k get ic
NAME STATUS ONLINE INSTANCES ROUTERS AGE
mgr1116 ONLINE 1 1 18h
mgr1117 ONLINE 1 1 6h50m

===

k get po |grep route
mgr1116-router-7c67d57d77-x688h 1/1 Running 0 18h
mgr1117-router-57f579fcf8-jfg95 1/1 Running 0 6h46m

Your operator cannot adapt to multiple architectures (1 reply)

Bing Ma — Thu, 09 Nov 2023 14:49:27 +0000

There is a serious problem here. Your operator cannot adapt to multiple architectures because your image has a special flag - aarch64 under arm64. When I deploy it on an arm64 machine, I will still pull the amd64 image. , I don't know if you understand what I said.
=====================================

your images:
https://container-registry.oracle.com/ords/f?p=113:4:115719165018774:::RP,4:P4_REPOSITORY,AI_REPOSITORY,P4_REPOSITORY_NAME,AI_REPOSITORY_NAME:1504,1504,MySQL%20Operator%20for%20Kubernetes,MySQL%20Operator%20for%20Kubernetes&cs=3D2OkKt3XK5lfiJTde5Ah8ueejHm-VsPYuVJdSkPNB5oq0cqc1bTVw68FyKPrfLpa5dqcvQqfBz4bjU3o_YlLbA

when I set imageRepository and metrics field, the metics.image does not use the imageRepository (1 reply)

Bing Ma — Thu, 09 Nov 2023 14:52:02 +0000

is this a feature or a bug?
because others will follow imageRepository

I wish I could have more options when setting up scheduled backups (1 reply)

Bing Ma — Thu, 09 Nov 2023 14:50:22 +0000

like spec.successfulJobsHistoryLimit and spec.failedJobsHistoryLimit fields

When customizing services, I hope to have more configurable items (1 reply)

Bing Ma — Thu, 09 Nov 2023 14:45:19 +0000

when use nodeport: hope the port can be specified

when use loadbalancer: spec.loadBalancerIP can be set, spec.externalTrafficPolicy and spec.internalTrafficPolicy can be set.

Does this operator support shrink/expand instance number？ (no replies)

Bing Ma — Thu, 26 Oct 2023 02:24:11 +0000

I shrink one ic's instance number from 3 to 1, it's status changed to ONLINE_PARTIAL.

I expand one ic's instance number from 1 to 3, then shrink to 1, the ONLINE number is still three.

NAME STATUS ONLINE INSTANCES ROUTERS AGE
ic1025-1 ONLINE_PARTIAL 1 1 1 18h
ic1025-2 ONLINE 3 1 1 15h