Hi, A customer ran an 'ALTER TABLE' query, which failed. This caused Galera slaves to shut themselves down: 2021-11-23 9:35:25 1 [ERROR] Slave SQL: Column 2 of table 'inserve_fpfvxiqm.invoices' cannot be converted from type 'date' to type 'int(10) unsigned', Internal MariaDB error code: 1677 2021-11-23 9:35:25 1 [Warning] WSREP: RBR event 17 Update_rows_v1 apply warning: 3, 28891485 2021-11-23 9:35:25 1 [Warning] WSREP: Failed to apply app buffer: seqno: 28891485, status: 1 at /home/buildbot/buildbot/build/galera/src/trx_handle.cpp:apply():353 [ 3 more times ] 2021-11-23 9:35:25 1 [Warning] WSREP: RBR event 17 Update_rows_v1 apply warning: 3, 28891485 2021-11-23 9:35:26 1 [ERROR] WSREP: Failed to apply trx: source: 41c479ab-0527-11ec-9fcc-9f02b1141194 version: 4 local: 0 state: APPLYING flags: 1 conn_id: 13475392 trx_id: 63620823 seqnos (l: 312653, g: 28891485, s: 28891454, d: 28891449, ts: 10603037948851154) 2021-11-23 9:35:26 1 [ERROR] WSREP: Failed to apply trx 28891485 4 times 2021-11-23 9:35:26 1 [ERROR] WSREP: Node consistency compromised, aborting... The node on which the query was executed, crashed ("mysqld got signal 11"). At first sight, this seems to be the result of "WSREP: Send action {(nil), 528, TORDERED} returned -107 (Transport endpoint is not connected)" - as all the slaves were down at this point. As 'ALTER' is a DDL statement that does not support rollback, I understand that the only option for Galera may be to abort. But is there a way to handle something like this more gracefully? -- With kind regards, William Edwards