[Bug 208109] databases/mariadb101-server with Galera crashes
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Fri Mar 18 00:44:32 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208109
Bug ID: 208109
Summary: databases/mariadb101-server with Galera crashes
Product: Ports & Packages
Version: Latest
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: Individual Port(s)
Assignee: brnrd at freebsd.org
Reporter: ganbold-freebsd at ateamsystems.com
Flags: maintainer-feedback?(brnrd at freebsd.org)
Assignee: brnrd at freebsd.org
Galera and Mariadb was installed from ports.
Mariadb-10.1.11 without Galera cluster works.
However with Galera it crashes:
160316 16:50:12 mysqld_safe Starting mysqld daemon with databases from
/var/db/mysql
160316 16:50:12 mysqld_safe WSREP: Running position recovery with
--log_error='/var/db/mysql/wsrep_recovery.pBHBpT'
--pid-file='/var/db/mysql/bsd2-recover.pid'
2016-03-16 16:50:12 34426872832 [Note] /usr/local/libexec/mysqld (mysqld
10.1.11-MariaDB) starting as process 60749 ...
160316 16:50:15 mysqld_safe WSREP: Recovered position
00000000-0000-0000-0000-000000000000:-1
2016-03-16 16:50:15 34426872832 [Note] /usr/local/libexec/mysqld (mysqld
10.1.11-MariaDB) starting as process 60762 ...
2016-03-16 16:50:15 34426872832 [Note] WSREP: Setting wsrep_ready to 0
2016-03-16 16:50:15 34426872832 [Note] WSREP: Read nil XID from storage
engines, skipping position init
2016-03-16 16:50:15 34426872832 [Note] WSREP: wsrep_load(): loading provider
library '/usr/local/lib/libgalera_smm.so'
2016-03-16 16:50:15 34426872832 [Note] WSREP: wsrep_load(): Galera 3.5(rXXXX)
by Codership Oy <info at codership.com> loaded successfully.
2016-03-16 16:50:15 34426872832 [Note] WSREP: CRC-32C: using hardware
acceleration.
2016-03-16 16:50:15 34426872832 [Note] WSREP: Found saved state:
00000000-0000-0000-0000-000000000000:-1
2016-03-16 16:50:15 34426872832 [Note] WSREP: Passing config to GCS: base_host
= 192.168.0.90; base_port = 4567; cert.log_conflicts = no; debug = no;
evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S;
evs.join_retrans_period = PT1S; evs.max_install_timeouts = 1; evs.send_window =
4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S;
evs.user_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir =
/var/db/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name =
/var/db/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 128M;
gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave =
no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit
= 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no;
gmcast.segment = 0; gmcast.version = 0; pc.announce_timeout = PT3S; pc.checksum
= false; pc.ignore_quorum = false; pc.ignore_sb = false; pc.npvo = false;
pc.version = 0; pc.wait_prim = true; pc.wait_prim_timeout = P30S; pc.weight =
1; protonet.
2016-03-16 16:50:15 34426875904 [Note] WSREP: Service thread queue flushed.
2016-03-16 16:50:15 34426872832 [Note] WSREP: Assign initial position for
certification: -1, protocol version: -1
2016-03-16 16:50:15 34426872832 [Note] WSREP: wsrep_sst_grab()
2016-03-16 16:50:15 34426872832 [Note] WSREP: Start replication
2016-03-16 16:50:15 34426872832 [Note] WSREP: 'wsrep-new-cluster' option used,
bootstrapping the cluster
2016-03-16 16:50:15 34426872832 [Note] WSREP: Setting initial position to
00000000-0000-0000-0000-000000000000:-1
2016-03-16 16:50:15 34426872832 [Note] WSREP: protonet asio version 0
2016-03-16 16:50:15 34426872832 [Note] WSREP: Using CRC-32C (optimized) for
message checksums.
2016-03-16 16:50:15 34426872832 [Note] WSREP: backend: asio
160316 16:50:15 [ERROR] mysqld got signal 6 ;
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.11-MariaDB
key_buffer_size=0
read_buffer_size=262144
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 52011 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 0x3c000
0xaf89de <my_print_stacktrace+0x2e> at /usr/local/libexec/mysqld
0x71fdbe <handle_fatal_signal+0x22e> at /usr/local/libexec/mysqld
0x8031fd95a <pthread_sigmask+0x4aa> at /lib/libthr.so.3
0x8031fd158 <pthread_getspecific+0xdd8> 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.
160316 16:50:15 mysqld_safe mysqld from pid file /var/db/mysql/bsd2.pid ended
my.cnf:
[client]
port = 3306
socket = /tmp/mysql.sock
[mysqld]
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
innodb_doublewrite=1
query_cache_size=0
query_cache_type=0
wsrep_on=ON
wsrep_provider=/usr/local/lib/libgalera_smm.so
wsrep_cluster_address='gcomm://'
wsrep_cluster_name='galera_cluster'
wsrep_node_name='node1'
wsrep_node_address="192.168.0.90"
wsrep_sst_method=rsync
wsrep_debug=1
wsrep_slave_threads=1
innodb_flush_log_at_trx_commit=0
FreeBSD version and ports:
FreeBSD bsd2 10.2-STABLE FreeBSD 10.2-STABLE #0 r287700: Fri Sep 18 19:06:30
ULAST 2015 tsgan at bsd2:/usr/obj/usr/stable/sys/GENERIC amd64
mariadb101-client-10.1.11 Multithreaded SQL database (client)
mariadb101-server-10.1.11 Multithreaded SQL database (server)
galera-25.3.5_2 Synchronous multi-master replication engine
See more at:
https://forums.freebsd.org/threads/53969/
Tried with stock FreeBSD 10.2-RELEASE, problem is the same.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-ports-bugs
mailing list