Comments - MariaDB versus MySQL - Compatibility

The columnstore storage engine, introduced in MariaDB 10.1, also seems to be missing at this time.

The global variable innodb_default_row_format, introduced in MySQL 5.7.9, also seems to be missing from InnoDB/XtraDB at this time.

I have installed MariaDB on fresh Ubuntu 14.04 server using apt-get and have no problems.

One month later I am prompted by the system that the following packages need to be installed:

• libmysqlclient18
• libssl1.0.0
• mysql-client
• mysql-client-5.5
• mysql-client-core-5.5
• mysql-common
• mysql-server
• mysql-server-5.5
• mysql-server-core-5.5

I am concerned these will overwrite MariaDB files (or libraries) and may downgrade my system or make the DB server inoperable.

Should I go ahead with the updates or not, and if not, is there somewhere I can tell the system that I am not using MySQL, but MariaDB.

As mentioned above the sever installed was plain vanilla Ubuntu, and only other packages added were MariaDB, PHP and Apache (and webmin). In my google searches I have not found other discussions relating to this.

Your concern is valid. Installing these packages would cause removal of MariaDB server.

Could you please specify which repository you use to install/upgrade MariaDB server? With Trusty, there are options -- MariaDB can be taken from the Ubuntu repo or from MariaDB repo. From what I see, currently Ubuntu repo contains MariaDB 5.5.39 and MySQL 5.5.40, which most likely causes the problem. MariaDB repo offers MariaDB 5.5.40 already.

But even with this version difference in the Ubuntu repo, it's not quite clear why the system forces you to install mysql* packages, could you please provide more details on how you got there? Was it a regular automatic system upgrade? Did you run apt-get install <something> and it attempted to pull mysql* as dependencies? Or was it something else?

Depending on which repo you use and which operation caused this, we'll try to suggest how to avoid it in future.

I am not sure whether I am pointing at the correct repositories, however here is my detail. Our first steps on Ubuntu install is to install webmin (perhaps this is where mysql imports are first initiated, I will ask a question on their support pages). Anyway after that is done and prior to any configuration we then install MariaDB. My commands are as follows:

apt-get install software-properties-common
apt-key adv --recv-keys --keyserver hkp:keyserver.ubuntu.com:80 0xcbcb082a1bb943db
add-apt-repository 'deb http://mirrors.hustunique.com/mariadb/repo/10.0/ubuntu trusty main'
apt-get update
apt-get install mariadb-server

The list of further updates are later reported in webmin, but presumably as a result of an apt-get update script, not through any specific script on webmins part.
I will see if I can get comment from their support.
Is it possible that something could be done by MariaDB to protect its installation?
Thanks for your quick response.

The whole thing is a bit mysterious, and I would really want to figure out what exactly is going on. Technically, you can have a similar problem during the period when MySQL 5.5.x is already in the Ubuntu repo, while MariaDB 5.5.x is not released yet. But it has not happened for a while, even for 5.5.40 -- MySQL 5.5.40 was uploaded to the Trusty repo on Oct 10, while MariaDB was released on Oct 9.

And even if you do catch the moment when the versions are different this way, apt-get upgrade just should not cause this effect. If it does, it might be a bug.

Still, assuming that somehow version mismatch is to blame, please refer to the KB page Version mismatch between MariaDB and Ubuntu/Debian Repositories. A few workarounds are described there, in your case the most suitable is probably Pinning the MariaDB repository. I cannot guarantee it will solve the problem for you, because as I said before, it's not quite clear what exactly causes it; but you can try, it shouldn't hurt.

If you have more information, please share it here or create an issue at our JIRA.

One thing which may be of relevance is that the installations were on Windows Azure and the Ubuntu was from the Windows Azure install. FWIW.

I am in the process of changing things over form MySQL to MariaDB. I am currently running MySQL 5.1.31 and have a new server that I have done a clean RPM install of MariaDB 10.0.11 . Hoping this is not too big a leap to take?

We are running Apache / PHP on separate web-servers and I would like to know if I need to change anything on them in order for them to connect properly from Apache / PHP to the MariaDB server? Not sure if I need to update or install anything on the web-servers, such as newer libmysqlclient.so.x or? If so, what RPM should I install on the web-heads and will this cause an issue with them continuing to connect to the MySQL DB server?

What I have done on the new DB server is imported a dump file of our production DB from MySQL into the new test server runningMariaDB which appears to have went good. I have already discovered that some queries that work in the MySQL DB come up empty in MariaDB. So the next question is, where can I find a list of differences/changes/deprecated items between MySQL 5.1.31 and MariaDB 10.0.11 . Or am I going to need to look at the differences noted on this page between MySQL 5.x and MariaDB 5.x and work my way towards MySQL 5.6 and MariaDB 10.0?

Thanks!!!

Yes, you can install any number of forks/versions. Install from generic Linux binaries, as explained here: https://mariadb.com/kb/en/installing-mariadb-binary-tarballs/ By running those commands, 2 different dirs will be created, so each software will have its own datadir, config files, etc. If you are going to run them together (but why?), just change the port of one for them in my.cnf. If you are going to run them separately (sounds more reasonable), just create a symlink which points to the server you are going to run, so you can always use the same scripts/menu items/guis: sudo rm /usr/local/mysql sudo ln /usr/local/mariadb-5.5 mysql

Similar steps for Windows. Use the noinstall package.

One of the easiest ways is, probably, the MySQL Sandbox: http://mysqlsandbox.net/

Is there a way that I can run MySQL and MariaDB side-by-side either on a Red Hat Linux 6 or Windows XP environment? I am using this scenario to compare and to learn both products. Thanks!!

