Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Nov 2016 01:26:01 +0100
From:      Bernard Spil <brnrd@FreeBSD.org>
To:        Miroslav Lachman <000.fbsd@quip.cz>
Cc:        FreeBSD Ports <ports@freebsd.org>
Subject:   Re: FreeBSD Port: databases/mariadb101-server / version 10.1.18 crashing
Message-ID:  <e4f2e3f663dc62138f3d3b1adf6db92b@FreeBSD.org>
In-Reply-To: <5823DCC2.7090305@quip.cz>
References:  <5823361A.4090200@quip.cz> <5823DCC2.7090305@quip.cz>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-11-10 3:34, Miroslav Lachman wrote:
> Miroslav Lachman wrote on 2016/11/09 15:43:
>> Please update port to 10.1.19. It includes critical fixes
>> https://jira.mariadb.org/browse/MDEV-10977
>> https://jira.mariadb.org/browse/MDEV-10394
>> 
>> We are getting following error on some machines too.
>> 
>> ERROR] InnoDB: Block in space_id 0 in file /var/db/mysql/ibdata1
>> encrypted. Miroslav Lachman
> 
> There is something terribly bad with MariaDB 10.1.18.
> 
> I upgraded next machine which was previously working fine for years
> but keep crashing after upgrade.
> 
> I strongly warn users before 10.1.18 version - if you have your
> databases created with some really old version and continously
> upgraded to 10.1, stay at 10.1.17 or expect unexpected crashes.
> 
> This is one of many errors from logfile:
> 
> InnoDB: Doing recovery: scanned up to log sequence number 36685500328
> 2016-11-10  3:13:59 34426872832 [Note] InnoDB: Starting an apply batch
> of log records to the database...
> InnoDB: Progress in percent: 30 31 32 33 34 35 36 37 38 39 40 41 42 43
> 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
> 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89
> 90 91 92 93 94 95 96 97 98 99
> InnoDB: Apply batch completed
> 2016-11-10  3:14:00 34426872832 [Note] InnoDB: 128 rollback segment(s)
> are active.
> 2016-11-10  3:14:00 34426872832 [Note] InnoDB: Waiting for purge to 
> start
> 2016-11-10  3:14:00 34426896384 [ERROR] InnoDB: Block in space_id 0 in
> file ./ibdata1 encrypted.
> 2016-11-10  3:14:00 34426896384 [ERROR] InnoDB: However key management
> plugin or used key_id 8 is not found or used encryption algorithm or
> method does not match.
> 2016-11-10  3:14:00 34426896384 [ERROR] InnoDB: Marking tablespace as
> missing. You may drop this table or install correct key management
> plugin and key file.
> 2016-11-10  3:14:00 34426896384 [ERROR] InnoDB: Block in space_id 0 in
> file ./ibdata1 encrypted.
> 2016-11-10  3:14:00 34426896384 [ERROR] InnoDB: However key management
> plugin or used key_id 8 is not found or used encryption algorithm or
> method does not match.
> 2016-11-10  3:14:00 34426896384 [ERROR] InnoDB: Marking tablespace as
> missing. You may drop this table or install correct key management
> plugin and key file.
> 161110  3:14:00 [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 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.1.18-MariaDB
> key_buffer_size=268435456
> read_buffer_size=2097152
> max_used_connections=0
> max_threads=152
> thread_count=0
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 5557219 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 0x48400
> 0xb0238e <my_print_stacktrace+0x2e> at /usr/local/libexec/mysqld
> 0x723631 <handle_fatal_signal+0x231> at /usr/local/libexec/mysqld
> 0x803211b4a <pthread_sigmask+0x51a> at /lib/libthr.so.3
> 0x80321122c <pthread_getspecific+0xe1c> at /lib/libthr.so.3
> 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.
> 161110 03:14:00 mysqld_safe mysqld from pid file /var/db/mysql/elsa.pid 
> ended
> 
> 
> 
> 
> It works fine after downgrade to 10.1.17
> 
> 161110 03:28:41 mysqld_safe Starting mysqld daemon with databases from
> /var/db/mysql
> 2016-11-10  3:28:41 34426872832 [Note] /usr/local/libexec/mysqld
> (mysqld 10.1.17-MariaDB) starting as process 75826 ...
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Using mutexes to ref
> count buffer pool pages
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: The InnoDB memory heap
> is disabled
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Mutexes and rw_locks
> use GCC atomic builtins
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: GCC builtin
> __atomic_thread_fence() is used for memory barrier
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Compressed tables use 
> zlib 1.2.8
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Using generic crc32 
> instructions
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Initializing buffer
> pool, size = 256.0M
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Completed
> initialization of buffer pool
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Highest supported file
> format is Barracuda.
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Log scan progressed
> past the checkpoint lsn 36685481501
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Database was not
> shutdown normally!
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Starting crash recovery.
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Reading tablespace
> information from the .ibd files...
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Restoring possible
> half-written data pages
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: from the doublewrite 
> buffer...
> InnoDB: Doing recovery: scanned up to log sequence number 36685500328
> 2016-11-10  3:28:41 34426872832 [Note] InnoDB: Starting an apply batch
> of log records to the database...
> InnoDB: Progress in percent: 30 31 32 33 34 35 36 37 38 39 40 41 42 43
> 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
> 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89
> 90 91 92 93 94 95 96 97 98 99
> InnoDB: Apply batch completed
> 2016-11-10  3:28:42 34426872832 [Note] InnoDB: 128 rollback segment(s)
> are active.
> 2016-11-10  3:28:42 34426872832 [Note] InnoDB: Waiting for purge to 
> start
> 2016-11-10  3:28:42 34426872832 [Note] InnoDB:  Percona XtraDB
> (http://www.percona.com) 5.6.31-77.0 started; log sequence number
> 36685500328
> 2016-11-10  3:28:42 34426899456 [Note] InnoDB: Dumping buffer pool(s)
> not yet started
> 2016-11-10  3:28:42 34426872832 [Note] Plugin 'FEEDBACK' is disabled.
> 2016-11-10  3:28:42 34426872832 [Note] Recovering after a crash using 
> tc.log
> 2016-11-10  3:28:42 34426872832 [Note] Starting crash recovery...
> 2016-11-10  3:28:42 34426872832 [Note] Crash recovery finished.
> 2016-11-10  3:28:42 34426872832 [Note] Server socket created on IP: 
> '::'.
> 2016-11-10  3:28:42 34426872832 [Note] /usr/local/libexec/mysqld:
> ready for connections.
> Version: '10.1.17-MariaDB'  socket: '/tmp/mysql.sock'  port: 3306 
> FreeBSD Ports
> 
> 
> 
> This is on FreeBSD 10.3-RELEASE-p12 amd64 GENERIC with MariaDB build
> in our Poudriere with following options
> 
> # pkg info -f mariadb101-server
> mariadb101-server-10.1.18_1
> Name           : mariadb101-server
> Version        : 10.1.18_1
> Installed on   : Wed Nov  9 01:19:47 2016 CET
> Origin         : databases/mariadb101-server
> Architecture   : freebsd:10:x86:64
> Prefix         : /usr/local
> Categories     : databases ipv6
> Licenses       : GPLv2
> Maintainer     : brnrd@FreeBSD.org
> WWW            : http://mariadb.org/
> Comment        : Multithreaded SQL database (server)
> Options        :
>         FASTMTX        : off
>         GSSAPI_BASE    : off
>         GSSAPI_HEIMDAL : off
>         GSSAPI_MIT     : off
>         GSSAPI_NONE    : on
>         INNOBASE       : on
>         MAXKEY         : on
>         MROONGA        : off
>         OQGRAPH        : off
>         SPHINX         : on
>         SPIDER         : on
>         TOKUDB         : off
> Shared Libs required:
>         libxml2.so.2
> Shared Libs provided:
>         libmysqld.so.18
> Annotations    :
>         cpe            : 
> cpe:2.3:a:mariadb:mariadb:10.1.18:::::freebsd10:x64:1
>         repo_type      : binary
>         repository     : codelab
> Flat size      : 169MiB
> 
> 
> Miroslav Lachman

Hi Miroslav,

Any specific reason you're using InnoBase not XtraDB? It should work but 
I don't think that many people are actually using it. It's disabled by 
default in MariaDB port as XtraDB is supposed to be better than 
InnoBase.

The default is XtraDB which is a drop-in replacement of InnoDB by 
Percona. Can you try the new version 10.1.19 in ports and switch 
InnoBase off?

Thanks for reporting!

Bernard.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e4f2e3f663dc62138f3d3b1adf6db92b>