[MDEV-35079] Migrate MySQL5.7 to MariaDB 10.4, then to MariaDB 10.11 Failed - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.11
Fix Version/s: 10.11.10, 11.2.6, 11.4.4, 11.6.2
Component/s: Upgrades
Labels:
None
Environment:
Windows OS + MySQL5.7 migrate to MariaDB 10.11

Description

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

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

alarming_alarm.frm
9 kB
2024-10-04 15:54
cdb_stacktrace_all_threads.txt
42 kB
2024-10-04 17:13
mysqld.dmp
81 kB
2024-10-04 15:03

Activity

Ascending order - Click to sort in descending order

Edwin Chan created issue - 2024-10-04 15:04

Vladislav Vaintroub added a comment - 2024-10-04 15:40

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.

Vladislav Vaintroub added a comment - 2024-10-04 15:40 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.

Edwin Chan made changes - 2024-10-04 15:54

Field	Original Value	New Value
Attachment		alarming_alarm.frm [ 74101 ]

Edwin Chan added a comment - 2024-10-04 15:57

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

Edwin Chan added a comment - 2024-10-04 15:57 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

Edwin Chan added a comment - 2024-10-04 16:03 - edited

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) */;

Edwin Chan added a comment - 2024-10-04 16:03 - edited 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) */ ;

Sergei Golubchik made changes - 2024-10-04 16:13

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.

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
{noformat}
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
{noformat}

From the upgrade log, got below message
{noformat}
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
{noformat}
Attached mysqld.dmp for reference.

Vladislav Vaintroub made changes - 2024-10-04 17:13

Attachment

cdb_stacktrace_all_threads.txt [ 74102 ]

Sergei Golubchik added a comment - 2024-10-04 19:35

I can repeat the crash, but only with when partitioning is disabled. Do you have skip-partitioning anywhere in my.ini ?

Sergei Golubchik added a comment - 2024-10-04 19:35 I can repeat the crash, but only with when partitioning is disabled. Do you have skip-partitioning anywhere in my.ini ?

Sergei Golubchik made changes - 2024-10-04 19:35

Status

Open [ 1 ]

Needs Feedback [ 10501 ]

Edwin Chan added a comment - 2024-10-07 09:35

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.

Edwin Chan added a comment - 2024-10-07 09:35 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.

Sergei Golubchik added a comment - 2024-10-07 10:09

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.

Sergei Golubchik added a comment - 2024-10-07 10:09 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.

Sergei Golubchik made changes - 2024-10-07 10:09

Status

Needs Feedback [ 10501 ]

Open [ 1 ]