I suggest to simple add mariadb-galera into same version ebuilds (now - 5.5.29) as USE flag. Next attaching working ebuild patch. Reproducible: Always
Created attachment 346222 [details, diff] mariadb-galera-useflag.patch IMHO this way is most minimalistic. But, fast check looks like patchlevel is near 5.5.30 (unsure).
dev-db/mariadb-galera was added to the mysql overlay.
The mariadb-galera package seems to work, I was able to install it on my system without any problems. But to run a Galera Cluster, the Galera Replicator is mandatory. I created an ebuild (dev-libs/galera), which installs the Galera Replicator and the Galera Arbitrator, if the "garb" useflag is activated. Could you please add this ebuild to the mysql overlay and to the offical portage later on?
Created attachment 351178 [details] galera-23.2.4.ebuild
Created attachment 351180 [details] metadata.xml
Created attachment 351182 [details, diff] galera-23.2.4-unused-result-error.patch
Created attachment 351184 [details] garbd.confd
Created attachment 351186 [details] garbd.initd
sys-cluster/galera was added to the overlay a few days ago. Thanks for the contribution. There may be some improvements to be made from your ebuild as a reference.
Thanks for your answer, didn't see that it was in the overlay already. The ebuild it self looks good to me, I just think that my rewritten version of the init script is a little bit better than the original one. It is smaller and gentoo specific. Right now, the init script is the only thing which prevents me from using the ebuild from the overlay. What do you think about that?
*** Bug 476868 has been marked as a duplicate of this bug. ***
Please give me a feedback about my rewritten version of the init script. It would be great to use this version instead of the original one. Please add it to the overlay.
(In reply to Thomas Oettli from comment #12) > Please give me a feedback about my rewritten version of the init script. > It would be great to use this version instead of the original one. > Please add it to the overlay. I don't see major differences that would keep the one in the overlay from working. Can you please explain why yours is better?
(In reply to Brian Evans from comment #13) > (In reply to Thomas Oettli from comment #12) > > Please give me a feedback about my rewritten version of the init script. > > It would be great to use this version instead of the original one. > > Please add it to the overlay. > > I don't see major differences that would keep the one in the overlay from > working. > Can you please explain why yours is better? The difference is that my start script runs the daemon with the user/group garb. This daemon really doesn't need root privileges. Of course, the user/group garb should be created by the ebuild. Further, my init script handles the nodes specified in GALERA_NODES perfectly, there are no visible error messages from netcat (e.g. if there are only hostnames specified in GALERA_NODES (no ports), or if all nodes are offline). And at last, if I start the daemon with my init script, rc-status shows it as running and not as crashed. I improved my version of the init script so the location of the pidfile is configurable, I will upload it immediately. Today, I changed to the galera ebuild from the overlay and found a small issue in the ebuild. The following to lines are not correct: newconfd "${FILESDIR}/garbd.cnf" garbd newinitd "${FILESDIR}/garbd.sh" garbd The problem is that the files in the files directory are called garb.cnf and garb.sh instead of garbd.cnf and garbd.sh ;-) I hope that we will be able to get the best possible result if we combine your work and mine.
Created attachment 356592 [details] garbd.confd
Created attachment 356594 [details] garbd.initd
Changes posted in the overlay as a revbump. Please test.
(In reply to Brian Evans from comment #17) > Changes posted in the overlay as a revbump. > > Please test. Tested the new versions of the ebuild and the init script, everything looks fine for me. Thanks alot ;-)
just want to make it simple, I'm not a gentoo developer, but the galera support is already done in mysql-v2.eclass, then in ebuild, I think it might be simple to do this: add a galera use flag, if galera is set, then change the PN to mariadb-galera. then eclass will take care everything. please check /usr/portage/eclass/mysql-v2.eclass, it also have the support for percona-server. But I really don't understand why these feature already exists in eclass but not in ebuild.
(In reply to Steve Yin from comment #19) > just want to make it simple, I'm not a gentoo developer, but the galera > support is already done in mysql-v2.eclass, > > then in ebuild, I think it might be simple to do this: add a galera use > flag, if galera is set, then change the PN to mariadb-galera. then eclass > will take care everything. > > please check /usr/portage/eclass/mysql-v2.eclass, it also have the support > for percona-server. > > But I really don't understand why these feature already exists in eclass but > not in ebuild. The ebuilds exist in the official mysql overlay. The team is wondering how popular the galera option is to include it in the tree or leave it in the overlay for now.
Well, including in tree would lessen my workload for sure :) so here's one interested party. But overall, I'm not sure how to determine the popularity.
well, I don't think this should be determined by the popularity.. As the only open-sources multi-master replication solution for mysql/mariadb, it should be the standard feature provided by portage, as for postgresql, we have pgpool to do that. I think this is a must have feature. and should not be determined by the needs of popularity.
(In reply to Steve Yin from comment #22) > well, I don't think this should be determined by the popularity.. As the > only open-sources multi-master replication solution for mysql/mariadb, it > should be the standard feature provided by portage, as for postgresql, we > have pgpool to do that. > > I think this is a must have feature. and should not be determined by the > needs of popularity. I totally agree with you. It should be the standard in portage, because it's the only solution to cluster mariadb. Personally, I use a MariaDB-Galera-Cluster on my private servers and on some productive systems in my company.
>The team is wondering how popular the galera option is to include it > in the tree or leave it in the overlay for now. +1 vote for it being in the tree
How come the dev-db/mariadb-galera-5.5.35 ebuild still doesn't install a systemd unit?
Sometimes it takes writing a silly comment to remember dev-db/mysql-init-scripts
Is there a forthcoming bump of mariadb-galera to 10.0.{7,10} in the MySQL overlay?
(In reply to Robin Kauffman from comment #27) > Is there a forthcoming bump of mariadb-galera to 10.0.{7,10} in the MySQL > overlay? http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=commit;h=cceab9b8e72b1a23e76e812406b3210c3fe19f88 done
dev-db/mariadb-galera and sys-cluster/galera are now in the main tree
(In reply to Brian Evans from comment #29) > dev-db/mariadb-galera and sys-cluster/galera are now in the main tree Thank you Brian. Why do we have a distinction between dev-db/mariadb-galera and dev-db/mariadb ? Why not a USE flag ?
(In reply to Bertrand Jacquin from comment #30) > (In reply to Brian Evans from comment #29) > > dev-db/mariadb-galera and sys-cluster/galera are now in the main tree > > Thank you Brian. Why do we have a distinction between dev-db/mariadb-galera > and dev-db/mariadb ? Why not a USE flag ? 1) They have different release schedules. That is difficult if not impossible to manage with a USE flag. 2) sys-cluster/galera is not proven to work on all architectures that MariaDB does. The author only accounts for amd64, x86 and ppc64 (and SunOS) in the build system. Therefore, the keywords are different. While this could be managed, the first reason is the major one.
(In reply to Bertrand Jacquin from comment #30) > (In reply to Brian Evans from comment #29) > > dev-db/mariadb-galera and sys-cluster/galera are now in the main tree > > Thank you Brian. Why do we have a distinction between dev-db/mariadb-galera > and dev-db/mariadb ? Why not a USE flag ? different upstream sources, it's not simply a flag on base mariadb.