Re: mysql8.0 upgrade crashes

I have done the 5.7 to 8.0 upgrade on other systems without trouble, and th=
e MySQL docs explain how to do it. Of course  I do a zfs snapshot before th=
e upgrade, but it normally works. Something is strange here but I do not kn=
ow what.

Please consider the environment before reading this message.
John Levine, johnl@taugh.com

> On Apr 17, 2023, at 02:33, Dan Mahoney <danm@prime.gushi.org> wrote:
>
> =EF=BB=BF
>
>> On Apr 16, 2023, at 8:12 PM, John Levine <johnl@iecc.com> wrote:
>>
>> I'm trying to upgrade my fbsd 13.1 system from MySQL 5.7 to 8.0. So I
>> shut down 5.7 cleanly, install the 8.0 package, start if up, and it
>> consistently crashes somwehere in the upgrade process. I don't think
>> there is anything very odd about my setup other than perhaps I set it
>> to put each innodb database in a separate directory.
>>
>> I realize I could dump everything, install 8.0 from scratch, and
>> restore it all, but I have a lot of databases and that would be
>> painful so it would be really nice if I could get the upgrade to work.
>>
>> R's,
>> John
>
> In the postgres world, we=E2=80=99re used to getting warnings from pkg ab=
out having to do a full dump and restore every time we make a major version=
 jump.  Maybe that=E2=80=99s advised here.
>
> -Dan
>
>>
>> 2023-04-16T18:46:12.6NZ mysqld_safe Logging to '/var/mysql/gal.iecc.com.=
err'.
>> 2023-04-16T18:46:12.6NZ mysqld_safe Starting mysqld daemon with database=
s from /var/mysql
>> 2023-04-16T18:46:12.933341Z 0 [Warning] [MY-010915] [Server] 'NO_ZERO_DA=
TE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be=
 used with strict mode. They will be merged with strict mode in a future re=
lease.
>> 2023-04-16T18:46:12.936708Z 0 [System] [MY-010116] [Server] /usr/local/l=
ibexec/mysqld (mysqld 8.0.32) starting as process 18731
>> 2023-04-16T18:46:12.961932Z 1 [System] [MY-011012] [Server] Starting upg=
rade of data directory.
>> 2023-04-16T18:46:12.962004Z 1 [System] [MY-013576] [InnoDB] InnoDB initi=
alization has started.
>> 2023-04-16T18:46:24.136645Z 1 [System] [MY-013577] [InnoDB] InnoDB initi=
alization has ended.
>> 2023-04-16T18:46:28Z UTC - mysqld got signal 11 ;
>> Most likely, you have hit a bug, but this error can also be caused by ma=
lfunctioning hardware.
>> Thread pointer: 0x81715e800
>> 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...
>> [0x2371c88] +0x0
>> [0x2371dcb] +0x0
>> [0x8036d3580] _pthread_sigmask+0x540
>> [0x8036d2b3f] _pthread_setschedparam+0x82f
>> [0x7ffffffff2d3] +0x82f
>> [0x30aa132] +0x82f
>> [0x30a8a8d] +0x82f
>> [0x2f73f62] +0x82f
>> [0x30b1bd9] +0x82f
>> [0x2ed1107] +0x82f
>> [0x2ecd314] +0x82f
>> [0x2ecdf04] +0x82f
>> [0x2ec8128] +0x82f
>> [0x1fc4ba5] +0x82f
>> [0x330b322] +0x82f
>> [0x8036c983a] _pthread_create+0x8ca
>> [0x0] +0x8ca
>> stack_bottom =3D 7fffdc0dceb8 thread_stack 0x100000
>> 0x2ef49be <_Z19my_print_stacktracePKhm+0x10e> at /usr/local/libexec/mysq=
ld
>> 0x2371c88 <_Z18print_fatal_signali+0x268> at /usr/local/libexec/mysqld
>> 0x2371dcb <handle_fatal_signal+0x2b> at /usr/local/libexec/mysqld
>> 0x8036d3580 <pthread_sigmask+0x540> at /lib/libthr.so.3
>> 0x8036d2b3f <pthread_setschedparam+0x82f> at /lib/libthr.so.3
>> 0x7ffffffff2d3 <???> at ???
>> 0x30aa132 <_Z15dict_load_tablePKcb17dict_err_ignore_tPKNSt3__112basic_st=
ringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEE+0x17c2> at /usr/local/libex=
ec/mysqld
>> 0x30a8a8d <_Z15dict_load_tablePKcb17dict_err_ignore_tPKNSt3__112basic_st=
ringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEE+0x11d> at /usr/local/libexe=
c/mysqld
>> 0x2f73f62 <_Z23dict_table_open_on_namePKcbb17dict_err_ignore_t+0x272> at=
 /usr/local/libexec/mysqld
>> 0x30b1bd9 <_Z16dd_upgrade_tableP3THDPKcS2_PN2dd5TableEP5TABLE+0x129> at =
/usr/local/libexec/mysqld
>> 0x2ed1107 <_ZN20malloc_unordered_setINSt3__112basic_stringIcNS0_11char_t=
raitsIcEENS0_9allocatorIcEEEENS0_4hashIS6_EENS0_8equal_toIS6_EEEC2Ej+0x7c7>=
 at /usr/local/libexec/mysqld
>> 0x2ecd314 <_ZN2dd10upgrade_5726migrate_plugin_table_to_ddEP3THD+0x2554> =
at /usr/local/libexec/mysqld
>> 0x2ecdf04 <_ZN2dd10upgrade_5721migrate_all_frm_to_ddEP3THDPKcb+0x7c4> at=
 /usr/local/libexec/mysqld
>> 0x2ec8128 <_ZN2dd10upgrade_5720fill_dd_and_finalizeEP3THD+0x118> at /usr=
/local/libexec/mysqld
>> 0x1fc4ba5 <_ZN9bootstrap20run_bootstrap_threadEPKcP10MYSQL_FILEPFbP3THDE=
16enum_thread_type+0x5a5> at /usr/local/libexec/mysqld
>> 0x330b322 <_Z19pfs_spawn_thread_vcjjP16my_thread_handlePKP12pthread_attr=
PFPvS5_ES5_+0x2a2> at /usr/local/libexec/mysqld
>>
>> Trying to get some variables.
>> Some pointers may be invalid and cause the dump to abort.
>> Query (0):
>> Connection ID (thread ID): 2
>> Status: NOT_KILLED
>>
>> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html conta=
ins
>> information that should help you find out what is causing the crash.
>> 2023-04-16T18:46:29.6NZ mysqld_safe mysqld from pid file /var/mysql/gal.=
iecc.com.pid ended
>