Installing MariaDB 10.1.8 on FreeBSD 10.2

BlindPenguin

BlindPenguin

Hi,

iI've played around with the new release of MariaDB and managed to compile and launch it. Here is what iI did so far:

At first install the Galera lib from ports. This should also build most dependencies which are needed to build MariaDB. Then download source code from here (click).

After extracting it you need to change a #include variable in the source code, so it can be compiled.

vi mariadb-10.1.8/include/mysql/service_encryption.h

Search for this:
Code: 
#include <alloca.h>
Replace with
Code: 
#include <stdlib.h>
Then use cmake to compile it:
cmake -DWITHOUT_MROONGA=1 .

I was unable to compile it with mroonga activated. Apparently some incompatibilities with the "try" stuff in the source code. Maybe someone else knows how to compile it. In my case iI didn't need it, so it didn't really matter.

make
make install

Should work just fine now.

If it's done, you can configure it at /usr/local/mysql/ according to your needs. However, iI stumbled upon some problems. The user "mysql" must have write permission to this directory. my.cnf on the other side shouldn't be writeable, otherwise it will be ignored automatically.

This is the configuration iI got to run:
Code: 
[mysqld]
user=mysql
wsrep_on=ON
wsrep_provider=/usr/local/lib/libgalera_smm.so
wsrep_cluster_address=gcomm://
wsrep_node_name=“awesome.domain.com“
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_doublewrite=1

Don't forget to initialize the database with the mysql_install_db script. You need to be at /usr/local/mysql/ to run it without problems.

So far it seems to be able to run now. The rsync service doesn't work properly, so you need to do some changes in one file: /usr/local/mysql/wsrep_sst_rsync. Modify the path of bash and change the "export PATH" to /usr/local/bin and /usr/local/sbin. Then it should start.

Start mysql on the "master" server with:
service mysql.server start bootstrap

Every additional Node can be started without "bootstrap". So far it seems to work pretty well, but iI still have problems with the second node and the synchronisation. According to netstat there is no connection to port 4444 (rsync), although rsync seems to run on the node. On the master it doesn't run. I've opened all ports (iI know, that's evil, but it's a testing environment anyway), but it still doesn't work.

According to systat -ifstat 1 the system seems to send and receive something, but only with 0.3 kb/s. I think it's trying to get a proper connection, but it seems to fail without error message and loops at this state. I let it run for hours and nothing happened. If iI created table on one node, it wasn't sent to the other one.

Actually iI'm not a FreeBSD guy. I'm using Arch Linux at home, so please be nice. :D

Did anyone manage to get it running properly on BSD or do you have any ideas what could possibly go wrong with communication?
 
Sadly no luck yet. Had to fiddle around with the settings, until the server found all the configuration files. The port seems to be a little bit shaky. If someone knows what those error messages want to tell me, your suggestions would be welcome. :D I'll also talk with the porting guy because of the outcome of mysql_install_db. This script only works if you are in /usr/local, but there it will throw all the stuff right into the same folder. Then you'll have pathes like /usr/local/data and so on. This feels just weird.

Code: 
2015-11-25  2:38:24 34426872832 [Note] WSREP: wsrep_sst_grab()
2015-11-25  2:38:24 34426872832 [Note] WSREP: Start replication
2015-11-25  2:38:24 34426872832 [Note] WSREP: 'wsrep-new-cluster' option used, bootstrapping the cluster
2015-11-25  2:38:24 34426872832 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1
2015-11-25  2:38:24 34426872832 [Note] WSREP: protonet asio version 0
2015-11-25  2:38:24 34426872832 [Note] WSREP: Using CRC-32C (optimized) for message checksums.
2015-11-25  2:38:24 34426872832 [Note] WSREP: backend: asio
151125  2:38:24 [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.8-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 = 52005 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
0xaeff7e <my_print_stacktrace+0x2e> at /usr/local/libexec/mysqld
0x71a84e <handle_fatal_signal+0x22e> at /usr/local/libexec/mysqld
0x8031d39aa <pthread_sigmask+0x4aa> at /lib/libthr.so.3
0x8031d31a8 <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.
151125 02:38:24 mysqld_safe mysqld from pid file /usr/db/mysql/cluster-1.pid ended

Configuration via my.cnf:
Code: 
[client]
port        = 3306
socket        = /tmp/mysql.sock


[mysqld]
port        = 3306
socket        = /tmp/mysql.sock
skip-external-locking
key_buffer_size = 16K
max_allowed_packet = 1M
table_open_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 240K
user=mysql
wsrep_on=ON
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
wsrep_provider=/usr/local/lib/libgalera_smm.so
wsrep_cluster_address=gcomm://
wsrep_cluster_name="awesome.cluster"
wsrep_certify_nonPK=1
wsrep_max_ws_rows=131072
wsrep_max_ws_size=1073741824
wsrep_debug=1

server-id    = 1

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size = 8M
sort_buffer_size = 8M

[mysqlhotcopy]
interactive-timeout

Without Galera it works just fine. So far it's pretty good.
 
To give an update after long time fiddling around: I got it running with the new official port. At least both nodes are running and are able to find each other. Therefore I needed to add the LD_LIBRARY_PATH into the mysqld_safe file. I tried it outside, but it didn't work. So that's the only way to get it running.

Code: 
/usr/local/bin/mysqld_safe
export LD_LIBRARY_PATH=/usr/local/lib/gcc48

As I was told, that's not the cleanest thing to do, but it just works. Communications however doesn't work. There seems to be something wrong.
 
Hello BlindPenguin,

Do you have any news about this?

I had tried this about 1 year ago and I'm trying it now as I see ports being updated.

However I ended up exactly where you did - nodes join the cluster, but can't communicate. One of 2 nodes is always desynced but the 2 nods always report Primary status.

Please let me know if you have succeeded with this one.

Thank you
 
BlindPenguin said:
Code: 
/usr/local/bin/mysqld_safe
export LD_LIBRARY_PATH=/usr/local/lib/gcc48
As I was told, that's not the cleanest thing to do, but it just works. Communications however doesn't work. There seems to be something wrong.
Click to expand...
That's very strange. That LD_LIBARY_PATH is only when you've built with gcc. This means that you'd have to have build all ports with gcc to make that reliable.

Any update from your side? We also have MariaDB 10.2 now in ports.
I've just been checking on the 10.2 port to see if it builds with WSREP support and it does. According to https://mariadb.com/kb/en/mariadb/getting-started-with-mariadb-galera-cluster/ you have to configure `-DWITH_WSREP=ON -DWITH_INNODB_DISALLOW_WRITES=1`. With or without these additional parameters, the result in CMakeCache.txt is that both are ON so the default port should be built with Galera Cluster support.

Cheers, Bernard Spil (maintainer of the MariaDB ports in FreeBSD)
 
You must log in or register to reply here.
Back
Top