Which one is good in terms of performance level: MySQL, MariaDB or PostgreSQL ? My application includes a map module, with self hosted map server(planning to use open street maps). Will need to query on very large sized geom tables.

I am looking at a network monitoring program called Zabbix. Instead of MySQL I wanted to use MariaDB. When I try to install Zabbix I get this error:

The following packages have unmet dependencies: zabbix-server-mysql : Depends: libmysqlclient16 (>= 5.1.21-1) but it is not installable Recommends: mysql-server (>= 4.0.16-2) Recommends: snmpd but it is not going to be installed Recommends: snmptt but it is not going to be installed E: Unable to correct problems, you have held broken packages.

Posting on the Zabbix forum yielded nothing except "use MySQL". Does anyone have any ideas?

What distribution? What version of it? What MariaDB version? Generally for libmysqlclient16 you need mariadb-5.2 or 5.3. Configure your system to use the appropriate repository.

Ubuntu 12.04LTS MariaDB I downloaded the latest version on last Thursday 5.5.

I will try an older version of MariaDB and see if that helps.

We installed MariaDB 5.5.29 over MySQL 5.5.12 - both 64 bit on Windows.

MariaDB is returning int64 instead of int32 for a literal value, i.e.

Select 103, name, address from employee;

In MySQL the 103 was being returned as an int32 value and in MariaDB it is an int64 value.

Also, we are having some strange character set issues for some fields.

We are using a rather old .net connector 6.1.2.0.

Suggestions? Thank you.

Can you check against more recent version of MySQL?

I have not tried .NET yet, however I do know it uses result set metadata to infer types. So I checked metadata, and for that I ran mysql command line client so it outputs result set metadata with (mysql --column-type-info )

"SELECT <Integer constant>" returns LONGLONG type for both MYSQL and MariaDB, that should translate to int64 if I understand correctly. I cannot comment on character set issues, because the description is not very specific.

Field 1: `1` Catalog: `def` Database: `` Table: `` Org_table: `` Type: LONGLONG Collation: binary (63) Length: 1 Max_length: 1 Decimals: 0 Flags: NOT_NULL BINARY NUM

Addendum:

I tried now also Connector/NET test (latest version of C/NET) .

I ran MySQLCommand.ExecuteScalar() for command "SELECT 1", on both MariaDB and MYSQL, both on version 5.5.31.

In both cases the object returned by ExecuteScalar was System.Int64, which I also would expect. So, I do not see incompatibilities here.

I have loaded MariaDB onto a fresh computer along with Apache and PHP. It works OK. On another computer I have an AMP system with a heap of data - MYISAM. I was hoping to be able to copy the data files across; both being MYISAM. Seems this won't work; or am I missing something?

Do I have to load MySQL onto the new computer first and then MariaDB on top of it; then data files get converted to a slightly differnt format? Thanks Paul

No, you don't. You should be able to copy MyISAM tables.

To understand why it didn't work for you I'd need more details about how exactly it "won't work". But please don't start a discussion here, send an email with the exact error message that you've got to [email protected]

First of all: I'm not sure this is the right place for questions, but I haven't found a better place.

Since replacing mysql 5.1 with MariaDB 5.5 several of my perl scripts don't work anymore.

Today I was trying to configure SPhinx with RT (Request Tracker from Best Practical), but when i launch the rt-setup-fulltext-index script I get this output:

How can I solve this problem?

Thank you in advance. Bye Cris

[email protected] would be a good place to ask questions like that.

Anyway...

It looks like your problem is not caused by MySQL->MariaDB migration, but by 5.1->5.5 migration. You would've had the same issue if you'd upgraded to MySQL-5.5.

Your DBD::mysql is linked with the old libmysqlclient library. You can either recompile it against the new client library (libmysqlclient.so.18) or install MariaDB-compat package with the 5.1-compatible client library.

Thank you Sergii for your help.
There's no MariaDB-compat in OpenIndiana's repositories. Actually I had to install MariaDB from the binary release for Solaris 10 on MariaDB web site.
I think I'll try to recompile.
Bye
Cris

If you are replacing MySQL 5.1 with MariaDB 5.2 or MariaDB 5.3 (e.g. MySQL 5.1.61, MariaDB 5.2.10 or 5.3.4 which are latest at the moment), it is wise to run mysql_upgrade even although MariaDB server includes the same MySQL version. MariaDB has a slightly different structure of mysql.event table, which causes event scheduler to be disabled on server startup, with the corresponding message in the error log file. Running mysql_upgrade and restarting the server afterwards fixes that.

While uninstalling a MySQL-server RPM and installing MariaDB-server, you can encounter some dependency errors. As of MariaDB 5.1.60, 5.2.10 and 5.3.3 RHEL RPMs comparing to MySQL 5.1.60, these dependencies are:

• perl-DBI
• libmysqlclient.so.16
• libmysqlclient_r.so.16
• libhsclient.so.0 (5.3 only)

perl-DBI is used in scripts:

• mysql_convert_table_format
• mysql_setpermission
• mysqlhotcopy

If you are not planning to use the scripts, it can be ignored. It is in fact the same for MySQL-server-5.1.60, but dependencies seem to be suppressed there; so chances are, if you did not need them before, you don't need to worry about it.

libmysqlclient_r is needed for mysqltest. If you are not going to run tests, it should not matter.

libmysqlclient is needed for mysql_upgrade. It is an important tool for server upgrades, so it is better to install the library from the MariaDB-shared package. It will resolve the previous problem, too.

libhsclient is required by HandlerSocket plugin. If you are planning to use the plugin, see installation instructions for more details; otherwise the dependency error can also be suppressed by the '--nodeps' rpm option.