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 : br...@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.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
