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)

    XMLWordPrintable

Details

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

    Description

      Hi,

      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
      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'
      OK

      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))
      ) ENGINE=InnoDB AUTO_INCREMENT=1009 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=COMPRESSED;

      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
      David

      Attachments

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

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              davrot David Rotermund
              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.