Migrate MySQL5.7 to MariaDB 10.4, then to MariaDB 10.11 Failed
Hi, I am going to migrate our existing MySQL5.7 to MariaDB 10.11.9. I setup a new Windows server that installed MySQL 5.7, MariaDB 10.4.34 and MariaDB 10.11.9 without create a new instance. I copied the data directory of MySQL5.7 from existing Windows server to the new server for migration test. First, I am able to start the MySQL5.7 on the new server. Then, I upgrade the MySQL5.7 to MariaDB 10.4.34 successfully using mysql_upgrade_service.exe which under MariaDB 10.4.34 bin directory. But failed at the last step that upgrade MariaDB 10.4.34 to MariaDB 10.11.9 using mariadb-upgrade-service.exe which under MariaDB 10.11.9 bin directory. From the error log, got below message 2024-10-03 16:17:39 0 [Note] InnoDB: Buffer pool(s) load completed at 241003 16:17:39 241003 16:17:40 [ERROR] mysqld got exception 0xc0000005 ; Sorry, we probably made a mistake, and this is a bug. Your assistance in bug reporting will enable us to fix this for the next release. To report this bug, see https://mariadb.com/kb/en/reporting-bugs From the upgrade log, got below message Phase 3/8: Running 'mysql_fix_privilege_tables' ERROR 2017 (HY000): Can't open named pipe to host: . pipe: mysql_upgrade_service_3564 (2) FATAL ERROR: Upgrade failed Checked named pipe enabled and local client able to connect using named pipe at each stage. Any idea why upgrade failed? When upgrade, MariaDB start the instance with socket which is not same as the socket option in my.ini. In this case, it start with socket mysql_upgrade_service_3564; I tried few times the last 4 numeric digits are not fixed and change every time. Thanks.
Hi, edwin.chan can you show more lines around "mysqld got exception 0xc0000005" ? On Oct 03, edwin.chan--- via discuss wrote:
Hi,
I am going to migrate our existing MySQL5.7 to MariaDB 10.11.9. I setup a new Windows server that installed MySQL 5.7, MariaDB 10.4.34 and MariaDB 10.11.9 without create a new instance. I copied the data directory of MySQL5.7 from existing Windows server to the new server for migration test. First, I am able to start the MySQL5.7 on the new server. Then, I upgrade the MySQL5.7 to MariaDB 10.4.34 successfully using mysql_upgrade_service.exe which under MariaDB 10.4.34 bin directory. But failed at the last step that upgrade MariaDB 10.4.34 to MariaDB 10.11.9 using mariadb-upgrade-service.exe which under MariaDB 10.11.9 bin directory.
From the error log, got below message
2024-10-03 16:17:39 0 [Note] InnoDB: Buffer pool(s) load completed at 241003 16:17:39 241003 16:17:40 [ERROR] mysqld got exception 0xc0000005 ; Sorry, we probably made a mistake, and this is a bug.
Your assistance in bug reporting will enable us to fix this for the next release. To report this bug, see https://mariadb.com/kb/en/reporting-bugs
From the upgrade log, got below message
Phase 3/8: Running 'mysql_fix_privilege_tables' ERROR 2017 (HY000): Can't open named pipe to host: . pipe: mysql_upgrade_service_3564 (2) FATAL ERROR: Upgrade failed
Checked named pipe enabled and local client able to connect using named pipe at each stage. Any idea why upgrade failed? When upgrade, MariaDB start the instance with socket which is not same as the socket option in my.ini. In this case, it start with socket mysql_upgrade_service_3564; I tried few times the last 4 numeric digits are not fixed and change every time.
Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org
Hi Sergei, Here you are. 2024-10-03 16:17:37 0 [Note] Starting MariaDB 10.11.9-MariaDB-log source revision 0e8fb977b00983d98c4c35e39bc1f36463095938 server_uid f3iI9vbuyCmKX95HRsYuhA40DDA= as process 7752 2024-10-03 16:17:37 0 [Note] Plugin 'partition' is disabled. 2024-10-03 16:17:37 0 [Note] InnoDB: Compressed tables use zlib 1.3.1 2024-10-03 16:17:37 0 [Note] InnoDB: Number of transaction pools: 1 2024-10-03 16:17:37 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2024-10-03 16:17:37 0 [Note] InnoDB: Initializing buffer pool, total size = 4.000GiB, chunk size = 64.000MiB 2024-10-03 16:17:37 0 [Note] InnoDB: Completed initialization of buffer pool 2024-10-03 16:17:37 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes) 2024-10-03 16:17:37 0 [Note] InnoDB: Upgrading redo log: 512.000MiB; LSN=432003077653 2024-10-03 16:17:37 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes) 2024-10-03 16:17:37 0 [Note] InnoDB: 128 rollback segments are active. 2024-10-03 16:17:37 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ... 2024-10-03 16:17:37 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB. 2024-10-03 16:17:37 0 [Note] InnoDB: log sequence number 432003077653; transaction id 149460289 2024-10-03 16:17:37 0 [Note] Plugin 'FEEDBACK' is disabled. 2024-10-03 16:17:37 0 [Note] InnoDB: Loading buffer pool(s) from R:\MariaDB 10.6\data\ib_buffer_pool 2024-10-03 16:17:37 0 [Note] mysqld.exe: SSPI: using principal name 'STMariaDB01$@internal.checkit.net', mech 'Negotiate' 2024-10-03 16:17:38 0 [Note] C:\Program Files\MariaDB 10.11\bin\mysqld.exe: ready for connections. Version: '10.11.9-MariaDB-log' socket: '' port: 0 mariadb.org binary distribution 2024-10-03 16:17:39 0 [Note] InnoDB: Buffer pool(s) load completed at 241003 16:17:39 241003 16:17:40 [ERROR] mysqld got exception 0xc0000005 ; Sorry, we probably made a mistake, and this is a bug. Your assistance in bug reporting will enable us to fix this for the next release. 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: 10.11.9-MariaDB-log source revision: 0e8fb977b00983d98c4c35e39bc1f36463095938 key_buffer_size=67108864 read_buffer_size=262144 max_used_connections=1 max_threads=65537 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 83975822 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x18e56ce1848 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... server.dll!TABLE_SHARE::init_from_binary_frm_image()[table.cc:2310] server.dll!open_table_def()[table.cc:738] server.dll!tdc_acquire_share()[table_cache.cc:859] server.dll!fill_schema_table_from_frm()[sql_show.cc:5091] server.dll!get_all_tables()[sql_show.cc:5410] server.dll!get_schema_tables_result()[sql_show.cc:9218] server.dll!JOIN::exec_inner()[sql_select.cc:4899] server.dll!mysql_select()[sql_select.cc:5201] server.dll!handle_select()[sql_select.cc:586] server.dll!execute_sqlcom_select()[sql_parse.cc:6385] server.dll!mysql_execute_command()[sql_parse.cc:3988] server.dll!mysql_parse()[sql_parse.cc:8149] server.dll!dispatch_command()[sql_parse.cc:1897] server.dll!do_command()[sql_parse.cc:1408] server.dll!tp_callback()[threadpool_common.cc:249] KERNEL32.DLL!LCMapStringEx() ntdll.dll!RtlAddRefActivationContext() ntdll.dll!RtlAcquireSRWLockExclusive() KERNEL32.DLL!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart() Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x18e56cd6e80): SELECT table_comment FROM information_schema.tables WHERE table_comment LIKE 'Unknown data type: %' Connection ID (thread ID): 10 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off,hash_join_cardinality=off,cset_narrowing=off The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains information that should help you find out what is causing the crash. Writing a core file at R:\MariaDB 10.6\data Minidump written to R:\MariaDB 10.6\data\mysqld.dmp Thanks. Regards, Edwin
Hi Edwin, It looks like one of the *.frm files is causing the crash. These files contain the MySQL or MariaDB table definition (as in SHOW CREATE TABLE). The serialized binary form is being converted to a memory object that is called TABLE_SHARE. In the InnoDB storage engine, there is a set of data dictionary tables that partly duplicates this information, but they do not seem to be the issue here. I would hope that the mysqld.dmp file contains enough information to identify the problematic *.frm file. If you shared the file with us, it should be possible to diagnose and fix the parsing problem. Best regards, Marko Mäkelä
https://mariadb.com/kb/en/meta/mariadb-ftp-server/ is one way, but as Marko said, a SHOW CREATE TABLE from the original MySQL or extracted out of a SQL backup is likely sufficient. One known migration bug is https://jira.mariadb.org/browse/MDEV-32277 On Fri, 4 Oct 2024 at 23:15, edwin.chan--- via discuss < discuss@lists.mariadb.org> wrote:
Hi Marko,
I got the mysqld.dmp, how to share here?
Thanks.
Regards, Edwin _______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Hello, around 2 years ago, we switched from mysql5 to mariadb10 also. We used that to cleanup the DB also, so YMMW. We found the most reliable way is to dump the data and import it (on the other machine). This takes a lot of time but saves in the long run. FYI we change the engine so binary was never an real option but in the first tests we used the old engine of cause. may this helps Am 30.10.24 um 07:23 schrieb Daniel Black via discuss:
https://mariadb.com/kb/en/meta/mariadb-ftp-server/ is one way, but as Marko said, a SHOW CREATE TABLE from the original MySQL or extracted out of a SQL backup is likely sufficient.
One known migration bug is https://jira.mariadb.org/browse/MDEV-32277
On Fri, 4 Oct 2024 at 23:15, edwin.chan--- via discuss < discuss@lists.mariadb.org> wrote:
participants (5)
-
Daniel Black -
edwin.chan＠checkit.net -
Marko Mäkelä -
Radisson -
Sergei Golubchik