Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-35079

Migrate MySQL5.7 to MariaDB 10.4, then to MariaDB 10.11 Failed

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.11
    • 10.11.10, 11.2.6, 11.4.4, 11.6.2
    • Upgrades
    • None
    • Windows OS + MySQL5.7 migrate to MariaDB 10.11

    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

          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.

          wlad Vladislav Vaintroub added a comment - 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 Edwin Chan added a comment -

          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 Edwin Chan added a comment - 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 Edwin Chan added a comment - - 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 Edwin Chan added a comment - - 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) */ ;

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

          serg Sergei Golubchik added a comment - I can repeat the crash, but only with when partitioning is disabled. Do you have skip-partitioning anywhere in my.ini ?
          Edwin.Chan Edwin Chan added a comment -

          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 Edwin Chan added a comment - 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.

          serg Sergei Golubchik added a comment - 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.
          Edwin.Chan Edwin Chan added a comment -

          after comment out the --skip-partitioning from my.ini, the upgrade success and no error in consistent check using mariadb-check.exe. Thanks.

          Edwin.Chan Edwin Chan added a comment - after comment out the --skip-partitioning from my.ini, the upgrade success and no error in consistent check using mariadb-check.exe. Thanks.

          People

            serg Sergei Golubchik
            Edwin.Chan Edwin Chan
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.