MacOS Monterey 12.6.3, Homebrew 4.0.26

Same update to 11.0.2, same startup crash, same collation number. Please advise.

[ERROR] [FATAL] InnoDB: Unable to find charset-collation for 271

Exactly the same problem upgrading from 10.11.4:

2023-08-02 22:25:17 0 [ERROR] [FATAL] InnoDB: Unable to find charset-collation for 254
230802 22:25:17 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 11.0.2-MariaDB-log source revision: 0005f2f06c8e1aea4915887decad67885108a929
Thread pointer: 0x0
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 = 0x0 thread_stack 0x49000
/usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x55f8039ad56e]
/usr/sbin/mariadbd(handle_fatal_signal+0x478)[0x55f80348ee78]
/lib64/libc.so.6(+0x54dd0)[0x7f4e40c54dd0]
/lib64/libc.so.6(+0xa156c)[0x7f4e40ca156c]
/lib64/libc.so.6(raise+0x16)[0x7f4e40c54d26]
/lib64/libc.so.6(abort+0xd3)[0x7f4e40c287f3]
/usr/sbin/mariadbd(+0x693865)[0x55f8030b5865]
/usr/sbin/mariadbd(+0x67db19)[0x55f80309fb19]
/usr/sbin/mariadbd(+0xdd566f)[0x55f8037f766f]
/usr/sbin/mariadbd(+0xdb1eca)[0x55f8037d3eca]
/usr/sbin/mariadbd(+0x6aebbe)[0x55f8030d0bbe]
/usr/sbin/mariadbd(+0x68d8be)[0x55f8030af8be]
/usr/sbin/mariadbd(+0xd57a19)[0x55f803779a19]
/usr/sbin/mariadbd(_Z24ha_initialize_handlertonP13st_plugin_int+0x82)[0x55f803492012]
/usr/sbin/mariadbd(+0x834586)[0x55f803256586]
/usr/sbin/mariadbd(_Z11plugin_initPiPPci+0x8dd)[0x55f8032576fd]
/usr/sbin/mariadbd(+0x706ae1)[0x55f803128ae1]
/usr/sbin/mariadbd(_Z11mysqld_mainiPPc+0x41c)[0x55f80312e1ac]
/lib64/libc.so.6(+0x3feb0)[0x7f4e40c3feb0]
/lib64/libc.so.6(__libc_start_main+0x80)[0x7f4e40c3ff60]
/usr/sbin/mariadbd(_start+0x25)[0x55f803122ae5]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /var/lib/mysql
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 361918 361918 processes
Max open files 32768 32768 files
Max locked memory 8388608 8388608 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 361918 361918 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h

Kernel version: Linux version 5.14.0-289.el9.x86_64 (mockbuild@x86-05.stream.rdu2.redhat.com) (gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4), GNU ld version 2.35.2-37.el9) #1 SMP PREEMPT_DYNAMIC Sun Mar 19 07:28:57 UTC 2023

In MySQL 8.0, 271 is utf8mb4_la_0900_ai_ci. Had you been using 8.0 at some point in the past?
(Unrelated: You should consider a innodb_buffer_pool_size bigger than 128M.)

I've run our servers for 13 years, so I'm guessing the answer is yes.

Does https://jira.mariadb.org/browse/MDEV-31443 resolve this issue too?

Is there anything we can do to prevent this upgrade error? I was able to downgrade back to 10 for now, and it's in my power to run whatever commands that would be needed to flush the problematic data out if it's possible.

This report seems to duplicate MDEV-31443. The quarterly releases, including MariaDB Server 11.0.3, are currently being prepared. I do not think that our CI systems cover macOS, so you would have to build a development snapshot yourself, ask a Homebrew maintainer to port the fix to 11.0.2 (like it was done for Arch Linux), or wait for the 11.0.3 release to be out both from us and from Homebrew.

A user in MDEV-31443 confirmed a work-around:

I have run into the same issue and can confirm that running SET GLOBAL innodb_fast_shutdown=0; prior to stopping my MariaDB 10 instance allows me to successfully install MariaDB 11.

Marko, any thoughts on charset-collation for 254? It's a different collation ID, however, the same error. Reproducible on CentOS.

thedotedge, the message could display different charset-collation numbers.

Does it mean that 11.0.3 would have a fix? Workaround with innodb_fast_shutdown didn’t help unfortunately.

Otherwise, is there any way to check which column has the collation in question to alter it manually?

11.0.3 is out https://mariadb.com/kb/en/mariadb-11-0-3-release-notes/.

I can confirm upgrading to 11.0.3 fixed the issue for me.

Aaand a few minutes in, the server started crashing. Not sure if related to this bug or not, but here: MDEV-32044.

archon810, MDEV-32044 should be completely unrelated to the change buffer, which is connected to secondary indexes. If there is a connection, it might be that the MDEV-30009 bug scenario had occurred in the past, and some stale change buffer entries were applied to a page that actually belongs to the clustered index.

thedotedge, did an upgrade to 11.0.3 fix this issue for you?

I confirmed MDEV-32044 to be a corruption due to a MDEV-30009 type scenario.