Page MenuHomeFreeBSD

add databases/mysqlwsrep56-server
ClosedPublic

Authored by lifanov on Feb 3 2017, 3:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, May 23, 10:03 PM
Unknown Object (File)
Tue, May 21, 9:51 AM
Unknown Object (File)
Thu, May 16, 9:42 PM
Unknown Object (File)
May 14 2024, 9:41 AM
Unknown Object (File)
May 12 2024, 7:30 AM
Unknown Object (File)
May 7 2024, 7:01 PM
Unknown Object (File)
May 4 2024, 2:37 PM
Unknown Object (File)
May 4 2024, 2:37 PM

Details

Summary
add databases/mysqlwsrep56-server

- MySQL version enabled for Galera Replication

 PR: 214807
 Submitted by: Philip Stoev <philip.stoev@galeracluster.com>
 Reviewed by: matthew, mat, mmokhi
 Approved by: portmgr (mat)
 Differential Revision: https://reviews.freebsd.org/D9427
Test Plan

poudriere testport - OK
portlint -A - as good as other MySQL ports

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 7253
Build 7422: arc lint + arc unit

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

It is possible to make it a slave, but we will need to override port version, master site, distfile name, etc.
I would like to do this if this is ever available as a separate patchset, but there is little value in doing so at this point.

FWIW, Percona also distributes pre-patched tarballs, so I think it's reasonable to treat it the same and a server in its own right at this point.

It is possible to make it a slave, but we will need to override port version, master site, distfile name, etc.
I would like to do this if this is ever available as a separate patchset, but there is little value in doing so at this point.

FWIW, Percona also distributes pre-patched tarballs, so I think it's reasonable to treat it the same and a server in its own right at this point.

Given that creating a separate port for each mysql variant seems to be the established practice,
I withdraw my suggestion about slave ports. (But compare the mysql / mariadb / percona ports to the postgresql ports.)

As this is mostly a copy, the port should be created by 'svn cp mysql56-server mysqlwrep56-server' and overwriting with these files, so that there is a connected version history.

lifanov edited edge metadata.

address matthew's feedback:

preserve ancestry where possible

Mk/bsd.default-versions.mk
57

This line is getting worse at each adition. It should either be sorted by:

  • version-brand
  • brand-version

But here, a w crept between two p.

databases/mysqlwsrep56-server/Makefile
67–68

This part is always-false, cause AFAIK this is a server-only port.
But keep it if galeracluster has client/slave port too.

databases/mysqlwsrep56-server/files/mysql-server.in
56

Why not moving it to bootstrap or precmd part?

lifanov edited edge metadata.

address mat's comment:

insert 5.6w addition in brand-version order

lifanov edited edge metadata.
  • remove last vestige of slave support
  • address mokhi64@gmail.com's comments: remove useless client support

It's nonsensical to have a separate client port for this
since WSREP is a server feature.

Okay, For me only 2 points left.
1- My comments on rc-script and cmake.
2- CONFLICTS part (which needs the naming before it)
The rest seems okay for me.

databases/mysqlwsrep56-server/Makefile
23

I'd suggest cmake:outsource, though the cmake itself is fine too.

databases/mysqlwsrep56-server/files/mysql-server.in
56

Is this even necessary? I'll ask the submitter.

lifanov edited edge metadata.
  • update pkg-descr
  • switch to cmake:outsource
lifanov edited edge metadata.

remove what seems to be an unnecessary nasty hack:

GCC ports already install the right thing to libdata/ldconfig

mmokhi edited edge metadata.

Okay, seems fine for me.
Thanks.

I'm getting a patch failure on databases/mysqlwsrep56-server/Makefile when I try and do:

% cd ${PORTSDIR}/databases
% svn cp mysql56-server mysqlwsrep56-server 
% arc patch D9427

Looks like mysql56-server has been updated since this differential was prepared.

After fixing the patch so that it would apply (by updating the PORTREVISION setting in the source), I find
that test building on 10.3-RELEASE succeeds but on 11.0-RELEASE it fails due to problems with during configuration:

-- Check size of wint_t - done
-- EDITLINE_INCLUDE_DIR /usr/include/edit/readline
-- EDITLINE_LIBRARY /usr/lib/libedit.so
-- Performing Test EDITLINE_HAVE_HIST_ENTRY
-- Performing Test EDITLINE_HAVE_HIST_ENTRY - Success
-- Performing Test EDITLINE_HAVE_COMPLETION
-- Performing Test EDITLINE_HAVE_COMPLETION - Failed
CMake Error at cmake/readline.cmake:206 (MESSAGE):
  Cannot find system editline libraries.
Call Stack (most recent call first):
  CMakeLists.txt:428 (MYSQL_CHECK_EDITLINE)


-- Configuring incomplete, errors occurred!
See also "/wrkdirs/usr/ports/databases/mysqlwsrep56-server/work/.build/CMakeFiles/CMakeOutput.log".
See also "/wrkdirs/usr/ports/databases/mysqlwsrep56-server/work/.build/CMakeFiles/CMakeError.log".
*** Error code 1

