Bug 259795 - databases/galera26: cannot initialize new cluster
Summary: databases/galera26: cannot initialize new cluster
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-12 11:12 UTC by Lapo Luchini
Modified: 2021-12-17 08:29 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (devel)


Attachments
complete error log (8.52 KB, text/plain)
2021-11-12 11:12 UTC, Lapo Luchini
no flags Details
Galera Cluster Full log (9.69 KB, text/plain)
2021-12-07 10:06 UTC, Albert Valbuena
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lapo Luchini 2021-11-12 11:12:01 UTC
Created attachment 229446 [details]
complete error log

I have a strange problem: I cannot initialize a new (MAriaDB 10.5) Galera cluster, doing the same things that I did a few months ago to set-up a similar cluster.

# cp /usr/local/etc/mysql/conf.d/wsrep.cnf.sample /usr/local/etc/mysql/conf.d/wsrep.cnf
# nano /usr/local/etc/mysql/conf.d/wsrep.cnf

and I only changed: wsrep_provider, wsrep_cluster_name, wsrep_cluster_address, wsrep_sst_method, wsrep_sst_auth.

I get this error:

2021-11-12 12:08:37 0 [ERROR] WSREP: exception from gcomm, backend must be restarted: failed to set FD_CLOEXEC: 9 (Bad file descriptor)
         at /wrkdirs/usr/ports/databases/galera26/work/galera-release_26.4.9/galerautils/src/gu_asio_socket_util.hpp:set_fd_options():41

Moreover, at the end I get this unexpected behavior that it cannot be stopped but there is some lingering process:

# service mysql-server onestop
mysql not running? (check /var/run/mysql/mysqld.pid).
# pgrep maria
73240
57197

Is this a known bug?
Is there a way to debug which socket is not accepting FD_CLOEXEC?
(maybe with truss? but the rc.d startup is a bit complex)
Comment 1 Albert Valbuena 2021-12-07 10:04:46 UTC
I'm experiencing the same issue.

Current config in /etc/rc.conf

mysql_enable="YES"
mysql_args="--wsrep-new-cluster"
mysql_optfile="/usr/local/etc/mysql/my.cnf"

Current config at /usr/local/etc/mysql/my.cnf

[albert@Cluster1 ~]$ cat /usr/local/etc/mysql/my.cnf
#
# This group is read both by the client and the server
# use it for options that affect everything, see
# https://mariadb.com/kb/en/configuring-mariadb-with-option-files/#option-groups
#
[client-server]
port    = 3306
socket  = /var/run/mysql/mysql.sock

#
# include *.cnf from the config directory
#
!includedir /usr/local/etc/mysql/conf.d/
[albert@Cluster1 ~]$

Current config at /usr/local/etc/mysl/conf.d/wsrep.cnf

[albert@Cluster1 /usr/local/etc/mysql/conf.d]$ cat wsrep.cnf
# This file contains wsrep-related mysqld options. It should be included
# in the main MySQL configuration file.
#
# Options that need to be customized:
#  - wsrep_provider
#  - wsrep_cluster_address
#  - wsrep_sst_auth
# The rest of defaults should work out of the box.

##
## mysqld options _MANDATORY_ for correct opration of the cluster
##
[mysqld]

# (This must be substituted by wsrep_format)
binlog_format=ROW

# Currently only InnoDB storage engine is supported
default-storage-engine=innodb

# to avoid issues with 'bulk mode inserts' using autoinc
innodb_autoinc_lock_mode=2

# Override bind-address
# In some systems bind-address defaults to 127.0.0.1, and with mysqldump SST
# it will have (most likely) disastrous consequences on donor node
bind-address=0.0.0.0

##
## WSREP options
##

# Enable wsrep
wsrep_on=1

# Full path to wsrep provider library or 'none'
wsrep_provider=/usr/local/lib/libgalera_smm.so

# Provider specific configuration options
#wsrep_provider_options=

# Logical cluster name. Should be the same for all nodes.
wsrep_cluster_name="test_cluster"

