Date: Fri, 18 Mar 2016 00:44:32 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 208109] databases/mariadb101-server with Galera crashes Message-ID: <bug-208109-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208109 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@freebsd.org Reporter: ganbold-freebsd@ateamsystems.com Flags: maintainer-feedback?(brnrd@freebsd.org) Assignee: brnrd@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=3D'/var/db/mysql/wsrep_recovery.pBHBpT' --pid-file=3D'/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(rXXX= X) by Codership Oy <info@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_h= ost =3D 192.168.0.90; base_port =3D 4567; cert.log_conflicts =3D no; debug =3D = no; evs.inactive_check_period =3D PT0.5S; evs.inactive_timeout =3D PT15S; evs.join_retrans_period =3D PT1S; evs.max_install_timeouts =3D 1; evs.send_= window =3D 4; evs.stats_report_period =3D PT1M; evs.suspect_timeout =3D PT5S; evs.user_send_window =3D 2; evs.view_forget_timeout =3D PT24H; gcache.dir = =3D /var/db/mysql/; gcache.keep_pages_size =3D 0; gcache.mem_size =3D 0; gcache= .name =3D /var/db/mysql//galera.cache; gcache.page_size =3D 128M; gcache.size =3D 128= M; gcs.fc_debug =3D 0; gcs.fc_factor =3D 1.0; gcs.fc_limit =3D 16; gcs.fc_mast= er_slave =3D no; gcs.max_packet_size =3D 64500; gcs.max_throttle =3D 0.25; gcs.recv_q_ha= rd_limit =3D 9223372036854775807; gcs.recv_q_soft_limit =3D 0.25; gcs.sync_donor =3D= no; gmcast.segment =3D 0; gmcast.version =3D 0; pc.announce_timeout =3D PT3S; p= c.checksum =3D false; pc.ignore_quorum =3D false; pc.ignore_sb =3D false; pc.npvo =3D = false; pc.version =3D 0; pc.wait_prim =3D true; pc.wait_prim_timeout =3D P30S; pc.= weight =3D 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 us= ed, 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=3D0 read_buffer_size=3D262144 max_used_connections=3D0 max_threads=3D153 thread_count=3D0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =3D 520= 11 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 =3D 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 end= ed my.cnf: [client] port =3D 3306 socket =3D /tmp/mysql.sock [mysqld] binlog_format=3DROW default_storage_engine=3DInnoDB innodb_autoinc_lock_mode=3D2 bind-address=3D0.0.0.0 innodb_doublewrite=3D1 query_cache_size=3D0 query_cache_type=3D0 wsrep_on=3DON wsrep_provider=3D/usr/local/lib/libgalera_smm.so wsrep_cluster_address=3D'gcomm://' wsrep_cluster_name=3D'galera_cluster' wsrep_node_name=3D'node1' wsrep_node_address=3D"192.168.0.90"=20 wsrep_sst_method=3Drsync wsrep_debug=3D1 wsrep_slave_threads=3D1 innodb_flush_log_at_trx_commit=3D0 FreeBSD version and ports: FreeBSD bsd2 10.2-STABLE FreeBSD 10.2-STABLE #0 r287700: Fri Sep 18 19:06:30 ULAST 2015 tsgan@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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-208109-13>