Stop.
make: stopped in /usr/ports/databases/mysqlwsrep56-server
build of databases/mysqlwsrep56-server ended at Sun Feb  5 14:41:35 GMT 2017
build time: 00:01:42
!!! build failure encountered !!!
databases/mysqlwsrep56-server/Makefile
23

Ah, sorry.
I almost forgot to say,
USES=libedit is needed when we use -DWITH_EDITLINE=system

mmokhi requested changes to this revision.Feb 5 2017, 4:37 PM
mmokhi edited edge metadata.
This revision now requires changes to proceed.Feb 5 2017, 4:37 PM
lifanov edited edge metadata.
lifanov marked 2 inline comments as done.

address feedback: putting USES=libedit back fixed this on 11.0 for me

philip.stoev_galeracluster.com added inline comments.
databases/mysqlwsrep56-server/files/mysql-server.in
56

A separate "bootstrap" command is introduced in order to align the FreeBSD script with the equivalent scripts on Linux. Not sure if this answers your question.

databases/mysqlwsrep56-server/files/mysql-server.in
56

A separate "bootstrap" command is introduced in order to align the FreeBSD script with the equivalent scripts on Linux. Not sure if this answers your question.

Is such alignment needed on local FreeBSD?
It's a personal opinion, but I believe keeping thing simple/local on Port Tree is better :-)

databases/mysqlwsrep56-server/files/mysql-server.in
56

Having the "bootstrap" options makes all the blog posts and documentation from Linux land applicable to FreeBSD, hopefully making adoption easier. Furthermore, a derivative Galera product such as Percona XtraDB Cluster includes this option.

databases/mysqlwsrep56-server/files/mysql-server.in
56

I see, Makes sense.
Just was a personal opinion.
For sure, If keeping bootstrap makes it "easier" I'll encourage to keep it.

In Galera land, a node can do one of two things when starting up: join a cluster (start) or create a cluster (bootstrap).
So, you can't bootstrap a node before starting it. If you bootstrap a node automatically if a start times out, you ensure confusion and data loss.

When a node starts, it starts in a desynced state and looks at a variable which is a combination of endpoints to download cluster state from. The first node to start up doesn't have anywhere authoritative to download the cluster state, so bootstrap instructs it to ignore this step and create a new cluster with just itself as a member.

Historically, this was done by setting wsrep_cluster_address to an empty string, but then the bootstrap command was implemented so that a user doesn't have to change configuration in my.cnf during this.

tl;dr: "bootstrap" is a different thing from "start" and running a bootstrap if start fails leads to confusion and data loss

Maybe it's a bit late to say, but, anyone checked databases/galera ?
Isn't it related to our work?

The WSREP patch enables pluggable replication engine replacements. Galera is one implementation of such an engine.
After this lands, the next step is to update databases/galera to the latest.

The WSREP patch enables pluggable replication engine replacements. Galera is one implementation of such an engine.
After this lands, the next step is to update databases/galera to the latest.

I didn't told my meaning quite good, Sorry about that.
I simply meant "maybe we can turn that port into slave of this one" :)

They don't really share code. They come from different tarballs, etc.
One is a shared library that gets loaded into the other but both have independent releases and updates.

They don't really share code. They come from different tarballs, etc.
One is a shared library that gets loaded into the other but both have independent releases and updates.

Aah! I see 🙂 .
Thanks for explanations 😉🙏 .

databases/mysqlwsrep56-server/Makefile
6

These patches still don't apply cleanly to an up-to-date tree. In particular PORTREVISION here should be *4*

lifanov edited edge metadata.

address matthew's feedback: reroll patch to chase ancestor update

lifanov edited edge metadata.

... and move patches back to "make makepatch"-compliant layout

matthew edited edge metadata.

lgtm. Still needs approval from portmgr for the infrastructure bits though.

lifanov added a subscriber: swills.

I'm adding swills to review. I would like to move this forward, but I don't have any feedback from portmgr folk :)

mat added a reviewer: mat.
mat added inline comments.
databases/mysqlwsrep56-server/Makefile
33

Any reason to not use MY_DBDIR any more ?

mmokhi edited edge metadata.

As I pointed before, seems fine for me (From MySQL points of view).
except that MY_DBDIR part ;-)

This revision is now accepted and ready to land.Feb 21 2017, 3:02 PM

Unlike original MySQL 5.6 port, MY_DBDIR would be dereferenced exactly once.
I can add it back in if this is preferable.

I'll add it back for the sake of similarity with other MySQL ports.

lifanov edited edge metadata.
  • add and use MY_DBDIR to reduce diff with other MySQL ports
  • collapse share/mysql/wsrep_notify in plist and sort
This revision now requires review to proceed.Feb 21 2017, 3:30 PM
lifanov edited edge metadata.
mmokhi edited edge metadata.

Thanks :-)

Macro lgtm:

This revision is now accepted and ready to land.Feb 21 2017, 5:11 PM
This revision was automatically updated to reflect the committed changes.