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

Randomly destroyed tables after migration to 10.6.4 (also under 10.6.5)



    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Duplicate
    • 10.6.4
    • 10.5.13, 10.6.5



      two weeks ago or so, I updated from OpenBSD 6.9 (MariaDB 10.5.9) to OpenBSD 7.0 (MariaDB 10.6.4). Since then nearly every day one of my tables breaks. Every time it is a different/random table and random database. If I "dump", "select", or "check" that table then the MariaDB server leaves this plane of existence for some time before coming back to life. This can happen to tables that were create before or after the update. Also I noticed that only chunks of the table are damaged. If I "select" stuff before or after the broken segment of the table, then I can still get the data.

      First I thought that something is wrong with the official OpenBSD package or some libs are not the same as in the official OpenBSD build. Thus I just compiled 10.6.5 on that server from source.

      cogniumweb# mysql_upgrade -u root -p
      Enter password:
      Phase 1/7: Checking and upgrading mysql database
      Processing databases
      mysql.column_stats OK
      Phase 2/7: Installing used storage engines... Skipped
      Phase 3/7: Fixing views
      Phase 4/7: Running 'mysql_fix_privilege_tables'
      Phase 5/7: Fixing table and database names
      Phase 6/7: Checking and upgrading tables
      Processing databases
      ntcognium.oc_file_locks OK
      ntcognium.oc_filecache OK
      ntcognium.oc_filecache_extended OK
      ntcognium.oc_files_trash OK
      Phase 7/7: Running 'FLUSH PRIVILEGES'

      cogniumweb# mysqlcheck -A -u root -p
      ntcognium.oc_federated_reshares OK
      ntcognium.oc_file_locks OK
      mysqlcheck: Got error: 2013: Lost connection to server during query when executing 'CHECK TABLE ... '

      I dropped that table and then recreated it via
      CREATE TABLE `oc_filecache` (
      `fileid` bigint(20) NOT NULL AUTO_INCREMENT,
      `storage` bigint(20) NOT NULL DEFAULT 0,
      `path` varchar(4000) COLLATE utf8mb4_bin DEFAULT NULL,
      `path_hash` varchar(32) COLLATE utf8mb4_bin NOT NULL DEFAULT '',
      `parent` bigint(20) NOT NULL DEFAULT 0,
      `name` varchar(250) COLLATE utf8mb4_bin DEFAULT NULL,
      `mimetype` bigint(20) NOT NULL DEFAULT 0,
      `mimepart` bigint(20) NOT NULL DEFAULT 0,
      `size` bigint(20) NOT NULL DEFAULT 0,
      `mtime` bigint(20) NOT NULL DEFAULT 0,
      `storage_mtime` bigint(20) NOT NULL DEFAULT 0,
      `encrypted` int(11) NOT NULL DEFAULT 0,
      `unencrypted_size` bigint(20) NOT NULL DEFAULT 0,
      `etag` varchar(40) COLLATE utf8mb4_bin DEFAULT NULL,
      `permissions` int(11) DEFAULT 0,
      `checksum` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
      PRIMARY KEY (`fileid`),
      UNIQUE KEY `fs_storage_path_hash` (`storage`,`path_hash`),
      KEY `fs_parent_name_hash` (`parent`,`name`),
      KEY `fs_storage_mimetype` (`storage`,`mimetype`),
      KEY `fs_storage_mimepart` (`storage`,`mimepart`),
      KEY `fs_storage_size` (`storage`,`size`,`fileid`),
      KEY `fs_id_storage_size` (`fileid`,`storage`,`size`),
      KEY `fs_mtime` (`mtime`),
      KEY `fs_size` (`size`),
      KEY `fs_storage_path_prefix` (`storage`,`path`(64))

      And now the system is happy again but tomorrow I expect it to kill the next table...
      It happened to nextcloud databases as well as drupal databases.

      I am a bit out of ideas what to do... Help? Please!

      best wishes


        1. err
          8 kB
        2. my.cnf
          0.9 kB

        Issue Links



              marko Marko Mäkelä
              davrot David Rotermund
              0 Vote for this issue
              3 Start watching this issue



                Git Integration

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