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
Details
Details
- Reviewers
lifanov mmokhi matthew feld mat - Group Reviewers
O5: Ports Framework (Owns No Changed Paths) portmgr - Commits
- rP434624: add databases/mysqlwsrep56-server
poudriere testport - OK
portlint -A - as good as other MySQL ports
Diff Detail
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 7162 Build 7332: arc lint + arc unit
Event Timeline
There are a very large number of changes, so older changes are hidden. Show Older Changes
Comment Actions
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.
Comment Actions
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.
| Mk/bsd.default-versions.mk | ||
|---|---|---|
| 57 | This line is getting worse at each adition. It should either be sorted by:
But here, a w crept between two p. | |
Comment Actions
- 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.
Comment Actions
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. | |
Comment Actions
remove what seems to be an unnecessary nasty hack:
GCC ports already install the right thing to libdata/ldconfig
Comment Actions
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 D9427Looks like mysql56-server has been updated since this differential was prepared.
Comment Actions
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. | |
| 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 |
Is such alignment needed on local FreeBSD? | |
| 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. | |
Comment Actions
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.
Comment Actions
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.
Comment Actions
tl;dr: "bootstrap" is a different thing from "start" and running a bootstrap if start fails leads to confusion and data loss
Comment Actions
Maybe it's a bit late to say, but, anyone checked databases/galera ?
Isn't it related to our work?
Comment Actions
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.
Comment Actions
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" :)
Comment Actions
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.
| 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* | |
Comment Actions
I'm adding swills to review. I would like to move this forward, but I don't have any feedback from portmgr folk :)
| databases/mysqlwsrep56-server/Makefile | ||
|---|---|---|
| 33 | Any reason to not use MY_DBDIR any more ? | |
Comment Actions
As I pointed before, seems fine for me (From MySQL points of view).
except that MY_DBDIR part ;-)
Comment Actions
Unlike original MySQL 5.6 port, MY_DBDIR would be dereferenced exactly once.
I can add it back in if this is preferable.
Comment Actions
- add and use MY_DBDIR to reduce diff with other MySQL ports
- collapse share/mysql/wsrep_notify in plist and sort