OpenBSD Journal

MySQL 4.0.15 binaries available for -current

Contributed by Dengue on from the now-supporting dept.

Jedi/Sector One writes : "Starting with version 4.0.15, MySQL provides official binaries for OpenBSD. They have successfully passed all MySQL regression tests (even with InnoDB) on our beloved platform. Binaries for OpenBSD 3.4 (-current from 2 days ago) are available from http://www.mysql.com/downloads/mysql-4.0.html

Warning: these binaries don't follow the ports(7) rules, they are packaged like on other operating systems.

Please give them a try!"

(Comments are closed)


Comments
  1. By butthead () on

    Anyone have any experience with this vs. Postgre?

    Comments
    1. By djm () on

      Standard response: MySQL is fast (especially for simple queries on tables that are read more than written to), PostgreSQL is a more complete SQL implementation that handles concurrent read/write traffic better.

      MySQL has run the portable OpenSSH bugzilla on OpenBSD for a couple of years without any problem whatsoever, but I'd switch to Postgres as soon as bugzilla supports it (so I don't have to run two DB daemons).

    2. By chill () on

      There seems to be a bit more 3rd party stuff for MySQL than for Postgres. People have integrated it a bit more into things like Postfix and other apps.

      Postgres is BSD licensed (http://www.postgres.org/licence.html), MySQL is GPL if your app is GPL or you never modify/redistribute any code. If not, you must get a commercial license.
      http://www.mysql.com/products/licensing.html

      Postgres seems to be a bit more ANSI SQL compliant. It also has a nice set of GIS extensions if you do a lot geographic/mapping stuff.

      Comments
      1. By Jedi/Sector One () j@pureftpd.org on http://www.skymobile.com/

        MySQL also has nice GIS extensions, but in the 4.1.x tree.

    3. By Anonymous Coward () on

      You can't compare them! Postgres is a real RDBMS. Mysql is a bunch of text files with lines drawn between them :)

      Now, this isn't to say that MySQL doesn't have it's uses. It's good for simple apps with simple queries. IMO, your database should be picked based on its merit rather than how well it's supported on your platform. Of course, if you can't justify moving to a platform that supports the database you need, then you're database needs are really simple, and MySQL will work.

      BTW, Postgres support under OpenBSD is great. MySQL support is getting there, apparently.

      Comments
      1. By gk () on http://gk.se/~gk

        The MySQL 4.x is much, much better than the 3.x-line . And with the 5.x line you will then have triggers, stored procedures, subselects, transactions , replication and so on.

        So I just wanted to say that MySQL has started to earn a better reputation though I agree that postgresql is on another level functionality-wise and licence-wise.


    4. By Martin Foster () martin@ethereal-realms.org on http://www.erealms.org

      Having recently moved my site from MySql to PostgreSQL, I can honestly say that comparing the two is nearly impossible as they don't cater to the same crowds. As a result, I can only provide my views on the two based on experience.

      MySQL is a joy to work with for rapid development and/or if you have little time to play with the nitty gritty of the DBMS in order to get going. Essentially, it's more of a install fire and forget style of program.

      The documentation is great, there are examples of how to configure your database beyond the basic needs and the command line utils are straight forward. All of this allows someone new to databases, the opportunity to get their feet wet or just have something run.

      Client site tools are far ahead of anything that PostgresSQL has available for free. Even the default MySQL tools are available for Windows and Unix, giving you the opportunity to work on your database without forking money to do so no matter where you are.


      PostgreSQL has advanced features that you will not find in MySQL, which in turn will allow for a reduced code base. The use of sub-queries when absolutely necessary can cut down client site processing quiet a bit but draw more resources from the server. Functions and stored proceedures can also automate many of the tasks, and referential integrity alone will cut down on a lot of script site complexity.

      The crux of PostgreSQL, I believe is related to a complete lack of tangible documentation to make use of. The documentation available on their page does little but give you a dictionary description of certain features while not providing you any real life examples to draw from. This makes configuring the database itself some sort of black magic, unless you find third party documentation that will help. Here's a link:

      http://www.varlena.com/GeneralBits/Tidbits/perf.html

      The use of Postgres is also more complex as it will generally require the Kernel to be compiled with higher values in order to support more then 64 connections, or add in more buffer space for read and writes. This to a new user, is far from obvious and makes it harder to deploy when the formula is hard from being one-to-one.

      The database also requires you to maintain it. Unlike MySQL which pretty much runs itself until the ends of time, Postgres will not remove rows when they are deleted from the database. This will increase overall speed, but sooner or later you will need to VACUUM the database in order to maintain it.

      If you don't VACUUM often enough, you will have to do a less agreeable variant of it that locks the database. However, mix this with transactions and the use of a persistent database connection, then you may cause a complete halt to your site for a while waiting for Postgres to sort itself out. So steps need to be taken to boot everyone off before it begins.

      You also can't forget to occasionally re-index, because indexes are handled the same as rows and need to be cleaned to speed things up.


      Would I go back to MySQL? Honestly no, but that is because I invested the time and effort needed to port the system over to Postgres and now that it's stable it's mostly as good or better then MySQL. At times it can be slower and at times faster.

      The code base and maintenance alone will save me more time then the migration took. Not to mention that a 15% cut in scripting code required to run the same site is not something to look down upon.

      Would I recommend Postgres for a new user? Honestly no, as it will do nothing by cause frustration overall for them unless they are very advanced from the start.

  2. By mirabile () mirabile@bsdcow.net on http://MirBSD.BSDadvocacy.org/

    If they really would like the OpenBSD people to
    look at their software, they'd at least create a
    package to install. I assume GNU/Linux users get
    RPM or DEB, and not simple .tgz either.

    And they would give away the source for said
    package, i.e. the port, so the maintainer can
    have a look at that, too.

    Just my 0.02 EUR

    Comments
    1. By chill () on

      If they really would like the OpenBSD people to
      look at their software, they'd at least create a
      package to install. I assume GNU/Linux users get
      RPM or DEB, and not simple .tgz either.

      And they would give away the source for said
      package, i.e. the port, so the maintainer can
      have a look at that, too.


      The binary files are distributed in .tar.gz and .rpm for Linux, and .tar.gz for everything else except Windows and Novell where it is .zip. Last I checked .tar.gz is the same as .tgz.

      It is GPL software, so the source is all there. There is only one source, not specific versions for each binary they distribute. It is available in .tar.gz, .srpm and .zip for Windows people.

      I'm not sure what OpenBSD-specific config files/flags are in the source -- it is still downloading.

      Comments
      1. By Jedi/Sector One () j@pureftpd.org on http://www.pureftpd.org/

        There were no special flag used to compile this on OpenBSD, except -Wbounded that has no incidence on the final code.

    2. By Anonymous Coward () on

      What's the exchange rate to U$?

  3. By kko () on http://sanchezalderete.net

    I'm so excited about this, and not in a good way. Gosh darn it, I really need a girlfriend....

  4. By MeAStoopidNewbie () richard-burns@shaw.ca on mailto:richard-burns@shaw.ca

    I am an openBSD newbie, but long time unix user who bought 3.4 on cd as step 1.
    Install of the os went great, setting up ssl, sendmail went ok.

    Then i had the misfortune to read about the mysql binaries for mysql 4.whatever on this board. So I went and installed the mysql 4.whatever using the mysql binary instructions. Which in themselves were fine until I couldn't start the daemon.

    So this led to a bit of googling for pages that provided some intersection of the worlds of openBSD and mysql. There are lots.

    Somewhere along the way I became aware that the CD had an older but very likely to work just fine via pkg_add version. After the problems I had been having I decided "get what works, working first" and decided to use the cd version.

    The problem with this path to openBSd/mysql enlightenment is that pkg_add installs assuming a user of "_mysql" all the mysql binary ( AND RELATED DOCS ) install assumes a user of "mysql" (note absence of lead underscore).

    Add to the mix the chroot ing of apache, and the need for the ln of the /var/mysql/mysql.sock on /var/www/yadda/yadda and this can rapidly become a nightmare of privileges confusion.

    As a heads up to any one reliving this, let me just say that in rc.local you do want
    "--user=_mysql"
    despite the advice of
    "--user=mysql"
    that abounds in the mysql.org and numerous other web pages, assuming you go the pkg_add route. I hope this saves some time wasting by others.

    Also the "chgrp -R mysql.mysql /var/mysql" and similar instructions need similar caution ("chgrp -R _mysql._mysql /var/mysql" happens by default in the pkg_add as the permissions come from the pkg).

    In retrospect, the original 4.whatever mysql install probably went off the rails on me because of ignorance about the need to relocate the mysql.sock reference in my.cnf, and the link that was needed down the /var/www tree. However to learn about that you need to actually do a
    pkg-add deployment of the code (and use refs like
    http://nomoa.com/bsd/mysql.htm which is wrong about "mysql" v "_mysql")

    There is one other painful gotcha, the /etc/my.cnf installed by mysql 4.whatever is not compatible with the one from the package in openBSD. ("invalid options" in the hostname.err file is your first clue.) You can find a good one to use in the share/mysql/my-small.cnf (also are "medium" and "large" variants) file if you untar and unzip the package locally, rename, and cp to /etc/.

    As my final 2 cents, the "rtfm" advice that seems to permeate the openbsd pages on the web, can only be bad for openBSD if it wants to thrive.

    OpenBSD does do things differently (for very good reasons), but in so doing the community needs some elasticity in its tolerance and attitude of those walking into it this space new.



Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]