Crash loop booting second MySQL instance on Docker Desktop for Mac

Percona Everest
1

I’m trying to boot a 3 node MySQL cluster on Docker Desktop for Mac k8s. All pods boot except the second MySQL node which goes into a crash loop:

2024-06-23T06:45:27.237674Z 2 [Note] [MY-000000] [Galera] Current view of cluster as seen by this node
view (view_id(NON_PRIM,10bbba7f-a48c,2)
memb {
	2409b0a3-8bf0,0
	}
joined {
	}
left {
	}
partitioned {
	10bbba7f-a48c,0
	}
)
2024-06-23T06:45:27.237887Z 2 [Note] [MY-000000] [Galera] PC protocol downgrade 1 -> 0
2024-06-23T06:45:27.237909Z 2 [Note] [MY-000000] [Galera] Current view of cluster as seen by this node
view ((empty))
2024-06-23T06:45:27.239960Z 2 [Note] [MY-000000] [Galera] gcomm: closed
2024-06-23T06:45:27.240047Z 0 [Note] [MY-000000] [Galera] New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1
2024-06-23T06:45:27.240263Z 0 [Note] [MY-000000] [Galera] Flow-control interval: [96, 96]
2024-06-23T06:45:27.240307Z 0 [Note] [MY-000000] [Galera] Received NON-PRIMARY.
2024-06-23T06:45:27.240320Z 0 [Note] [MY-000000] [Galera] Shifting PRIMARY -> OPEN (TO: 64)
2024-06-23T06:45:27.240360Z 0 [Note] [MY-000000] [Galera] New SELF-LEAVE.
2024-06-23T06:45:27.240519Z 0 [Note] [MY-000000] [Galera] Flow-control interval: [0, 0]
2024-06-23T06:45:27.240530Z 0 [Note] [MY-000000] [Galera] Received SELF-LEAVE. Closing connection.
2024-06-23T06:45:27.240533Z 0 [Note] [MY-000000] [Galera] Shifting OPEN -> CLOSED (TO: 64)
2024-06-23T06:45:27.240567Z 0 [Note] [MY-000000] [Galera] RECV thread exiting 0: Success
2024-06-23T06:45:27.240617Z 2 [Note] [MY-000000] [Galera] recv_thread() joined.
2024-06-23T06:45:27.240635Z 2 [Note] [MY-000000] [Galera] Closing replication queue.
2024-06-23T06:45:27.240642Z 2 [Note] [MY-000000] [Galera] Closing slave action queue.
2024-06-23T06:45:27.240829Z 2 [Note] [MY-000000] [Galera] mysqld: Terminated.
2024-06-23T06:45:27.240891Z 2 [Note] [MY-000000] [WSREP] Initiating SST cancellation
2024-06-23T06:45:27Z UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=df9f6877fc91c9a71d439f27569eabdef408f622
Server Version: 8.0.32-24.2 Percona XtraDB Cluster (GPL), Release rel24, Revision 2119e75, WSREP version 26.1.4.3, wsrep_26.1.4.3

Thread pointer: 0x7fffc4000b60
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7fffd0ad6c70 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x2253a31]
/usr/sbin/mysqld(print_fatal_signal(int)+0x39f) [0x1262d0f]
/usr/sbin/mysqld(handle_fatal_signal+0xd8) [0x1262df8]
/lib64/libpthread.so.0(+0x12ce0) [0x7fffff3bfce0]
/lib64/libc.so.6(abort+0x203) [0x7ffffd69bee1]
/usr/lib64/galera4/libgalera_smm.so(+0x17935) [0x7ffff08a8935]
/usr/lib64/galera4/libgalera_smm.so(+0x207d92) [0x7ffff0a98d92]
/usr/lib64/galera4/libgalera_smm.so(+0x2098aa) [0x7ffff0a9a8aa]
/usr/lib64/galera4/libgalera_smm.so(+0x212077) [0x7ffff0aa3077]
/usr/lib64/galera4/libgalera_smm.so(+0x2122be) [0x7ffff0aa32be]
/usr/lib64/galera4/libgalera_smm.so(+0x1f07d2) [0x7ffff0a817d2]
/usr/lib64/galera4/libgalera_smm.so(+0x2113c4) [0x7ffff0aa23c4]
/usr/lib64/galera4/libgalera_smm.so(+0x22e262) [0x7ffff0abf262]
/usr/sbin/mysqld(wsrep::wsrep_provider_v26::run_applier(wsrep::high_priority_service*)+0x12) [0x2c25002]
/usr/sbin/mysqld() [0x12b46dd]
/usr/sbin/mysqld(start_wsrep_THD+0x371) [0xf5be41]
/usr/sbin/mysqld() [0x27b1249]
/lib64/libpthread.so.0(+0x81cf) [0x7fffff3b51cf]
/lib64/libc.so.6(clone+0x43) [0x7ffffd6b3dd3]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 2
Status: NOT_KILLED

You may download the Percona XtraDB Cluster operations manual by visiting
http://www.percona.com/software/percona-xtradb-cluster/. You may find information
in the manual which will help you identify the cause of the crash.
Writing a core file using lib coredumper
PATH: (null)

Error writting coredump: -1 Signal: 11
2

Are you on an x86 mac or an arm mac? (m1/m2) If you are on M1/M2 then you won’t be able to run PXC as we do not have ARM-compatible binaries yet.

3

I am on an M1 Mac. I’ll use GKE for now, thanks!

FWIW, I did get a single node MySQL running.

4

We do have docker images for Percona MySQL, but not yet for Percona XtraDB Cluster. If you have not seen it, Percona Everest is a 1-stop solution for running MySQL in K8S environments. Control plane, management, etc

5

Sorry, maybe I wasn’t clear that I’m using Everest. Everest is what led to this error.

6

Hi, I have an M1 Mac as well, unfortunately it always causes different problems as Everest uses Operators and Operators don’t support ARM.

Sometimes the cluster runs without problems and sometimes there are problems. Unfortunately right now the problems are not being investigated, waiting for ARM support from Operators.

As a result I use GKE for tests, instead of local mac m1. My colleague also takes an EC2 instance in AWS and runs Minikube there.

Although some developers use Kind and they run on M1 without problems, on one MySQL cluster.

Translated with DeepL Translate: The world's most accurate translator (free version)