MySQL Cluster is a wsrep-patched MySQL distribution by Codership. Wsrep API developed by Codership Oy is a modern generic (database-agnostic) replication API for transactional databases with a goal to make database replication/logging subsystem completely modular and pluggable. It is developed with flexibility and completeness in mind to satisfy broad range of modern replication scenarios. It is equally suitable for synchronous and asynchronous, master-slave and multi-master replication. wsrep stands for Write Set REPlication. Wsrep patch for MySQL/InnoDB allows MySQL server to load and use various wsrep API implementations ("wsrep providers") with different qualities of service. Without wsrep provider MySQL-wsrep server will function like a regular standalone server. Source code can be found at wsrep API: https://launchpad.net/wsrep MySQL patch: https://launchpad.net/codership-mysql Compatible with databases/galera WWW: http://galeracluster.com/downloads/ Fix: Build log: https://redports.org/buildarchive/20140401042904-44009/ Patch attached with submission follows:
Responsible Changed From-To: freebsd-ports-bugs->nemysis nemysis@ wants this submitter's PRs (via the GNATS Auto Assign Tool)
Client: http://www.freebsd.org/cgi/query-pr.cgi?pr=188180
Responsible Changed From-To: nemysis->swills Not have time for these PR
I stumbled upon this while trying to get Percona-XtraDB-Cluster ported (also uses wsrep+galera). There are several plist issues, which are easy to fix. Also, I would like to suggest adding xtrabackup to default options, since this is the only non-blocking SST method. However, I couldn't get Percona to run with the databases/galera wsrep provider. I tried your patch (this port) and I also can't get it to run! The servers starts up and works fine without the provider, but provider exits with signal 11 after sprinkling some files: 141107 23:12:25 mysqld_safe WSREP: Recovered position 00000000-0000-0000-0000-000000000000:-1 2014-11-07 23:12:25 0 [Note] WSREP: wsrep_start_position var submitted: '00000000-0000-0000-0000-000000000000:-1' 2014-11-07 23:12:25 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2014-11-07 23:12:25 78763 [Note] WSREP: Read nil XID from storage engines, skipping position init 2014-11-07 23:12:25 78763 [Note] WSREP: wsrep_load(): loading provider library '/usr/local/lib/libgalera_smm.so' 2014-11-07 23:12:25 78763 [Note] WSREP: wsrep_load(): Galera 3.5(rXXXX) by Codership Oy <info@codership.com> loaded successfully. 2014-11-07 23:12:25 78763 [Note] WSREP: CRC-32C: using hardware acceleration. 2014-11-07 23:12:25 78763 [Warning] WSREP: Could not open saved state file for reading: /var/db/mysql//grastate.dat 2014-11-07 23:12:25 78763 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1 2014-11-07 23:12:25 78763 [Note] WSREP: Passing config to GCS: base_host = 10.10.0.1; 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.bac 2014-11-07 23:12:25 78763 [Note] WSREP: Service thread queue flushed. 2014-11-07 23:12:25 78763 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1 2014-11-07 23:12:25 78763 [Note] WSREP: wsrep_sst_grab() 2014-11-07 23:12:25 78763 [Note] WSREP: Start replication 2014-11-07 23:12:25 78763 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1 2014-11-07 23:12:25 78763 [Note] WSREP: protonet asio version 0 2014-11-07 23:12:25 78763 [Note] WSREP: Using CRC-32C (optimized) for message checksums. 2014-11-07 23:12:25 78763 [Note] WSREP: backend: asio 2014-11-07 23:12:25 78763 [Note] WSREP: GMCast version 0 2014-11-07 23:12:25 78763 [Note] WSREP: (72136400-66fd-11e4-aed9-a3b0ce02ba7a, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567 2014-11-07 23:12:25 78763 [Note] WSREP: (72136400-66fd-11e4-aed9-a3b0ce02ba7a, 'tcp://0.0.0.0:4567') multicast: , ttl: 1 2014-11-07 23:12:25 78763 [Note] WSREP: EVS version 0 2014-11-07 23:12:25 78763 [Note] WSREP: PC version 0 2014-11-07 23:12:25 78763 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '' 04:12:25 UTC - 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. 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.
I can also reproduce it with running both the mysql56-galera-client and mysql56-galera-server installed together from your PRs. Ohh, well, at least here is a rerolled bsd.databases.mk patch...
Created attachment 149177 [details] rerolled bsd.databases.mk patch chase MariaDB 10.0 addition
Reentered lost comments: I'm using the MariaDB version of the patch right now, rebuilding using gcc worked, no more segfaults. I'm trying to setup a cluster right now, but it seems like the SST scripts haven't been patched, so state transfer fails (rsync needs lsof, which isn't installed by default and doesn't work inside of jails, xtrabackup uses ss and gnu tar etc.). [reply] [−] Comment 10 Nikolai Lifanov 2015-01-09 21:00:47 UTC With Galera clustering, xtrabackup-v2 is probably the only reasonable SST method: it's lockless for InnoDB and much faster than anything else. You might get away with having socat, and I thought it uses xbstream (it's own format) + qpress? [reply] [−] Comment 11 Nikolai Lifanov 2015-01-09 21:03:32 UTC I will have a moment to look at SST scripts and fix as needed in a few hours. [reply] [−] Comment 12 Michael Gmelin 2015-01-09 21:36:10 UTC I tried this: wsrep_sst_method=xtrabackup-v2 [sst] streamfmt=xbstream When starting a new cluster, syncing the first node works, adding an additional node hangs (I saw the same with a patched version of rsync though). Various server processes keep hanging (stray socat processes, mysql-server claiming it's not running, even though there are mysqld processes etc.). I have virtually no experience running galera, so this could just be my fault.
Sorry, Bugzilla was broken and that's where the patches are. I'll try it again today. As for Galera semantics, you are not supposed to have mysql service up while the SST or IST are in progress. The Unix domain socket is created and the TCP port is open only after the cluster code verifies that the data is in sync.
FYI: I'll have time to resume work on this in the next few days.
I'd very much appreciate your efforts and am happy to volunteer for testing. I'm desperately looking for a *SQL cluster solution that works on FreeBSD.
Looking forward to your results, thanks for your effort! (I assume you'll also cover on mariadb10-galera ports?).
ping!