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

apt-get upgrade to 10.1.9 fails on Debian

Details

    Description

      I am dead in the water. Downgrade attempts are failing

      (I show install command instead of upgrade command because I have uninstalled / reinstalled with identical failure.)

      # apt-get install mariadb-server
      Reading package lists... Done
      Building dependency tree
      Reading state information... Done
      The following packages were automatically installed and are no longer required:
        libphp5-embed mysql-common-5.6
      Use 'apt-get autoremove' to remove them.
      The following extra packages will be installed:
        libdbd-mysql-perl libmariadbclient18 libmysqlclient18 mariadb-client-10.1 mariadb-client-core-10.1 mariadb-common
        mariadb-server-10.1 mariadb-server-core-10.1
      Suggested packages:
        mariadb-test netcat-openbsd socat tinyca
      The following NEW packages will be installed:
        libdbd-mysql-perl libmariadbclient18 libmysqlclient18 mariadb-client-10.1 mariadb-client-core-10.1 mariadb-common mariadb-server
        mariadb-server-10.1 mariadb-server-core-10.1
      0 upgraded, 9 newly installed, 0 to remove and 1 not upgraded.
      Need to get 0 B/37.7 MB of archives.
      After this operation, 132 MB of additional disk space will be used.
      Do you want to continue [Y/n]?
      Preconfiguring packages ...
      Selecting previously unselected package mariadb-common.
      (Reading database ... 59260 files and directories currently installed.)
      Unpacking mariadb-common (from .../mariadb-common_10.1.9+maria-1~wheezy_all.deb) ...
      Selecting previously unselected package libmariadbclient18.
      Unpacking libmariadbclient18 (from .../libmariadbclient18_10.1.9+maria-1~wheezy_amd64.deb) ...
      Selecting previously unselected package libmysqlclient18.
      Unpacking libmysqlclient18 (from .../libmysqlclient18_10.1.9+maria-1~wheezy_amd64.deb) ...
      Selecting previously unselected package libdbd-mysql-perl.
      Unpacking libdbd-mysql-perl (from .../libdbd-mysql-perl_4.021-1+b1_amd64.deb) ...
      Selecting previously unselected package mariadb-client-core-10.1.
      Unpacking mariadb-client-core-10.1 (from .../mariadb-client-core-10.1_10.1.9+maria-1~wheezy_amd64.deb) ...
      Selecting previously unselected package mariadb-client-10.1.
      Unpacking mariadb-client-10.1 (from .../mariadb-client-10.1_10.1.9+maria-1~wheezy_amd64.deb) ...
      Selecting previously unselected package mariadb-server-core-10.1.
      Unpacking mariadb-server-core-10.1 (from .../mariadb-server-core-10.1_10.1.9+maria-1~wheezy_amd64.deb) ...
      Processing triggers for man-db ...
      Setting up mariadb-common (10.1.9+maria-1~wheezy) ...
      Selecting previously unselected package mariadb-server-10.1.
      (Reading database ... 59430 files and directories currently installed.)
      Unpacking mariadb-server-10.1 (from .../mariadb-server-10.1_10.1.9+maria-1~wheezy_amd64.deb) ...
      Stopping MariaDB database server: mysqld.
      Selecting previously unselected package mariadb-server.
      Unpacking mariadb-server (from .../mariadb-server_10.1.9+maria-1~wheezy_all.deb) ...
      Processing triggers for man-db ...
      Setting up libmysqlclient18 (10.1.9+maria-1~wheezy) ...
      Setting up libdbd-mysql-perl (4.021-1+b1) ...
      Setting up libmariadbclient18 (10.1.9+maria-1~wheezy) ...
      Setting up mariadb-client-core-10.1 (10.1.9+maria-1~wheezy) ...
      Setting up mariadb-client-10.1 (10.1.9+maria-1~wheezy) ...
      Setting up mariadb-server-core-10.1 (10.1.9+maria-1~wheezy) ...
      Setting up mariadb-server-10.1 (10.1.9+maria-1~wheezy) ...
      Stopping MariaDB database server: mysqld.
      /var/lib/dpkg/info/mariadb-server-10.1.postinst: line 241: deb-systemd-helper: command not found
      Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
      invoke-rc.d: initscript mysql, action "start" failed.
      dpkg: error processing mariadb-server-10.1 (--configure):
       subprocess installed post-installation script returned error exit status 1
      dpkg: dependency problems prevent configuration of mariadb-server:
       mariadb-server depends on mariadb-server-10.1 (= 10.1.9+maria-1~wheezy); however:
        Package mariadb-server-10.1 is not configured yet.
       
      dpkg: error processing mariadb-server (--configure):
       dependency problems - leaving unconfigured
      Errors were encountered while processing:
       mariadb-server-10.1
       mariadb-server   
      E: Sub-process /usr/bin/dpkg returned an error code (1)

      ====

      2015-12-12 18:37:43 140389541214048 [Note] mysqld (mysqld 10.1.9-MariaDB-1~wheezy-log) starting as process 8650 ...
      2015-12-12 18:37:43 140389541214048 [Note] Using unique option prefix 'myisam_recover' is error-prone and can break in the future. Please use the full name 'myisam-recover-options' instead.
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Using mutexes to ref count buffer pool pages
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: The InnoDB memory heap is disabled
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Memory barrier is not used
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Compressed tables use zlib 1.2.7
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Using Linux native AIO
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Using CPU crc32 instructions
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Initializing buffer pool, size = 256.0M
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Completed initialization of buffer pool
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Highest supported file format is Barracuda.
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Log scan progressed past the checkpoint lsn 536517802
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Database was not shutdown normally!
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Starting crash recovery.
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Reading tablespace information from the .ibd files...
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Restoring possible half-written data pages 
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: from the doublewrite buffer...
      InnoDB: Doing recovery: scanned up to log sequence number 536517812
      InnoDB: Last MySQL binlog file position 0 215898, file name /var/log/mysql/mariadb-bin.000493
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: 128 rollback segment(s) are active.
      2015-12-12 18:37:43 140389541214048 [Note] InnoDB: Waiting for purge to start
      151212 18:37:43 [ERROR] mysqld got signal 11 ;
      This could be because you hit a bug. It is also possible that this binary
      or one of the libraries it was linked against is corrupt, improperly built,
      or misconfigured. This error can also be caused by malfunctioning hardware.
       
      To report this bug, see http://kb.askmonty.org/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.1.9-MariaDB-1~wheezy-log
      key_buffer_size=134217728
      read_buffer_size=2097152
      max_used_connections=0
      max_threads=102
      thread_count=0
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 759822 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
       
      Thread pointer: 0x0x0
      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...
      stack_bottom = 0x0 thread_stack 0x48000
      addr2line: 'mysqld': No such file
      mysqld(my_print_stacktrace+0x2b)[0x7faefd64c1ab]
      mysqld(handle_fatal_signal+0x475)[0x7faefd1ad1e5]
      /lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x7faefc7a60a0]
      mysqld(+0x85e5b7)[0x7faefd4335b7]
      mysqld(+0x82da7f)[0x7faefd402a7f]
      mysqld(+0x7f3f6f)[0x7faefd3c8f6f]
      mysqld(+0x85ba71)[0x7faefd430a71]
      mysqld(+0x84957d)[0x7faefd41e57d]
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x7faefc79db50]
      /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7faefac6895d]
      The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
      information that should help you find out what is causing the crash.

      Attachments

        Issue Links

          Activity

            danorton Daniel Norton added a comment -

            I have isolated the crash trigger to a single InnoDB database. Is there some way I can validate or otherwise diagnose the files, directly?

            danorton Daniel Norton added a comment - I have isolated the crash trigger to a single InnoDB database. Is there some way I can validate or otherwise diagnose the files, directly?
            danorton Daniel Norton added a comment -

            I managed to isolate the tables that were triggering the crash. Fortunately, they were cache tables and I simply replaced them with empty tables. So, I'm up and running, but the nasty bug is still lurking.

            danorton Daniel Norton added a comment - I managed to isolate the tables that were triggering the crash. Fortunately, they were cache tables and I simply replaced them with empty tables. So, I'm up and running, but the nasty bug is still lurking.

            Based on stack dump this is MDEV-9177, MariaDB 10.1.0-10.1.8 had a bug that was fixed 10.1.9, unfortunately the bug was such that if you did migrate to earlier 10.1 version, you will be affected. Migrating from older MariaDB version e.g. to MariaDB 10.1.8 corrupted the database, even now that bug is fixed older 10.1 databases do not work.

            jplindst Jan Lindström (Inactive) added a comment - Based on stack dump this is MDEV-9177 , MariaDB 10.1.0-10.1.8 had a bug that was fixed 10.1.9, unfortunately the bug was such that if you did migrate to earlier 10.1 version, you will be affected. Migrating from older MariaDB version e.g. to MariaDB 10.1.8 corrupted the database, even now that bug is fixed older 10.1 databases do not work.
            danorton Daniel Norton added a comment -

            Perhaps this is MDEV 9177, but it doesn't seem resolved, as there are two bugs:

            1. The bug that corrupts the database
            2. The bug that crashes the entire server.

            Part 1 might have been fixed, but part 2 definitely persists in 10.1.11. It seems to me that a proper fix to #2 is to not crash the server. At worst, it might simply not open the offending database, but the other databases should remain fully operational.

            danorton Daniel Norton added a comment - Perhaps this is MDEV 9177, but it doesn't seem resolved, as there are two bugs: The bug that corrupts the database The bug that crashes the entire server. Part 1 might have been fixed, but part 2 definitely persists in 10.1.11. It seems to me that a proper fix to #2 is to not crash the server. At worst, it might simply not open the offending database, but the other databases should remain fully operational.

            My first questions is did you upgrade from earlier MariaDB/MySQL version, or did you create tables on < MariaDB 10.1.9 version ? If you did, your database is corrupted. Problem is that if database is corrupted, there is not much you can do, InnoDB traditionally has selected the crash option, not continue with what you got option. Continue with you got option has problem that further modifications to database could lead database more corrupted and inconsistent state. That is the reason InnoDB has selected stop option, naturally it could do it more controlled way (instead of assert and core), but shutdown normally also makes modifications to the persistent database (maybe messing things more up), so that is also hard.

            jplindst Jan Lindström (Inactive) added a comment - My first questions is did you upgrade from earlier MariaDB/MySQL version, or did you create tables on < MariaDB 10.1.9 version ? If you did, your database is corrupted. Problem is that if database is corrupted, there is not much you can do, InnoDB traditionally has selected the crash option, not continue with what you got option. Continue with you got option has problem that further modifications to database could lead database more corrupted and inconsistent state. That is the reason InnoDB has selected stop option, naturally it could do it more controlled way (instead of assert and core), but shutdown normally also makes modifications to the persistent database (maybe messing things more up), so that is also hard.

            People

              jplindst Jan Lindström (Inactive)
              danorton Daniel Norton
              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.