Details
Major Description
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: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
|
From the upgrade log, got below message
Phase 2/8: Installing used storage engines... Skipped
|
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
|
Attached mysqld.dmp for reference.
Attachments
Activity
Uploaded alarming_alarm.frm. When upgrade from Mysql5.7 to MariaDB 10.4.19, I got below message in the upgrade log which mentioned alarming_alarm error.
Phase 6/7: Checking and upgrading tables
Processing databases
bureauv2alarms
bureauv2alarms.a2j_localactivealarm OK
bureauv2alarms.a2j_service_status OK
bureauv2alarms.ach_config_audits OK
bureauv2alarms.ach_customer_config OK
bureauv2alarms.ach_dept_config OK
bureauv2alarms.ach_excluded_subfixture OK
bureauv2alarms.ach_keyholderlist_config OK
bureauv2alarms.ach_keyholders_config OK
bureauv2alarms.ach_main_config OK
bureauv2alarms.ach_site_config OK
bureauv2alarms.ach_threshold_active_breach OK
bureauv2alarms.active_logins OK
bureauv2alarms.activity OK
bureauv2alarms.alarm_maping OK
bureauv2alarms.alarm_status OK
bureauv2alarms.alarm_status_description OK
bureauv2alarms.alarmassets_cache OK
bureauv2alarms.alarmassets_cachetest OK
bureauv2alarms.alarmassets_calibrationtype OK
bureauv2alarms.alarming_activealarm OK
bureauv2alarms.alarming_alarm
Error : Table 'bureauv2alarms.alarming_alarm' doesn't exist in engine
status : Operation failed
bureauv2alarms.alarming_alarm_call OK
When I generated the create statement of the table I got this. Although the partition part commented, is it the point trigger error?
CREATE TABLE `alarming_alarm` ( |
`alarm_id` bigint(20) NOT NULL DEFAULT '0', |
`alarm_type` varchar(250) DEFAULT NULL, |
`receive_time` datetime NOT NULL, |
`finish_time` datetime DEFAULT NULL, |
`handle_type` int(11) DEFAULT NULL, |
`alarm_trap_id` int(11) DEFAULT NULL, |
`alarmasset_id` int(11) DEFAULT NULL, |
`localfinish_time` datetime DEFAULT NULL, |
`subfixture` varchar(255) DEFAULT NULL, |
`site_code` varchar(50) DEFAULT NULL, |
`time_taken` int(11) DEFAULT '0', |
`time_held` int(11) DEFAULT '0', |
`legacy_alarm_id` int(11) DEFAULT '0', |
`site_name` varchar(255) NOT NULL DEFAULT '', |
`siteGroup` varchar(50) DEFAULT NULL, |
`is_alarm` bit(1) NOT NULL DEFAULT b'1', |
`sentToAToJ` bit(1) DEFAULT b'0', |
`execution_sid` varchar(200) DEFAULT NULL, |
PRIMARY KEY (`alarm_id`,`receive_time`), |
KEY `siteindex` (`site_code`), |
KEY `alarmtype` (`alarm_type`), |
KEY `receive_time` (`receive_time`), |
KEY `alarmasset` (`alarmasset_id`) |
) ENGINE=InnoDB DEFAULT CHARSET=latin1 MAX_ROWS=4294967295 AVG_ROW_LENGTH=50 |
/*!50100 PARTITION BY RANGE (year(receive_time))
|
(PARTITION p2013 VALUES LESS THAN (2013) ENGINE = InnoDB,
|
PARTITION p2014 VALUES LESS THAN (2014) ENGINE = InnoDB,
|
PARTITION p2015 VALUES LESS THAN (2015) ENGINE = InnoDB,
|
PARTITION p2016 VALUES LESS THAN (2016) ENGINE = InnoDB,
|
PARTITION p2017 VALUES LESS THAN (2017) ENGINE = InnoDB,
|
PARTITION p2018 VALUES LESS THAN (2018) ENGINE = InnoDB,
|
PARTITION p2019 VALUES LESS THAN (2019) ENGINE = InnoDB,
|
PARTITION p2020 VALUES LESS THAN (2020) ENGINE = InnoDB,
|
PARTITION p2021 VALUES LESS THAN (2021) ENGINE = InnoDB,
|
PARTITION p2022 VALUES LESS THAN (2022) ENGINE = InnoDB,
|
PARTITION p2023 VALUES LESS THAN (2023) ENGINE = InnoDB,
|
PARTITION p2024 VALUES LESS THAN (2024) ENGINE = InnoDB,
|
PARTITION p2025 VALUES LESS THAN (2025) ENGINE = InnoDB,
|
PARTITION p2026 VALUES LESS THAN (2026) ENGINE = InnoDB,
|
PARTITION p2027 VALUES LESS THAN (2027) ENGINE = InnoDB,
|
PARTITION p2028 VALUES LESS THAN (2028) ENGINE = InnoDB,
|
PARTITION p2029 VALUES LESS THAN (2029) ENGINE = InnoDB,
|
PARTITION p2030 VALUES LESS THAN (2030) ENGINE = InnoDB,
|
PARTITION pEOW VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */; |
I can repeat the crash, but only with when partitioning is disabled. Do you have skip-partitioning anywhere in my.ini ?
you are right, I put skip-partitioning in my.ini which follow our production environment. But using the data from testing environment for migration test and just found that which enabled partitioning.
Thanks for confirming. This will be fixed not to crash and instead report an error when opening such a table.
But you still won't be able to use a partitioned table with --skip-partitioning.
after comment out the --skip-partitioning from my.ini, the upgrade success and no error in consistent check using mariadb-check.exe. Thanks.
Thank you! Maybe you can also post alarming_alarm.frm from the subdirectory bureauv2alarms of the data directory?
This one seems to be responsible for the crash.