# Group communication system handle
wsrep_cluster_address="gcomm://192.168.1.73,192.168.1.79,192.168.1.80"

# Human-readable node name (non-unique). Hostname by default.
wsrep_node_name=Cluster1

# Base replication <address|hostname>[:port] of the node.
# The values supplied will be used as defaults for state transfer receiving,
# listening ports and so on. Default: address of the first network interface.
wsrep_node_address=192.168.1.73

# Address for incoming client connections. Autodetect by default.
#wsrep_node_incoming_address=

# How many threads will process writesets from other nodes
wsrep_slave_threads=1

# DBUG options for wsrep provider
#wsrep_dbug_option

# Generate fake primary keys for non-PK tables (required for multi-master
# and parallel applying operation)
wsrep_certify_nonPK=1

# Maximum number of rows in write set
wsrep_max_ws_rows=0

# Maximum size of write set
wsrep_max_ws_size=2147483647

# to enable debug level logging, set this to 1
wsrep_debug=0

# convert locking sessions into transactions
wsrep_convert_LOCK_to_trx=0

# how many times to retry deadlocked autocommits
wsrep_retry_autocommit=1

# change auto_increment_increment and auto_increment_offset automatically
wsrep_auto_increment_control=1

# retry autoinc insert, which failed for duplicate key error
wsrep_drupal_282555_workaround=0

# enable "strictly synchronous" semantics for read operations
wsrep_causal_reads=0

# Command to call when node status or cluster membership changes.
# Will be passed all or some of the following options:
# --status  - new status of this node
# --uuid    - UUID of the cluster
# --primary - whether the component is primary or not ("yes"/"no")
# --members - comma-separated list of members
# --index   - index of this node in the list
wsrep_notify_cmd=

##
## WSREP State Transfer options
##

# State Snapshot Transfer method
wsrep_sst_method=rsync

# Address which donor should send State Snapshot to.
# Should be the address of THIS node. DON'T SET IT TO DONOR ADDRESS!!!
# (SST method dependent. Defaults to the first IP of the first interface)
#wsrep_sst_receive_address=

# SST authentication string. This will be used to send SST to joining nodes.
# Depends on SST method. For mysqldump method it is root:<root password>
wsrep_sst_auth=root:

# Desired SST donor name.
#wsrep_sst_donor=

# Reject client queries when donating SST (false)
#wsrep_sst_donor_rejects_queries=0

# Protocol version to use
# wsrep_protocol_version=
[albert@Cluster1 /usr/local/etc/mysql/conf.d]$

The mysql-server status output is the service isn't running.

[albert@Cluster1 /usr/local/etc/mysql/conf.d]$ sudo service mysql-server status
mysql is not running.
[albert@Cluster1 /usr/local/etc/mysql/conf.d]$

However, there are two mysql processes running. But yes, MariaDB is unsuable.

[albert@Cluster1 /usr/local/etc/mysql/conf.d]$ ps aux | grep mysql
mysql  2625   0.0  0.2  13628  3168  -  Is   00:15    0:00.01 /bin/sh /usr/local/bin/mariadbd-safe --defaults-extra-file=/usr/local/etc/mysql/my.cnf --user=mysql --datadir=/var/db/mysql --
mysql  2922   0.0  2.4 215076 49064  -  I    00:15    0:00.05 /usr/local/libexec/mariadbd --defaults-extra-file=/usr/local/etc/mysql/my.cnf --basedir=/usr/local --datadir=/var/db/mysql --p
albert 2944   0.0  0.0    432   244  1  R+   00:16    0:00.00 grep mysql
[albert@Cluster1 /usr/local/etc/mysql/conf.d]$
Comment 2 Albert Valbuena 2021-12-07 10:06:31 UTC
Created attachment 229954 [details]
Galera Cluster Full log
Comment 3 Lapo Luchini 2021-12-17 08:29:14 UTC
In the meanwhile I tried with MariaDB 10.3 and cluster creation went smoothly (with identical configuration). Seems to be a regression.