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

    XMLWordPrintable

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

          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.