I'm having a problem with a MySQL UDF function (mychem.sourceforge.net) that's dependent on a large library (openbabel.org) which is in turn plugin based. The problem is that the format plugins to openbabel doesn't seem to load in MySQL 5.1 and I suspect it might be due to the plugin_dir setting. I have set plugin_dir to /usr/lib/ which is the location for both libmychem.so and libopenbabel.so as well as the directory openbabel that contains the format plugins. Is there a way to turn off the plugin_dir restriction in MySQL (preferably without compiling MySQL from sources) so that I can test this hypothesis or do you have a different idea on what might cause the problem?
All this is done on Ubuntu 10.04 (but I had the same kind of problems on 8.04, where I managed to get it working after a lot of steps that I unfortunately have forgotten...)
I have turned off apparmor during testing and it doesn't help either.
I kind of solved my problem, so here is kind of an answer to my question. It all boils down to problems with apparmour, at least for me. The problem was that I couldn't turn off the apparmor, doing so seems to leave MySQL in full-enforce mode or something. If I had apparmor in complain mode, it worked fine, and I could also modify the apparmor profile so to not complain about the specific directories (i.e. the OpenBabel shared directory).
/Fredrik
Related
I'm using HeidiSQL to edit a MYSQL database, and it's asking which library I want to use for the edits:
libmysql-6.1.dll
libmysql.dll
How do I know which one to use?
These alternative libmysql*.dll and libmariadb*.dll libraries are there to solve (SSL) connectivity issues on newer MySQL and MariaDB servers. For example on MySQL 5.7, some users reported the following error with the older libmysql.dll:
ASN: bad other signature confirmation
Using libmariadb.dll may cause another error:
Unknown SSL error (0x80090308)
Especially when you provide a SSL certificate, you may run into such issues.
For this and any other connectivity issue, HeidiSQL provides alternative libraries the user can try. Apart from that, I never heard of any other advantage or disadvantage of one or another of these libraries.
While the question of which library to use for MariaDB seems pretty obvious (libmariadb.dll), what to make of the other two?
As a clue, I looked a the file properties.
libmysql.dll shows ProductVersion 5.6.6.0
libmysql-6.1.dll shows ProductVersion 6.1.11.0
Given that these files are included in HeidiSql v11.3, I concluded they are NOT generated by building HeidiSql. So, where did those version numbers come from?
Poking around in C:\Program Files\MySQL\MySQL Server 8.0\lib, I see a libmysql.dll there too (ProductVersion 8.0.25).
So, my guess is that HeidiSql acquired those files from builds of MySQL. And the newer one (libmysql-6.1.dll) is probably the better bet for current releases of MySQL.
That does leave open the question of where the number "6.1" came from. It doesn't appear there was ever a 6.1 release of MySQL?
And it also doesn't address which one is best for MSSQL, PostgreSQL, etc. But that wasn't the question here.
First of all, I am not sure how I came to this state. I use mySQL5.7 and I recently upgraded few dependencies for my gradle project. After the upgrade it didn't like previous comments in my database migration files. By the way I didn't change database version. Some of the comments were made without a space like bellow and it was fine before. If I add spaces after '--' it works but it's an issue with other environments to which
migration is already applied since migration files checksum is changed. Could anyone suggest me a solution? I initialize my local environment frequently and I need to make this work for all environments.
--My comments start here
Your best option is to fix your scripts, so that they contain valid MySQL syntax and then run Flyway's repair command to realign the checksums.
Back in september '17 I installed an ejabberd-instance on a (debian 9-)server my dad still pays for, but is no longer using. The small circle of friends that initially used it, quickly grew and now there's a few hundred of us chatting away.
Time has come to update the ejabberd (I installed 16.09-4) because we want to stay secure and be able to enjoy all the latest whistles and bells. I thought some simple 'apt-get upgrade'-magic would do the trick, but boy, was I wrong.
I looked at the docs (Specific version upgrade notes) and tried to update to 17.03, by following the steps described there.
These updates fail miserably (missing links to /usr/sbin/ causing failure to to restart server after update. Adding symlinks does not help. I believe I chose to install to /opt/ last year, which would explain why).
Since I have some experience with MySQL and none whatsoever with Mnesia, I also decided in the beginning to add "default_db : SQL" in my ejabberd.yml file. I (wrongly) assumed all data would be stored in a MySQL-DB, and no longer in the Mnesia. This does not seem to be the case: I see all of the registered users in Mnesia (using ejabberdctl) but only part of the complete list in MySQL.
I guess my question is twofold:
What would be the most efficient way to update from 16.09-4 to the latest version ? (I am aiming for a solution without having to install a new ejabberd-instance on a different server and simply backing up and migrating the MySQL)
How can I avoid using Mnesia completely and only use MySQL ? And, related: How can I push all existing Mnesia-data into MySQL ?
What would be the most efficient way to update from 16.09-4 to the latest version ?
As you have some kind of confusion about what and where is installed, problems in links, paths, etc, I propose as "the most efficient" a solution that has many many steps, but at least will work whatever you have:
First handle the old one:
Find your config dir and mnesia spool (try 'ejabberdctl help')
Stop ejabberd
Move to a safe location your config dir and mnesia spool
Uninstall ejabberd and all ejabberd related files and dirs
Now comes the new one:
Install ejabberd in the way you prefer: Debian package, source, whatever
Let it start, so it creates default config files and minimal mnesia spool
You can even register an account, login, check it runs correctly
Find the new config dir and mnesia spool (maybe they are different paths due to different install process)
Stop ejabberd
And now recover your old information
Replace the new config dir with old one, and the new mnesia spool with your old one
Start ejabberd again, with old config and old mnesia. It may complain about useless or unknown options, it may also report it's updating the database schema.
If it at least starts, check you have all the users, and also update the config file in case there were renamed options...
Of course, there are easier and faster ways to update, but your special case requires special steps.
How can I avoid using Mnesia completely and only use MySQL ?
Why exactly do you want to avoid it at all costs? It's required for some stuff in ejabberd, like client sessions, internal routes, commands... Other stuff can be moved to MySQL, like roster, passwd, MUC, vcards...
And, related: How can I push all existing Mnesia-data into MySQL ?
You can configure many modules to use sql instead of mnesia, and then run the export2sql command that produces a *.sql file that you will import into your new MySQL database. After that, you can delete content of mnesia tables using the WebAdmin.
I am using sphinx to index my content. I used it in my development environment (xampp) and it worked fine. Now I took it to the server (same config file), and it is giving me trouble.
I have a VPS Windows 2008 server with Plesk panel. I am the administrator. the problem is that when i run the indexer tool, it tells me that it found 0 docs and indexing 0 docs. So it seems like it is working fine as far as accessing the database, but it just doesn't find any docs. Does anyone have any ideas, I spent a whole day playing with the configuration and database with no success.
Thanks.
Well maybe the database table that sphinx is trying to index is empty?
Either way would suggest adding debug command line switches when you run indexer. Eg --verbose, --print-queries etc. They will probably give you a better clue where the problem lies.
We're currently running MySQL 5.0.36sp1, and I'd like to evaluate whether we would get any kind of performance gain in running a more recent version. Can I safely install a newer version and run it on a different port without affecting my existing instance?
Ideally, I'd be able to turn on one instance at a time, and run the same tests on each instance.
You'd have to give it a different:
port
socket
pidfile
datadir
But that's about it.
Yes it is possible. Although deprecated by 5.1, this
http://dev.mysql.com/doc/refman/5.0/en/instance-manager.html
might be the easiest solution to what you are looking for.