You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The exporter container becomes ready, the mysql container does not
The logs show
2024-10-04T10:57:57.983050Z 5 [System] [MY-010562] [Repl] Slave I/O thread for channel '': connected to master 'replicator@lala-mysql-primary:3306',replication started in log 'FIRST' at position 4
2024-10-04T10:57:57.983129Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /tmp/mysqlx.sock
2024-10-04T10:57:57.983214Z 0 [System] [MY-010931] [Server] /opt/bitnami/mysql/bin/mysqld: ready for connections. Version: '8.0.32' socket: '/opt/bitnami/mysql/tmp/mysql.sock' port: 3306 Source distribution.
2024-10-04T10:57:58.185967Z 7 [ERROR] [MY-010584] [Repl] Slave SQL for channel '': Worker 1 failed executing transaction 'ANONYMOUS' at master log mysql-bin.000117, end_log_pos 1128; Error executing row event: 'Unknown database 'koko'', Error_code: MY-001049
2024-10-04T10:57:58.186219Z 6 [ERROR] [MY-010586] [Repl] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000117' position 157
The LivenessProbe restarts the container after a while, finally reaching CrashLoopBackOff
From the container we can see all the required env variables (root / rootpass, koko / kokopass, replicator / replicator pass, etc)
Attempts to use mysql to gather information about the state fail with (regardless of user)
I have no name!@lala-mysql-secondary-1:/$ mysql -u root -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
In the db data dir (/bitnami/mysql/data/) we can see shipped binlogs but not the koko db directory
From the primary DB we can see the two secondaries
Name and Version
bitnami mysql 9.7.0
What architecture are you using?
amd64
What steps will reproduce the bug?
Are you using any custom parameters or values?
We deploy via flux. The committed HelmRelease Object, to scale from 1 replica to 2, looks like this:
What is the expected behavior?
What do you see instead?
The text was updated successfully, but these errors were encountered: